> Still trying to get my head around best UI practices in CFMX.
> Responses to date seem equally split between using UI cfc's
> and preferring custom tags.
I'm not sure I understand the distinction between a "UI cfc" and a custom tag approach, and how that has anything to do with encapsulating object data.
To me a "UI cfc" means a CFC whose primary purpose is generating and/or outputting HTML, and a "custom tag" (in the context of a user interface) is a CF custom tag that outputs HTML. Depending on which one you are using your display page (or view or whatever) looks like one of these:
#myUI.addLayout("Blah blah blah")#
-- or --
<cf_addLayout>Blah blah blah</cf_addLayout>
But neither one of these approaches really has anything to do with your primary question (as I understand it), which is...
> In short, how can I create a specific UI for an object while
> ensuring that the UI has no knowledge of the fields and their
> associated display properties for that object?!
Does this mean you are looking to automagically generate a details form for an object, but you need to have some control over the form details (input type, maxlength, etc)?
The simplest way would be to obtain the object's meta data and then look for all methods with a name starting with "get". These indicate getter methods, so you would pull off the "get" part to obtain the field name and then invoke the getter to get the value. This doesn't give you granular control over the field properties though.
A more advanced "automagical" approach might introspect the database to determine things like field length, data type, etc. Of course, you'd need to tell your form generator which DSN and table to introspect, so this ins't really "automagical" after all. Plus, you still don't have manual control over specific form fields.
A far less automatic approach, but the best one IMHO, would be an XML config file that describes how the form should be built. You'd have one of these files for each object type, and then a generic FormGenerator CFC that reads the XML and creates the appropriate form.
Depending on your application, it might be appropriate to add a generateFormBuilderXml() method directly to your objects. This method would generate the XML for that object. (You might even add
this method to a generic base class with a default implementation that introspects the object's private data members and creates a default XML schema. You would then override this implementation with a specific one on the objects that require it)
Hope that helps a bit... if I totally misunderstood you let me know and I'll try again :)
On 1/20/06, Peter Bell <[EMAIL PROTECTED]> wrote:
Hello All,
Still trying to get my head around best UI practices in CFMX. Responses to
date seem equally split between using UI cfc's and preferring custom tags.
Here's a question that maybe someone on the "custom tag" side should speak
to.
Lets say I need an HTML UI comprising of a form, and the FirstName field
must have the following code: <input type="text" name="UserFirstName"
size=="50" maxlength="150">. Lets further assume that some of those
properties are unique to FirstName, so I can't just generically loop through
a struct of passed field names in the UI and use default field HTML for all
of the properties.
How can I put the code above into a custom tag without breaking
encapsulation? In short, how can I create a specific UI for an object while
ensuring that the UI has no knowledge of the fields and their associated
display properties for that object?!
It seems to me that I must put the UI into the appropriate object as a
displayAsHTML method or similar otherwise something other than the object
knows about and depends on the internal structure of what should be private
properties. (Of course, the displayAsHTML should wrap the getUserDetail
method rather than knowing anything about data access)
I'm sure I am missing something here. Any input on what I'm missing would be
most gratefully received!
Best Wishes,
Peter
----------------------------------------------------------
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]
