If every app is 'self-contained' how can we leverage 'shared libraries' of CFC's? It might make sense to publish the design of each application before it is programmed so that other team members can suggest pushing some of the components into a base library that can be extended on a per-application basis.
Eric -----Original Message----- From: Matt Woodward [mailto:[EMAIL PROTECTED] Sent: Sunday, January 29, 2006 9:42 PM To: [email protected] Subject: Re: [DFWCFUG Dev Team] Architectural Ideas II Don't worry about hijacking Tracy--any discussion is good discussion at this point. I think sub-apps is a sane way to go with this and will support the pluggable architecture we discussed as well as support the type of development you outline in which each person/persons can work on their own chunk of things without too much interference from the other sections. One thing I'd suggest concerning your directory structure below is that we have everything for the app (other than the Mach-II directory itself) under a single directory. That way we don't rely on this being the dominating/only app running on someone's server. Which brings me to my next question: What the heck are we going to call this application? To use DFW CFUG folks it's our "web site," but since one of the big goals is to release this to the world, I think we need an actual name for the application, so let's start brainstorming on that. I didn't get the code skeleton uploaded yet--let me think on that a bit and come up with a directory structure based on sub-applications. I'm going through the oswd deisgns right now and I'll post links on the Wiki in a bit here. Then we can pick one and run with it. Matt On 1/29/06, Tracy Logan <[EMAIL PROTECTED]> wrote: > Here I go again! :*) > > A common stumbling block for Mach-II teams is that darned XML config > file getting so huge on a big project. This only gets worse when you > add a lot of developers who all need to make changes in it at once. > > Happily, there is a good (if not quite Excellent!) approach that I > think will really work well in our case: Sub-apps! > > That's a concept that scared me off for more than a year; it seemed > too complex to be of use, somehow. But once I really gave it a shot, > it turned out not to be complex in the slightest; in fact, it's dead > easy: Just break your app into sensible pieces, and build each as its > own app. > > There's a *bit* more to it, and I'm not certain that I've made the > best choices in some of those "bits" -- so one reason I'm proposing > this is to get everyone else's input on better ways to build those > "bits". > > However, there are many more-important benefits: > > Each sub-app can have its own design team, timeline, coders, etc. -- > which also means you can release each element of the app as it's > finished, rather than waiting for all elements to be done. In effect, > each new release primarily consists of added features, building on the > solid core that's preceded it. > > With your standard old-school CF_Spaghetti app, that could/would be a > nightmare -- but with an app framework like Mach-II, using sub-apps > and a clean OO model, adding a new feature usually requires literally > *one* change elsewhere in the app: Adding a link to it in the > navigation! > > Here's a simplified example of what that might look like: > > /wwwroot/ > /MachII > /cfug > /blog > /jobs > /links > /survey > /Application.cfc > /index.cfm > > In each subdirectory, you'd have the usual Mach-II skeleton -- index > file, model/view/config/filters/plugins/etc., everything you need for > a regular non-sub-app. The /cfug/ subdirectory would hold shared > files (the site graphics, navigation, exception, and layout files, as > well as the shared model elements, such as User). > > The only time the sub-apps have to do anything awkward is when they > need to refer to a different sub-app (for example, a link on a Survey > page that points to the Links page) -- and there are a variety of > not-quite-elegant ways to deal with that. It's a small price to pay > for the tremendous flexibility the sub-apps provide. > > Of course, there are lots of other ways to structure this, including > keeping the good stuff out of the web root -- I don't mean to hijack > that discussion, just to add these thoughts to it. > > =tracy > ~~~~~~~~~~~~ > Reply To: [email protected] > List Archive: http://www.mail-archive.com/devteam%40list.dfwcfug.net/ > To Subscribe: Send an email to [EMAIL PROTECTED] with "subscribe devteam" in the body - no quotes. > To Unsubscribe: Reply to the list with unsubscribe in the subject line. > Sponsors: www.HostMySite.com & www.cvsdude.org > > > -- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com ~~~~~~~~~~~~ Reply To: [email protected] List Archive: http://www.mail-archive.com/devteam%40list.dfwcfug.net/ To Subscribe: Send an email to [EMAIL PROTECTED] with "subscribe devteam" in the body - no quotes. To Unsubscribe: Reply to the list with unsubscribe in the subject line. Sponsors: www.HostMySite.com & www.cvsdude.org CONFIDENTIALITY NOTICE: The information contained in this e-mail and attached document(s) may contain confidential information that is intended only for the addressee(s). If you are not the intended recipient, you are hereby advised that any disclosure, copying, distribution or the taking of any action in reliance upon the information is prohibited. If you have received this e-mail in error, please immediately notify the sender and delete it from your system. ~~~~~~~~~~~~ Reply To: [email protected] List Archive: http://www.mail-archive.com/devteam%40list.dfwcfug.net/ To Subscribe: Send an email to [EMAIL PROTECTED] with "subscribe devteam" in the body - no quotes. To Unsubscribe: Reply to the list with unsubscribe in the subject line. Sponsors: www.HostMySite.com & www.cvsdude.org
