Partial custom fields design document
etzwane at schwag.org
Fri Mar 12 06:58:25 UTC 2004
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
>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
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.
More information about the developers