Rick Reumann wrote:
This app I'm working on is sort of any odd beast. It's a case where
the resulting JSP is going to be built by generic beans that are
nested inside of the same type of generic bean etc. So for an example ...
class FooBar {
Collection fooBars;
Integer id;
String type;
String value;
//set/gets
}
So what happens is you can have Collections of these beans nested
serveral levels and you don't know before run-time how deep.
My form will need to display everything and capture any changes to the
'value' field.
So my ActionForm (in this example) would only have one main property:
private FooBar fooBar;
When the form submits it captures all the nested fooBar information.
The problem of course is making sure you don't get those nasty
BeanUtils index errors when the form submits.
Typically, for standard applications, I'd use ListUtils.lazyList for
my Collections. The problem, though, here is that you don't know how
deep the Collections go (without a call to the business layer).
The only way I've found to get this type of form to work is to give it
Session scope. Everything is fine then since it retains the initial
FooBar object placed in the form that is done in a 'setUp' or 'prep'
method before the form is displayed for the user.
Just wondering if there is another approach I could consider to tackle
this without using the Session. I think in this case the Session holds
the most promise.
The following is just what I have recently been experimenting with and
it has had some success for those nasty "What scope do I use?" problems
for persistence. That is all I am addressing here. What I do is to
save the data in application scope and keep references as keys in
session scope. Further, I run a task scheduler from Timer and TimerTask
classes in a plugin at startup to keep checking if the data is needed in
application scope and get rid of it if it isn't. This is an attempt to
solve the continuing problem of persistence in memory in web apps. My
stuff is working pretty well with an experimental chat room written in
Struts for port 80. The TaskScheduler checks static boolean fields in
the Chat application to determine what the state of the Chat application
is, e.g., is there an object in application scope or not, what use is
being made of various chat rooms, etc. If there is a Chat object in
application scope, then the TaskScheduler polls the object to see what
is happening with the ChatRooms therein. Again, whatever needs to be
done with the ChatRooms is decided. Meanwhile, users keep references to
chatRooms and their chatProfiles in session scope and these act as keys
for the Chat object to manipulate the ChatRooms. I use what I call
instrumented BeanMaps for the Chat and POJOs for the ChatRoom. I find
that this works really good compared to the normal problems I have with
scoping variables in ram, i.e. passing them around, checking them in and
out of databases, etc. The combination of request, session, and
application scopes with minimal use of the session and a task scheuler
plugin is opening up new vistas for me. Don't know if this is something
that is useful to you. I tried to use some instrumented forms which are
in the struts catalog wikis and had trouble because they were mapps and
so caused difficulty with the commons utils. My understanding however,
is that this has been fixed in 1.2 and that it could at any rate be
fixed by hand if you wanted to use instrumented ActionForms, which I
have also put on the wiki at struts catalog.
We seem to be thinking along the same lines lately, Rick.
Michael McGrady
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
