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 
>> <mailto: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 
>>> <mailto: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 
>>>> <mailto: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 
>>>> <mailto:Webobjects-dev@lists.apple.com>)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com 
>>>> <https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com>
>>>> 
>>>> This email sent to sam...@samkar.com <mailto: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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to