> Or > re-engineer fourq et al to look at a new attribute like proptype or > something (a fair bit of work required).
I think we may have spoken about this down at MXDU, Geoff. And I think it may need addressing completely separate from the BD issue. While I have always thought it was a brilliant use of the <CFPROPERTY> tag I have also been concerned that something in the tag may change in the future and that fourq would be the victim. As Tim has mentioned, BD may be doing stricter checking (or may have a bug). I think there may be a few places outside fourq that use getMetaData() directly to get properties rather than through the fourq::getProperties() method. While there are obvious points where fourq is relying on the getMetaData() method to obtain properties, the REAL hitch is re-coding all the derived types to NOT use <CFPROPERTY> but a different method and catching any points that use getMetaData() for properties and re-coding them to use fourq::getProperties(). However, if a new tag were created that mimicked <CFPROPERTY> and included using a <CFIMPORT> then that would reduce the effort considerably (e.g. a <fourq:property> tag instead with the same set of attributes as <CFPROPERTY>). While each fourq-derived class would have to be visited, the changes to each file could probably be scripted using a search/replace. Unfortunately, I don't have any spare time to allocate to doing any of this at the moment. Regards, Gary Menzel --- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
