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 <ch...@gevityinc.com> 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
>
> From: <webobjects-dev-bounces+chill=gevityinc....@lists.apple.com> on behalf
> of Johann Werner <j...@oyosys.com>
> Date: Tuesday, March 21, 2017 at 2:19 PM
> To: Ricardo Parada <rpar...@mac.com>
> Cc: WebObjectsDev <webobjects-dev@lists.apple.com>
> Subject: Re: ERXWOConditional - where does it get installed?
>
> Hi Ricardo,
>
> 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.
>
> jw
>
>
> 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 <rpar...@mac.com>:
> Hi all,
> 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.
> Ricardo
> On Mar 14, 2017, at 10:46 AM, Samuel Pelletier <sam...@samkar.com> wrote:
> Ricardo,
> 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.
> Regards,
> Samuel
> Le 14 mars 2017 à 09:53, Ricardo Parada <rpar...@mac.com> 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);
> }
> @Override
> 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.
> */
> @Override
> protected boolean conditionInComponent(WOComponent wocomponent) {
> return conditionValue;
> }
> }
> On Mar 14, 2017, at 9:39 AM, Samuel Pelletier <sam...@samkar.com> wrote:
> Hi,
> 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");
> Samuel
> Le 13 mars 2017 à 19:46, Ricardo Parada <rpar...@mac.com> a écrit :
> Hi all,
> 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?
> Thanks
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com
> This email sent to sam...@samkar.com
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/jw%40oyosys.com
> This email sent to j...@oyosys.com
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
