>That sounds like an argument against using any standard framework? Not at all! Everything we've done is in Feuuu .... Feuuu ... Feuuu ... .
http://helmsandpeters.com/audiofiles/HaP-FrameworkShrink.mp3 And i'd prefer to move it to model-glue ... just to clean it all up nicely. >I use frameworks on a shared host without mappings. How? Please explain ... What we need is a simple, self-contained architecture that can scale out easily to say 10 - 20, maybe 30 installations a week and take no more than 10 or 15 minutes per installation. And i'd like that it can be "InstalledAnywhere" in the same amount of time. And each installation needs to stand on it's own. I'd be very happy to move it to MG ... but that would, i think, practically limit us to only offering this as a "We'll host it for you" package. We'll be making maybe $20 dollars a month on each installation. I'd like to sell 5000 of them or so and "retire" to a beach somewhere on a $80,000 a month income, and pay someone $20,000 a month to maintain it. All the customization requests would be extra. :) n. >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Sean Corfield >Sent: Saturday, November 05, 2005 5:56 PM >To: [email protected] >Subject: Re: [CFCDev] Factory Pattern > > >On 11/4/05, Nando <[EMAIL PROTECTED]> wrote: >> 1) it requires a mapping > >No more so than Mach II. Could you explain? > >> 2) combined with the fact that it's not a 1.0 release yet, which >means the >> API is still very much open to change, as i understand it. > >Actually the API is very stable - the version number is a little >misleading. The next release will likely be 0.5 and will contain very >few changes (it will implement a few more parts of the Spring grammar; >AOP will be slightly more fleshed out - it will include exception >advice). The jump to 1.0 will likely occur after more testing but will >still likely include almost no functional changes. Dave and Chris are >just a little more conservative with their version numbers than most >folks. > >Tartan "suffers" from the same thing - Paul is very conservative about >his versioning... > >Bear in mind that Mach II sprang into life as version 1.0.x yet it was >unusable in production until 1.0.8 due to thread safety issues. >Version numbers can be very misleading! > >> One of the big advantages for me about using a Factory.cfc like i've >> outlined as a single interface for creating object instances is >that i can: >> >> ... Place it in a /model subdirectory with the rest of my components > >Probably a bad idea to have all your model components sitting in one >directory - you'd do better to structure you model into separate >subdirectories. Also a generic factory is a utility rather than an >inherent part of your business model so it probably doesn't belong in >the model directory at all (depends how tied to your business model >your factory is). > >> ... Instantiate it from Application.cfm/cfc as a singleton using the >> notation createObject(model.Factory) > >That's what you do with ColdSpring. > >> ... And let Factory create the rest of my cfc instances >_without_ needing a >> mapping! > >If ColdSpring is installed in your webroot you don't need a mapping >(i.e., same as Mach II, Fusebox, Model-Glue, Tartan, Arf!...). > >> What that allows me to do is set up a server and drop in many >instances of >> the same application without needing to modify the code in each one > >So you duplicate your factory CFC all over the server? > >> accomodate different mappings for each separate installation, and free to >> make variations in each application according to our clients' varied and >> unpredicable requests for customization without concern that i'd break >> another app doing so (if we went with a shared model directory for all >> instances on a server). > >I didn't suggest a shared model - but a shared factory like ColdSpring >makes sense. > >> The core benefit here is that it allows us to let our business >expand - even >> quickly - without fear that we'll drown under 100's or 1000's of >different >> installations to install and maintain. > >Your frameworks would all just have a single installation each - your >model requires "100's or 1000's of different" factory CFCs doesn't it? > >> I know this doesn't present a problem in other situations. But >in this case, >> each installation would become very dependent on ColdSpring, and >i'd like to >> move toward each installation being, as much as possible, self sufficient >> so the code is portable and easily installable, even next to other >> installations of the same app. > > >> And even if i need to place an installation >> on a shared server somewhere for a particular client. I don't >even want to >> think about the possibility anymore that a mapping will be already taken. > >I use frameworks on a shared host without mappings. > >I'm not really out to persuade you to rewrite your code, just trying >to dig down into your objections about frameworks... >-- >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]
