> I had a long conversation with a developer friend
> yesterday about this very topic - Writing output
> inside a CFC (or UDF)
> Personally, I feel it's not bad form to create GUI cfc's.
> They don't perform any true business logic, just return
> pagelets or form parts.
> How do you feel about that Isaac - AND what do you use for
> pagelets? (cfinclude, cfmodule?)
I'm not necessarily opposed to writing display logic in a
CFC method -- and I suppose that may be part of the
confusion where I'm concerned, because I'm not (like a lot
of them) saying that you shouldn't ever use CFC's for
display. I'm just saying you shouldn't use output="true" to
do it. :) I think it's fine if you want to write reuseable
CFC methods for display, but you should make the method
return a string of html instead of writing it directly to
the output buffer so that the method is reuseable without
resorting to some kludge like:
<cfoutput><cfsavecontent
variable="myvar">#mycfc.method()#</cfsavecontent></cfoutput>
if you write them correctly, this line becomes:
<cfset myvar = mycfc.method()>
That being said, I think if you are going to write reuseable
display methods, you should definitely separate them from
the controller and model or other business logic methods.
The display method should never perform a query by itself
for instance, it should always call another method to get
query data.
And I don't think GUI _necessarily_ needs to be in a
separate CFC from other business logic either, however, I do
think you need to pick a pattern and stick to it in this
regard. If you've got display methods in your CFC's, _all_
of your CFC's should reserve (if not use) the same method
name(s) for display (and preferably derive some
functionality for handling CSS and the like from a root
CFC). Otherwise you should create a separate CFC for
handling display.
But I could see this as a method in a root cfc or a gui cfc:
<cffunction name="qrytable" output="false">
<cfargument name="qry" type="query" required="true">
<cfset var thetable = "">
<cfsavecontent variable="thetable">
<cfoutput>
<table class="#this.html.table.class#">
<tr class="#this.html.table.class_header#">
<cfloop item="x"
collection="#this.html.table.columns#">
<td
class="#this.html.table.columns[x].class_header#">
#this.html.table.columns[x].label#</td>
</cfloop>
</tr>
<cfloop query="qry">
<tr class="#this.html.table.class_row#">
<cfloop item="x"
collection="#this.html.table.columns#">
<td
class="#this.html.table.columns[x].class_body#">
#qry[this.html.table.columns[x].colname]#</td>
</cfloop>
</tr>
</cfloop>
</table>
</cfoutput>
</cfsavecontent>
<cfreturn thetable>
</cffunction>
Something like this either in a GUI CFC or as a derived
method of a root class could go a long way to creating
consistency in the display or look and feel of a site or
application without having to continually write or paste the
code to create that display. It's generic enough to allow
you to set specific column widths if necessary among other
things. If I really wanted to go all out I'd even include an
alternate row class for alternating row colors.
As to pagelets I'm not sure I know offhand what they are...
but given my assumption (little reuseable bits of html for
the display of a particular section of a page), I'd say I've
probably used cfmodule more than anything else up to this
point. That may change if I get more MX work. :)
s. isaac dealey 972-490-6624
team macromedia volunteer
http://www.macromedia.com/go/team
chief architect, tapestry cms http://products.turnkey.to
onTap is open source http://www.turnkey.to/ontap
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe:
Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
