|
Hey Seth, Can I see an example of some XML you have
generated to display a form? Curious, Baz From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Seth Petry-Johnson > 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:
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] |
- RE: [CFCDev] UI and encapsulation Baz
- Re: [CFCDev] UI and encapsulation Seth Petry-Johnson
- [CFCDev] Expense of Operations? Peter Bell
- Re: [CFCDev] Expense of Operations? Barney Boisvert
- [CFCDev] Load balancing and clustering... Kirk Brogdon
- Re: [CFCDev] Load balancing and c... John Beynon
- Re: [CFCDev] Expense of Operations? Jerry Ela
- RE: [CFCDev] Expense of Operations? Nando
- Re: [CFCDev] Expense of Operation... Peter J. Farrell
- Re: [CFCDev] Expense of Operations? Jason Daiger
