I have a tendency to work much with a combination of:
2) A plugin/COAL like implementation that gives you a singleton apon request to a service.
3) Using relative type and extend attributes using / or \ synatx
To get my stuff going.
I try and make little 'black box' folders that use relative / typing for each sort of thing that I do. These have a top level Factory class that should be created as a singleton to manage the functionality of that 'Black Box'
I also have an XML file that links to a CFC that let's me pull my top level Factories out (much like COAL, but only for Factories), and I then use those Factories as my public interface to the functionality provided.
It's not ideal, it means sometimes I have to have 2+ of the same CFC's in different directories in the same application (erk!) and do things like that, but that's the best way I have found to work around the issue.
There are alot of bad things with this approach - i.e. the / syntax is not documented - but I'm happy to work with what I've got, and then change it when a better option comes along.
Let me know what you decide to do.
On 5/5/05, Nando <[EMAIL PROTECTED]> wrote:
Mark,If you had to choose a workaround today, which one would you go with? Right now my choice would be a flat directory structure with a prefix naming convention that kind of simulates a directory structure for me. The only con there is the lack of file organization and no packaging possible (the latter i'm fine with, the former i can live with much more easily than abandoning inheritance.) Am i missing something?-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mark Mandel
Sent: Thursday, May 05, 2005 2:10 AM
To: [email protected]
Subject: Re: [CFCDev] Basic component inheritance path questionSo essentially - you have a directory for cfcs that is shared across apps?ICQ: 3094740 ----------------------------------------------------------
(or a single app). Well, we can go around in a circle once more and state that that isn't a viable option in all circumstances.
So what you have done is work around the fact you can't do inheritence across packages, and you can't do typing across pacakges.
We keep going around in this circle -
1) There is a real issue that CFC's can't be namespaced and ported easily. Because the fact is, they can't.
2) There is 'X' workaround, that allows you to get past *some* of the issue
3) Yes, but what abou the part it doesn't work for?
4) Goto (2)
And we can go around and around and around as much as we like.
Ultimately it looks the following workarounds are viable solutions, and they each have their own issues (in no particular order)
1) Flat directory structure
2) A plugin/COAL like implementation that gives you a singleton apon request to a service.
3) Using relative type and extend attributes using / or \ synatx
4) Using a custom mapping
5) Starting from the root of the app.
It should well be noted that none of these *really solve the problem*. They are simply workarounds.
The fact is you can't easily port CFC code from one codebase to another with any sort of ease I believe is a *serious* flaw in CF. I can't think of another language I've worked with that has also got this issue.
I love CF, don't get me wrong. But I do find this issue seriosuly limits the amount of growth I can have with it as a developer, because it is a serious limitation on the capability of the systems i can write from an OO perspective.
I mean, at the end of the day, as a framework like mach-ii shouldn't need to be installed as a root on the server, it should just be able to be dropped in at any level of a application directory, and be able to be just RUN. There shouldn't be all this fussing around to get types and issues with extensions etc going, it's just getting silly.
That's my 2c.
Mark
On 5/5/05, Stijn Dreezen <[EMAIL PROTECTED]> wrote:On Wed, 4 May 2005, Nando wrote:
> Stijn,
>
> So basically, what you're doing is isolating the apps from each other by
> containing them within a Singleton - did i get that right?
Exactly
> "... from the cfc's in the BaseCFCPath ..."
> sounds like composition to me.
>
> How do the paths get resolved properly when using extends, arguments ... ?
> Or are you using a flat directory structure?
No
During runtime, I always have a unique path to each method in each cfc,
wether it be static (in the application singleton) or in a instance (in the session,
to which i have a pointer in the application singleton).
During compile-time (extends, datatypes, ...), for the naming, i have the
luxury to be able to use the same directory, which is very unlikely to change.
I must say i rarely Extend, and i only do it if i know for sure i can use a fixed path (so i wont extend cfc's
that are deeper in the three past the point where i need a variable, for
example an application name. I have a number of cfc's which are quite
generic and which i DO extend often (QueryManagers, Caching Managers,
Logging, ...) which don't belong to a specific application, and are
available to all applications with a hardcoded path
(int.eu.consilium.common, while application-specific cfc's reside in
int.eu.consilium.#appName# ) into the appName cfc scope.
I'm sure it has a name, but i'm not good with OO terms and i am only using
patterns for 2 years, so i'm still a noob,and i dare not put names on it,
chances are high i'd label it wrongly.
I hope it makes a little sence what i'm saying, its hard to explain if you
don't master the OO/dp vocabulary very well.
Cheers,
Stijn
>
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
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]
--
E: [EMAIL PROTECTED]
W: www.compoundtheory.com
ICQ: 3094740 ----------------------------------------------------------
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]
