On Today at 3:31pm, KW=>Kirk Wylie <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
