The problem we found was that a master list is impossible to manage. For
instance, on the soon to arrive 10th page of the property file, you will
have to search all of the previous pages to check to see if you already used
the property name already. Chances are that you did use the name already
because an individual tends to think in their own way and come up with the
same naming schemes, and you will have more for the property name "name" in
many many other pages. Then some designer or manager tells you to add a
form field which you recognize that you could use "name" as the field
property and realize you have to rethink the way you have been and will
continue naming things, such as "signup_name", "logon_name", "search_name",
"artist_name", "publication_name"...... after completeing the 30th jsp page
you say to yourself, "man(sigh), if I just had a properties file for each
page or include, than I wouldnt have a 3000 line properties file with which
I cannot sort, group, or categorize all of the property names nicely".
It was easier for us to:
1) know what was on any page (just look at the like named proerties file)
2) fix or add to a page without thinking if the name was used, and whether I
thus have to come up with a naming scheme for this one or all of them.
3) just hand over translatable content to the translators on a page by page
basis.
4) if you later decide to keep it in the database you can because you just
associate pageName with propertyName
logon.jsp user.name
logon.jsp user.address
logon.jsp
signup.jsp user.name
signup.jsp user.password
checkout.jsp user.name
This is much easier. Try it. You will see how managing this grand list
sucks ;^)
If your developers are anything like places I have worked for, than you know
how things
get out of control. I just take this as a given. With my way, at any time,
I can email out new pages and text to be translated (by a clerk, designers,
editors). I send a visual and typeographic pair of items that go together
and that an editor can say, "yes, this is what I want the caption to say on
this page". Do I repeadedly send the editor chunks of a 3000+ item list and
then say:
(me) "can you tell me what you want to say in these new lines of text?"
(editor) "which lines?"
(me) " the ones I highlighted"
(editor) "which of these lines of text is on this page we are talking
about?".
Do you see why I say the benefits from a big list loose out to a small list?
What if I delete one. What pages does it effect? Which ones have been left
orphaned? You dont know in any easy way. For search and replace you now
have to search each particularly named item. If they all were called
"user.name" I could just search and replace it everywhere below a directory.
If one is "logon.user.name" and another "search.user.name" you now have to
search and find each unique one. Could you get them all, or did you miss
some because someone was using "logon.User.Name" instead of
"logon.user.name" or "logonUserName".
----- Original Message -----
From: "Nanduri, Amarnath" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 31, 2001 5:50 PM
Subject: RE: Resources clarification - is there a work around
> Hi Guys,
>
> From my personal experience it would not be a bad idea for struts
to
> support multiple resource bundles. I will explain my reasons below.
>
> At present struts has one resource bundle in which you can include error
> messages , confirmation messages , labels on html fileds etc.... For a big
> application ( like i am on right now. We are going to have > 50 jsp pages
> minimum) it is quite a pain in the neck to add properties to a single
file.
> Besides the developers having to compete with one another to checkout the
> properties file ( from source safe ) maintaining it is an another pain.
>
> One more problem we encountered is nested exceptions deep in the EJB's.
> Trying to throw the error msgs (which ofcourse have to be
internationalized)
> and showing it to the user, it was somewhat of a problem to define all the
> correct error messages in the same property file. After sometime we were
> able to coordinate properly and get stuff back on track (without losing
> tempers).
>
> I would propose that struts 1.1 make it a standard to have separate
> Resource Bundles for different categories. I do not agree with one
Resource
> Bundle per page as this would lead to too much confusion.
>
> For example, all the error msgs would be in a Resource Bundle by
> themselves. Confirmation msgs would have their own Resource Bundle. HTML
> related fields will have their own Resource Bundles etc ..
>
> From a performance point of view which would be more efficient ? Having
a
> single Resource Bundle (or) Multiple Resource Bundles ? Which one can give
> the user faster lookup access ?
>
>
> At present we have close to 2000+ (properties + error msgs) in the
> properties file and the number would most likely quadruple by the time we
> take it to production. I would certainly like to hear your opinions on
> this....esp from people who have deployed their applications...
>
> just my 2cents
>
> cheers,
> Amar..
>
>
>
>
> -----Original Message-----
> From: Jonathan [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 31, 2001 10:28 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Resources clarification - is there a work around
>
>
> Hi Peter. Read the whole thread and you will see some good examples as to
> why I want to do this.
>
> I think I will end up doing some surgery on the struts classes. I will
> associate the page I am forwarding to with a properties file, maybe inside
> the struts-config. That will mean I will have to look at the dom
> manipulation which gets the values and ad another group of items (the
> associated properties file) to a hashtable or object. I will put the
> properties files in the same directory as the jsp page but protected. I
> will try to protect all files that end in ".properties".
>
> I would love to hear suggestions from Niall, Ted, Craig, Hal, Jeff,
Nanduri,
> Dave etc....
>
>
> ----- Original Message -----
> From: "Peter Alfors" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, May 31, 2001 10:03 AM
> Subject: Re: Resources clarification - is there a work around
>
>
> > We are currently using two different resource bundles. One for our
> messages and
> > another for our constants (that define
> > web look and feel). To do this, we overrode the init() method in the
> > ActionServlet and added another method to initialize a second bundle
into
> a
> > different session attribute.
> > This works well for 2 different bundles, but it would not be practical
for
> a
> > large number or bundles (one per page).
> >
> > Maybe there would be a way to initialize all of the page bundles at
> startup?
> > Some sort of loop or somethine?
> > I don't have any suggestions on how this would work, but maybe it is a
> starting
> > point??
> >
> > One supporting reason for a single bundle would be this... It allows
you
> to
> > easily keep consistent naming across your app.
> > For instance, if each of your pages has the label "Id", but then later
on
> you
> > (or the customer) decide that "Name" is a better choice, you only have
to
> change
> > it in one place. There are other situations as well, this is just one.
> > Also, creating new locales is as simple as handing a single resource
> bundle over
> > to your translater, rather than 100 different bundles to duplicate.
> > As for naming problems, there is a simple solution. Use a naming
strategy
> for
> > each key.
> >
> > <pageName>.<Key>=Value
> > or
> > common.<Key>=Value <-- if this is common across all pages.
> >
> > HTH,
> > Pete
> >
> >
> > Jonathan Asbell wrote:
> >
> > > Thanks Pete. However it just seems strange that Struts just offers
one
> big
> > > resource file for each Local. I have developed 3 international sites,
> and I
> > > can safely say that when a set of resources are associated with a
> particular
> > > page it is much easier to manage than 1 resources for all pages. Has
> anyone
> > > hacked at the Struts code to get around this? I dont like the
> concatenating
> > > idea because it is too easy to have duplicates; and you probably want
to
> use
> > > the same resource names anyway to keep a consistency. Anyone else
have
> any
> > > ideas?
> > >
> > > ----- Original Message -----
> > > From: "Peter Alfors" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, May 30, 2001 9:33 AM
> > > Subject: Re: Resources clarification :^)
> > >
> > > > You could combine all of your property files during your build.
> > > > This would allow you to have as many different property files as you
> > > > want.
> > > > However, you need to be careful that you do not have duplicate names
> > > > across multiple files.
> > > >
> > > > HTH,
> > > > Pete
> > > >
> > > > Jonathan wrote:
> > > >
> > > > > Hello all. It appears that the ActionServlet points to a
resources
> > > > > file, and not a ResourceBundle object. Is this true? The reason
is
> > > > > that I would like to group in the same directory the following:1)
a
> > > > > particular ActionForm2) the Action class that works with that
> > > > > ActionForm3) the resources (strings) that work with that
> > > > > ActionForm The reason is that it is much easier to manage the
> > > > > artifacts on a page by page basis.How can I do this
> > > > > properly ThanksJonathan
> > > >
> >
>
