in a shared enviroment, the root of the site is not the phisival web root,
and generally you do not havve access to this
regards
salvatore
----- Original Message -----
From: "Sean Corfield" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, November 08, 2005 5:07 PM
Subject: Re: [CFCDev] CF Pro vs Ent (was factory pattern)
On 11/8/05, Patrick Branley <[EMAIL PROTECTED]> wrote:
pretty much any of the 'frameworks' out there have this requirement that
you need to set up a mapping on the server.
I disagree. I've deployed apps built with Fusebox / Mach II /
Model-Glue without mappings, just by putting the framework under the
webroot. One framework install per webroot - multiple applications per
webroot - multiple applications share the single framework install.
eg. something like farcry that
requires the 'farcry' mapping to be set up on the server
FarCry requires a *webserver* mapping (or did the last time I tried to
evaluate it). It may also require a CF mapping (it probably does).
or even 'mach-ii'
that its need for its own mapping..
Mach II does not *need* a mapping (but best practice suggests placing
the framework install outside of the webroot).
or if you code an application using
inerhitance based heirarchys... they all need a base mapping.
Unless you use paths relative to your webroot.
1. Run Enterprise version with multiple instances for multiple
environments
...
2. have source code set up with mapping as a variable that get replaced
dynamically by a build script.
...
3. be carefull how you code and limit inheritance to only within the same
folder.
cons:
now you cant have a global 'base object' thats shared across the
application unless all the cfc's are in that same folder.
Well, a "global 'base object'" is a terrible idea IMO. Inheritance
should be for "is-a" relationships only and Product and User do not
have a common ancestor.
4. dont use inheritance
im sure some purists would argue this point also, but extends give you a
very fast way of reusing code and for simple projects it makes alot of
sense.
Use composition, not inheritance, to reuse code.
5. Run CFPro on a new staging server
cons:
extra hardware cost (minimal) and extra software license (CFPro tho',
not CFEnt).
6. Run Developer Edition (free) for dev
cons:
??
Assumption here is that you can dev/test on a workstation for free
with multiple instances if you need to (so multiple environments) and
then deploy to your CFPro whenever you want.
You don't state all of your requirements as regards how many
developers need to access which versions of the software.
I'd say the minimum setup for team development would need to be:
- localhost Developer Edition (in Multiserver config, J2EE) for dev /
testing
- shared staging server (CFPro) for "integration testing"
- production server (CFPro) for deployment
and a version control repository of course.
The more parallel development you do, the more instances of CFPro
you'll need so really as soon as you get to four concurrent projects,
CFEnt becomes cost effective (and memory is cheap so 512Mb per
instance is no big deal - I have 2Gb in my laptop for localhost
development!).
--
Sean A Corfield -- http://corfield.org/
Got frameworks?
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
----------------------------------------------------------
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]
