Hmm,
My thoughts about CFC & HTML are quite clear :) No.
I believe CFCs should be kept to pure logic, in that to me a CFC is simply a nice big fat Data object with lots of custom-side utilities.
I generally prefer to use CFIMPORT to cater for piece-meal UI components, mainly so i can see it visually via code layed out in an XML solution - don't go the flex thing again! hehe.
I've tried the UI/CFC approach before, i was stoned for it yes, but i was curious and i found it frustrating at times, simply because the overall UI is stored in pieces all over the framework, and the only way to draw the callstack/flow is do a dump? (or do you have another way). This is good if you have the time to analyise each page or your screens are pretty vanilla.
In my apps, this isn't the case as i need to tweak screens at times, and i need to do it rapidly enough.
Nothing beats in *my opinion* then:
<sb:TabPane id="myTabPane" class="">
<sb:Tab label="MyTab">
<sb:AccordionPanel>
<sb:Panel label="Panel A">
<sb:Tree dataModel="#myPreMadeDataStruct#"/></sb:Panel>
<sb:Panel label="Panel A">
<sb:Form>
<sb:FormItem label="Enter your Email Here.." formField="yourHTMLFormFieldName" width="20" isRequired="true" validationType="email" errorMessage="Please re-enter your Email Address" toolTip="Please provide a valid Email Address"/>
....
<sb:FormButton type="submit" value=""
</sb:Form>
</sb:Panel>
</sb:AccordionPanel>
</sb:Tab>
<sb:Tab label="MyTab">
do my other stuff here.
</sb:Tab>
</sb:TabPane>
Now, taking above code, its basically a series of DHTML/CFMX mixed together to come out looking like a FLEX app :D (hey why not, ActionScript & DHTML are a like, so if i can't have it legit, i'll roll my own damn it!)
If i were to do the above in a CFC format, and I needed to make some changes to the layout or the attributes within etc, it could get a bit "programmatic" resulting in more time to adjust and less agile imho? Not only that, you're now actually "imagining" how it comes together via a callstack style approach? or am i off base?
So thats why *I* choose not to use CFC's for UI. Its not a real hard fast rule if *You* choose to do so, just that its an un-said No No, much like using the "this" scope. Lots of negative reasons why, but nothing overally dramatic enough to have you shot if you decide to.
Regards Scott Barnes http://www.mossyblog.com
P.S WILL CODE HTML FOR FOOD.
Gary Menzel wrote:
It's generally considered a 'bad thing' to use CFC's to output html, as they are better placed in the logic tier of an application, rather than in the output.
I'm going to ride the other gravy train on this one. You certainly shouldn't put <CFOUTPUT> statements in your CFC's (and just generate the HTML to be output by the calling page). But it is VERY valid to encapsulate output generation in a CFC (not necessarily the same CFC's as the business logic though).
Why would you do this?
Because then you can just instantiate a different "UI" CFC (that supports the same method set/interface) and you don't have to change any of the code that uses that object.
The actual CFM page then become the "glue" between your business logic and your UI. You could even create a "glue" object for a page that provided a facade onto your business and UI objects.
Just an alternate point of view.
Regards, Gary Menzel
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
