Michiel Meeuwissen wrote:
On 5 Nov 2005, at 11:45, Ernst Bunders wrote:
well, that is arbitrary, as wel as logical. it would also be logical
to take a line input type for every string that can only be 40 or 50
chars long. But that's not really the point.
The point is that the specification dous not allow you to define the
interface type for a given presentation medium (html, swing, is there
an other..?). So the result is that the mmeditors, the my_editors and
the wizards might produce different interface elements for the same
fieldtype. Which is not a problem, becouse they still have to follow
the rules that define the field type, but still it is not consistent.
Well, we could perhaps also implement generic 'html-handlers' or so.
Actually code for this is now accumalating in taglib (the infamous
mm:fieldinfo), of which the 'typehandlers' now take the task of
translating datatypes into html form entries. They did that in previous
versions as well, but they're are getting much more generic, because
they depend heavily on information of the data-type.
Perhaps we can go one step further and move also that code outside
taglib, to a generic 'HtmlDataTypeHander' or so, which translates
DataTypes into Html, and which can then be itself pluggable and reused
e.g. in editwizards.
Of course you can then also anticipate SwingDataTypeHandler,
SMSDataTypeHandler then or whatever you like.
But perhaps we can postpone that to 1.8.1 :-)
there is allso a middle way. We could define a gui defenition language
compareable to the searchquery syntax, where you can define
characteristics of a gui interface element:
<guitype>
<line length="40">
</guitype>
or
<guitype>
<textarea width="40" height="10%">
</guitype>
where the attributes defining size would be taken as hint rather than
definit values, so the 'layout manager' of the given platform could then
transform them into the local variaty of the interface type.
the advantage would be that it would take away the ambiguity of the
interface type choice, but would leave the platform-specific details to
the client code.
getting all carried away, i think we could even add some kind of
databinding where, for instance in an i18n fieldtype (an xml field with
elements for some content for different languages) you could define a
combination of a dropdown with all supported languages with a textarea
allowing you to edit the contents of the matching element.
but maybe this is all over the top, i don't know. it just seems kind of
logical, thinking about xul and formats like that.
Ernst
Not a real problem, but i am just a bit surprised. I have not fully
delved into the fieldtype code and specification yet, but i guess i
had more or less expected something like this.
The funny thing is that now using the 'guitype' element in the
builder configuration, you can define a lot about a field, except the
actual gui type :-)
Actually the 'guitype' element is deprecated. 'new style' builders
define it not at all or define a 'datatype' in stead.
They only give indication for GUI, because of course the type itself
needs to be as device independent as possible.
Btw, I also anticipate a transfer from the 'gui' function to the
datatype implementation. Because the gui-function produce HTML now,
which is a bit silly, so it would be nice if the datatype could somehow
produce the relevant information for that only.
--
mihxil'
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
