Homepage / Roadmap - bugs / Archived projects


Michiel Meeuwissen (project leader)

Jaco de Groot

Willem Voogd

Pierre van Rooden



Field Type Specializations. Review article + discussion.

Minutes 2004-07-21

Field Types & Data Types


evidently missing is a date-time field type, which is supported by most
databases, but MMBase offers to store times and dates in integer (or long)
typed fields only, which is a bit silly, and blocks for example the
possibility to delegate a task like 'find the persons who have there
birthday today' to the database (using functions on date-fields). ('guitype'). Additional value-constraints (enum-types (drop-downs) and
more) must be acquirable for use by editors (also, e.g. by editwizards).




to define these characteristics of a field and propogate this information to the several parts of
the code which would need these ((taglib/jsp) editors, editwizards).


This projects wants to solve these problems. Post- and pre-processing was already implemented in 1.7
(as an aid for e.g. i18n implementations). The given database-types are to be implemented and a
framework for field type specialisions will be created (based on the processors-xml of 1.7).

The project will be considered completed when these goals are achieved, and
some actual specialization implementations are created.


For the new database types every current 'switch' between existing database
types will be extended with the new ones. Such switches and arrays occur on
several places in the mmbase core code, but most noticably in the storage
and query layer. The 'FieldDefs' class may need review.

The database types will remain to be defined in the java code by means of specialized functions and
switch statements, so this will remain a fixed list.

Specializations on that (similar to the current Strings in 'guitype' of builder XML's) will become
fully pluggable though. In an XML (similar to fielddefinitions.xml, which is currently
'experimental' and will probably be moved) you will be able to define per
database-type/specialization combination:

value of the field, and perhaps also indications for a GUI value (e.g. if the field is enum, the
gui-value must be based on a string associated with the integer value). Also other functions on
field (rather then on node) should be implementable on this level.

Perhaps even inter-field-dependency will be dealt with (e.g. the value of the 'itype', 'filename'
and 'size' fields of images should depend on an upload of the 'handle' field). It is not yet
completely clear how this would look like. Perhaps it can simply be done in a post-processor.

Other detail-preferences may also be indicatable in interface or XML. Like
preferred sort-order, uniqueness and these kind of things.

The current existing 'specializations' like 'field' 'string' '<node-type>' '<resource bundle>' 'eventtime' are
of course to be replicated in this new framework.


Core classes will be modified to know about the new database types (like the storage and query
layer), and also the bridge ('Node#getDateValue' and the like). The bridge will also need some
extension to be able to request the new specialization information ('Field#getDefaultValue,
Field#getPossibleValues etc). Taglib will be modified to use the field-specialisation interfaces to
generate edit-tools (mm:fieldinfo), rather then implement it itself, and there will be e.g. a new
constraint tag for date-time fields. Editwizard, Dove will also need improvents to be able to profit
from these interfaces (e.g. 'optionslist' will need to be generated from the list of possible
values, and transferred to the wizards, for possible use). We will ignore SCAN, which will not
profit from these improvements.

There will be created a package to hold the interfaces and implementations (presumably in a
sub-package) of the field specialisations. Probably org.mmbase.module.core.fields will take the
function of org.mmbase.bridge.util.fields (experimental and will then be removed again). It also
depends on where core classes 'should' reside according to the cleaning project.

To make the pre- and post-processing functionality more feasible, on cloud set- and getProperty
(like on BridgeList) will be implemented.

Small backward compatibility issues will arise for those already using the experimental
field-definitions XML of 1.7, but probably little more then moving the XML and perhaps recompiling
the "processors" classes will be needed to fix those.

No front-end issues are anticipated. It is possible though that configuration issues will arise (to
get excactly the same behavior as previously, it might e.g. be necessary to edit some builder
XML's). It is possible that e.g. the jsp-editors will have slightly different drop downs (better


The database types will firstly be implemented and that will be ready very soon, because it is a
rather straight-forward change. This will be followed by support for them in bridge and taglib.

After that, the specialisation framework will be set up. The specialization interfaces will be added
and tested by making some implementations. E.g. sorted localized enums, based on integer database
stype, java constants and resource-bundles.

Depending on how much time we find, I think that in a few months time we could have a reached a
stable state which can be released in 1.8. Then we will probably need some time for
detail-improvements, bugfixing, and actual specialization implementations.