I was looking over the code, and I saw this:
if (!_tracker.getHasErrors()) _tracker.clear();
and should be:
if (!_tracker.getHasErrors()) {
_tracker.clear();
ValidationTracker tmp = _tracker;
_tracker = tmp;
}
Fernando Padilla wrote:
Another nuance I see is that a form keeps displaying the old input
values.. when normally those are cleared after a form submits. So I'm
assuming that the ValidationTracker is not being properly cleared, so
maybe some code that clears the validationTracker isn't "setting" it
afterwards.
that is, if my theory and ideas, so late in the night are close to true. :)
food for thought.
fernando
Fernando Padilla wrote:
So.. I need confirmation on an HttpSession expected behavior, to see
if there is an annoyance with @ApplicationState and @Persist:
a) Object value = session.getAttribute( key );
b) value.modifyMe();
c) session.setAttribute( key, value );
It was my understanding (maybe really old servlet spec), that sessions
would not guarantee changes in attributes (line b) to be property
persisted unless you called setAttribute directly (line c) to tell it
the value has changed. This was to support persisted or distributed
sessions that might be dealing with copies of values intead of a
single centralized instance.
If this is the case, then modifications to ApplicationState objects
require you to explicitly set them again in order for modifications to
actually take:
@ApplicationState
private MyASO aso;
a) MyASO tmp = aso;
b) tmp.modifyMe();
c) aso = tmp;
Most session stores that people use (default ones for tomcat/jetty)
have in memory caches, and we probably do lots of testing in single
boxes, not distributed session stores. But I just ran into this
behavior trying to use a Memcached backed session store: I noticed
that changes to our ASOs were not being stored in the session store.
(yes I just implemented the memcached session store)
So some questions for discussion:
1) do you agree with the spec as I stated above, and thus the
resulting bug? Or is the session store suppose to be really smart and
autodetect when changes occur, or really inefficient and write back
all attributes that were loaded during the request?
2) Can tapestry do anything to help us out? To make this fool proof.
How easy would it be to implement a ASO modification checker, where
at the end of the request (before it clears variables), Tapestry woud
ask the ASO if it has been modified, and if so, set it for us?
3) The above behavior is theoretically present in @Persist as well,
but I have not tested it yet. How does @Persist track changes?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
