On Tue, 29 Mar 2005 17:52:19 -0500, Dave Merrill <[EMAIL PROTECTED]> wrote: > 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.
I'm sure you already do but you might not realize it has a standard name - page controller (which is where each page has its own 'control logic' - a page-centric approach). There you would have a page that: 1. checks if a search query was passed in and, if so, runs a search 2. checks if a search result exists and, if so, display the results 3. displays the search form No one is saying you'd be wrong to build stuff like this - it's how most people build web sites and even with ASP.NET the only change would typically be to move the logic in #1 to a code-behind object. Murat Demirci is working on a framework for ColdFusion that allows exactly that kind of ASP.NET-style code-behind development. However, MVC aka Model 2 funnels operations through a specific controller which, for multi-page applications, makes things look a little different. > 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. Well, yes and no. The M has to be passed data in a known format that is equivalent to the fields on the web page but the C could map them. In fact, Fusebox, Mach II and Model-Glue all map URL and form scope to a single synthetic scope before handing the data to the C which may well extract the specific data and hand it directly to the M. In other words, the field names don't have to match the arguments passed to the model. > 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? A ColdFusion query object is a good abstraction of an aggregate result set so there is no need to convert it to anything. Yes, the view needs to know the exact format of the query - but then the view needs to know enough about the model's results to be able to display them correctly in any case. To recap: - C knows about M and V - V knows about (parts of) M and maybe parts of C - M knows about neither C nor V > I've used FB3 a lot, and FB41 some, but while they're useful, neither of > them really described how to make these decisions. True. FB is a very flexible framework that lets you program in a wide variety of styles from "traditional" (albeit with FB as a simple controller) to structured MVC to OO MVC etc. Mach II and M-G are more structured (you could say more restrictive) OO MVC frameworks. > 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. Well, you need to modify the C to accept and process a new action; you may need to modify the M to process new data / return new results; you will need to modify the V to add the new actions / display the new results. So you are touching three things anyway - whether they're in one file, two files, three files or more. -- Sean A Corfield -- http://corfield.org/ Team Fusebox -- http://fusebox.org/ Got Gmail? -- I have 50, yes 50, invites to give away! "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- 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]
