I'm not sure I understand what you're saying here. Pretty much everything that needs to be loaded is loaded at application start up and lives in the application scope. When you need to use it in your code you just need to reference the copy in application scope rather than creating a new instance.
Just like my initial suggestion that anybody can override any of the application scope component instances already with their own cfcs in _applicationInit.cfm
Why I mentioned that there may be a problem is that from memory I have seen a fair few instances where people's code are instantiating types directly. If the still need to instantiate the types directly then I believe using a factory component would make the most sense.
The component factory will also need a programmatic interface to setting component extensions, for e.g.:
application.comFactory.setComponent("core.com.path","new.com.path");
I don't think so.
I see this more like the custom admin xml file. There isn't a programmatic way to modify that because it really doesn't change apart from during the development of a project. I think the component registry would be the same.
I've already put my objections down for having no programmatic interface to getting certain aspects of the custom admin (such as just generating a URL that refers to the correct custom admin page). If there was a custom admin component then I wouldn't have to copy+paste the core's implementation of how they calculate the parenttabindex value.
Also, you may not always want the instance from application scope -- you may want to instantiate a new instance.
It's my opinion that it makes the most sense to use the factory design pattern in this case.
All you want to do is say 'hey, gimme the tree component', and it should return the correct one (either the core or the extended version) for the current project.
In a standard install the factory component would only be called twice.
Firstly by the XML loader class to set the component path for each core component.
Secondly by the application init which would populate the application scope with the relevant component instances.
A separate component should be responsible for loading the XML file and making the relevant calls to the comFactory to set the project's extensions.
I'd have all of this happen in the application initialization code in farcry_core.
Essentially replace all the try/catch blocks that check for custom components with some code that reads the xml file and checks to see if a custom component has been defined.
Sure that would work, but it's my opinion that it would be more suitable to have the two roles separated into separate components. The registry doesn't need to know of the storage mechanism.
Either way it would make no difference to the end user which way you do it -- they'll still be just defining the xml file.
-- tim lucas
http://www.toolmantim.com
--- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
