>
>Stephen Milligan spoke the following wise words on 3/07/2004
>12:28AM EST:
>> 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.
Ah, I see what you're saying.
Yes, I think this is a good idea.
>
>>>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.
Agreed.
>
>Also, you may not always want the instance from application
>scope -- you
>may want to instantiate a new instance.
Very true.
>
>It's my opinion that it makes the most sense to use the factory design
>pattern in this case.
>
Yep, applying some design patterns to Farcry would probably be a good idea
and the factory pattern would work well 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.
>
I see what you're saying now.
Essentially it's adding a bit of abstraction to allow for more cohesion and
less coupling.
That's probably a good thing in the long run and it's principle that I think
should be applied to a lot of what goes on in Farcry. The only downside is
that adding abstraction requires that you have something documenting what is
going on. Again, I think this would also be good for Farcry in the long run,
so long as it gets done.
>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.
Indeed.
---
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/
