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. That sounds like an argument against using any standard framework? > 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]
