Re: [Simple-support] stating the deserialization strategy on a class using annotation

[Niall G. <gal...@ya...>]

Cool, I will take a look at adding something like this in a future release. I am currently finishing of a new feature. So ill take a look after that. Thanks for the feed back.

--- On Tue, 1/3/11, hatchetman82 <hat...@gm...> wrote:

> From: hatchetman82 <hat...@gm...>
> Subject: Re: [Simple-support] stating the deserialization strategy on a class using annotation
> To: "Niall Gallagher" <gal...@ya...>
> Cc: sim...@li...
> Received: Tuesday, 1 March, 2011, 3:37 AM
> we will. i just thought this feature
> might be useful in a more general
> sense, so i brought the idea here.
> 
> On Tue, Mar 1, 2011 at 13:31, Niall Gallagher <gal...@ya...>
> wrote:
> > Why not create this annotation yourself. It seems
> specific to what your doing so just created it in your own
> package. It will works just as well. Just wrap the Persister
> in a Serliaizer implementation that uses this annotation.
> >
> >
> > --- On Mon, 28/2/11, hatchetman82 <hat...@gm...>
> wrote:
> >
> >> From: hatchetman82 <hat...@gm...>
> >> Subject: Re: [Simple-support] stating the
> deserialization strategy on a class using annotation
> >> To: "Niall Gallagher" <gal...@ya...>
> >> Cc: sim...@li...
> >> Received: Monday, 28 February, 2011, 4:02 AM
> >> we have an enterprise system with a
> >> REST api. basically we're sending
> >> and receiving XML over HTTP.
> >> all of our methods send or receive
> Simple-xml-annotated
> >> classes that
> >> represent either requests or responses. RESTeasy
> (the
> >> framework we use
> >> to drive this API) provides a mechanism to
> derialize and
> >> deserialize
> >> Objects into their string representation (XML in
> our case)
> >> via its
> >> MessageBodyReader and MessageBodyWriter
> interfaces.
> >> our use case revolves around the reader component.
> this is
> >> the
> >> component that gets an input stream and a class
> type and
> >> is
> >> responsible for deserializing an instance of this
> class
> >> type from the
> >> input stream.
> >>
> >> some of our simple-annotated classes require a
> strategy to
> >> deserialize
> >> (this strategy needs to be provided as an argument
> to the
> >> Persister
> >> constructor). since we know what type we intend
> to
> >> deserialize, we can
> >> provide the appropriate strategy, but the
> resulting code is
> >> a giant
> >> switchboard of if-elses and it not very pretty,
> fast or
> >> maintainable
> >> as a result (this message body reader is a single
> point of
> >> entry to
> >> the entire application).
> >>
> >> since Persister receives the type to be serialized
> as the
> >> 1st argument
> >> to its read() method, i was thinking it would have
> been
> >> nice to be
> >> able to state the deserialization strategy on the
> >> simple-annotated
> >> class somehow.
> >>
> >> so, for instance, instead of doing this:
> >>
> >> Strategy s = getStrategy(type); //ugly code hidden
> here
> >> Persister p = new Persister(s);
> >> Object result = s.read(type,inputStream);
> >>
> >> i could have something like this on my class:
> >>
> >> @DeserializationStrategy(MyStrategy.class)
> >> @Root(name="myClass")
> >> public class MyClass {
> >>    //code here
> >> }
> >>
> >> and then i could create a Persister using the
> no-arg
> >> constructor, and
> >> upon calling read() the persister could inspect
> the type
> >> (its getting
> >> it as the 1st arg anyway) for
> @DeserializationStrategy, and
> >> if found
> >> use that strategy to read the object from the
> input
> >> stream.
> >> that would save us the need to find the strategy
> ourselves,
> >> and would
> >> make the resulting code more elegant
> >>
> >> On Mon, Feb 28, 2011 at 13:09, Niall Gallagher
> >> <gal...@ya...>
> >> wrote:
> >> > Hi,
> >> >
> >> > If you could provide more details that would
> be great!
> >> Not sure what your trying to achieve here. Have
> you tried
> >> the @Convert annotation or even a visitor?
> >> >
> >> > Niall
> >> >
> >> >
> >> > --- On Sun, 27/2/11, hatchetman82 <hat...@gm...>
> >> wrote:
> >> >
> >> >> From: hatchetman82 <hat...@gm...>
> >> >> Subject: [Simple-support] stating the
> >> deserialization strategy on a class using
> annotation
> >> >> To: sim...@li...
> >> >> Received: Sunday, 27 February, 2011,
> 10:47 PM
> >> >> Hi.
> >> >>
> >> >> we use simple-xml to (de)serialize entity
> classes
> >> for out
> >> >> application's REST api (using resteasy).
> >> >> as part of the RESTeay api, there's an
> interface
> >> called
> >> >> MessageBodyReader responsible for
> deserializing
> >> XML into a
> >> >> java class
> >> >> with the following signature:
> >> >> public Object readFrom(Class type, /*
> stuff
> >> omitted */,
> >> >> InputStream
> >> >> inputStream);
> >> >> deserializing some of our classes
> requires custom
> >> Strategy
> >> >> implementations, which turns the
> implementation of
> >> the
> >> >> above method
> >> >> int a giant switchboard of if-elses
> according to
> >> the type
> >> >> variable. it
> >> >> would be very nice to be able to have
> some sort
> >> of
> >> >> @DeserializationStrategy(value=[some
> strategy
> >> class])
> >> >> annotation on
> >> >> simple-xml-annotated classes to prevent
> this
> >> scenario.
> >> >> is this possible?
> >> >> if so, is it on the roadmap anywhere?
> >> >>
> >> >> thanks in advance for any assistance,
> >> >>    radai.
> >> >>
> >> >>
> >>
> ------------------------------------------------------------------------------
> >> >> Free Software Download: Index, Search
> &
> >> Analyze Logs
> >> >> and other IT data in
> >> >> Real-Time with Splunk. Collect, index and
> harness
> >> all the
> >> >> fast moving IT data
> >> >> generated by your applications, servers
> and
> >> devices whether
> >> >> physical, virtual
> >> >> or in the cloud. Deliver compliance at
> lower cost
> >> and gain
> >> >> new business
> >> >> insights. http://p.sf.net/sfu/splunk-dev2dev
> >> >>
> _______________________________________________
> >> >> Simple-support mailing list
> >> >> Sim...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/simple-support
> >> >>
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >
> >
> >
>