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-----So essentially - you have a directory for cfcs that is shared across apps?
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 question
(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
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]
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]
