Special Purpose (Derivative) Applications

[David E Jones-2]

Just a quick note on something related to some conversations I've had  
recently (including one at the users conference), and this Jira issue:

http://issues.apache.org/jira/browse/OFBIZ-226

There seems to be some interest in creating more special purpose  
applications that are meant to be used generally by a person in a  
specific role, or that are meant to work along with the "core"  
applications but make things easier for certain activities or  
processes. We might eventually have lots of these (including this  
one), so it might be good to have a separate top level folder for  
these so that they don't have to do in the "applications" folder.

In a way this would be like the old "specialized" folder, but with a  
couple of distinctions. These components should be:

- limited in scope to a certain role or activity in an organization
- be mostly based on existing artifacts (forms, services, entities,  
etc) in the components in the applications directory
- should have enough interest from multiple parties that they will  
likely be maintained over time
- should not become personal crusades that are almost a fork of OFBiz  
itself (ie functionality should always go in the applications  
directory components and be re-used and special purposed in these add-
on components)

Some examples that people have talked about or that exist elsewhere  
would be applications for:

- Asset Maintenance (special UI pulling from Facility, Product,  
Accounting, Order, etc)
- Sales Force Automation (special UI pulling from Party, Marketing,  
Product, Order, etc)

Does anyone have any thoughts on this or what we might call it? In  
general these are aggregations of screens from the "core  
applications", plus special screens to tie things together and enable  
specific processes or activities.

-David

[Jacopo Cappellato]

David,

this sounds like a good idea.
However, the new "special purpose" components should still be focused on
a business/functional area instead of a specific platform.
For example, the upcoming "hand held" component should be a new
application, with a simplified ui suitable for hand held devices, to
manage warehouse tasks; if we will need an hand held ui for, let's say,
workeffort tasks, this will go into a different component: we should
avoid to create a new component based ona specific platform, e.g. hend
held version of OFBiz in one big component.

Should we consider the POS a good candidate for this new group?

And last but not least, I think that these extensions should be
considered 'official' OFBiz components, and the decisions about them
will be taken in the same way they are taken from the components in the
application folder (not like the ones in the specialized folder).

Jacopo

David E Jones wrote:

>
> Just a quick note on something related to some conversations I've had
> recently (including one at the users conference), and this Jira issue:
>
> http://issues.apache.org/jira/browse/OFBIZ-226
>
> There seems to be some interest in creating more special purpose
> applications that are meant to be used generally by a person in a
> specific role, or that are meant to work along with the "core"
> applications but make things easier for certain activities or processes.
> We might eventually have lots of these (including this one), so it might
> be good to have a separate top level folder for these so that they don't
> have to do in the "applications" folder.
>
> In a way this would be like the old "specialized" folder, but with a
> couple of distinctions. These components should be:
>
> - limited in scope to a certain role or activity in an organization
> - be mostly based on existing artifacts (forms, services, entities, etc)
> in the components in the applications directory
> - should have enough interest from multiple parties that they will
> likely be maintained over time
> - should not become personal crusades that are almost a fork of OFBiz
> itself (ie functionality should always go in the applications directory
> components and be re-used and special purposed in these add-on components)
>
> Some examples that people have talked about or that exist elsewhere
> would be applications for:
>
> - Asset Maintenance (special UI pulling from Facility, Product,
> Accounting, Order, etc)
> - Sales Force Automation (special UI pulling from Party, Marketing,
> Product, Order, etc)
>
> Does anyone have any thoughts on this or what we might call it? In
> general these are aggregations of screens from the "core applications",
> plus special screens to tie things together and enable specific
> processes or activities.
>
> -David

[Anil Patel]

I have created Issue for Asset Maintenance application.

http://issues.apache.org/jira/browse/OFBIZ-437

We have this application running in testing/user acceptance phase. Is it
possible to use this application as Pilot project?

Regards
Anil Patel


On 11/15/06, Jacopo Cappellato <[hidden email]> wrote:

>
> David,
>
> this sounds like a good idea.
> However, the new "special purpose" components should still be focused on
> a business/functional area instead of a specific platform.
> For example, the upcoming "hand held" component should be a new
> application, with a simplified ui suitable for hand held devices, to
> manage warehouse tasks; if we will need an hand held ui for, let's say,
> workeffort tasks, this will go into a different component: we should
> avoid to create a new component based ona specific platform, e.g. hend
> held version of OFBiz in one big component.
>
> Should we consider the POS a good candidate for this new group?
>
> And last but not least, I think that these extensions should be
> considered 'official' OFBiz components, and the decisions about them
> will be taken in the same way they are taken from the components in the
> application folder (not like the ones in the specialized folder).
>
> Jacopo
>
> David E Jones wrote:
> >
> > Just a quick note on something related to some conversations I've had
> > recently (including one at the users conference), and this Jira issue:
> >
> > http://issues.apache.org/jira/browse/OFBIZ-226
> >
> > There seems to be some interest in creating more special purpose
> > applications that are meant to be used generally by a person in a
> > specific role, or that are meant to work along with the "core"
> > applications but make things easier for certain activities or processes.
> > We might eventually have lots of these (including this one), so it might
> > be good to have a separate top level folder for these so that they don't
> > have to do in the "applications" folder.
> >
> > In a way this would be like the old "specialized" folder, but with a
> > couple of distinctions. These components should be:
> >
> > - limited in scope to a certain role or activity in an organization
> > - be mostly based on existing artifacts (forms, services, entities, etc)
> > in the components in the applications directory
> > - should have enough interest from multiple parties that they will
> > likely be maintained over time
> > - should not become personal crusades that are almost a fork of OFBiz
> > itself (ie functionality should always go in the applications directory
> > components and be re-used and special purposed in these add-on
> components)
> >
> > Some examples that people have talked about or that exist elsewhere
> > would be applications for:
> >
> > - Asset Maintenance (special UI pulling from Facility, Product,
> > Accounting, Order, etc)
> > - Sales Force Automation (special UI pulling from Party, Marketing,
> > Product, Order, etc)
> >
> > Does anyone have any thoughts on this or what we might call it? In
> > general these are aggregations of screens from the "core applications",
> > plus special screens to tie things together and enable specific
> > processes or activities.
> >
> > -David
>
>

[Adrian Crum]

Another role-oriented app would be human resources.

I have done a lot of role-oriented development here. I would be more than happy
to help out.


David E Jones wrote:

>
> Just a quick note on something related to some conversations I've had  
> recently (including one at the users conference), and this Jira issue:
>
> http://issues.apache.org/jira/browse/OFBIZ-226
>
> There seems to be some interest in creating more special purpose  
> applications that are meant to be used generally by a person in a  
> specific role, or that are meant to work along with the "core"  
> applications but make things easier for certain activities or  
> processes. We might eventually have lots of these (including this  one),
> so it might be good to have a separate top level folder for  these so
> that they don't have to do in the "applications" folder.
>
> In a way this would be like the old "specialized" folder, but with a  
> couple of distinctions. These components should be:
>
> - limited in scope to a certain role or activity in an organization
> - be mostly based on existing artifacts (forms, services, entities,  
> etc) in the components in the applications directory
> - should have enough interest from multiple parties that they will  
> likely be maintained over time
> - should not become personal crusades that are almost a fork of OFBiz  
> itself (ie functionality should always go in the applications  directory
> components and be re-used and special purposed in these add- on components)
>
> Some examples that people have talked about or that exist elsewhere  
> would be applications for:
>
> - Asset Maintenance (special UI pulling from Facility, Product,  
> Accounting, Order, etc)
> - Sales Force Automation (special UI pulling from Party, Marketing,  
> Product, Order, etc)
>
> Does anyone have any thoughts on this or what we might call it? In  
> general these are aggregations of screens from the "core  applications",
> plus special screens to tie things together and enable  specific
> processes or activities.
>
> -David
>
>

[David E Jones-2]

On Nov 15, 2006, at 11:41 PM, Jacopo Cappellato wrote:

> David,
>
> this sounds like a good idea.
> However, the new "special purpose" components should still be  
> focused on a business/functional area instead of a specific platform.
> For example, the upcoming "hand held" component should be a new  
> application, with a simplified ui suitable for hand held devices,  
> to manage warehouse tasks; if we will need an hand held ui for,  
> let's say, workeffort tasks, this will go into a different  
> component: we should avoid to create a new component based ona  
> specific platform, e.g. hend held version of OFBiz in one big  
> component.
>
> Should we consider the POS a good candidate for this new group?

Yes, that's a good distinction. The new hand held application would  
be in this group because it is a special purpose or role oriented  
application for certain warehouse management tasks, and not because  
it is a hand held application instead of an HTML one.

And yes, we should probably move the pos component because it would  
fit in the category of a special purpose add-on applications.

> And last but not least, I think that these extensions should be  
> considered 'official' OFBiz components, and the decisions about  
> them will be taken in the same way they are taken from the  
> components in the application folder (not like the ones in the  
> specialized folder).

Yes, very much so. That is why I mentioned the sufficient interest  
and certain other points. We don't want these getting separated and  
falling off like the specialized apps did. These are a bit different  
in intent, so hopefully this won't be a problem.

-David

> Jacopo
>
> David E Jones wrote:
>> Just a quick note on something related to some conversations I've  
>> had recently (including one at the users conference), and this  
>> Jira issue:
>> http://issues.apache.org/jira/browse/OFBIZ-226
>> There seems to be some interest in creating more special purpose  
>> applications that are meant to be used generally by a person in a  
>> specific role, or that are meant to work along with the "core"  
>> applications but make things easier for certain activities or  
>> processes. We might eventually have lots of these (including this  
>> one), so it might be good to have a separate top level folder for  
>> these so that they don't have to do in the "applications" folder.
>> In a way this would be like the old "specialized" folder, but with  
>> a couple of distinctions. These components should be:
>> - limited in scope to a certain role or activity in an organization
>> - be mostly based on existing artifacts (forms, services,  
>> entities, etc) in the components in the applications directory
>> - should have enough interest from multiple parties that they will  
>> likely be maintained over time
>> - should not become personal crusades that are almost a fork of  
>> OFBiz itself (ie functionality should always go in the  
>> applications directory components and be re-used and special  
>> purposed in these add-on components)
>> Some examples that people have talked about or that exist  
>> elsewhere would be applications for:
>> - Asset Maintenance (special UI pulling from Facility, Product,  
>> Accounting, Order, etc)
>> - Sales Force Automation (special UI pulling from Party,  
>> Marketing, Product, Order, etc)
>> Does anyone have any thoughts on this or what we might call it? In  
>> general these are aggregations of screens from the "core  
>> applications", plus special screens to tie things together and  
>> enable specific processes or activities.
>> -David
>

[David E Jones-2]

Human resources should start out as a generic application like the  
others in OFBiz, and perhaps variations on it after the basic stuff  
is developed would make sense as special purpose add-on apps. As I  
mentioned these special purpose apps should whenever possible reuse  
resources in the generic applications, so naturally the generic  
application needs to exist first.

-David


On Nov 16, 2006, at 9:20 AM, Adrian Crum wrote:

> Another role-oriented app would be human resources.
>
> I have done a lot of role-oriented development here. I would be  
> more than happy to help out.
>
>
> David E Jones wrote:
>> Just a quick note on something related to some conversations I've  
>> had  recently (including one at the users conference), and this  
>> Jira issue:
>> http://issues.apache.org/jira/browse/OFBIZ-226
>> There seems to be some interest in creating more special purpose  
>> applications that are meant to be used generally by a person in a  
>> specific role, or that are meant to work along with the "core"  
>> applications but make things easier for certain activities or  
>> processes. We might eventually have lots of these (including this  
>> one), so it might be good to have a separate top level folder for  
>> these so that they don't have to do in the "applications" folder.
>> In a way this would be like the old "specialized" folder, but with  
>> a  couple of distinctions. These components should be:
>> - limited in scope to a certain role or activity in an organization
>> - be mostly based on existing artifacts (forms, services,  
>> entities,  etc) in the components in the applications directory
>> - should have enough interest from multiple parties that they  
>> will  likely be maintained over time
>> - should not become personal crusades that are almost a fork of  
>> OFBiz  itself (ie functionality should always go in the  
>> applications  directory components and be re-used and special  
>> purposed in these add- on components)
>> Some examples that people have talked about or that exist  
>> elsewhere  would be applications for:
>> - Asset Maintenance (special UI pulling from Facility, Product,  
>> Accounting, Order, etc)
>> - Sales Force Automation (special UI pulling from Party,  
>> Marketing,  Product, Order, etc)
>> Does anyone have any thoughts on this or what we might call it?  
>> In  general these are aggregations of screens from the "core  
>> applications", plus special screens to tie things together and  
>> enable  specific processes or activities.
>> -David

[Jacopo Cappellato]

That's great.
David, if you'll have the time to setup things in the repository to
support this new kind of stuff (e.g. a new folder and new component-load
xml file etc.) I'll take care of importing there the hend held application.
Jacopo


David E Jones wrote:

>
> On Nov 15, 2006, at 11:41 PM, Jacopo Cappellato wrote:
>
>> David,
>>
>> this sounds like a good idea.
>> However, the new "special purpose" components should still be focused
>> on a business/functional area instead of a specific platform.
>> For example, the upcoming "hand held" component should be a new
>> application, with a simplified ui suitable for hand held devices, to
>> manage warehouse tasks; if we will need an hand held ui for, let's
>> say, workeffort tasks, this will go into a different component: we
>> should avoid to create a new component based ona specific platform,
>> e.g. hend held version of OFBiz in one big component.
>>
>> Should we consider the POS a good candidate for this new group?
>
> Yes, that's a good distinction. The new hand held application would be
> in this group because it is a special purpose or role oriented
> application for certain warehouse management tasks, and not because it
> is a hand held application instead of an HTML one.
>
> And yes, we should probably move the pos component because it would fit
> in the category of a special purpose add-on applications.
>
>> And last but not least, I think that these extensions should be
>> considered 'official' OFBiz components, and the decisions about them
>> will be taken in the same way they are taken from the components in
>> the application folder (not like the ones in the specialized folder).
>
> Yes, very much so. That is why I mentioned the sufficient interest and
> certain other points. We don't want these getting separated and falling
> off like the specialized apps did. These are a bit different in intent,
> so hopefully this won't be a problem.
>
> -David
>
>
>> Jacopo
>>
>> David E Jones wrote:
>>> Just a quick note on something related to some conversations I've had
>>> recently (including one at the users conference), and this Jira issue:
>>> http://issues.apache.org/jira/browse/OFBIZ-226
>>> There seems to be some interest in creating more special purpose
>>> applications that are meant to be used generally by a person in a
>>> specific role, or that are meant to work along with the "core"
>>> applications but make things easier for certain activities or
>>> processes. We might eventually have lots of these (including this
>>> one), so it might be good to have a separate top level folder for
>>> these so that they don't have to do in the "applications" folder.
>>> In a way this would be like the old "specialized" folder, but with a
>>> couple of distinctions. These components should be:
>>> - limited in scope to a certain role or activity in an organization
>>> - be mostly based on existing artifacts (forms, services, entities,
>>> etc) in the components in the applications directory
>>> - should have enough interest from multiple parties that they will
>>> likely be maintained over time
>>> - should not become personal crusades that are almost a fork of OFBiz
>>> itself (ie functionality should always go in the applications
>>> directory components and be re-used and special purposed in these
>>> add-on components)
>>> Some examples that people have talked about or that exist elsewhere
>>> would be applications for:
>>> - Asset Maintenance (special UI pulling from Facility, Product,
>>> Accounting, Order, etc)
>>> - Sales Force Automation (special UI pulling from Party, Marketing,
>>> Product, Order, etc)
>>> Does anyone have any thoughts on this or what we might call it? In
>>> general these are aggregations of screens from the "core
>>> applications", plus special screens to tie things together and enable
>>> specific processes or activities.
>>> -David
>>

[David E Jones-2]

Okay, it should all be in place in SVN rev 476486, including moving  
the pos component and getting build.xml and component-load.xml files  
in place and such.

-David


On Nov 18, 2006, at 12:43 AM, Jacopo Cappellato wrote:

> That's great.
> David, if you'll have the time to setup things in the repository to  
> support this new kind of stuff (e.g. a new folder and new component-
> load xml file etc.) I'll take care of importing there the hend held  
> application.
> Jacopo
>
>
> David E Jones wrote:
>> On Nov 15, 2006, at 11:41 PM, Jacopo Cappellato wrote:
>>> David,
>>>
>>> this sounds like a good idea.
>>> However, the new "special purpose" components should still be  
>>> focused on a business/functional area instead of a specific  
>>> platform.
>>> For example, the upcoming "hand held" component should be a new  
>>> application, with a simplified ui suitable for hand held devices,  
>>> to manage warehouse tasks; if we will need an hand held ui for,  
>>> let's say, workeffort tasks, this will go into a different  
>>> component: we should avoid to create a new component based ona  
>>> specific platform, e.g. hend held version of OFBiz in one big  
>>> component.
>>>
>>> Should we consider the POS a good candidate for this new group?
>> Yes, that's a good distinction. The new hand held application  
>> would be in this group because it is a special purpose or role  
>> oriented application for certain warehouse management tasks, and  
>> not because it is a hand held application instead of an HTML one.
>> And yes, we should probably move the pos component because it  
>> would fit in the category of a special purpose add-on applications.
>>> And last but not least, I think that these extensions should be  
>>> considered 'official' OFBiz components, and the decisions about  
>>> them will be taken in the same way they are taken from the  
>>> components in the application folder (not like the ones in the  
>>> specialized folder).
>> Yes, very much so. That is why I mentioned the sufficient interest  
>> and certain other points. We don't want these getting separated  
>> and falling off like the specialized apps did. These are a bit  
>> different in intent, so hopefully this won't be a problem.
>> -David
>>> Jacopo
>>>
>>> David E Jones wrote:
>>>> Just a quick note on something related to some conversations  
>>>> I've had recently (including one at the users conference), and  
>>>> this Jira issue:
>>>> http://issues.apache.org/jira/browse/OFBIZ-226
>>>> There seems to be some interest in creating more special purpose  
>>>> applications that are meant to be used generally by a person in  
>>>> a specific role, or that are meant to work along with the "core"  
>>>> applications but make things easier for certain activities or  
>>>> processes. We might eventually have lots of these (including  
>>>> this one), so it might be good to have a separate top level  
>>>> folder for these so that they don't have to do in the  
>>>> "applications" folder.
>>>> In a way this would be like the old "specialized" folder, but  
>>>> with a couple of distinctions. These components should be:
>>>> - limited in scope to a certain role or activity in an organization
>>>> - be mostly based on existing artifacts (forms, services,  
>>>> entities, etc) in the components in the applications directory
>>>> - should have enough interest from multiple parties that they  
>>>> will likely be maintained over time
>>>> - should not become personal crusades that are almost a fork of  
>>>> OFBiz itself (ie functionality should always go in the  
>>>> applications directory components and be re-used and special  
>>>> purposed in these add-on components)
>>>> Some examples that people have talked about or that exist  
>>>> elsewhere would be applications for:
>>>> - Asset Maintenance (special UI pulling from Facility, Product,  
>>>> Accounting, Order, etc)
>>>> - Sales Force Automation (special UI pulling from Party,  
>>>> Marketing, Product, Order, etc)
>>>> Does anyone have any thoughts on this or what we might call it?  
>>>> In general these are aggregations of screens from the "core  
>>>> applications", plus special screens to tie things together and  
>>>> enable specific processes or activities.
>>>> -David
>>>
>

[Jacopo Cappellato]

David,

that's really great!
It looks like you did a lot of work to setup this thing, thanks!

Jacopo

David E Jones wrote:

>
> Okay, it should all be in place in SVN rev 476486, including moving the
> pos component and getting build.xml and component-load.xml files in
> place and such.
>
> -David
>
>
> On Nov 18, 2006, at 12:43 AM, Jacopo Cappellato wrote:
>
>> That's great.
>> David, if you'll have the time to setup things in the repository to
>> support this new kind of stuff (e.g. a new folder and new
>> component-load xml file etc.) I'll take care of importing there the
>> hend held application.
>> Jacopo
>>
>>
>> David E Jones wrote:
>>> On Nov 15, 2006, at 11:41 PM, Jacopo Cappellato wrote:
>>>> David,
>>>>
>>>> this sounds like a good idea.
>>>> However, the new "special purpose" components should still be
>>>> focused on a business/functional area instead of a specific platform.
>>>> For example, the upcoming "hand held" component should be a new
>>>> application, with a simplified ui suitable for hand held devices, to
>>>> manage warehouse tasks; if we will need an hand held ui for, let's
>>>> say, workeffort tasks, this will go into a different component: we
>>>> should avoid to create a new component based ona specific platform,
>>>> e.g. hend held version of OFBiz in one big component.
>>>>
>>>> Should we consider the POS a good candidate for this new group?
>>> Yes, that's a good distinction. The new hand held application would
>>> be in this group because it is a special purpose or role oriented
>>> application for certain warehouse management tasks, and not because
>>> it is a hand held application instead of an HTML one.
>>> And yes, we should probably move the pos component because it would
>>> fit in the category of a special purpose add-on applications.
>>>> And last but not least, I think that these extensions should be
>>>> considered 'official' OFBiz components, and the decisions about them
>>>> will be taken in the same way they are taken from the components in
>>>> the application folder (not like the ones in the specialized folder).
>>> Yes, very much so. That is why I mentioned the sufficient interest
>>> and certain other points. We don't want these getting separated and
>>> falling off like the specialized apps did. These are a bit different
>>> in intent, so hopefully this won't be a problem.
>>> -David
>>>> Jacopo
>>>>
>>>> David E Jones wrote:
>>>>> Just a quick note on something related to some conversations I've
>>>>> had recently (including one at the users conference), and this Jira
>>>>> issue:
>>>>> http://issues.apache.org/jira/browse/OFBIZ-226
>>>>> There seems to be some interest in creating more special purpose
>>>>> applications that are meant to be used generally by a person in a
>>>>> specific role, or that are meant to work along with the "core"
>>>>> applications but make things easier for certain activities or
>>>>> processes. We might eventually have lots of these (including this
>>>>> one), so it might be good to have a separate top level folder for
>>>>> these so that they don't have to do in the "applications" folder.
>>>>> In a way this would be like the old "specialized" folder, but with
>>>>> a couple of distinctions. These components should be:
>>>>> - limited in scope to a certain role or activity in an organization
>>>>> - be mostly based on existing artifacts (forms, services, entities,
>>>>> etc) in the components in the applications directory
>>>>> - should have enough interest from multiple parties that they will
>>>>> likely be maintained over time
>>>>> - should not become personal crusades that are almost a fork of
>>>>> OFBiz itself (ie functionality should always go in the applications
>>>>> directory components and be re-used and special purposed in these
>>>>> add-on components)
>>>>> Some examples that people have talked about or that exist elsewhere
>>>>> would be applications for:
>>>>> - Asset Maintenance (special UI pulling from Facility, Product,
>>>>> Accounting, Order, etc)
>>>>> - Sales Force Automation (special UI pulling from Party, Marketing,
>>>>> Product, Order, etc)
>>>>> Does anyone have any thoughts on this or what we might call it? In
>>>>> general these are aggregations of screens from the "core
>>>>> applications", plus special screens to tie things together and
>>>>> enable specific processes or activities.
>>>>> -David
>>>>
>>