+1 for separating internal model from persistence provider. Also, do we have demand for xml from the api?
On Thu, Mar 21, 2013 at 1:38 PM, Venkatesh S R <[email protected]> wrote: > Hi Team, > > I am Venkatesh and I am new to this group :). But reading this email, I > recognize this problem and +1 for the same. I want sure if we have taken a > look at Dozer, its very intuitive and simple for Model Mappings. > > Thanks > Venkatesh > > > > > > On Wed, Mar 20, 2013 at 2:39 PM, Matt Franklin <[email protected] > >wrote: > > > On Wednesday, March 20, 2013, Chris Geer wrote: > > > > > As I've been working on this new web service layer it's becoming > clearer > > > that we need to separate our public model from our private model since > we > > > need to control serialization/deserialzation. A great example of this > is > > > the User password field. It's needed internally but should never be > sent > > > externally. The challenge we have right now is it's up to the > persistence > > > provider to annotate their objects with the proper serialization data > > > (JAXB/JSON) so each provider could serialize/deserialize differently. > > There > > > is also a challenge of deserializing into the right object type. > > > > > > My suggestion is we create a separate model that is used for the web > > > services that can be converted to the correct backend datatype. There > is > > > probably some ways to use inheritance and stuff to simplify this but > I'll > > > have to play and see what works. We'll also have to move away from the > > > Spring OXM marshaling approach since that only works with Spring > Web/MVC > > > not JAX-RS. > > > > > > +1. There is a good chance we may want the modem exposed to be different > > than the internal one in terms of fields anyway. For instance, we > probably > > want to expose regionWidgets the way they are used in the client, > including > > security tokens. > > > > > > > > > > Does anyone have any concerns about this? > > > > > > Chris > > > > > >
