> > 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 > ...
Very good and appreciated explanation of how this works. > 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? 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? Anyone else have thoughts about this? Well I'm glad the testing brought up something to consider before the official release :-) Frederic -- [EMAIL PROTECTED] _______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
