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
