[Modus-devs] HTML SELECT, WAS: Collections of content objects and performance

[Nathan D. <na...@ch...>]

Sean asks: What has an HTML SELECT got to do with data descriptors????

Yes, what does an HTML SELECT have to do with a data descriptor??  OK, I
should have said that the categoryPicker manifests itself as a form widget
with an HTML SELECT.  The original issue was that I wanted a way to have a
field that needed to be chosen from a discrete list of values.  The way to
get this done in the "real world" was with a SELECT field.  The CFPROPERTY
tags did not allow me to specify much about what those options might be, so
I did an experiment by creating my own "custom" field type called
categoryPicker.  categoryPicker.cfc uses the formFieldFactory to make a
SELECT with some options in it.  This really goes to the more philosophical
discussion about how much a contentObject (or, really, a field) should know
about how to render itself (see the generic discussion post that precedes
this message).

Sean says he shudders when he sees:

<field name="type"
label="Type"
type="org.bacfug.modus.fields.picklist">
   <options>
      <option value="normal" label="Normal"/>
      <option value="special" label="Special"/>
   </options>
</field>

I have mixed feelings about it.  When I had to build the categoryPicker it
felt "dirty" -- I didn't want to have go build new field types every time I
just wanted a discrete list to choose from for a given field.  So, when
moving to XML it seemed to offer a good deal of freedom to do something
simple like have a generic "picklist" field that can be fed some options.  I
am very open to suggestions on to accomplish this in a better way.  It did
not seem sufficient to me to just say that "type" in this case is just a
"string" and then make the developer worry about what the options for "type"
might be -- I don't see how that has much advantage over the "old way" with
an RDBMS and a bunch of templates for rendering forms.  I also don't think
that every time I want to pick from a list of things that it should be a
list of other contentObjects -- seems like overkill for a "type" or a
"category" or a "state" to have to be a contentObject, when all it needs to
be is one (or more) from a list of defined options (though
org.bacfug.modus.fields.usastate is probably a candidate to be a built-in
field given how often it's used).