Issue with a framework dependency on the Party component

[Jacopo Cappellato-4]

Hi Hans (all),

I am trying to run a "framework" only distribution of OFBiz (i.e. I  
have removed the specialpurpose and applications folders), it builds  
and loads succesfully but when I try to point my browser to the  
webtools application I get an error caused by the following code in  
the actions section of the GlobalDecorator (defined in the common  
component):

                 <entity-one entity-name="PartyAcctgPrefAndGroup"  
value-name="orgParty">
                     <field-map field-name="partyId" env-
name="defaultOrganizationPartyId"/>
                 </entity-one>
                 <set field="defaultOrganizationPartyCurrencyUomId"  
from-field="orgParty.baseCurrencyUomId" default-
value="defaultCurrencyUomId" global="true"/>
                 <set field="defaultOrganizationPartyGroupName" from-
field="orgParty.groupName" global="true"/>

Hans, I think you added this code but we have to find a different  
approach and resolve this dependency... would you mind having a look?  
Or do you think we can just remove (or comment out) these lines for now?

Cheers,

Jacopo

[Hans Bakker]

Hi Jacopo,

i think the only way to solve any framework dependency on application
components is the introduction of a common-application-decorator and
related files. All applications should use that decorator which then
uses the common decorator.

Because the party component is required for all other application
components, i would suggest to put that in the party component.

by the way i did a scan on "partyId" in the framework and got 268
hits....so sure this is not the only one?

Regards,
Hans

On Sun, 2009-01-25 at 20:00 +0100, Jacopo Cappellato wrote:

> Hi Hans (all),
>
> I am trying to run a "framework" only distribution of OFBiz (i.e. I  
> have removed the specialpurpose and applications folders), it builds  
> and loads succesfully but when I try to point my browser to the  
> webtools application I get an error caused by the following code in  
> the actions section of the GlobalDecorator (defined in the common  
> component):
>
>                  <entity-one entity-name="PartyAcctgPrefAndGroup"  
> value-name="orgParty">
>                      <field-map field-name="partyId" env-
> name="defaultOrganizationPartyId"/>
>                  </entity-one>
>                  <set field="defaultOrganizationPartyCurrencyUomId"  
> from-field="orgParty.baseCurrencyUomId" default-
> value="defaultCurrencyUomId" global="true"/>
>                  <set field="defaultOrganizationPartyGroupName" from-
> field="orgParty.groupName" global="true"/>
>
> Hans, I think you added this code but we have to find a different  
> approach and resolve this dependency... would you mind having a look?  
> Or do you think we can just remove (or comment out) these lines for now?
>
> Cheers,
>
> Jacopo
>

--
http://www.antwebsystems.com :
Quality OFBiz support for competitive rates....

[David E Jones-3]

On Jan 25, 2009, at 6:31 PM, Hans Bakker wrote:

> Hi Jacopo,
>
> i think the only way to solve any framework dependency on application
> components is the introduction of a common-application-decorator and
> related files. All applications should use that decorator which then
> uses the common decorator.
>
> Because the party component is required for all other application
> components, i would suggest to put that in the party component.

There are various things in the framework now that have general  
infrastructure that applications can "plugin" to, and I think we could  
follow that same pattern here.

It's a bit different for portal, themes, extended entities, etc, etc,  
and I guess the most similar thing to this might be the lists of CSS  
and JS files to include. Like those we could have a list of  
"headerlets" that are super-small templates that will be included in  
the header. Decorators in different places can include the  
"headerlets" desired for that application, and it is a simple means to  
allow independence from the framework.

> by the way i did a scan on "partyId" in the framework and got 268
> hits....so sure this is not the only one?

Yes, this is a travesty, and that is why I complain about it so much.  
There are a few people who either don't understand the concept of  
framework independence, or who do not agree with it, or for whatever  
reason have not tried to stick to it. It makes the framework messy,  
and I guess the applications moreso too, when anyone does this, and it  
may also by hiding a lot of code and design problems too.

Are you saying that we should be harder on commits that break this  
pattern? If so, I agree. We should request commit reverts whenever  
this is broken. I usually try to complain and convince people (as you  
know) by trying to explain reasons and effects of doing things, but it  
often doesn't work and only rarely am I up for a fight.

Of course, that doesn't mean I won't come along and clean it up  
quietly at some point after things have quieted down... ;)

Taking a look at the search results for party in the framework it is  
easy to spot features that break this and that code, l10n labels,  
configuration files/settings, data, templates, etc that need to be  
moved. Even old things that may not be used much any more, like the  
EntityPermissionChecker, that needs to go into securityext in the  
applications (or somewhere in applications).

-David

> On Sun, 2009-01-25 at 20:00 +0100, Jacopo Cappellato wrote:
>> Hi Hans (all),
>>
>> I am trying to run a "framework" only distribution of OFBiz (i.e. I
>> have removed the specialpurpose and applications folders), it builds
>> and loads succesfully but when I try to point my browser to the
>> webtools application I get an error caused by the following code in
>> the actions section of the GlobalDecorator (defined in the common
>> component):
>>
>>                 <entity-one entity-name="PartyAcctgPrefAndGroup"
>> value-name="orgParty">
>>                     <field-map field-name="partyId" env-
>> name="defaultOrganizationPartyId"/>
>>                 </entity-one>
>>                 <set field="defaultOrganizationPartyCurrencyUomId"
>> from-field="orgParty.baseCurrencyUomId" default-
>> value="defaultCurrencyUomId" global="true"/>
>>                 <set field="defaultOrganizationPartyGroupName" from-
>> field="orgParty.groupName" global="true"/>
>>
>> Hans, I think you added this code but we have to find a different
>> approach and resolve this dependency... would you mind having a look?
>> Or do you think we can just remove (or comment out) these lines for  
>> now?
>>
>> Cheers,
>>
>> Jacopo
>>
>
> --
> http://www.antwebsystems.com :
> Quality OFBiz support for competitive rates....
>

[Hans Bakker]

David,

see below....

On Sun, 2009-01-25 at 23:00 -0700, David E Jones wrote:
> ....
> There are various things in the framework now that have general  
> infrastructure that applications can "plugin" to, and I think we could  
> follow that same pattern here.

if you can tell me how to insert 'action' and 'widget' statements in the
common/widget/commonscreens.xml decorators from a lower level component,
I am very happy to do that.

regards,
Hans

--
http://www.antwebsystems.com :
Quality OFBiz support for competitive rates....

[David E Jones-3]

On Jan 26, 2009, at 1:53 AM, Hans Bakker wrote:

> David,
>
> see below....
>
> On Sun, 2009-01-25 at 23:00 -0700, David E Jones wrote:
>> ....
>> There are various things in the framework now that have general
>> infrastructure that applications can "plugin" to, and I think we  
>> could
>> follow that same pattern here.
>
> if you can tell me how to insert 'action' and 'widget' statements in  
> the
> common/widget/commonscreens.xml decorators from a lower level  
> component,
> I am very happy to do that.

The main tool to combine actions and widgets is the screen widget, so  
including screens would be the natural way to get this information  
shown in the header. In a way the header is too big right now anyway,  
ie the code is all in one big block and such, and it would be nice to  
have it more parameterized and organized, and easier to customize...  
perhaps even with preferences and what what (seems to be the general  
direction we're going).

What I was saying about the CSS and JS files is that we have a list of  
those files to include for those, and for things to go in the header  
we could create a similar list of screens to include, and just loop  
through it (in the header.ftl file) and include each one using the  
screens.include thingy. These would just be little informational  
screenlets to show stuff in the header, just like these things you've  
added (ie the organization party, even others like the currency, etc).

I hope that helps.

-David

[Adrian Crum]

Or we could add more sections to the global decorator.

-Adrian

David E Jones wrote:

>
> On Jan 26, 2009, at 1:53 AM, Hans Bakker wrote:
>
>> David,
>>
>> see below....
>>
>> On Sun, 2009-01-25 at 23:00 -0700, David E Jones wrote:
>>> ....
>>> There are various things in the framework now that have general
>>> infrastructure that applications can "plugin" to, and I think we could
>>> follow that same pattern here.
>>
>> if you can tell me how to insert 'action' and 'widget' statements in the
>> common/widget/commonscreens.xml decorators from a lower level component,
>> I am very happy to do that.
>
> The main tool to combine actions and widgets is the screen widget, so
> including screens would be the natural way to get this information shown
> in the header. In a way the header is too big right now anyway, ie the
> code is all in one big block and such, and it would be nice to have it
> more parameterized and organized, and easier to customize... perhaps
> even with preferences and what what (seems to be the general direction
> we're going).
>
> What I was saying about the CSS and JS files is that we have a list of
> those files to include for those, and for things to go in the header we
> could create a similar list of screens to include, and just loop through
> it (in the header.ftl file) and include each one using the
> screens.include thingy. These would just be little informational
> screenlets to show stuff in the header, just like these things you've
> added (ie the organization party, even others like the currency, etc).
>
> I hope that helps.
>
> -David
>
>
>

[Hans Bakker]

David,

ok i understand, however that means we have to asd the retrieval/display
of the logged in party/defaultOrganizationParty in every application
component?

i still think there is a need for an application-decorator between the
application and the global-decorator.

Regards,
Hans

On Mon, 2009-01-26 at 12:33 -0700, David E Jones wrote:

> On Jan 26, 2009, at 1:53 AM, Hans Bakker wrote:
>
> > David,
> >
> > see below....
> >
> > On Sun, 2009-01-25 at 23:00 -0700, David E Jones wrote:
> >> ....
> >> There are various things in the framework now that have general
> >> infrastructure that applications can "plugin" to, and I think we  
> >> could
> >> follow that same pattern here.
> >
> > if you can tell me how to insert 'action' and 'widget' statements in  
> > the
> > common/widget/commonscreens.xml decorators from a lower level  
> > component,
> > I am very happy to do that.
>
> The main tool to combine actions and widgets is the screen widget, so  
> including screens would be the natural way to get this information  
> shown in the header. In a way the header is too big right now anyway,  
> ie the code is all in one big block and such, and it would be nice to  
> have it more parameterized and organized, and easier to customize...  
> perhaps even with preferences and what what (seems to be the general  
> direction we're going).
>
> What I was saying about the CSS and JS files is that we have a list of  
> those files to include for those, and for things to go in the header  
> we could create a similar list of screens to include, and just loop  
> through it (in the header.ftl file) and include each one using the  
> screens.include thingy. These would just be little informational  
> screenlets to show stuff in the header, just like these things you've  
> added (ie the organization party, even others like the currency, etc).
>
> I hope that helps.
>
> -David
>

--
http://www.antwebsystems.com :
Quality OFBiz support for competitive rates....

[David E Jones-3]

On Jan 26, 2009, at 8:27 PM, Hans Bakker wrote:

> David,
>
> ok i understand, however that means we have to asd the retrieval/
> display
> of the logged in party/defaultOrganizationParty in every application
> component?

Yes, each component would need to have a few lines in the actions of  
the screen def for the "main-decorator" screen (I think always called  
that, and always in the CommonScreens.xml file). It would be just like  
the labels files thingy, ie with a list of set operations.

> i still think there is a need for an application-decorator between the
> application and the global-decorator.

You're right, there is no such thing right now. If it is too much of a  
pain to maintain these things in the various main-decorator screens it  
might make sense.

This would be a good part of the applications common component  
(something like appcommon to be different from the framework/common  
component) that Jacopo proposed. However, doing anything like this,  
wherever we do it, does lead a very funny dependency issue and if we  
did it in the appcommon component: the appcommon component would  
depend on various other applications components, AND those other  
applications components would depend on the appcommon component (ie a  
circular dependency)...

I guess if there is anything I dislike more than redundancy it is  
circular dependencies... but maybe the circular dependencies won't  
cause us any problems in this case...

-David

> On Mon, 2009-01-26 at 12:33 -0700, David E Jones wrote:
>> On Jan 26, 2009, at 1:53 AM, Hans Bakker wrote:
>>
>>> David,
>>>
>>> see below....
>>>
>>> On Sun, 2009-01-25 at 23:00 -0700, David E Jones wrote:
>>>> ....
>>>> There are various things in the framework now that have general
>>>> infrastructure that applications can "plugin" to, and I think we
>>>> could
>>>> follow that same pattern here.
>>>
>>> if you can tell me how to insert 'action' and 'widget' statements in
>>> the
>>> common/widget/commonscreens.xml decorators from a lower level
>>> component,
>>> I am very happy to do that.
>>
>> The main tool to combine actions and widgets is the screen widget, so
>> including screens would be the natural way to get this information
>> shown in the header. In a way the header is too big right now anyway,
>> ie the code is all in one big block and such, and it would be nice to
>> have it more parameterized and organized, and easier to customize...
>> perhaps even with preferences and what what (seems to be the general
>> direction we're going).
>>
>> What I was saying about the CSS and JS files is that we have a list  
>> of
>> those files to include for those, and for things to go in the header
>> we could create a similar list of screens to include, and just loop
>> through it (in the header.ftl file) and include each one using the
>> screens.include thingy. These would just be little informational
>> screenlets to show stuff in the header, just like these things you've
>> added (ie the organization party, even others like the currency,  
>> etc).
>>
>> I hope that helps.
>>
>> -David
>>
>
> --
> http://www.antwebsystems.com :
> Quality OFBiz support for competitive rates....
>

[Adrian Crum]

David E Jones wrote:

> This would be a good part of the applications common component
> (something like appcommon to be different from the framework/common
> component) that Jacopo proposed. However, doing anything like this,
> wherever we do it, does lead a very funny dependency issue and if we did
> it in the appcommon component: the appcommon component would depend on
> various other applications components, AND those other applications
> components would depend on the appcommon component (ie a circular
> dependency)...
>
> I guess if there is anything I dislike more than redundancy it is
> circular dependencies... but maybe the circular dependencies won't cause
> us any problems in this case...

There are circular dependencies within the framework that revolve around
the common component. As long as the appcommon-induced circular
dependencies are limited to the applications folder, I don't see a
problem with it.

-Adrian

[Adam Heath-2]

David E Jones wrote:
>> by the way i did a scan on "partyId" in the framework and got 268
>> hits....so sure this is not the only one?
>
> Yes, this is a travesty, and that is why I complain about it so much.
> There are a few people who either don't understand the concept of
> framework independence, or who do not agree with it, or for whatever
> reason have not tried to stick to it. It makes the framework messy, and
> I guess the applications moreso too, when anyone does this, and it may
> also by hiding a lot of code and design problems too.

I am a few days behind, but here is my take on this problem.

Move Party/PartyType to framework; leave Person/PartyGroup in
applications/party(along with the seed data).  The framework then just
deals with some abstract party, it has no idea what the exact kind of
party it is dealiing with.

Party is a *very* low-level critical entity; I don't think we can get
away from not requiring it in framework.

[Jacopo Cappellato-4]

On Jan 29, 2009, at 11:56 PM, Adam Heath wrote:

>
> I am a few days behind, but here is my take on this problem.
>
> Move Party/PartyType to framework; leave Person/PartyGroup in
> applications/party(along with the seed data).  The framework then just
> deals with some abstract party, it has no idea what the exact kind of
> party it is dealiing with.
>
> Party is a *very* low-level critical entity; I don't think we can get
> away from not requiring it in framework.

This is an interesting idea, but I am not sure we will have to go in  
this direction.
I'd suggest to try to live without it, and postpone the decision.
In the meantime we may move the common "ERP-oriented" resources to an  
"applications/appcommon" (another name could be "commonext", to use  
the same pattern used for security/securityext and entity/entityext)  
component and leave the common "framework-oriented" ones in the  
"framework/common" component.
Well, initially we should just move to the "applications/appcommon"  
component the resources that are causing a dependency from the  
framework to the applications.

Jacopo

[David E Jones-3]

On Jan 30, 2009, at 1:10 AM, Jacopo Cappellato wrote:

> On Jan 29, 2009, at 11:56 PM, Adam Heath wrote:
>>
>> I am a few days behind, but here is my take on this problem.
>>
>> Move Party/PartyType to framework; leave Person/PartyGroup in
>> applications/party(along with the seed data).  The framework then  
>> just
>> deals with some abstract party, it has no idea what the exact kind of
>> party it is dealiing with.
>>
>> Party is a *very* low-level critical entity; I don't think we can get
>> away from not requiring it in framework.
>
> This is an interesting idea, but I am not sure we will have to go in  
> this direction.
> I'd suggest to try to live without it, and postpone the decision.
> In the meantime we may move the common "ERP-oriented" resources to  
> an "applications/appcommon" (another name could be "commonext", to  
> use the same pattern used for security/securityext and entity/
> entityext) component and leave the common "framework-oriented" ones  
> in the "framework/common" component.
> Well, initially we should just move to the "applications/appcommon"  
> component the resources that are causing a dependency from the  
> framework to the applications.

I like the commonext name better than appcommon, I forgot about that  
pattern.

In general I'd rather see things from the framework go into the  
applications than see something like Party go into the framework/
common component. In many cases where party is currently referenced in  
the framework this may not help anyway, as many things refer to stuff  
other than just the Party/partyId.

Anyway, I'm still not comfortable with moving all of the entity defs  
currently in framework/common to applications/commonext. We have a lot  
of code and a few entities for doing basic things (and by basic I mean  
OS and language types of features, ie things Java supports) like  
selecting languages and locales and supporting enumerations stored in  
the database (as opposed to "hard coded") or modeling states and valid  
state changes. IMO all of those make much more sense as part of the  
framework.

-David

[Jacopo Cappellato-4]

On Jan 30, 2009, at 10:39 AM, David E Jones wrote:

>
> I like the commonext name better than appcommon, I forgot about that  
> pattern.
>
> In general I'd rather see things from the framework go into the  
> applications than see something like Party go into the framework/
> common component. In many cases where party is currently referenced  
> in the framework this may not help anyway, as many things refer to  
> stuff other than just the Party/partyId.
>
> Anyway, I'm still not comfortable with moving all of the entity defs  
> currently in framework/common to applications/commonext. We have a  
> lot of code and a few entities for doing basic things (and by basic  
> I mean OS and language types of features, ie things Java supports)  
> like selecting languages and locales and supporting enumerations  
> stored in the database (as opposed to "hard coded") or modeling  
> states and valid state changes. IMO all of those make much more  
> sense as part of the framework.
>
> -David
>
>

Yes, I agree that entities like Enumeration should stay in the  
framework/common component; and in general, I think that we should not  
move any entity to commonext (aka applications/common) at least  
initially: we should just use the new component to fix the dependency  
issue we have right now.

Jacopo

[David E Jones-3]

On Jan 30, 2009, at 2:11 AM, Jacopo Cappellato wrote:

>
> On Jan 30, 2009, at 10:39 AM, David E Jones wrote:
>>
>> I like the commonext name better than appcommon, I forgot about  
>> that pattern.
>>
>> In general I'd rather see things from the framework go into the  
>> applications than see something like Party go into the framework/
>> common component. In many cases where party is currently referenced  
>> in the framework this may not help anyway, as many things refer to  
>> stuff other than just the Party/partyId.
>>
>> Anyway, I'm still not comfortable with moving all of the entity  
>> defs currently in framework/common to applications/commonext. We  
>> have a lot of code and a few entities for doing basic things (and  
>> by basic I mean OS and language types of features, ie things Java  
>> supports) like selecting languages and locales and supporting  
>> enumerations stored in the database (as opposed to "hard coded") or  
>> modeling states and valid state changes. IMO all of those make much  
>> more sense as part of the framework.
>>
>> -David
>>
>>
>
> Yes, I agree that entities like Enumeration should stay in the  
> framework/common component; and in general, I think that we should  
> not move any entity to commonext (aka applications/common) at least  
> initially: we should just use the new component to fix the  
> dependency issue we have right now.

I guess I missed something about the commonext idea... which  
dependency issues would we use it to fix? I'll admit I haven't tried  
to create a list of all of the dependency issues, but the ones like  
the Party issues and such should go in the party component and  
probably not anywhere else.

The one that Hans brought up with the various header things might be a  
good reason to have something in this component, but actually I like  
the idea better of having it in the database somewhere, perhaps using  
the portal stuff. That would give us a way to have a default set of  
things to show there and a way to let users customize it. It would  
also give us a way to have each component setup the data for the  
header portlets it offers in seed data, instead of in a file somewhere.

-David