You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by David E Jones <jo...@undersunconsulting.com> on 2006/11/15 23:42:05 UTC
Special Purpose (Derivative) Applications
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
Re: Special Purpose (Derivative) Applications
Posted by David E Jones <jo...@undersunconsulting.com>.
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
Re: Special Purpose (Derivative) Applications
Posted by Adrian Crum <ad...@hlmksw.com>.
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
>
>
Re: Special Purpose (Derivative) Applications
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
>>>>
>>
Re: Special Purpose (Derivative) Applications
Posted by David E Jones <jo...@undersunconsulting.com>.
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
>>>
>
Re: Special Purpose (Derivative) Applications
Posted by Jacopo Cappellato <ti...@sastau.it>.
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
>>
Re: Special Purpose (Derivative) Applications
Posted by David E Jones <jo...@undersunconsulting.com>.
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
>
Re: Special Purpose (Derivative) Applications
Posted by Anil Patel <to...@gmail.com>.
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 <ti...@sastau.it> 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
>
>
Re: Special Purpose (Derivative) Applications
Posted by Jacopo Cappellato <ti...@sastau.it>.
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