Back to overview

Field Type Specializations. Review article + discussion.

Fields of MMBase nodes can currently be of the following types: string, integer, byte array, float,
double, long, xml and node. These are the values which can be given to the <type> tag in the builder
Obviously, this is not enough, so the type can currently be more precisely specified like this:

'notnull' and 'key'. I think the available attributes are not optimally well defined but that is another
issue.. fields. I don't think it is a very good idea to specify it in the db-section is used by editors. Several interpretation mechanisms are available:
- Certain key strings are recognized. For example I think 'field' and 'string' are recognized by
scan-editors to determin with a &lt;input&gt; or a &lt;textarea&gt; must be used. Someone (er, me) did not
realize this, and taglib editors do not use this. They simply look at the size of the string to
decide this.
You can also see things like 'boolean', 'types', 'eventtime' etc here (only make sense for
integer and long fields).
- If the field is of type Node, the guitype can be the name of a builder. This means that the node
must be of this type, and a dropdown box with all nodes of that builder can be generated in
- If the field is of type Integer then the guitype can be interpreted as the name of a resource
bundle, which - if succesful - can be used to generated (internationalized) dropdown boxes of
possible values in editors (if based on taglib). alternative type-handler, place an xml in WEB-INF/lasses and it will be used by fieldinfo tag).
You could also define more guitypes like this.
So, I think most necessary things are basicly possible, but what is lacking is a nice and clear idea
behind it. Furthermore it is pitty that interesting information and interpretation functionality is
implemented a bit too 'high' (in actual implementation of editors / taglib).
It seems to be a good idea to add hooks on a lower level to define type specializations for editors
(now mostly in guitype). I think of the bridge here. Perhaps we can say that real database
limitations (defined in the db-section of builder xml) can be enforced in core/database layer, and
that further specialization can be enforced and/or provided on bridge level.
I was trying to define an interface which should fixate the specialization information of a certain
field. It should e.g. somehow be able to inform about the 'possible values' of a
field. Editor-implementations can then request this information to make drop-downs if the number is
limited, or e.g. simply to check (with javascript or so) that the given float value is indeed between 0.0
and 10.0, as required by the field specialization.
It should also provide the hooks for processing set- and getValue-calls. If the field is for example
of XML type, then it could check if the field is actually of the right specified doctype (or even
(xslt) convert it to right type). If the field is for example of type String with specialization
'translatable' then it could consider the Locale setting of the Cloud in the get- and setValue of
that field.
Only for xml-field doctype combinatation there is some code know (made for the rich-text project),
but I do not think it is general enough.
What are the ideas about this? What kind of implementation/interface would we like best, and 'where'
should it be defined?