Hi folks,
This question is about a technique I've used in a custom ViewHandler.
I'm asking if you folks think this technique is a fragile hack or a
portable and correct overriding of the default JSF behaviors.
I am using JSF (specifically, MyFaces) to write an application which
would be greatly simplified if my UIComponents did *not* have to save/
restore state, and I am willing to live with the dependency on that
fact. (See below for more details.)
Since I am using a custom ViewHandler anyway, I tried overriding
ViewHandler methods renderView and restoreView to *not* call the
state saving mechanism. The result is that I can run my app without
UIComponent methods processSaveState or processRestoreState ever
being called, which is what I want.
Hence my question: do you folks see any problems with this approach?
* * * * *
More details about my application follow.
I am writing a UI for a scientific database where the user community
is small, so there is no problem with keeping all current user
sessions in server memory at a given time. I am generating the UI
(mostly "property sheets" for now) via metadata, so I am not using
JSP pages at all -- everything is programmatic. My domain objects are
persisted to our database using JDO.
The problem with the save/restore state cycle is that it forces me to
swizzle various Java references to domain objects, etc. For example,
I cannot just addPropertyChangeListener() to one of my domain
objects, to update the UI, without worrying about what's going to
happen to the views on the next cycle.
It would be much easier -- and more "rightsized" for my application
-- to simply avoid the save/restore state cycle altogether, and just
keep each HTTP session's UIComponent tree live in server memory as
long as the session is active.
* * * * *
Thanks & peace,
Ihab
