You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Haroon Rafique <ha...@utoronto.ca> on 2003/12/02 22:50:19 UTC
[OT] initialization of application-wide drop-down settings
Hi,
Long time lurker, first time poster.
I'm using struts 1.1. My question is rather general and may even be
off-topic.
I use a ServletContextListener class for populating certain
application-wide settings inside the contextInitialized() method. One of
the requirements is that I need to maintain the order of the drop-down
values. Might need to separate them by locale at a future stage as well.
So, for example my "phone types" collection looks as follows:
// set up list of phone types
Collection col = new ArrayList();
// FIXME: read from a properties resource bundle instead
col.add(new LabelValueBean("Business Tel.", "B"));
col.add(new LabelValueBean("Cell Phone", "C"));
col.add(new LabelValueBean("Pager", "D"));
col.add(new LabelValueBean("Fax - Mailing (local) address", "F"));
col.add(new LabelValueBean("Fax - Permanent (home) address",
"G"));
col.add(new LabelValueBean("Fax - Business", "H"));
// place under PHONE_TYPE_KEY in application scope
servletContext.setAttribute(Constants.PHONE_TYPE_KEY,
col);
Later on, in my view, I can use the <html:options> tag to populate the
drop-down. Hah! I used <html:options> in the previous sentence, so that
makes this post partially on-topic.
So, far so good, as this is only development.
In production, I'm really supposed to get these values and labels from a
database. It is acceptable to only load this once upon application startup
as is the case now by using ServletContextListener. Making the call to the
database upon application startup is not an option, however, a cron job is
able to pull these values out and store them in a file.
Now my question to you is "what is the most convenient file structure
which will let me meet my above-stated requirements?"
So, far I have thought of (and discounted):
1. ResourceBundle (since it will not keep the original order)
Likely candidates are:
1. custom code to read a .properties file which maintains the order
(something along the lines of using getResourceAsStream() - have to think
about locales).
2. Use Digester to read XML data (have to think about locales).
I'm pretty certain some of you must have run into this problem beforehand.
Can I call upon your experience to provide me with some input or point
out something obvious that I may have missed?
Cheers,
--
Haroon Rafique
<ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] initialization of application-wide drop-down settings
Posted by Haroon Rafique <ha...@utoronto.ca>.
On Yesterday at 4:32pm, KW=>Kirk Wylie <kw...@m7.com> wrote:
KW>
KW> Okay, another real brute-force approach which is taken by old-skool
KW> Java systems (i.e. it's a real idiom, and is used in such places as
KW> the security.policy file amongst other places) is to use property
KW> files, but in a specific way for ordered, multi-value properties like
KW> this:
KW> - Create a "key", such as "m7.my.listbox"
KW> - Add a property which is a count, like "m7.my.listbox.count"
KW> - Add individual properties which are numbered, from 0 to (count - 1):
KW> "m7.my.listbox.0", "m7.my.listbox.1", etc.
KW> In your case, you might then have a property file which would look like:
KW> desc.phone.types.count=3
KW> desc.phone.types.0.mnemonic=B
KW> desc.phone.types.0.value=Business Tel.
KW> desc.phone.types.1.mnemonic=C
KW> desc.phone.types.1.value=Cell Phone
KW> desc.phone.types.2.mnemonic=D
KW> desc.phone.types.2.value=Pager
KW>
Kirk,
I definitely like this idea. Thanks for keeping the creative juices
flowing.
KW>
KW> [..snip..]
KW>
KW> Just an option. You'll probably hear soon enough about the more elegant
KW> approaches that you've not discarded. But in my experience, when all
KW> else fails, Java Property files tend to solve a lot of problems.
I'll leave the esoteric ideas for later and try the simple approach first.
KW>
KW> Kirk Wylie
KW> M7 Corporation
KW>
--
Haroon Rafique
<ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] initialization of application-wide drop-down settings
Posted by Kirk Wylie <kw...@m7.com>.
Haroon Rafique wrote:
> On Today at 3:31pm, KW=>Kirk Wylie <kw...@m7.com> wrote:
>
> KW> [..snip..]
> KW>
> KW> Obligatory Monty Python quotation: "What's wrong with a Kiss, boy?"
>
> Kiss = Keep it simple stupid, I hope? ;-)
From The Meaning Of Life. But it connotes the same thing. I won't
discuss the context of the quotation, though. :-)
> KW> Why not just grab it in the cron job and serialize it to a file using
> KW> plain old Java serialization? Or, failing that, using the new-fangled
> KW> 1.4 XML encoding? This sort of thing is very well handled by the VM
> KW> (and serialization has been stable/consistently stored for several
> KW> years now), so why create extra work for yourself?
>
> I hear ya. However, I just replied to Vic's reply and here's the skinny.
>
> My situation is different because the call to the data layer for the
> specific purpose of downloading the application-wide settings is not
> available yet via java. It is only available, at the moment, via a C API,
> which is why I mentioned the daily cron job which could be used to
> generate the "data files" (failed to mention in orig msg that it is
> written in C). That's life. You gotta deal with what's available.
>
> So, serialization and xml encoding are both out the door.
Okay, another real brute-force approach which is taken by old-skool Java
systems (i.e. it's a real idiom, and is used in such places as the
security.policy file amongst other places) is to use property files, but
in a specific way for ordered, multi-value properties like this:
- Create a "key", such as "m7.my.listbox"
- Add a property which is a count, like "m7.my.listbox.count"
- Add individual properties which are numbered, from 0 to (count - 1):
"m7.my.listbox.0", "m7.my.listbox.1", etc.
In your case, you might then have a property file which would look like:
desc.phone.types.count=3
desc.phone.types.0.mnemonic=B
desc.phone.types.0.value=Business Tel.
desc.phone.types.1.mnemonic=C
desc.phone.types.1.value=Cell Phone
desc.phone.types.2.mnemonic=D
desc.phone.types.2.value=Pager
This is a brute-force (i.e. not very elegant) approach, but it has the
following advantages:
1) It's fast to code, in both ends.
2) The persistence is done for you in the Java side by the property
system. Thus no additional library requirements, and nothing more to
test (such as a custom format).
3) It's not tied to a specific class system (like the Digester with its
JavaBean-based approach where you have to keep the javabeans in sync
with the virtual DTD).
4) Files can be read/written in any order, meaning it's easier to use
Perl or Python dictionaries (or STL maps since you're in C/C++) since
you can just rely on native hashing support.
5) It smacks of KISS: the system isn't overengineered at all.
It has some disadvantages:
1) It's a little ugly/less elegant
2) You have to maintain separate documentation over your property system
so that you know what's going on.
3) It's probably harder to maintain if your schemas start getting large
for this type of thing.
4) It'll be harder to move to something "better", like being able to
work with the database from Java, meaning that you'll probably just
throw this away.
Note that I've also used JAXB for this in the past (before Sun decided
to couple it to the JWDSP and make it more difficult to use), but it's a
real nest of libraries to untangle to use separately, and might not be
worth the effort.
Just an option. You'll probably hear soon enough about the more elegant
approaches that you've not discarded. But in my experience, when all
else fails, Java Property files tend to solve a lot of problems.
Kirk Wylie
M7 Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] initialization of application-wide drop-down settings
Posted by Haroon Rafique <ha...@utoronto.ca>.
On Today at 3:31pm, KW=>Kirk Wylie <kw...@m7.com> wrote:
KW> Note lots of snipping.
KW>
No problem.
KW> [..snip..]
KW>
KW> Obligatory Monty Python quotation: "What's wrong with a Kiss, boy?"
Kiss = Keep it simple stupid, I hope? ;-)
KW> Why not just grab it in the cron job and serialize it to a file using
KW> plain old Java serialization? Or, failing that, using the new-fangled
KW> 1.4 XML encoding? This sort of thing is very well handled by the VM
KW> (and serialization has been stable/consistently stored for several
KW> years now), so why create extra work for yourself?
I hear ya. However, I just replied to Vic's reply and here's the skinny.
My situation is different because the call to the data layer for the
specific purpose of downloading the application-wide settings is not
available yet via java. It is only available, at the moment, via a C API,
which is why I mentioned the daily cron job which could be used to
generate the "data files" (failed to mention in orig msg that it is
written in C). That's life. You gotta deal with what's available.
So, serialization and xml encoding are both out the door.
KW>
KW> Admittedly, it might be nice to use a full caching system to control
KW> how often things go to the database using your DAO system for hte rest
KW> of the model, but if you're already working fine with this model why
KW> not just keep it but use some type of built-in serialization?
KW>
KW> Kirk Wylie
KW> M7 Corporation
Thanks for taking the time to reply.
--
Haroon Rafique
<ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] initialization of application-wide drop-down settings
Posted by Kirk Wylie <kw...@m7.com>.
Note lots of snipping.
Haroon Rafique wrote:
> Now my question to you is "what is the most convenient file structure
> which will let me meet my above-stated requirements?"
>
> So, far I have thought of (and discounted):
>
> 1. ResourceBundle (since it will not keep the original order)
>
> Likely candidates are:
>
> 1. custom code to read a .properties file which maintains the order
> (something along the lines of using getResourceAsStream() - have to think
> about locales).
>
> 2. Use Digester to read XML data (have to think about locales).
>
> I'm pretty certain some of you must have run into this problem beforehand.
>
> Can I call upon your experience to provide me with some input or point
> out something obvious that I may have missed?
Obligatory Monty Python quotation: "What's wrong with a Kiss, boy?" Why
not just grab it in the cron job and serialize it to a file using plain
old Java serialization? Or, failing that, using the new-fangled 1.4 XML
encoding? This sort of thing is very well handled by the VM (and
serialization has been stable/consistently stored for several years
now), so why create extra work for yourself?
Admittedly, it might be nice to use a full caching system to control how
often things go to the database using your DAO system for hte rest of
the model, but if you're already working fine with this model why not
just keep it but use some type of built-in serialization?
Kirk Wylie
M7 Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] initialization of application-wide drop-down settings
Posted by Haroon Rafique <ha...@utoronto.ca>.
On Today at 5:34pm, VC=>Vic Cekvenich <ce...@basebeans.com> wrote:
VC> What I do is do data (Model) caching the data layer, the DAO, such as
VC> iBatis. For example I can set the cache for "options" to 24 hours or
VC> more, thus no special code for caching otside of DAO.
VC>
VC> Then I retrive optionsCollection from DAO "order by
VC> some_sort_colum_for_order". This puts them in order. The data is
VC> accessed once for the application context ('cuase of DAO).
VC>
VC>
VC> hth,
VC> .V
Vic,
All valid points, except that they don't apply to my situation. This might
help someone else if they're searching the archives.
My situation is different because the call to the data layer for the
specific purpose of downloading the application-wide settings is not
available yet via java. It is only available, at the moment, via a C API,
which is why I mentioned the daily cron job which could be used to
generate the "data files" (failed to mention in orig msg that it is
written in C). That's life. You gotta deal with what's available.
Thanks for the reply,
--
Haroon Rafique
<ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: [OT] initialization of application-wide drop-down settings
Posted by Vic Cekvenich <ce...@basebeans.com>.
What I do is do data (Model) caching the data layer, the DAO, such as
iBatis. For example I can set the cache for "options" to 24 hours or
more, thus no special code for caching otside of DAO.
Then I retrive optionsCollection from DAO "order by
some_sort_colum_for_order". This puts them in order.
The data is accessed once for the application context ('cuase of DAO).
hth,
.V
Haroon Rafique wrote:
> Hi,
>
> Long time lurker, first time poster.
>
> I'm using struts 1.1. My question is rather general and may even be
> off-topic.
>
> I use a ServletContextListener class for populating certain
> application-wide settings inside the contextInitialized() method. One of
> the requirements is that I need to maintain the order of the drop-down
> values. Might need to separate them by locale at a future stage as well.
>
> So, for example my "phone types" collection looks as follows:
>
> // set up list of phone types
> Collection col = new ArrayList();
> // FIXME: read from a properties resource bundle instead
> col.add(new LabelValueBean("Business Tel.", "B"));
> col.add(new LabelValueBean("Cell Phone", "C"));
> col.add(new LabelValueBean("Pager", "D"));
> col.add(new LabelValueBean("Fax - Mailing (local) address", "F"));
> col.add(new LabelValueBean("Fax - Permanent (home) address",
> "G"));
> col.add(new LabelValueBean("Fax - Business", "H"));
> // place under PHONE_TYPE_KEY in application scope
> servletContext.setAttribute(Constants.PHONE_TYPE_KEY,
> col);
>
> Later on, in my view, I can use the <html:options> tag to populate the
> drop-down. Hah! I used <html:options> in the previous sentence, so that
> makes this post partially on-topic.
>
> So, far so good, as this is only development.
>
> In production, I'm really supposed to get these values and labels from a
> database. It is acceptable to only load this once upon application startup
> as is the case now by using ServletContextListener. Making the call to the
> database upon application startup is not an option, however, a cron job is
> able to pull these values out and store them in a file.
>
> Now my question to you is "what is the most convenient file structure
> which will let me meet my above-stated requirements?"
>
> So, far I have thought of (and discounted):
>
> 1. ResourceBundle (since it will not keep the original order)
>
> Likely candidates are:
>
> 1. custom code to read a .properties file which maintains the order
> (something along the lines of using getResourceAsStream() - have to think
> about locales).
>
> 2. Use Digester to read XML data (have to think about locales).
>
> I'm pretty certain some of you must have run into this problem beforehand.
>
> Can I call upon your experience to provide me with some input or point
> out something obvious that I may have missed?
>
> Cheers,
> --
> Haroon Rafique
> <ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org