Re: [Wonder-disc] D2W rule system + userPreferences

[Ramsey L. G. <rg...@ma...>]

Hmm,

Or perhaps use a delayed switch assignment...  That might actually be  
able to reduce the number of rules I need to make this happen. That  
was my original intent anyway...

Thanks again Denis :)

Ramsey

On Apr 19, 2009, at 8:48 AM, Ramsey Lee Gurley wrote:

> Hi Denis,
>
> Thank you for responding :)
>
> I don't think moving the pageView assignment out of a delayed
> assignment is going to be an option, because there's really going to
> be no way to tell when the value has changed.  The userPreferences
> object is (usually) a singleton so it never changes.  Only the values
> it produces change.
>
> I agree with you on 2) that a conditional assignment would be clumsy
> given I have four values.  I was unaware the rule system cached lhs
> for delayed assignments up until now, so this is good to know.  I
> discovered in debugging it also drops dependentKeys() that resolve to
> a delayed assignment as well.  I'll have to review my rules and
> assignments to make sure I haven't made this mistake elsewhere.
> Looking again, I can see the ERDDelayedAssignment docs do hint at  
> this.
>
> It looks like I'll need to go back to coding this directly into the
> component and getting the keys for each view off an enum instead.
>
> Ramsey
>
> On Apr 19, 2009, at 4:54 AM, Denis Frolov wrote:
>
>> Hi Ramsey,
>>
>> LHS of the rule is indeed cached even in case of delayed assignments.
>> Have a look at this thread for details -
>> http://thread.gmane.org/gmane.comp.web.webobjects.wonder-disc/6260
>>
>> I guess your options are:
>> * Get rid of delayed assignment in LHS (e.g. resolve  
>> viewComponentName
>> using new assignment)
>> * Use ERDDelayedConditionalAssignment and move your condition to it's
>> "qualifierFormat" (solves the caching issue but is somewhat hackish
>> and clumsy).
>>
>> Denis
>>
>> On Sat, Apr 18, 2009 at 8:09 PM, Ramsey Lee Gurley <rg...@ma...>
>> wrote:
>>> Hi all,
>>> I'm trying to build rules based on current userPreferences but so  
>>> far
>>> nothing works.  It seems no matter what I do, my preference gets
>>> cached and
>>> the rules always evaluate the same way once the preference is in
>>> the rule
>>> system.  So far, I have the following in an ERDDelayedAssignment
>>> subclass
>>> /**
>>> * The rhsKey is the preference key. Default values are defined
>>> using a
>>> * similarly named default key in the D2WContext. The preference key
>>> * and the default key should be named using a xxx, defaultXxx naming
>>> * convention. Examples are batchSize, defaultBatchSize and
>>> sortOrdering,
>>> * defaultSortOrdering.
>>> * @return the user preference value for the preference key or the
>>> default
>>> * value if no user preference value is found.
>>> */
>>> @Override
>>> public Object fireNow(D2WContext c) {
>>> String rhsKey = keyPath();
>>>
>>> // Get the default value
>>> StringBuffer sb = new StringBuffer(rhsKey);
>>> sb.setCharAt(0, Character.toUpperCase(sb.charAt(0)));
>>> sb.insert(0, default_key);
>>> Object result = c.valueForKey(sb.toString());
>>> // Get the preference for the RHS key
>>> String prefKey =
>>> ERXExtensions.userPreferencesKeyFromContext(rhsKey, c);
>>> NSKeyValueCoding userPreferences = (NSKeyValueCoding)
>>> c.valueForKey(UserPreferencesKey);
>>> if (userPreferences != null) {
>>> Object pref = userPreferences.valueForKey(prefKey);
>>> if(pref != null) { result = pref; }
>>> }
>>> // Return the preference
>>> return result;
>>> }
>>> This works, but it seems the lhs side of the rule is being cached.
>>> I have
>>> four rules defined to give me a componentName based on the
>>> preference value
>>> that look something like:
>>> pageView = 'VIEW1' => viewComponentName = "view1ComponentName"
>>> ERDDelayedKeyValueAssignment
>>> pageView comes out of the above assignment method.  When I set a
>>> breakpoint
>>> in fireNow, it gets called four times initially and then it is
>>> never called
>>> again no matter how many times I change the pageView.  I've tried
>>> making
>>> this assignment an ERDAssignment with dependentKeys of
>>> ("userPrefenences")
>>> but that didn't work.  In desperation, I also tried creating an
>>> ERDAssignment to use in place of ERDDelayedKeyValueAssignment with a
>>> dependentKeys of ("pageView").  Still no luck.  It seems no matter
>>> what I
>>> try, the rule's lhs value has been cached and I cannot get the rule
>>> system
>>> to re-evaluate it.
>>> Any insight/advice would be appreciated...
>>> Thanks everyone,
>>> Ramsey
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Stay on top of everything new and different, both inside and
>>> around Java (TM) technology - register by April 22, and save
>>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>>> 300 plus technical and hands-on sessions. Register today.
>>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>>> _______________________________________________
>>> Wonder-disc mailing list
>>> Won...@li...
>>> https://lists.sourceforge.net/lists/listinfo/wonder-disc
>>>
>>>
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Wonder-disc mailing list
> Won...@li...
> https://lists.sourceforge.net/lists/listinfo/wonder-disc