Partial custom fields design document

[Sean McAfee]

Joel Peshkin <bugreport at peshkin.net> wrote:
>It seems that multiple fields may wind up using the same selection id. 

Yeah, that's the idea.

> In that case, would it make sense to treat the cf_selection records as 
>items that have a human-understandable name (like a typedef) so that an 
>administrator who is creating 3 or 4 fields of the same type has a name 
>with which to refer to that type??

Maybe.  I think my original schema had such a selection name column, but I
never got around to writing any code that used it, so I took it out again.
An alternative to providing a name is to just let the administarator say
"when creating this new selection field, use the same selection set as that
other field".

>I am a bit confused about as_string.  Is that supposed to be something 
>that is fixed for each field type or something that is configured 
>somewhere?

It's fixed for each field type.  In my current implementation it's a no-op
for integer and string fields; for date fields, it converts the date fields'
[ $year, $month, $day ] representation (more convenient for code to deal
with, I think) to a string representation.  The custom fields template then
looks liks this:

[% IF field.is_selection %]
  [% # ... %]
[% ELSE %]
  [% value = field.as_string(field.value) %]
  [% # do stuff with value %]
[% END %]

Another alternative is to bless the arrays holding the date data into a
class that overloads stringification.  That would eliminate the need for
as_string.  I'm a bit reluctant to employ magic for so small a gain, though.


--Sean