From: Ramsey L. G. <rg...@ma...> - 2009-04-18 16:09:17
|
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 |
From: Denis F. <df...@de...> - 2009-04-19 08:54:50
|
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 > > |
From: Ramsey L. G. <rg...@ma...> - 2009-04-19 12:48:21
|
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 >> >> |
From: Ramsey L. G. <rg...@ma...> - 2009-04-19 12:59:56
|
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 |
From: Denis F. <df...@de...> - 2009-04-19 15:57:32
|
On Sun, Apr 19, 2009 at 4:59 PM, Ramsey Lee Gurley <rg...@ma...> wrote: > 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... Didn't now about ERDDelayedSwitchAssignment's existence up until now... Looks like a way to go. > Thanks again Denis :) Glad that I could help. > > 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 > > > ------------------------------------------------------------------------------ > 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 > |