Gary Menzel wrote:
We are finding (as we start building more and more facilites to access our existing databases) that the includedObj directory is getting full of a lot of files. This is starting to make it difficult to manage.
Is there any reason why some of these could not in fact be publishing rules? Wouldn't this give you greater flexibility in terms of how you deploy the functionality.
In some instances, we have created subdirectories to hold ancillary "includes" that are pulled in based on state (think fusebox style of thing with one includedObj that controls a set of functions) but this doesnt always satisfy every need.
We do a similar thing for include objects with PLP steps.
PROPOSALS:
1. Allow the included objects that are display and accessed to reside in subdirectories - but each "exposed" file will be prefixed with an underscore (_). While this is not restricted as such in FarCry at present, it is the default "model" that is used (I dont know if people who use includedObj have deviated from this at all).
Your suggesting the selection list is populated from a recursive look at all _filename.cfm files in the branch? Sounds reasonable.
2. Extend the included object facility to have a FarCry config variable to specify one OR MORE subdirectories that can contain included objects.
Perhaps this should be a "_serverspecificvar". ie. you could override it programatically in the project code base instead of adding to teh list of general config items?
AND - I also would add the standard FarCry comments (DisplayName/Author) parsed and displayed in place of the CFM filename (as is done with template files).
I think this is a must. The edit handler for include objects is rudimentary at best.
-- geoff http://www.daemon.com.au/
--- 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
