Re: Queries and display files

[Lee Borkman]

Hi Roger,   This sounds like an extension of what is now standard in FB3, ie the separation of content from presentation.  In FB3, we usually only take this to a single level, meaning that our display fuseactions actually display nothing, but merely populate a variable called "fusebox.layout".  The actually display is always deferred to the topmost layout file.  Of course, we were using this idea long before FB3, with Steve's CF_BodyContent tag.   But it sounds like you are going a step further, in that you are explicitly populating a some kind of content structure in your fuseactions, as opposed to a single variable, and then you are invoking some display template to re-purpose the content for the desired skin/medium, etc.   In recent weeks, we have had a few discussion on the "role" of "the fuseaction", my view being that is creates content and metadata only.  The layout files are then used to present the content in a way that is appropriate to the user and to the content.   Is there any chance we could see an example?  This is using your variation on FB-Classic, is that right?  It sounds like you have independently formalised the same kind of content/presentation separation that was built into FB3.  I wonder, though, if the two schemes could not learn from each other, if you might not find that you can now achieve your aims within FB3, or indeed the other way around ;-)   Sounds very interesting, Thanks, LeeBB Bjork.NET - Postcards gratefully accepted. ----- Original Message ----- From: Roger B.   Kay Smoljak wrote: > Can you give me an example of where this approach is an advantage? > Sounds interesting... Well, the example I'm most familiar with is my community app... it's been designed to support a level of "skinning" that allows more than the typical layout modifications. It can support completely different interface structures... the user can choose to view the forum as a UBB-style, linear board, in a Compuserve-style, multi-framed and fully threaded format, and so on. Whatever the developer can dream up. Each skin exists as its own little pseudo-circuit, and relies on a central set of dsp_ files to feed it data. The generic dsp_s process queries, check permissions, and so on... but leave the actual display of data to the individual skin's tmp_ files. All of which has two primary advantages: (1) Those dsp_s get re-used over and over across multiple skins. (2) I can restrict the CFML in tmp_ files to CFOUTPUT and CFLOOP... not so much as a CFSET anywhere in sight. That leaves the templates much easier for non-programming types to modify. ==^================================================================ This email was sent to: archive@jab.org EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================