Joe Germuska wrote:
I was thinking to deserialize the java bean on login and I will have
to in
order to build the sub menu. I felt I shouldn't keep the bean around
as it
may be large containing several pages of content and too heavy for the
session. So I would have to retrieve the bean on each content
request, might
not be that slow... have to test?
If you do use Java serialization, use XMLEncoder -- there are a lot of
headaches involved in serializing to the binary format if your
classes' APIs change -- or rather, in deserializing, since without
your efforts, beans serialized with one version of a class will not
deserialize with a revised version of that class.
I hate this problem!!!!
If XMLEncoder doesn't work for you, there are a few automated XML
binding tools, like jakarta-commons-betwixt, Castor, and Enhydra
Zeus. All should dodge that problem with deserializing beans as long
as you only extend your API and don't remove anything.
commons-digester does a *nice* job of turning XML into instantiated
objects. You have to setup some rules, but that's not hard at all.
Refer to the javadoc for commons-digester. I'm not sure if it can
"serialize objects to XML" or not. I don't think that is the job it was
designed for. Craig could say better than I. It really makes
reading/instantiating objects represented in XML very easy though.
How dynamic is your content? If it's just a matter of hiding and
showing various values, then you could just use logic tags to control
that based on data in your user profile bean. That would minimize
some of the management issues.
If users basically get to create bookmarks (arbitrary links and link
titles) in your app, I guess you don't have much choice than to create
one or more files. You'd have to weigh the benefits of reading in the
file each time and storing it in request scope vs. reading it in once
and storing it in your session. I'd avoid bloating the session
myself. I don't know how fast all that file access would be, but it's
probably not much slower than the common alternative of making a
network call to a database.
Is the flat file requirement for readability/manual editing? Or just
to save money on a database? If it's the latter, you might be able to
use RandomAccessFile to manage all this user data. You'd probably
want to be careful about opening a file handle and sticking that in
the session, though, just because you'd never really know when to
clean it up...
Money should not be a factor nowadays. There are several *fine* OS DBMS
implementations: Firebird, PostgreSQL are two I am familiar with.
You may also want to consider portal-oriented software systems which
may provide a better framework for the degree of user customization
you need. There's Jakarta Jetspeed,
<http://jakarta.apache.org/jetspeed/> which is pretty well developed,
but based on Turbine instead of Struts, and Vic C. has been leading a
Struts portal project on sourceforge.
<http://basicportal.sourceforge.net/ > Just to keep your options open...
Joe
--
Eddie Bush
--
To unsubscribe, e-mail: <mailto:struts-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@;jakarta.apache.org>
