My attempt at some comments, but I'm no guru on MMBase internals so don't flame me if some comments make no sense :)
> 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 Well, I think that the name 'db' for this section might be obsolete now. These kinds of constraints on the field should maybe be called 'constraints'. All these fields pose restrictions on possible values for a field: - type: what kind of characters are allowed - key/unique: may the same value be allowed for multiple instances? - doctype: what form should the character data have? - size: what is the max size of the data? etc. etc. Not all these requirements are strictly db-related; for instance the doctype is a bit weird. But I think this is the best way to place it. > - 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). This all sounds good ... > - 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). Well, I think you'r quite far with summarizing the clear idea: - Objects consist of definition of fields - Fields have: - constraints - GUI thingies that give representations of the fields Apparently these constraints are handled in the builder XMLs, while the TypeHandlers are responsible for the GUI part. Ofcourse there are is some legacy GUI stuff in the builder XML too, but maybe this could be rewritten? > 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 don't think pushing the field constraints down the db layer is a good idea, since not all constraints are db related. > 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. Another example of constraints; I don't think this is a DB constraint; it's a more high-level constraint. > 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. Maybe something for the TypeHandler also? > 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 the current code is very well usuable, except for some legacy code (gui stuff in the builder XML). Johannes
