Hi Tim, We've just done something that has a lot of similarities. A 4-layer application with the lower 3 layers being cfcs ... contact me off- list if you'd like to know more. A few specific comments below ...
--- "Tim Blair" <[EMAIL PROTECTED]> wrote: > > [snip] > > Questions I have: > > I want to make the core CFCs completely stateless so there is > no need to > reference any external vars. How should I go about making sure > that > each instance that requires access to the DB has the DSN > available to it > -- pass the DSN name through on init()? We generate our lowest-level (data layer) components from the information in the database. Our dsns are hardcoded into the data layer components as part of the generation process. I can see that a lot of people would take issue with that but it does give us a single, simple way of changing the dsn ... regen the data-layer. Actually there's something I'm glossing over here, the data-layer components that do single-row operations (insert, update, delete, select) are generated. Multi-row operations (joins, searches on criteria other than primary key) are hand-coded cfc's and sit in a different directory. One search and replace operation on that directory is sufficient there. Could be better I know, but it works. > For the fa�ade interface, I want things to be secured so only the > appropriate client can call the remoting methods or web services. > How > should I go about this? > > How does anyone recommend setting up the "bespoke" sites, still > using > the application engine? Simply another "view"? We only have one "site" running against our new application engine at present. We've used Fusebox 3 for our presentation layer (both the public facing and administrative sides). The admin side only has one view, but the public side can be re-branded by setting up some new layout files (two or three of them) and coding a new CSS file for the exact colouring, layout, font selection etc. As far as a "bespoke" site is concerned, we plan to implement a "features" functionality, where a given "site" has a certain number of features assigned to it. If we have new functionality that's being given to only one client on their own site, then only they will have that feature activated, the other clients/sites won't see it. That will work for us because we have re-written an application for an existing business, so the aspects of the business we need to turn into modular "features" are quite clear. The "site" infrastucture is already in our database, the "feature" functionality is part of the the next piece of development. I figure if we have a mapping of fuseactions to features, then the existing infrastructure we have to dynamically generate menus (depending on whether the user is allowed to see a certain fuseaction) could be very easily adapted to hide/show features. Andy. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
