Was that in a session-less app instance perhaps? I have not tested that scenario.
In my test I do not see dynamic elements being shared across sessions, so I'm not seeing exactly how is it that concurrency plays a role in the session app scenario where the dynamic elements are not shared with the ones from other sessions processing a request at the same time.
But again, there may be something else, a property or something that affects this sharing that I may be missing.
Anyways, the consensus is that it is a bad idea, so I'll follow advise and implement it as a WOComponent subclass instead.
Thank you all. On Mar 21, 2017, at 5:34 PM, Chuck Hill < email@hidden> wrote:
I’ve run into code that did this in the past. It is very, very much not fun to debug. You could stash the values in a ThreadLocal or in the context.userInfo(). But don’t ever add state to a WODynamicElement
subclass.
Chuck
you are ignoring one very important aspect of dynamic components: they must be thread-safe!
As soon as you are holding local values you will head to a serious mess. In your „manual“ tests of course you probably won’t ever encounter concurrency problems as long as you are not doing sort of automated parallel tests where multiple
request are processed concurrently. Just think about why WO uses constructs like WOAssociations in dynamic components which introduce an additional layer of complexity to exchange / access request dependent values. Surely not for the fun of it ;-)
Of course concurrency problems only show up infrequently and are often not reproducible. So depending on the number and activity of your app users you could have been just luckily to not run into any problems or—most likely—did not notice
when you actually hit one of those situations.
PS: If you have access to the recordings of WOWODC 2012 there is actually a talk on dynamic elements.
Am 21.03.2017 um 21:11 schrieb Ricardo Parada <email@hidden>:
I’m just reporting back on my findings on whether saving state between appendToResponse and a subsequent takeValuesFromRequest in a dynamic component is bad or not.
I read Chuck’s Practical WebObjects, p. 193 where it talks about Dynamic Elements. As he pointed out there, dynamic elements are shared among all instances of a WOComponent subclass. My MPVWOConditional is implemented as a dynamic element
because it extends ERXWOConditional which then extends WODynamicGroup which then extends WODynamicElement.
To test this I created a Hello app with a single page, Main.wo. I have three MPVWOConditionals in there. An instance is created for each occurrence of my MPVWOConditional in Main. A total of three to be exact.
I then have a link on Main that calls an action returning a new instance of the page Main:
public WOActionResults newPage() {
return pageWithName(Main.class);
Every time this newPage() action gets called I can confirm that the constructor in Main gets called, which indicates that a new page is being created every single time this action gets called.
However, the constructor of the MPVWOConditional is not getting called three times as when the first/second time the page was created. On the other hand, the appendToResponse() of the MPVWOConditional keeps getting called three times,
once for every instance of MPVWOConditional in Main. The hashCode() of each of these three MPVWOConditional coincides with the ones that were previously created.
To summarize, when new instances of the page are created, the MPVWOConditionals are being reused on new instances of the page.
Fortunately, the dynamic components are not shared among page instances from different sessions. Which makes sense. The sharing only applies among instances within the same session.
I can see how some might object to storing this state in the dynamic component. It has worked like this all this time. It’s the way it works.
However, I think it is okay to save this piece of state between an appendToResponse and a subsequent takeValuesFromRequest because the takeValuesFromRequest is being done on the same page that generated the appendToResponse.
Furthermore, if a new page is created and the components are shared, their appendToResponse will get called and this piece of state will be re-computed and saved awaiting a subsequent takeValuesFromRequest.
Now, let’s assume that instead of submitting a form, a regular action is called on the page. Let’s suppose this action retrieves the previous page from some sort of cache and returns that page. Then that page’s appendToResponse will get
called and so will the appendToResponse of the dynamic components being shared, which would recompute the condition and save it awaiting a possible subsequent takeValuesFromRequest or invokeAction. Again, this behavior just makes the appendToResponse consistent
with the invokeAction/takeValuesFromRequest phases.
Having this behavior has corrected problems for me. It is yet to be determined whether this will create a problem. If I find out later that this creates a problem I’ll be happy to report back to the group.
But so far, on my tests, it looks like it is okay.
Thanks for all the comments and feedback.
On Mar 14, 2017, at 10:46 AM, Samuel Pelletier <email@hidden> wrote:
This patch seem dangerous to first. I do not thing it is safe to have state in WODynamicElement. I think they can be reused by the framework.
The correct way is to make sure the condition does not change during RR loop cycle, same apply to WORepetition list for example.
Le 14 mars 2017 à 09:53, Ricardo Parada <email@hidden> a écrit :
Thanks Samuel. I see that now.
Have others experienced a problem where a form is submitted and then during takeValuesFtomTequest a condition that was false when the page was rendered becomes true all of a sudden causing some input elements (textfields, pop-up list, etc.)
to participate in takeValuesFromRequest even though those elements were not on the page when the form was submitted? This causes those elements to be set to null. I've ran into such bugs in the past many times.
I have been able to prevent that from happening by using the following code:
public class MPVWOConditional extends ERXWOConditional {
protected boolean conditionValue = false;
public MPVWOConditional(String name, NSDictionary dict, WOElement element) {
super(name, dict, element);
public void appendToResponse(WOResponse woresponse, WOContext wocontext) {
// Cache the condition every time the page is being rendered
conditionValue = _condition.booleanValueInComponent(wocontext.component());
super.appendToResponse(woresponse, wocontext);
* Returns the value for the condition binding cached during appendToResponse.
* This makes the takeValuesFromRequest consistent with the appendToResponse
* preceding it by making sure that input elements that were not present on
* the page at the time the form was submitted do not participate in
* takeValuesFromRequest inadvertently.
protected boolean conditionInComponent(WOComponent wocomponent) {
On Mar 14, 2017, at 9:39 AM, Samuel Pelletier <email@hidden> wrote:
If you use inline bindings with ONGL, the class WOHelperFunctionTagRegistry registers classes mapped to tag
WOHelperFunctionTagRegistry.registerTagShortcut("ERXElse", "else");
WOHelperFunctionTagRegistry.registerTagShortcut("ERXWOConditional", "if");
WOHelperFunctionTagRegistry.registerTagShortcut("ERXWOConditional", "conditional");
Le 13 mars 2017 à 19:46, Ricardo Parada <email@hidden> a écrit :
Does anybody know where does ERXWOConditional install to replace WOConditional?
I created an MPVWOConditional which extends ERXWOConditional and fixes a bug and want to install it as the one to use for WOConditional.
I checked in ERXPatches but it does not seem to be getting installed there. Does anybody know?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
|