We have discussed about this topic before. But I want to try to reanimate it, because
I think it is
important.
I'll try to summarize the current situation first as far as I know and understand it.
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
xml's.
Obviously, this is not enough, so the type can currently be more precisely specified
like this:
- attributes on the <type> tag in builder xmls. These are database related issuses
like 'size',
'notnull' and 'key'. I think the available attributes are not optimally well defined
but that is another
issue..
- one of the attributes here is also 'doctype' which is relatively new and makes only
sense for xml
fields. I don't think it is a very good idea to specify it in the db-section
- the 'guitype' tag in the 'gui' section, can specify a bit further what kind of field
it is. This
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 <input> or a <textarea> 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
editors.
- 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).
- MMbase knows the concept of TypeHandler, which principally are pluggable. (implement
you
alternative type-handler, place an xml in WEB-INF/classes 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?
Michiel
--
Michiel Meeuwissen
Mediapark C101 Hilversum
+31 (0)35 6772979
nl_NL, eo, en_US
mihxil'
[]()
