Homeijer, Michael wrote:
> Building a proxy gives you the power to expose properties, relations and
> other stuff the way you want it to EL. You also have the possibility to
> wrap returned values if neccesary and you won't loose the dynamics of
> Nodes.
Ah, I did not thought of that yet.
So, if I may resume, I think we have three or four ideas now:
- Node extends Map
Fieldvalues would become accessible in EL, but Node interface gets
polluted.
- MapNode implements Map, Node
FieldValues become accessible in EL, Node interface stays clean, node
functionality still available on the object (but probably not in EL).
Implementation is relatively simple.
- NodeMap implements Map
Node is a Map, implementation even simpler, fieldvalues are accessible, but
nothing else.
The original Node needs separate storage (mm:node referid=".." coudl not
deal with a map).
- NodeProxy implements Node
Field values are accessible. Except the ones coinciding with node methods
(a field name 'cloud' may get inaccessible?). The advantage is that those
things are accessible. ${node.cloud.name} woudl work, as would, I suppose,
${node.relatedNodes[0].title}, if Node is Map it wouldnt' but, because the
existing 'get' method would shield everything.
The last one is obviously the post powerful, because it avoids shielding of
bean-like methods in Node, and with some imagination practicly the complete
bridge get accessible directly in EL. It also seems the most complicated to
implement and perhaps to understand (because it would be a bit confusing
that you cannot do 'node.cloud' to get a field named 'cloud').
Is that a correct representation of all ideas?
Michiel
--
Michiel Meeuwissen mihxil'
Mediacentrum 140 H'sum [] ()
+31 (0)35 6772979 nl_NL eo_XX en_US
_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers
