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?
I can't think of a good use case for the 'feature' either.. but if you
did
need this kind of behavior, would it be possible to do it yourself in
your
element and have the default behavior not have this 'feature/bug'
in it?
Not without saving off the state temporarily yourself as for example
request attributes and making your embedded elements aware of that.
I thought of another possible fix for this, instead of having a
parallel map, keep the same map and detect when there are several
executions of the same element instance. If that's the case, their
execution ordinal is added to each element's context id. This means
that each execution has its own state. This sounds very nice and
powerful to me, however I can already see problems with it too. When
the order of execution is different in the embedding element, the
wrong state will appear in the wrong embedded element.
Anyone else have thoughts about this?
Yeah, some other people have any thoughts about all this?
--
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
