On Jan 26, 2009, at 7:11 AM, David E Jones wrote:
The specific thing about messages is pretty simple... they should like in the lowest level (most depended on) component that uses them. If they are used in the party and common components, then they should go in the common component. Looking at the common component it is frustrating to see a number of labels/messages that include the word "party" as the common component doesn't know anything about parties (and should remain lower level and not know anything about parties even if we do split some of it into the applications).
Yes, I totally agree with you.
What to do with the common component is a bit of a tough call. I originally considered a lot of those data structures to be very generic and appropriate to put in a framework. There are lots of examples of low level tools including infrastructure for things like this, the Java APIs being a good example of one that includes things related to many of these.
For sure we still need a common component for the framework, but in my opinion it should contain only framework related common artifacts (entities etc...) and not applications related common artifacts (that should be moved into the new common component in the applications folder).
Some entities should definitely stay in the framework, like the Status* and Enumeration* entities in common and the WebSite and related entities in webapp, and I still think most of the other ones should too. There may be specific cases, but for the most part I think they are where they should be.
Well, in my opinion these entities would be good candidates for the new applications ' common component (unless they are used by other framework related entities, quite possible, I have not checked this). The main goal would be to have a framework as clean as possible, with no ERP/applications related entities in it (just user related and very tech entities).
Jacopo
I'll admit some are more dubious, so I'll gladly join in discussing specific entities. Some are really generic, but only used in one application component, like the CustomTimePeriod is only used in accounting, but it is a more generic concept so doesn't have to be only used there and could be reused for other things...-David On Jan 25, 2009, at 12:59 PM, Jacopo Cappellato wrote:I really think it is time to start to think about splitting the common component into two components: 1) a common component to be placed into the applications folder and loaded before the other ones2) a common component that will stay in the framework folderAll these labels, plus other ERP related artifacts, should then go in #1In my opinion entities like Geo, CountryCode, KeywordThesaurus should not appear in a framework only distro.But maybe I am off topic in this thread and I should create a new one.Jacopo On Jan 25, 2009, at 10:14 AM, [email protected] wrote:Hi Hans,it's ok to move it to the framework is they are more generics and they can be shared by all the components but in this case I think it's better to put the Common prefix on those labels.Thanks Marco Il giorno 25/gen/09, alle ore 02:54, Hans Bakker ha scritto:Hi Marco,sure we can do this, however captcha itself is a framework function, but at the moment only used in myportal... We will move the captcha messagesto the framwork.... regards, Hans On Sat, 2009-01-24 at 22:22 +0100, [email protected] wrote:Hi Hans,I suggest to use the prefix MyPortal for those type of labels, I spent a lot of days to cleanup all the wasted labels into OFBiz and I thinkwe cannot all use different standard to codify the labels.And if it's possible do not use the underscore character in the labelsname could be more readable. In my opinion for example CaptchaMissingError could be MyPortalCaptchaMissingError or something similar to that.If we do not follow this simple rule in two or three months the labelswill be completed wasted again. What others thinks about that ? Thanks MarcoIl giorno 20/gen/09, alle ore 09:30, [email protected] ha scritto:Author: hansbak Date: Tue Jan 20 00:30:41 2009 New Revision: 735965 URL: http://svn.apache.org/viewvc?rev=735965&view=rev Log: first version of captcha, not perfect yet: multiple users registering at the same time, image should be stored in 'runtime' not working on windows. Another problem is what files to put where.....the captcha itself looks like a framework feature...however the registration process needs the party component....so let us know, we will correct it.... Added: ofbiz/trunk/framework/common/src/org/ofbiz/common/Captcha.java (with props)ofbiz/trunk/specialpurpose/myportal/widget/login.ftl (with props)Modified: ofbiz/trunk/framework/common/widget/CommonMenus.xml ofbiz/trunk/specialpurpose/myportal/config/MyPortalUiLabels.xml ofbiz/trunk/specialpurpose/myportal/script/org/ofbiz/myportal/ Events.xml ofbiz/trunk/specialpurpose/myportal/webapp/myportal/WEB-INF/ controller.xml ofbiz/trunk/specialpurpose/myportal/widget/CommonScreens.xml ofbiz/trunk/specialpurpose/myportal/widget/MyPortalForms.xmlAdded: ofbiz/trunk/framework/common/src/org/ofbiz/common/ Captcha.javaURL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/src/org/ofbiz/common/Captcha.java?rev=735965&view=auto = = = =
smime.p7s
Description: S/MIME cryptographic signature
