There is quite some movement on the field-types project during the
last few weeks. Actually, that much has been changed, that a 1.8 beta
seems impossible at the moment...
Most work is by Pierre. Sometimes he and I discuss a bit about the
design decisions which were made, and though he listens quite well, it
would be better to give more people the opportunity to participate.
It is becoming evident that some of the made decisions will have an
influence on the design of the mythical 'core 2'. E.g. we introduced
'org.mmbase.core.CoreField', because 'FieldDefs' was obviously too
full of deprecated stuff. Currently CoreField extends
org.mmbase.bridge.Field, but the other way around, or both extending
from some mutual generic base, would also be imaginable (IIRC that
was my first approach). Likely the same paradigm will have to be
followed when 'CoreNode' is appearing to replace MMObjectNode and
'CoreNodeManager' to replace MMObjectBuilder (but these are far
outside the scope of the project, and likely much more involving).
Of course we would not necessarly be stuck with the decision we make
now, but some community contemplation about this design is desirable,
because having it right when 1.8 is release would certainly be
preferable.
Other issues are in my view could be:
- DataType. Originally the design was to make type/specialization
combinations (see the classes and XML's ('fieldtypedefinitions.xml)
under org.mmbase.bridge.util.fields), but now everything is called
DataType. Both approaches basicly deprecate and replace the 'guitype'
of a field.
- DataType and extensions now are in interfaces/basic-implementations.
That is indeed bridge-like, but since these things are actually quite
simple and straight-forward, it would perhaps make a simpler framework
if these things are simple serializable classes without implementiing
some intermediate interface. That would make things simpler and less
code-bloated. I think alternative implementations are not ever needed.
(serialization would e.g. be good enough for RMMCI). The whole stuff
can then perhaps even be 'cut loose' and be implemented rather
stand-alone. (a bit like org.mmbase.util.functions).
On the other hand we see that even Sun is eventually providing
interfaces for such simple things (e.g. String now implements
CharSequence...).
- DataTypes have now properties implemented with a 'Property'
sub-interface, which is even exposed to the outside. What do we think
of that? The idea of that is to not pollute the interface with all
kind of quite specific properties of a certain property (because one
property e.g. the 'required' property is actually a small set of
properties, like its 'value', with its 'error message' and its
'finalness'). A disadvantage is e.g. that a simple boolean property
gets represented in an general Object.
- other issues?
So, a field-types meeting seems necessary. Preferably in real life
('HEL'), but if people are in foreign countries or otherwise far away,
we could arrange something virtual too. That should perhaps happen
this month.
Who would like to attend and when?
Michiel
PS You're invited to react on the points of this mail too, of
course... If we can come to a conclusion like that, that would be fine
too, but I doubt if we can :-)
--
mihxil' http://mihxil.komputilo.org/
nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
