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 <da...@hotwaxmedia.com> on 2009/01/26 07:11:51 UTC
Split the framework/common component?
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).
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.
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.
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 ones
> 2) a common component that will stay in the framework folder
>
> All these labels, plus other ERP related artifacts, should then go
> in #1
>
> In 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, risalitim@gmail.com 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
>>> messages
>>> to the framwork....
>>>
>>> regards,
>>> Hans
>>>
>>> On Sat, 2009-01-24 at 22:22 +0100, risalitim@gmail.com 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
>>>> think
>>>> we cannot all use different standard to codify the labels.
>>>> And if it's possible do not use the underscore character in the
>>>> labels
>>>> name 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
>>>> labels
>>>> will be completed wasted again.
>>>>
>>>> What others thinks about that ?
>>>>
>>>> Thanks
>>>> Marco
>>>>
>>>>
>>>> Il giorno 20/gen/09, alle ore 09:30, hansbak@apache.org 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.xml
>>>>>
>>>>> Added: ofbiz/trunk/framework/common/src/org/ofbiz/common/
>>>>> Captcha.java
>>>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/src/org/ofbiz/common/Captcha.java?rev=735965&view=auto
>>>>> =
>>>>> =
>>>>> =
>>>>> =
Re: Split the framework/common component?
Posted by Jacques Le Roux <ja...@les7arts.com>.
OK, it seems that there is already a consensus around Jacopo's proposition. So I will switch common/geo to it ASAP
Jacques
From: "Jacques Le Roux" <ja...@les7arts.com>
> In revision 738452 , I have commited last changes related to Geolocation.
> I believe that one of the most importants things when coding is to chase similar blocks of code and try to merge them..
> I have notably removed the method PartyWorker.findPartyLatestGeoPoint() and introduced instead GeoWorker.findLatestGeoPoint() (in
> common/geo).
> However, I have still to achieve the work. I'd like to merge in common/geo also Groovy and FreeMarker files but (I guess for now)
> PartyGeoLocation.groovy
> All parameters could be set in screens and calling a parameterized couple of Groovy/FreeMarker files in common/geo.
> The goal then would be to move them to a new an applications/common component where all shared (transversal like geo)
> features/artifacts would be, as I suggested in r738452 commit.
>
> What do you think ?
>
> Jacques
>
> From: "Jacques Le Roux" <ja...@les7arts.com>
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> 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.
>>
>>>>From a practical point of view I would prefer Jacopo's solution. For instance take the label CommonGeoLocation. I agree it has
>> nothing to do in Framework. But on the other hand it's no more related to Party than Product (Facility) or Accouting (Fixed
>> Asset).
>> So, from a logical point of view, it does not make sense to put them in Party (most depended on) and we could create a Common
>> application component where such artifacts (not only labels) could reside. I'm sure that at term it will prove useful, because
>> it's logical! Why searching in Party something common at the same level at several components ?
>>
>>>> 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).
>>
>> +1
>>
>>>> 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).
>>
>> +1
>>
>> My 2cts
>>
>> Jacques
>>
>>> 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 ones
>>>>> 2) a common component that will stay in the framework folder
>>>>>
>>>>> All these labels, plus other ERP related artifacts, should then go in #1
>>>>>
>>>>> In 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, risalitim@gmail.com 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 messages
>>>>>>> to the framwork....
>>>>>>>
>>>>>>> regards,
>>>>>>> Hans
>>>>>>>
>>>>>>> On Sat, 2009-01-24 at 22:22 +0100, risalitim@gmail.com 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 think
>>>>>>>> we cannot all use different standard to codify the labels.
>>>>>>>> And if it's possible do not use the underscore character in the labels
>>>>>>>> name 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 labels
>>>>>>>> will be completed wasted again.
>>>>>>>>
>>>>>>>> What others thinks about that ?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Marco
>>>>>>>>
>>>>>>>>
>>>>>>>> Il giorno 20/gen/09, alle ore 09:30, hansbak@apache.org 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.xml
>>>>>>>>>
>>>>>>>>> Added: ofbiz/trunk/framework/common/src/org/ofbiz/common/ Captcha.java
>>>>>>>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/src/org/ofbiz/common/Captcha.java?rev=735965&view=auto
>>>>>>>>> =
>>>>>>>>> =
>>>>>>>>> =
>>>>>>>>> =
>>>
>>>
>>
>
Re: Split the framework/common component?
Posted by Jacques Le Roux <ja...@les7arts.com>.
In revision 738452 , I have commited last changes related to Geolocation.
I believe that one of the most importants things when coding is to chase similar blocks of code and try to merge them..
I have notably removed the method PartyWorker.findPartyLatestGeoPoint() and introduced instead GeoWorker.findLatestGeoPoint() (in
common/geo).
However, I have still to achieve the work. I'd like to merge in common/geo also Groovy and FreeMarker files but (I guess for now)
PartyGeoLocation.groovy
All parameters could be set in screens and calling a parameterized couple of Groovy/FreeMarker files in common/geo.
The goal then would be to move them to a new an applications/common component where all shared (transversal like geo)
features/artifacts would be, as I suggested in r738452 commit.
What do you think ?
Jacques
From: "Jacques Le Roux" <ja...@les7arts.com>
> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> 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.
>
>>>From a practical point of view I would prefer Jacopo's solution. For instance take the label CommonGeoLocation. I agree it has
> nothing to do in Framework. But on the other hand it's no more related to Party than Product (Facility) or Accouting (Fixed
> Asset).
> So, from a logical point of view, it does not make sense to put them in Party (most depended on) and we could create a Common
> application component where such artifacts (not only labels) could reside. I'm sure that at term it will prove useful, because
> it's logical! Why searching in Party something common at the same level at several components ?
>
>>> 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).
>
> +1
>
>>> 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).
>
> +1
>
> My 2cts
>
> Jacques
>
>> 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 ones
>>>> 2) a common component that will stay in the framework folder
>>>>
>>>> All these labels, plus other ERP related artifacts, should then go in #1
>>>>
>>>> In 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, risalitim@gmail.com 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 messages
>>>>>> to the framwork....
>>>>>>
>>>>>> regards,
>>>>>> Hans
>>>>>>
>>>>>> On Sat, 2009-01-24 at 22:22 +0100, risalitim@gmail.com 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 think
>>>>>>> we cannot all use different standard to codify the labels.
>>>>>>> And if it's possible do not use the underscore character in the labels
>>>>>>> name 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 labels
>>>>>>> will be completed wasted again.
>>>>>>>
>>>>>>> What others thinks about that ?
>>>>>>>
>>>>>>> Thanks
>>>>>>> Marco
>>>>>>>
>>>>>>>
>>>>>>> Il giorno 20/gen/09, alle ore 09:30, hansbak@apache.org 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.xml
>>>>>>>>
>>>>>>>> Added: ofbiz/trunk/framework/common/src/org/ofbiz/common/ Captcha.java
>>>>>>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/src/org/ofbiz/common/Captcha.java?rev=735965&view=auto
>>>>>>>> =
>>>>>>>> =
>>>>>>>> =
>>>>>>>> =
>>
>>
>
Re: Split the framework/common component?
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> 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.
>From a practical point of view I would prefer Jacopo's solution. For instance take the label CommonGeoLocation. I agree it has
nothing to do in Framework. But on the other hand it's no more related to Party than Product (Facility) or Accouting (Fixed Asset).
So, from a logical point of view, it does not make sense to put them in Party (most depended on) and we could create a Common
application component where such artifacts (not only labels) could reside. I'm sure that at term it will prove useful, because it's
logical! Why searching in Party something common at the same level at several components ?
>> 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).
+1
>> 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).
+1
My 2cts
Jacques
> 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 ones
>>> 2) a common component that will stay in the framework folder
>>>
>>> All these labels, plus other ERP related artifacts, should then go in #1
>>>
>>> In 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, risalitim@gmail.com 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 messages
>>>>> to the framwork....
>>>>>
>>>>> regards,
>>>>> Hans
>>>>>
>>>>> On Sat, 2009-01-24 at 22:22 +0100, risalitim@gmail.com 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 think
>>>>>> we cannot all use different standard to codify the labels.
>>>>>> And if it's possible do not use the underscore character in the labels
>>>>>> name 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 labels
>>>>>> will be completed wasted again.
>>>>>>
>>>>>> What others thinks about that ?
>>>>>>
>>>>>> Thanks
>>>>>> Marco
>>>>>>
>>>>>>
>>>>>> Il giorno 20/gen/09, alle ore 09:30, hansbak@apache.org 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.xml
>>>>>>>
>>>>>>> Added: ofbiz/trunk/framework/common/src/org/ofbiz/common/ Captcha.java
>>>>>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/src/org/ofbiz/common/Captcha.java?rev=735965&view=auto
>>>>>>> =
>>>>>>> =
>>>>>>> =
>>>>>>> =
>
>
Re: Split the framework/common component?
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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 ones
>> 2) a common component that will stay in the framework folder
>>
>> All these labels, plus other ERP related artifacts, should then go
>> in #1
>>
>> In 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, risalitim@gmail.com 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
>>>> messages
>>>> to the framwork....
>>>>
>>>> regards,
>>>> Hans
>>>>
>>>> On Sat, 2009-01-24 at 22:22 +0100, risalitim@gmail.com 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
>>>>> think
>>>>> we cannot all use different standard to codify the labels.
>>>>> And if it's possible do not use the underscore character in the
>>>>> labels
>>>>> name 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
>>>>> labels
>>>>> will be completed wasted again.
>>>>>
>>>>> What others thinks about that ?
>>>>>
>>>>> Thanks
>>>>> Marco
>>>>>
>>>>>
>>>>> Il giorno 20/gen/09, alle ore 09:30, hansbak@apache.org 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.xml
>>>>>>
>>>>>> Added: ofbiz/trunk/framework/common/src/org/ofbiz/common/
>>>>>> Captcha.java
>>>>>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/src/org/ofbiz/common/Captcha.java?rev=735965&view=auto
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> =