Count me in Andrey! This is a topic of interest for us. Current we have Data
Transfer Objects and a dozer factory that moves data back and forth. It
works well but direct serialization would be absolutely fantastic.
This is also very interesting for Wicket development since it would let us
serialize some of our smaller items and not be forced to use loadable
detachables.
I would love to contribute, keep me posted..
John-
On Sun, Mar 7, 2010 at 2:03 PM, Andrey Razumovsky <
razumovsky.andre..mail.com> wrote:
> Hi John (and others working with Cayenne and GWT)!
>
> Are you still interested in the subject?
> I've been doing some research and on the surface the first results look
> very
> promising.
> In a couple of words, I bet you can use your CDOs on client without any
> other branch of generated classes and without any custom templates!
> All you'll need is to add a line in your gwt.xml - and the objects will
> become Serializable! Thus, you can make CDOs as result of RPC call, and
> vice
> versa, send them to server. This is faster because no Dozer copying or
> something is needed.
> The next steps will be to make Query API avaliable to client, so that you
> can perform asynchronous queries from client side, and think of mechanizm
> of
> merging client changes back to server (or even make some mock ObjectContext
> for client side).
> I'm seriosly thinking of starting Cayenne subroject with that (or separate
> open-source project). Does anyone find this interesting??
>
> 2010/1/28 John Armstrong <siberia..mail.com>
>
> > The way I am handling 'what gets mapped' is with a BeanFactory class
> > that uses Dozer to do basic mapping on a per CDO/Bean basis. BeanUtils
> > could do this but BeanUtils blows up a lot more easily. Dozer handles
> > serializable attributes automatically for us. Case by case I add logic
> > to my BeanFactory for a specific class or use a Dozer xml mapping file
> > as appropriate (same as you are doing in xml probably, just with
> > Dozer). I get to pick which method to use though so the tool scales
> > well from a developer point of view.
> >
> > This gets me my basic POJO/CDO back and forth. The bean itself (pure
> > client side object) is not a one to one map with the CDO, its just a
> > client side representation of what data we want out of the CDO that is
> > required for the app display/logic.
> >
> > In other words: The bean has fields that the CDO doesn't. We treat the
> > CDO as 'data tier' and the mapped Bean as 'display tier'. What is in
> > the bean is very much driven by our UI requirements.
> >
> > So the CDO may have a many mapping that represents a list of 'client'
> > objects, the POJO has an integer that is 'clientCount' instead and
> > used for display purposes. To get an actual list of 'clients' is a
> > round-trip to the server to get a list of ClientBean based on some
> > attribute in the application. This seems to work nicely in the GWT
> > async construct. We keep this in mind as we design the interface so as
> > to minimize user wait states and we add Bean attributes as required to
> > support new UI requirements (CDO is not changed without a lot of
> > discussion however, it impacts a lot of other non-GWT interfaces).
> >
> > This is where I want to use Velocity templates. Just as cayenne
> > generates the _CLASS and CLASS versions of the file I want a third
> > which is CLASSBEAN that is very boiler plate. Just a bunch of :
> >
> > public ClientsettingsBean getClientsettingsBean(Clientsettings settings){
> > return mapper.map(settings,ClientsettingsBean.class);
> > }
> > public void setClientsettings(ClientsettingsBean bean,
> > Clientsettings
> > settings){
> > mapper.map(bean,settings);
> > }
> >
> > which can then be added to by the developer as required to achieve UI
> > goals that the Bean must support:
> >
> > public ClientsettingsBean getClientsettingsBean(Clientsettings settings){
> > ClientsettingsBean theBean =
> > mapper.map(settings,ClientsettingsBean.class);
> > // these could be dozer xml maps as well, developer choice
> >
> > theBean.setCountOfSomeAspectOfMyGraph(settings.getCountofSomeObject());
> >
> > theBean.setSomeOtherHugeAndExpensiveThingIfWeSentItAsARealObject(12);
> > return theBean;
> > }
> >
> > On the UI framework front. This is somewhat of a big debate,
> > particularly on the GWT lists. We really find the widget support in
> > GXT invaluable. Our GWT apps are very 'dashboard' like in nature and
> > almost entirely Grid driven. Our opinion is that the GXT grids are the
> > best going right now so thats where we ended up.
> >
> > John-
> >
> > On Thu, Jan 28, 2010 at 1:49 AM, Andrey Razumovsky
> > <razumovsky.andre..mail.com> wrote:
> > > Cool, didn't know about BeanModel.. I'm never used GXT. We've wrote
> quite
> > a
> > > lot of code in GWT-Ext (and it supports JSON).. This is raw and
> abandoned
> > > project, and I hate it more and more each day (and also I will never
> > anymore
> > > use wrapper library, like SmartGWT). Still I've been unable to persuade
> > my
> > > manager to spend several dollars for a licence :( Looks like now I have
> > one
> > > more reason to do it.
> > > As about beans on client, I've been dreaming about something like ROP
> for
> > > GWT. For now we can do the task of converting the objects to POJOs,
> this
> > > must be quite easy. Still I'm not sure, how you're going to decide what
> > part
> > > of Cayenne object graph is to be sent on client (this is what I use XML
> > > descriptions BTW)
> > >
> > > 2010/1/28 John Armstrong <siberia..mail.com>
> > >
> > >> I'm using GXT which has a pretty strong preference for its own
> > >> 'BeanModel' (thin wrapper around a javabean that understands GXT) for
> > >> grid population etc.
> > >>
> > >> That (in my mind) means I am either serializing Cayenne Models -> JSON
> > >> -> BeanModels or just going from Cayenne Model -> BeanModel so I
> > >> decided to skip the JSON step.
> > >>
> > >> Outside of easy GXT integration the only other thing I get are
> > >> enumerations (supposedly) which I use in a few important places in my
> > >> models.
> > >>
> > >> Does that make sense? I haven't done much straight GWT which is much
> > >> different then GXT so the interactions may be different.
> > >>
> > >> I am very interested in what you are doing, finding someone using GWT
> > >> and Cayenne is not so common!
> > >>
> > >> John-
> > >>
> > >> On Thu, Jan 28, 2010 at 12:43 AM, Andrey Razumovsky
> > >> <razumovsky.andre..mail.com> wrote:
> > >> > I'm currently using Cayenne and GWT. I think the question should be
> if
> > it
> > >> is
> > >> > worth it to convert server beans to client beans. Do you really need
> > data
> > >> > objects on client side? With a lack of reflection they cannot be
> > easily
> > >> used
> > >> > in UI. I think this only produces unneeded convertion.
> > >> > What I do is convert CDOs to JSON on server side, this is done with
> > >> > XML-based descriptions (which look much like json-taglib, but are
> > >> > standalone) and use only JSON-based data on client side.
> > >> > What do you think?
> > >> >
> > >> > 2010/1/28 John Armstrong <siberia..iberian.org>
> > >> >
> > >> >> I'm finding myself generating a lot of Beans that mirror my cayenne
> > >> >> entities (plus Dozer mappings) as I delve into GWT.
> > >> >>
> > >> >> This is crying out for automation and I'm sure a few others would
> > >> >> enjoy it. It may even make Cayenne very GWT Friendly.
> > >> >>
> > >> >> To move this ball forward (for me minimally) can anyone point me to
> > >> >> either some sort of sample implementation of Cayenne velocity
> > template
> > >> >> based code generation (or whatever is being used in 3.0) or a
> pointer
> > >> >> to where in the source code a sample template/generator lives that
> I
> > >> >> can explore?
> > >> >>
> > >> >> Tx. My fingers are getting sore-
> > >> >> John-
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Andrey
> > >> >
> > >>
> > >
> > >
> > >
> > > --
> > > Andrey
> > >
> >
>
>
>
> --
> Andrey
>
This archive was generated by hypermail 2.0.0 : Sun Mar 07 2010 - 20:32:11 EST