> 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?!
I'm not 100% clear what you mean by this,
but if i'm getting you, it has to be coupled somewhere. Specific fields in
the database (if i'm understanding you correctly) will map to specific
output points in your HTML. You can't get around that. The OO ideal is to reduce
coupling, not eliminate it. Sometimes you need some coupling, and sometimes it
doesn't make sense to reduce it, even if you can. It's just not worth the extra
work.
Practically speaking, i think it's faster
to simply create custom display methods as needed per
project. I can usually manage to go quite far with CSS styling alone
in altering how a content block looks. But when i need a custom set of
elements in a content block, i create a new display method. Usually i
have a specific project ContentDisplay object that extends my generic
ContentDisplay object, so i can easily do
this.
I also have a contentContainer config
object that defines for me the content containers for each position (1-20 for
instance) on a template. In it, i set the contentType (text, image, flash, etc),
the viewScope (per page, per section, per site - a per site content container
will be shared across all pages on a site), which display method to use to
render the content container, which gateway method to use for the content
container, and which fields to show. A specific image content container might
not need the align setting, because it takes up all the horizonal space in the
layout, for instance.
So with this config object, there is some
reduction of coupling happening, but it's not eliminated. Between the database,
the content container configuration, the gateway method, and the display method,
there is coupling. But the CCManager, as i call it, makes the whole application
much more flexible.
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]
