From: "Jacopo Cappellato" <jacopo.cappell...@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, risali...@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, risali...@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, hans...@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
=
=
=
=
