Thanks AJ, I'll try that fix in the morning. I've always felt this rule needs to be at the top of the list and in bold. It truly is the ultimate rule. I remember someone (Geoff?) referring to it as the 'almighty' handpicked rule. Maybe we should change it out of utility :) To my knowledge it's broken in 6.0.4 and 6.0.5.
On Jul 25, 6:19 pm, AJ Mercer <[email protected]> wrote: > I have been crash-n-burning burning my way through this one :-( > > It seems to me this is an old-school rule - maybe it could do with a > complete rewrite?? > > anyhoo - my changes so far to update.cfm > > <!--- AJM: added typename ---><ft:object > typename="#stWizard.data[stobj.objectid].aObjects[i].typename#" > objectid="#stWizard.data[stobj.objectid].aObjects[i].objectid#" > lfields="webskin" r_stFields="stFields" /> > > and > > <tr> > <td style="padding:10px;">#teaserHTML#</td> > <td style="padding:10px;"> > <cfif IsDefined('stFields.webskin.htm')> > #stFields.webskin.html# > <cfelseif IsDefined('stFields.displayMethod.html')> > #stFields.displayMethod.html# > <cfelse> > no display tempate > </cfif> > </td> > </tr> > > This has got me to the point where I can save the rule > but now working on execute.cfm > > Also, a couple of bugs for 606 I have submitted > https://farcry.jira.com/browse/FC-2326 > <https://farcry.jira.com/browse/FC-2326>https://farcry.jira.com/browse/FC-2327 > <https://farcry.jira.com/browse/FC-2327> > > On 23 July 2010 19:03, Phillip R <[email protected]> wrote: > > > > > Great, missed this, thought I was going nuts :) Look forward to the > > patch. > > Phil > > > On Jul 17, 2:23 pm, Geoffrey Bowers <[email protected]> wrote: > > > On 17/07/2010, at 8:16 AM, Jeff Coughlin wrote: > > > > > But, yeah. That one change in arrayTable.cfc (setting > > bRefObjects="false") breaks a lot of extended array use we have. Sure we > > can manually turn it on for all extended array components, but is there a > > specific reason for disabling that? Just wondering. Although it breaks > > backwards compatibility, if there is a reason to have it there then we'll > > just have to live with it. > > > > Every time FarCry doesn't know the typename it has to do a findType() > > look up on refObjects. This can be avoided by providing the typename in > > your code, assuming you have it available. We really should know the > > typename in almost all internal core operations, so we've been trying to > > remove core content types (plus rules etc) dependence on refobjects to > > improve overall performance. > > > > We've been implementing these progressive performance enhancements ever > > since 6.0 was released. Note these are supposed to be transparent to users > > and should not be causing compatibility issues in the maintenance branch. > > Apologies for the inconvenience -- it looks like we've over stepped the > > mark on this recent revision and we should have a patch out shortly. > > > > Regards, > > > > -- geoffhttp://www.daemon.com.au/ > > > -- > > You received this message cos you are subscribed to "farcry-dev" Google > > group. > > To post, email: [email protected] > > To unsubscribe, email: > > [email protected]<farcry-dev%[email protected]> > > For more options:http://groups.google.com/group/farcry-dev > > -------------------------------- > > Follow us on Twitter:http://twitter.com/farcry > > -- > > *AJ Mercer* > <webonix:net strength="Industrial" /> <http://webonix.net> | <webonix:org > community="Open" /> <http://webonix.org>http://twitter.com/webonix -- You received this message cos you are subscribed to "farcry-dev" Google group. To post, email: [email protected] To unsubscribe, email: [email protected] For more options: http://groups.google.com/group/farcry-dev -------------------------------- Follow us on Twitter: http://twitter.com/farcry
