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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
