I think that would work. The way I see there are 2 "path" areas of concern:
- Create objects using CreateObject-- gotta give the path. This is
doable because you can use dynamic strings, e.g.
CreateObject('component', '#PathToCFC#.Person')
- Ideally specifying the complete returntype path. This is the most
troublesome because you cannot use dynamic strings here.
Item #2 sucks because it then means that I have to use just the CFC
name and no complete path (I havent investigated its complete
limitations just yet). Since I dont know my site names beforehand I
cannot just code these in (as you say, there is no "drag-and-drop"
deployment available).
To some degree mappings would work (at least on the Service/ColdSpring
side of things where object instantiation is done in 1 place, hence
changing the mapping paths is pretty easy), but it doesnt address the
returntype side of things.
/william
On 12/15/05, Nando <[EMAIL PROTECTED]> wrote:
> I believe it works without any problems if you keep all your CFC's in the
> same directory. If for instance i have a factory in a parent directory, and
> i want to instantiate an object in a subdirectory, specifying only the name
> in the returntype without the full path doesn't work. At least it didn't
> work for me the other day. I'd suggest you check that out for yourself. You
> might be able to get away with it by using a factory for each directory that
> takes care of instantiating all the classes in that directory - that idea
> just occured to me. Not sure what problems i'd run into there tho'.
>
> If you haven't done so, you might check out BlueDragon. They've implemented
> a new mapping tag that allows you to specify application specific mappings,
> and the final release of that update is out in a few days, i believe. It's a
> solution that's aimed squarely at the problem you're trying to solve.
>
> http://blog.newatlanta.com/index.cfm?mode=entry&entry=9FC194BA-D28D-7C53-4C3
> F848A4BC5550D
>
> Then i think you wouldn't even need the dynamic bit here
>
> Obj = CreateObject('component',
> '#Request.SiteName#.Objects.Person').init();
>
> you could simply use the same name for all your sites, for example:
>
> Obj = CreateObject('component',
> 'Site.Objects.Person').init();
>
> and map Site uniquely for each application.
>
> As an aside, I'm wondering if ColdSpring can help here. As far as i've seen,
> the paths to each CFC need to be declared explicitly in the XML config file.
> If i needed a "drag and drop" style deployment as you describe (and i do),
> how could that be handled using ColdSpring? (on CFMX). Maybe i'm not
> thinking broadly enough and don't see it, but at a minimum, i would assume
> you'd need to go through the XML and rework each path statement to point at
> the new site location. That might not be so bad, as it's all there for you
> in one file. Back it up, a careful search and replace on a single file, and
> you're (hopefully) done.
>
> Would that work as i describe?
>
>
>
> >-----Original Message-----
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> >Behalf Of William Langshaw
> >Sent: Thursday, December 15, 2005 10:45 PM
> >To: [email protected]
> >Subject: [CFCDev] CFC name vs. full path in returntype attribute
> >
> >
> >I am wondering what kind of ill-effects can arise from NOT using the
> >CFC's complete type (path) in the returntype attribute. That is, using
> >
> >Returntype="Person"
> >
> >As opposed to
> >
> >Returntype="com.sitename.foobar.Person"
> >
> >Obviously, in a perfect world the complete path would be better as its
> >not ambiguous and CF can perform run-time type checking (as much as
> >possible for, which for CF isnt that much). We are considering an
> >application controlled by MachII that in turn can control many
> >different "sites" (e.g. foo.com, bar.com, baz.com) using 1 core
> >"MachII" framework (at the root) and then the root index.cfm does a
> >lookup on CGI.SERVER_NAME to do a lookup and include the correct path
> >to that site's mach-ii.cfm. The idea is that every site would then
> >have its own set of CFCs which all inherit from a Core CFC suite (so
> >each site can be customized). But for every site specific CFC it would
> >have to specify its complete path and this wouldn't be always known.
> >E.g. we want to be able to quickly make a new site and use it, so all
> >object creations would look like:
> >
> >Obj = CreateObject('component',
> >'#Request.SiteName#.Objects.Person').init();
> >
> >That is, the system is purely dynamic. But now you can see that the
> >returntype would have to be just the CFC name and not a complete path
> >since that isnt really known.
> >
> >Are we going totally off the deep-end here? The idea is that we
> >develop 1 code-base to share amongst many different sites with a few
> >little tweaks here and there (done by extending core objects) but for
> >the most part they would all be same, except for the presentation and
> >view layer, obviously.
> >
> >Any ideas?
> >
> >Thanks in advance
> >/cody
> >
> >
> >----------------------------------------------------------
> >You are subscribed to cfcdev. To unsubscribe, send an email to
> >[email protected] with the words 'unsubscribe cfcdev' as the
> >subject of the email.
> >
> >CFCDev is run by CFCZone (www.cfczone.org) and supported by
> >CFXHosting (www.cfxhosting.com).
> >
> >An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
>
> ----------------------------------------------------------
> You are subscribed to cfcdev. To unsubscribe, send an email to
> [email protected] with the words 'unsubscribe cfcdev' as the subject of the
> email.
>
> CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
> (www.cfxhosting.com).
>
> An archive of the CFCDev list is available at
> www.mail-archive.com/[email protected]
>
>
>
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
