Joe, thanks for your feedback and encouragement; replies interleaved. Dave Merrill
> Another important thing > to remember is that you will not get it "perfect" the first time. OO > design is an iterative process, and as you design and develop your > application, it's likely that there are portions that you will > refactor. Sure, but this kind of data-driven area is such a standard animal, it really seems like folks (me included) should have a handle on at least one standard way of implementing it. Special cases there may be, but the garden variety scenarios I described should be a done deal I'd think. > M: A CFC that reads the list of records and applies any search criteria > V: Displays a list of records or a form that allows search criteria > C: Sends any criteria from the V to the M, and sets a variable that > the V will "know" contains the resulting query > > > The controller gets the user's employees.list request, and > detects that the > > submit btn wasn't clicked, so it calls employees.view.show_search. User > > submits that back to the controller, which now sees that the > search has been > > submitted, so it calls employees.model.do_query, then > > employees.view.show_list. So in an area with a search form, C checks if the search submit btn was pressed, and if not (initial entry into the area), calls V.show_search. If it was pressed, it calls M.do_query, then checks if the query found some rows. If it did, it calls V.show_list. If not, it calls V.show_search, passing in the html of the no-rows-found msg to display. IOW, all branching happens in C, based on request parameters, query results, whatever. Well, kinda. M doesn't exactly branch, but it does react within itself to the search fields the user did or didn't fill in. If there was some extremely dense bit in the query logic, would you consider having the query file itself detect that the user's search requires it, and cfinclude a separate file? Is that decision M? Even though in the app it's based on user V actions, from M's perspective it's just another aspect of its API. > > Or does the controller always blindly call the > > model and the view; the model detects that it shouldn't query > > because the submit btn wasn't pressed, > > The model shouldn't know anything about the submit button - models > should have no knowledge of views or their API. Aren't the fields on the search form part of the view? M *has* to know about them to function. Why is the submit btn any different? Maybe it's just another part of the M.query API. Speaking of APIs, I know there are different ways to play this, but would you pass a cf query object into V.show_list, or (say) an array of structs? The array of structs makes binds you less to the model's implementation, but takes more work, both coding and executing. Also, if there's translation to be done, would you say that M.do_query returns a query to C, which then calls something else to map it into an array of structs? Who else? If it's a piece of V, then V knows about the native-cfquery implementation of M anyway, so why not have V.show_list know directly? I can't be M, because it doesn't own the output format requirement, V does. Or is it C itself, because it's the glue between V and M? > A framework can also help by aiding you in organizing your MVC > application. If you're not used to OO development, I'd suggest > checking out Fusebox, and specifically "MVC Fusebox". If you'd like > to take a full-blown OO approach, there's Model-Glue > (www.model-glue.com) and Mach-II (www.mach-ii.com). They will > probably both have steeper learning curves, but Model-Glue is designed > to be a little quicker to get up to speed with. I've used FB3 a lot, and FB41 some, but while they're useful, neither of them really described how to make these decisions. I know the principles behind mach II, but haven't used it. Hadn't heard about model-glue, thanks, I'll take a look. Though I have to say, I'm getting a little sick of my own tendency to abstract everything I can get my hands on. I've been experimenting with a really Fred Flintstone-simple CFC-based app structure, directly invoking CFC methods from the url, and it feels pretty reasonable so far. At the moment, each area does have M, V and C components, which is part of what made me want to better understand how to partition things between them. But at least on this small-experiment scale, all MVC really does in this context is make you add new methods to three CFCs instead of one. Not to make light of the great framework work folks are doing, but the Fred part of me still likes that better than editing XML files just to tell the engine about a new method (that I also have to write code for), or where to find existing components (;-). ---------------------------------------------------------- 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]
