particular case, but I can say that - Yes, in general, that's "a very
bad thing". I'm not going to go into detail about WHY it's a bad thing,
because I'll be rabbiting on for hours, but in practical it harms the
flexibility, re-usability and maintainability of your code.
The idea is to separate your "backend" from your "frontend" - or your
Model from your Views, in MVC speak. This is achieved by an intermediary
layer called the Controller.
So your back-end CFCs are all self-contained - they don't know ANYTHING
about the front-end display templates that actually define the
interface.
Fusebox ( www.fusebox.org <http://www.fusebox.org/> ) was an attempt to
achieve this degree of separation long before the advent of CFCs,
Mach-II ( www.mach-ii.com <http://www.mach-ii.com/> ) is probably the
way to go if you want a standard way of doing it that harnesses the
power of the CFC model.
Hope that helps
Al
_____
From: stylo stylo [mailto:[EMAIL PROTECTED]
Sent: 10 August 2004 06:37
To: CF-Talk
Subject: advice on structure and cfcs (petmarket related)
I'm looking how to best structure an application and build it with cfcs.
I'm looking at the petmarket example right now (cfml only, not the flash
front end version).
What do people feel in general about the way that application is
structured?
In particular, I'm wondering about the detailview.cfm which is called by
the product.cfc detailview function and used to output the page. Isn't
that a "bad thing"? I would have thought you would call from a page
template a cfc to return query info on a product and output that.
Anything else about this application in particular I should be aware of
or wary of duplicating, as maybe there is a better method or better
performance to be had another way?
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
