RE: Zeus: Data binding and Enhydra Enterprise services

["Christophe Ney" <cney@xxxxxxxxxx>]

- I like marshaller.setImplClass("Foo", "MyFooImpl");
- using reflexion is fine, we'll se if performance is a problem
as we go.

Christophe


>-----Original Message-----
>From: owner-Zeus@xxxxxxxxxxx [mailto:owner-Zeus@xxxxxxxxxxx]On 
>Behalf Of
>Brett McLaughlin
>Sent: Tuesday, January 16, 2001 2:53 PM
>To: Zeus@xxxxxxxxxxx
>Subject: RE: Zeus: Data binding and Enhydra Enterprise services
>
>
>
>
>> -----Original Message-----
>> From: owner-Zeus@xxxxxxxxxxx 
>[mailto:owner-Zeus@xxxxxxxxxxx]On Behalf Of
>> Christophe Ney
>> Sent: Tuesday, January 16, 2001 4:43 PM
>> To: Zeus@xxxxxxxxxxx
>> Subject: RE: Zeus: Data binding and Enhydra Enterprise services
>>
>>
>> Yes it make sense. Comments:
>>
>> - We might want the marshaler to use another concrete
>> class implementing Foo instead of FooImpl
>
>Agreed. And I think that's the only problem I'm not completely 
>happy with a
>solution for. Some thoughts include:
>
>* Make Marshaller an interface, and the functionality I 
>described would be
>handled by <code>SimpleMarshaller</code>. Then, other impls could be
>supplied/provided.
>
>* Add a method to Marshaller (back to the concrete class):
>
>public void setImplClass(String interfaceName, String implClassName);
>
>This would build up a Hashtable with interface/impl class 
>names in it. By
>default, each interface would be associated with 
><interfaceName>Impl. But
>doing, for example:
>
>marshaller.setImplClass("Foo", "MyFooImpl");
>
>would mean that when the marshaller did object creation, and 
>looked up the
>class to use for the interface "Foo", it would find your 
>MyFooImpl class
>name, and Class.forName() that, instead of FooImpl.
>
>I actually really like the last one better, as I type it - what do you
>think?
>
>> - One marshaler is perfect, but will require intensive use of
>> the reflection API.
>
>True. And it's worth asking if that tradeoff (usability vs. 
>speed) is worth
>it. I'll let the (small) community speak out before I do on this one.
>
>> - Are we reading/writing to a stream or a reader/writter?
>
>Won't matter - the Stream and Result interfaces abstract that. 
>You'll do
>something like:
>
>Result result = new Result("foo.xml");
>result.write("blah blah blah");
>
>and it will take care of the rest. On the other side, the 
>result impl will
>use whatever is easiest for it. So it's going to become an 
>implementation
>detail. Of course, you could do:
>
>Result result = new Result(myOutputStream);
>Result result = new Result(myWriter);
>
>and it takes care of all of that.
>
>-Brett
>
>>
>> Christophe
>>
>> >-----Original Message-----
>> >From: owner-Zeus@xxxxxxxxxxx [mailto:owner-Zeus@xxxxxxxxxxx]On
>> >Behalf Of
>> >Brett McLaughlin
>> >Sent: Tuesday, January 16, 2001 2:26 PM
>> >To: Zeus@xxxxxxxxxxx
>> >Subject: RE: Zeus: Data binding and Enhydra Enterprise services
>> >
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: owner-Zeus@xxxxxxxxxxx
>> >[mailto:owner-Zeus@xxxxxxxxxxx]On Behalf Of
>> >> Christophe Ney
>> >> Sent: Tuesday, January 16, 2001 4:14 PM
>> >> To: Zeus@xxxxxxxxxxx
>> >> Subject: Zeus: Data binding and Enhydra Enterprise services
>> >>
>> >>
>> >> Brett,
>> >>
>> >> Do you plan to write a marshaler class that will marshal/unmarshal
>> >> the Data Object using setter and getter methods?
>> >
>> >I had not... one Marshaller class and one Unmarshaller class
>> >would be able
>> >to do all marshalling and unmarshalling, I would think. I'm
>> >not sure why you
>> >would need specific "flavors" like MyDtdMarshaller or
>> >MyFooMarshaller. But
>> >maybe I'm missing something?
>> >
>> >However, as for the DTD, I assume you meant:
>> >
>> ><!ELEMENT foo (description)>
>> ><!ELEMENT description (#PCDATA)>
>> >
>> >In that case, you would get:
>> >
>> >public interface Foo {
>> >  public String getDescription();
>> >  public void setDescription(String description);
>> >}
>> >
>> >public class FooImpl implements Foo {
>> >  private String description;
>> >
>> >  public String getDescription() {
>> >    return description;
>> >  }
>> >
>> >  public void setDescription(String description) {
>> >    this.description = description;
>> >  }
>> >}
>> >
>> >Then, if you had an XML document:
>> >
>> ><?xml version="1.0"?>
>> >
>> ><foo>Hello World</foo>
>> >
>> >called, say, /usr/local/foo.xml, you could do:
>> >
>> >Marshaller marshaller = Marshaller.getInstance();
>> >Object o = marshaller.marshal(new 
>StreamSource("/usr/local/foo.xml"));
>> >
>> >if (o != null) {
>> >  Foo foo = (Foo)o;
>> >  String theDescription = foo.getDescription();
>> >
>> >  foo.setDescription("See you later");
>> >  Unmarshaller unmarshaller = Unmarshaller.getInstance();
>> >  unmarshaller.unmarshal(foo, new 
>StreamResult("/usr/local/foo.xml"));
>> >}
>> >
>> >You would have then written back out:
>> >
>> ><?xml version="1.0"?>
>> ><foo>See you later</foo>
>> >
>> >Make sense? Comments?
>> >
>> >-Brett
>> >
>> >>
>> >> This would be very usefull for configuration of EE services.
>> >> In EE the configuration object must extends 
>TargetAccessPoint which
>> >> implies that it cannot be generated by the Zeus framework.
>> >> However, the Zeus framework could generate a Data Object interface
>> >> and provide a marshaler for it.
>> >>
>> >> let say that myDTD contains
>> >>
>> >> <!ELEMENT foo (description)>
>> >> <!ELEMENT a (#PCDATA)>
>> >>
>> >> Zeus would generate
>> >>
>> >> public interface Foo {
>> >>   public void setA(String a);
>> >>   public String getA();
>> >> }
>> >>
>> >> public MyDTDMarshaler {
>> >>   public void marshal(Reader r, Foo f){...}
>> >>   public void unmarshal(Writer w, Foo f){...}
>> >> }
>> >>
>> >>
>> >> ------------------------------------------------------------------
>> >> -----------
>> >> To unsubscribe from this mailing list, send email to
>> >majordomo@xxxxxxxxxxx
>> >> with the text "unsubscribe zeus" in the body of the email.
>> >> If you have other questions regarding this mailing list,
>> >send email to
>> >> the list admin at owner-zeus@xxxxxxxxxxxx
>> >>
>> >
>> >---------------------------------------------------------------
>> >--------------
>> >To unsubscribe from this mailing list, send email to
>> >majordomo@xxxxxxxxxxx
>> >with the text "unsubscribe zeus" in the body of the email.
>> >If you have other questions regarding this mailing list, 
>send email to
>> >the list admin at owner-zeus@xxxxxxxxxxxx
>> >
>>
>> ------------------------------------------------------------------
>> -----------
>> To unsubscribe from this mailing list, send email to 
>majordomo@xxxxxxxxxxx
>> with the text "unsubscribe zeus" in the body of the email.
>> If you have other questions regarding this mailing list, 
>send email to
>> the list admin at owner-zeus@xxxxxxxxxxxx
>>
>
>---------------------------------------------------------------
>--------------
>To unsubscribe from this mailing list, send email to 
>majordomo@xxxxxxxxxxx
>with the text "unsubscribe zeus" in the body of the email.
>If you have other questions regarding this mailing list, send email to
>the list admin at owner-zeus@xxxxxxxxxxxx
>

-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx
with the text "unsubscribe zeus" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-zeus@xxxxxxxxxxxx