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


Reply via email to