here! here! after comming off a large project that uses this method I highly recommend it.
bottom line: view layer as cfm's and custom tag librarys <cfimport taglib ="whatever" with all data being sent to and processed by CFC's. the only time we had CFC's as part of the "view" layer were for flash remoting facades. note of caution: we were having some performance issues with custom tags importing librarys themselves - nesting of libraries (but it could have been just the way we were doing it). we simplified the nesting and it was both fast to build and proformant. we were quite happy. just my 2c, nothing more On 19/01/06, Barney Boisvert <[EMAIL PROTECTED]> wrote: > I generally write my UI widgets as custom tags. Keeps things simple, > since my view templates are all simple markup, be it HTML or CFML > custom tags. Tags are also easy for designers to understand, since > they'll already be familiar with nesting, attributes, and the like. > > How those custom tags work, I can't say for sure, but they usually > take the form of "query the model CFCs, render some HTML". Some > widgets, of course, won't need the first part (like a pager for a > paged record set), and some might not need the second part (I can't > think of a good generic example). > > cheers, > barneyb > > On 1/18/06, Peter Bell <[EMAIL PROTECTED]> wrote: > > Hello All, > > > > My introduction to OOP in CF is a rewrite of a CF5 application generator in > > CFMX 7. I have a pretty good domain object model but am having trouble > > finding best practices for the UI. > > > > All of the controller (index.cfm) and model (various cfc's with a simple > > façade abstracting the business objects) runs first and then the model uses > > rules to determine what screen template to include. For instance, if form > > validated, display a list and a "added OK" message, if it failed, re-display > > the form screen. It then calls the appropriate screen. > > > > The screen is currently looking like being a simple CFML template that > > knowledgeable graphic designers can edit and that is comprised of static > > HTML, support for variables and basic logic using a generic syntax (so I can > > generate in other languages), and a number of widgets. > > > > The widgets are produced by a code generator that generates (and can save to > > files at design time) common UI widgets (table with pagination, simple form, > > n-record update table, etc.) from a set of primitives. The generated UI > > widgets can then be passed certain runtime properties (object type to > > display, display properties for this instance, etc.) and generate the > > appropriate HTML which is then pulled together by the page and screen > > templates. > > > > I'm tempted to describe the widgets something like: <Element > > name="PagedTable" Property1="value1" . . . /> for the designers. I can then > > use a Regex/parser to turn that into any appropriate format/include/call. > > > > How would you recommend calling the user interface widgets? > > > > I'm tempted to put them into methods of a UI CFC which returns the HTML > > string to display. That would also make it fairly easy to refactor to a > > Factory pattern to support n-output methods (optimized for different > > devices, etc.) but no less than Ben Forta suggests using custom tags for UI. > > > > Are there some considerations I'm missing? > > > > Be gentle on me. This is my first OOP projects and I've been thinking about > > this less than a week!!! > > > > Best Wishes, > > Peter > > > > -- > Barney Boisvert > [EMAIL PROTECTED] > 360.319.6145 > http://www.barneyb.com/ > > Got Gmail? I have 100 invites. > > > ---------------------------------------------------------- > 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] > > > ---------------------------------------------------------- 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]
