Well, in that case, you'd need to modify the codebase for each individual
app you'd install on the same server. For instance:
root.app1.model.dao.UserDAO
root.app2.model.dao.UserDAO
Is
that what you mean? If i need to change that in a few thousand places in the
codebase, i can just as well change the mapping. It's not the mapping per se,
it's the code that uses it that i need to remain consistent across all
installations - or at least as consistant as possible.
Mappings would be OK for me if i dealt in quantities under
10 installations or so. It's when it gets up to 50 that you start running out of
support staff patience and separate webservers at your favorite webhosting
company. Or some variation on that theme.
An
alternative plan would be to use the same model directory for all installations,
and put them on a dedicated server. But i'm very reluctant to do that
because some clients want customizations. What happens if the customization
would break 100 other installations on the server? Worse, what if it would
conflict with 24 other installations and i didn't notice right
away?
I'd
rather have them isolated from each other, so that once it's working, i don't
touch it. And if i do for some reason, like a bug fix, i only touch one at a
time so that if anything unexpected happens, i can repair it
quickly.
I
read somewhere that the reason you can't use variables for types, arguments and
extends is because those need to be resolved at compile time, not at run time.
Without knowing much of anything about the compile process, that sounds
reasonable to me. Which is why i *think* the application specific mapping
solution would be the way to go. If we ask for something that is hopefully more
easy to accomplish, it might happen.
The
same happens to my clients. If they ask for something that is easy for me to do,
i generally do it right away.
Which is why i've been postponing updating the Japanese version of this
website .... i should really learn to say "I don't do HTML"!
---------------------------------------------------------------Original Message-----Nando...
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Jared Rypka-Hauer - CMG, LLC
Sent: Wednesday, May 04, 2005 3:31 AM
To: [email protected]
Subject: Re: [CFCDev] Basic component inheritance path question
In colloqial terms, "evil" can mean anything from michievous to "I really really don't like them" and I think the latter is close to Roland's meaning.
Maybe I'm missing something here... and granted, I can see the benefit of sharing a codebase across sites... but I've written anything I needed to redeploy using the webroot as the base of the CFC's path. I haven't seen anyone address this as viable/not viable as a solution.
I think the best idea is to allow a variable as part of a CFC type so that "#myapp#.lib.cfc.foo" is a valid type. If the directory isn't there, it throws an error as if it couldn't find a file.
Laterz,
J
On 5/3/05, Nando <[EMAIL PROTECTED]> wrote:I haven't lived in America for 25 years, so i'm probably not up on the use
of the word "evil" in everyday speech. But in my very direct experience, for
those of us that are creating applications to be distributed on anything
"less" than a dedicated server, server-wide mappings tend to create bigger
problems than the ones they attempt to solve, and it's very possible you
might not see it coming.
On a larger scale, for all the reasons Roland lists, they limit your ability
to create a viable business with what needs to be a plug and play
application. I've got nearly 2000 instances of a mapping in our code base.
And the app isn't THAT big. Once you start relying on CFC's, mappings, if
you use them, are all over the place.
I would add to his list that whenever you are forced to search and replace
the mapping so you can install a separate instance on a server ... you make
it "twice" as difficult to maintain your codebase across installations with
bug fixes and improvements. That can get out of hand exponentially!
To expand our business, either we're going to have to modify our codebase
and move toward what Roland is doing, perhaps using a single directory for
all CFC's so i can use inheritance. Or wait until CFMX has application
specific mappings.
We had a provisional offer to include our app within another much larger
online service. They wanted it now. I backpedaled largely because of the
mapping issue, and the deal fizzled. It might have fizzled anyway if i had
gone for it, but i couldn't really take the first step forward.
Is that evil? Well, let's just say it was a little unfortunate.
--
---------------
-------------------------------------
Buy SQLSurveyor!
http://www.web-relevant.com/sqlsurveyor
Never make your developers open Enterprise Manager again. ----------------------------------------------------------
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]
