Mail Archive Home | zeus List | January 2001 Index
| <-- Date Index --> | <-- Thread Index --> |
> -----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
| <-- Date Index --> | <-- Thread Index --> |
Powered by MHonArc.
Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.