I think you stumbled into a bug though since it seems that even if
you explicitly call processEmbeddedElement afterwards it looks like
the new state of the embedded element isn't replacing the old one
(the one that resulted from the default render).
Ok, I looked into this and it can be seen as a feature instead of a
bug ;-)
Would be nice to get some thoughts from other people about this
though to see if it doesn't need fixing anyway.
RIFE collects the state of elements by maintaining a map of result
states. The keys of the map are the logical contextual IDs of the
elements. These are built from the embedding hierarchy of element
IDs, the active element ID and the element's differentiator. So each
element in your page has a unique ID identifying it.
The state of each element is collected stored into the map after
right after processElement has finished executing. The map of states
is then stored according to the state storage mechanism (in the query
string it will be a base64 value, in the session it'll just remain a
map).
When a request comes in, all the states are restored and the elements
execute by receiving the appropriate inputs, taking their preserved
state into account.
Now in your case, when you have the tag (without the + sign):
<r:v name="ELEMENT:Table:1"/>
This embedded element will be executed a first time when the template
is instantiated, after its execution its state is put into the map.
The second time you execute it manually with processEmbeddedElement,
and again the state is stored, but with the same contextual ID (so it
replaces the state of the first execution).
The request finishes and after a click, the next request starts. The
state of the second execution of the embedded element from the
previous request is now however passed to the first execution when
the template is instantiated (since the contextual ID is the same).
The execution of that one results into a new (empty) state, that
replaces the state that was stored after the first request. So now,
the second execution of this embedded element in the second request
will receive the state of its first execution in that same request.
The result is that it seems that the state is lost.
Now I need to decide if this needs fixing.
The 'feature' that this provides is that you can create new states
inside the same request for subsequent executions of the same element
instance. Not sure if that's actually handy though, and I can't find
a good use case for it. So I'm inclined to fix 'the bug'.
The easiest way to fix this is to simply separate the state map that
is restored when the request executes, from the one that is built
from the execution of the elements.
What do you guys think?
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
[email protected]
http://lists.uwyn.com/mailman/listinfo/rife-users
