>> but its boggled my mind why having a separate set of ui cfcs that
produce the output html was seen as such a 'bad thing'.
perhaps "bad" implies never do it (and never is a bit harsh), but since the generated
UI is tightly bound to the way the request comes in (ie: a request from a browser),
tightly binding the call to UI objects (taglibs' etc) within the cfm file is, IMHO the
way to go.
I mean you've got other HTML in the CFM as well...
just 2c worth (I'm home sick and bored to tears!)
barry.b
(and for those people who have never bothered with taglibs before and have got no idea
what this is all about...)
the following snips are abstracted HTML/JS that are really easy to build pages with
and still follow OO "ideas" of abstraction and encapsulation. It doesn't look like it
but they are really just output boring bits of DHTML. But thanx to the taglib API,
they can be changed, extended, etc without major headache. the final washup is that
it's just an XML-type layout with a bit of client side logic behind the sceens.
(I'd also like to point out that CFMX and ASP.NET owe a debt to JSP taglibs who - IIRC
- came up with this idea first)
some ASP.NET UI (re-usable) controls.
<form action="controls3.aspx" runat=server>
Please enter your name:
<asp:textbox id="Name" runat=server/>
<asp:button text="Enter" Onclick="EnterBtn_Click" runat=server/>
<p>
<asp:label id="Message" runat=server/>
</p>
</form>
a similar idea using CF taglibs:
<container:form class="general"
id="entry"
name="entry"
onsubmit=""
method="post"
action="#cgi.script_name#">
<content:setup class="general"
Count="#strAdminValues.ANUM#"
Active="#strAdminValues.ACTV#"
Address="#strAdminValues.ADDR#"
DefaultTransfer="#strAdminValues.TFER#"
/>
<container:formsave class="" />
</container:form>
---
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/
