On May 12, 2009, at 9:52 , Michiel Meeuwissen wrote:
On Mon, May 11, 2009 at 14:40, Peter Maas <pe...@maas-frensch.com>
wrote:
There is still a lot of ground to cover, but the basics work, and the
populator class is still less then 200 lines of code! No public
sourcecode
yet, but I'd be more than happy to contribute it in the near future
if
others are interested.
looking forwards to ideas, criticism etc.
My first idea is that it actually seems to solve a similar problem as
I'm often trying to address nowadays using virtual fields which I then
implement using 'get' and 'set' processors, which often boils down to
adding pieces of XML to the builder xml. If I understand correctly I
see that you try to 'rename' field (e.g. description/intro) or embed
stuff of a related node into the object itself. For this last thing I
e.g. recently added to a builder xml:
<field
xmlns="http://www.mmbase.org/xmlns/builder";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.mmbase.org/xmlns/builder
http://www.mmbase.org/xmlns/builder.xsd";
name="mediaprovider" state="virtual">
<gui>
<guiname xml:lang="nl">Provider</guiname>
<guiname xml:lang="en">Provider</guiname>
</gui>
<datatype base="node" xmlns="http://www.mmbase.org/xmlns/datatypes"; >
<default value="mediaprovider_localhost" />
<required value="true" />
<enumeration enforce="never">
<query type="mediaproviders"
xmlns="http://www.mmbase.org/xmlns/searchquery";>
<sortorder field="name" />
</query>
</enumeration>
<setprocessor>
<class name="org.mmbase.datatypes.processors.Related$Setter">
<param name="type">mediaproviders</param>
</class>
</setprocessor>
<getprocessor>
<class name="org.mmbase.datatypes.processors.Related$Getter">
<param name="type">mediaproviders</param>
</class>
</getprocessor>
</datatype>
</field>
which completely implements a related 'provider' which simply is a
relation, but it looks like a field now (not only readonly, but also
writable), by telling it what are allowed values, what must happen on
set, and what must happen on get of the value. The main goal is
actually editors, because for this new field an entry in customized
editors can be made just as simply as for any other field.
Cool, didn't know about this feature... I'll have to think about it
and do some experiments!
This does of course not provide strong typing so a system like you
propose seems to have a certain advantage too. But in that case even
builder xmls themselves could perhaps be completely replaced by
something like this; I'd say that one can as well drive the complete
node-manager configuration by annotations (something which IIRC was a
century ago or so already proposed by keesj). I do think however that
there may be a long way to get that as feature-rich as the builder XML
(+ datatype XML) is now.
The huge advantage of a 'pojo' datamodel is that it is far easier to
use in combination with other frameworks (i.e. JAXB, CXF, DWR, ..
endless list). I'm not proposing to replace the XML builders but to
create an easy way to get MMBase nodes to play with other frameworks.
But anyways, If you like to show a bit more of it, e.g. actually
usuable code, and are looking for a way to do that, I invite you to
simply commit it into the 'speeltuin' (iirc you do have commit rights
already?).
Yeah, I'll do that (if I'm able to recover my credentials). Still
fighting a battle to get a decent set of tests to run without MMBase
getting in the way; and I still have to rip it out of the VPRO
codebase. Can show a working version on thursday though ;)
Michiel
Peter
_______________________________________________
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
--
mihxil' http://meeuw.org
nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
_______________________________________________
Developers mailing list
Developers@lists.mmbase.org
http://lists.mmbase.org/mailman/listinfo/developers
