-----Oorspronkelijk bericht----- 
        Van: [EMAIL PROTECTED] namens Michiel Meeuwissen 
        Verzonden: za 29-1-2005 17:49 
        Aan: [email protected] 
        CC: 
        Onderwerp: Re: [Developers] Re:[MMBASECVS]src/org/mmbase/bridge/util 
MapNode.java
        
        

        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').
        

NodeProxy doesn't implement Node, although it could implement getNode() 
allowing you to access node methods from EL (no problems in overriding anything)

Furthermore you determine the model/methods and what methods are overriden when 
exposed to EL and the model can also be exposed to jxpath (although we need a 
connection from jxpath to query mechanisms to be more powerfull).

Michael

        
        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 
<http://lists.mmbase.org/mailman/listinfo/developers> 
        


Disclaimer

Dit bericht met eventuele bijlagen is vertrouwelijk en uitsluitend bestemd voor 
de geadresseerde. Indien u niet de bedoelde ontvanger bent, wordt u verzocht de 
afzender te waarschuwen en dit bericht met eventuele bijlagen direct te 
verwijderen en/of te vernietigen. Het is niet toegestaan dit bericht en 
eventuele bijlagen te vermenigvuldigen, door te sturen, openbaar te maken, op 
te slaan of op andere wijze te gebruiken. Ordina N.V. en/of haar 
groepsmaatschappijen accepteren geen verantwoordelijkheid of aansprakelijkheid 
voor schade die voortvloeit uit (de inhoud van) de verzending van dit bericht.

This e-mail and any attachments are confidential and is solely intended for the 
addressee only. If you are not the intended recipient, please notify the sender 
and delete and/or destroy this message and any attachments immediately. It is 
prohibited to copy, to distribute, to disclose or to use this e-mail and any 
attachments in any other way. Ordina N.V. and/or its group companies do not 
accept any responsibility nor liability for any damage resulting from (the 
content of) the transmission of this message.

<<winmail.dat>>

_______________________________________________
Developers mailing list
[email protected]
http://lists.mmbase.org/mailman/listinfo/developers

Reply via email to