We have discussed about this topic before. But I want to try to reanimate it, because I think it is important.
I agree, and I'm sorry I didn't reply sooner......
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..
Which must be taken care off.
- 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
It depends. Some database are capable of storing xml inside a field, maybe the databaselayer can do some kind of dtd-checking?
But maybe you're right, and maybe it's better to define the doctype (or schema??) elsewhere.
- 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).
With the scaneditors you could also create an editpart (a little shtml file with the same name as the guitype) to create somekind of display of the field.
- 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.
Is there some kind of documentation about these options?
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 think that's a good idea.
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.
You're creating some kind of FieldType class/interface?
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.
This would certainly create some interesting possibilities.
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?
I think (as I wrote earlier today) starting a project is a good idea.
Gerard
