The essence is that a 1) WOComponent is created for every occurrence within a specific page template for each session
2) stateless WOComponent is created once for any number of occurrences within
any page template, additional instances are created if a stateless component is
currently used by a thread and requested by another one
3) WODynamicElement is created for every occurrence within a specific page
template
That means that if you have one page where the template uses your component /
element three times and you are serving 5 users you end up with
1) 3 × 5 = 15
2) 1 ≤ n ≤ 5
3) 3
instances of your component / element. For 1) and 2) you can be sure that
during a RR-phase you won’t share an instance with multiple threads (unless you
do some weird things like passing a component instance into a background thread
or stuff like that). However in case 3) those instances are shared with any
thread that requests them which can happen at any time during the RR-loop where
WO does not mind for initialization or cleanup of local values (that is one
point in making those components fast).
jw
> Am 21.03.2017 um 23:18 schrieb Ricardo Parada <rpar...@mac.com>:
>
> 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
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
