Re: Issue with a framework dependency on the Party component
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
Re: Issue with a framework dependency on the Party component
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 smime.p7s Description: S/MIME cryptographic signature
Re: Issue with a framework dependency on the Party component
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
Re: Issue with a framework dependency on the Party component
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 smime.p7s Description: S/MIME cryptographic signature
Re: Issue with a framework dependency on the Party component
David E Jones wrote: >> by the way i did a scan on "partyId" in the framework and got 268 >> hitsso 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.
Re: Issue with a framework dependency on the Party component
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
Re: Issue with a framework dependency on the Party component
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
Re: Issue with a framework dependency on the Party component
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
Re: Issue with a framework dependency on the Party component
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
Re: Issue with a framework dependency on the Party component
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
Re: Issue with a framework dependency on the Party component
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
Re: Issue with a framework dependency on the Party component
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 hitsso 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): 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
Re: Issue with a framework dependency on the Party component
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 hitsso 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): > > value-name="orgParty"> > name="defaultOrganizationPartyId"/> > > from-field="orgParty.baseCurrencyUomId" default- > value="defaultCurrencyUomId" global="true"/> > 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
Issue with a framework dependency on the Party component
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): value-name="orgParty"> name="defaultOrganizationPartyId"/> from-field="orgParty.baseCurrencyUomId" default- value="defaultCurrencyUomId" global="true"/> 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 smime.p7s Description: S/MIME cryptographic signature
