You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Andrey Razumovsky <ra...@gmail.com> on 2010/03/07 23:03:44 UTC
Cayenne and GWT
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 <si...@gmail.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
> <ra...@gmail.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 <si...@gmail.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
> >> <ra...@gmail.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 <si...@siberian.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
Re: Cayenne and GWT
Posted by John Armstrong <si...@gmail.com>.
Since we are discussing, I really like GXT as well, its quite powerful and
although odd in parts is probably the best going in this particular niche. I
highly recommend buying WindowBuilder Pro for GWT/GXT. It really enables a
fast pace of development.
This GWT/Cayenne integration project would be a huge win for Cayenne if
possible and gain a significant new group of users, this is why its so
exciting to me.
John-
On Tue, Mar 9, 2010 at 1:33 PM, Andrey Razumovsky <
razumovsky.andrey@gmail.com> wrote:
> Yeah, I used json serialization in the past as well. The goal of new
> project
> is to enable use plain Cayenne API on GWT client too. Direct serialization
> should also be faster than JSON serialization because you don't need extra
> conversion. Also I'm implementing Query API on client, so that you could
> construct and run queries from client.
> As frontend I used GWT-Ext, but I'm already sick of it and I'll never use
> JS
> wrapper again (not to mention it is abandoned). I find GXT much nicer, and
> CDOs are easy to be plugged in it as data models.
>
> Never worked with JavaFX, does it have nice widgets embedded? Why I like
> GWT
> is that I don't need to study yet another script language. Hope that
> appearance of fast, light, powerful and free widget library "for everyone"
> is only a matter of time..
>
> 2010/3/9 Emanuele Maiarelli <em...@mengozzi.com>
>
> > Nice work, i did something like that in the past, but i used json
> > serialization, and skipped GTW, cause GTW widgets are very poor, unless
> > you
> > plug Ext GW, but Ext libs are performace killers (I tried em on both IE
> and
> > Mozilla but they never run smooth as u expect). I'm hoping in javaFX,
> where
> > porting cayenne clients shouldn't be hard, since javaFX engine is built
> > ontop of a JVM.
> >
> >
> > -----Messaggio originale-----
> > Da: Andrey Razumovsky [mailto:razumovsky.andrey@gmail.com]
> > Inviato: lunedì 8 marzo 2010 9.37
> > A: user@cayenne.apache.org
> > Oggetto: Re: Cayenne and GWT
> >
> > John,
> >
> > I committed the prototype of the project:
> > http://svn.apache.org/repos/asf/cayenne/sandbox/cayenne-gwt/
> >
> > It is build using Cayenne 3.0RC2 and GWT 2.0.0 (haven't tried, but almost
> > sure previous versions of GWT will work too).
> > You can get some insight of how to use it looking at test project (in
> > src/test/). In fact, only two points are required to enable
> > synchronization:
> > 1. Classes are generared in client folder of your project (e.g.
> > foo.bar.client package)
> > 2. your foo.bar.FooBar.gwt.xml includes this line;
> > <inherits name="org.apache.cayenne.Cayenne"/>
> >
> > Of course this project is startup and never used in production, so
> anything
> > can not work.
> >
> > Note that faults cannot be resolved on GWT client side
> > (FaultFailureException will be thrown), so, to send linked objects to
> > client, you'll need to prefetch them.
> >
> > 2010/3/8 John Armstrong <si...@gmail.com>
> >
> > > 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.andrey@gmail.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 <si...@gmail.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
> > > > > <ra...@gmail.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 <si...@gmail.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
> > > > > >> <ra...@gmail.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 <si...@siberian.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
> > > >
> > >
> >
> >
> >
> > --
> > Andrey
> >
> >
>
>
> --
> Andrey
>
R: Cayenne and GWT
Posted by Emanuele Maiarelli <em...@mengozzi.com>.
javaFX got nice widgets, and there will be more, i hope.
Atm javaFX is mainly a simplification of swing framework (that I use a lot,
and always feel confortable on it).
More javaFX will works on lots of mobiles platforms, at least that was the
plan
of Sun before Oracle acquisition.
I used flex in the past, and javaFX should be like flex/Silverlight, a
scripting
Language widgetfull with client capabilities of local data storing, caching
and such.
Every software market player is moving towards such solutions, if they will
be the future
of RIA, or not, it's hard to tell now, but for sure they will need robust
data serialization
and persisting frameworks, most of technologies suggested for flex data
handling reminds me
oldschool applet/servlet communication tricks.
If there will be a ROP for javaFX i think it will be a great plus for both
cayenne(since
other orms got troubles having to remote their objects, and having to manage
lazy loading
in such contexts) and for javaFX itself.
-----Messaggio originale-----
Da: Andrey Razumovsky [mailto:razumovsky.andrey@gmail.com]
Inviato: martedì 9 marzo 2010 22.34
A: user@cayenne.apache.org
Oggetto: Re: Cayenne and GWT
Yeah, I used json serialization in the past as well. The goal of new project
is to enable use plain Cayenne API on GWT client too. Direct serialization
should also be faster than JSON serialization because you don't need extra
conversion. Also I'm implementing Query API on client, so that you could
construct and run queries from client.
As frontend I used GWT-Ext, but I'm already sick of it and I'll never use JS
wrapper again (not to mention it is abandoned). I find GXT much nicer, and
CDOs are easy to be plugged in it as data models.
Never worked with JavaFX, does it have nice widgets embedded? Why I like GWT
is that I don't need to study yet another script language. Hope that
appearance of fast, light, powerful and free widget library "for everyone"
is only a matter of time..
2010/3/9 Emanuele Maiarelli <em...@mengozzi.com>
> Nice work, i did something like that in the past, but i used json
> serialization, and skipped GTW, cause GTW widgets are very poor, unless
> you
> plug Ext GW, but Ext libs are performace killers (I tried em on both IE
and
> Mozilla but they never run smooth as u expect). I'm hoping in javaFX,
where
> porting cayenne clients shouldn't be hard, since javaFX engine is built
> ontop of a JVM.
>
>
> -----Messaggio originale-----
> Da: Andrey Razumovsky [mailto:razumovsky.andrey@gmail.com]
> Inviato: lunedì 8 marzo 2010 9.37
> A: user@cayenne.apache.org
> Oggetto: Re: Cayenne and GWT
>
> John,
>
> I committed the prototype of the project:
> http://svn.apache.org/repos/asf/cayenne/sandbox/cayenne-gwt/
>
> It is build using Cayenne 3.0RC2 and GWT 2.0.0 (haven't tried, but almost
> sure previous versions of GWT will work too).
> You can get some insight of how to use it looking at test project (in
> src/test/). In fact, only two points are required to enable
> synchronization:
> 1. Classes are generared in client folder of your project (e.g.
> foo.bar.client package)
> 2. your foo.bar.FooBar.gwt.xml includes this line;
> <inherits name="org.apache.cayenne.Cayenne"/>
>
> Of course this project is startup and never used in production, so
anything
> can not work.
>
> Note that faults cannot be resolved on GWT client side
> (FaultFailureException will be thrown), so, to send linked objects to
> client, you'll need to prefetch them.
>
> 2010/3/8 John Armstrong <si...@gmail.com>
>
> > 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.andrey@gmail.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 <si...@gmail.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
> > > > <ra...@gmail.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 <si...@gmail.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
> > > > >> <ra...@gmail.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 <si...@siberian.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
> > >
> >
>
>
>
> --
> Andrey
>
>
--
Andrey
Re: Cayenne and GWT
Posted by Andrey Razumovsky <ra...@gmail.com>.
Yeah, I used json serialization in the past as well. The goal of new project
is to enable use plain Cayenne API on GWT client too. Direct serialization
should also be faster than JSON serialization because you don't need extra
conversion. Also I'm implementing Query API on client, so that you could
construct and run queries from client.
As frontend I used GWT-Ext, but I'm already sick of it and I'll never use JS
wrapper again (not to mention it is abandoned). I find GXT much nicer, and
CDOs are easy to be plugged in it as data models.
Never worked with JavaFX, does it have nice widgets embedded? Why I like GWT
is that I don't need to study yet another script language. Hope that
appearance of fast, light, powerful and free widget library "for everyone"
is only a matter of time..
2010/3/9 Emanuele Maiarelli <em...@mengozzi.com>
> Nice work, i did something like that in the past, but i used json
> serialization, and skipped GTW, cause GTW widgets are very poor, unless
> you
> plug Ext GW, but Ext libs are performace killers (I tried em on both IE and
> Mozilla but they never run smooth as u expect). I'm hoping in javaFX, where
> porting cayenne clients shouldn't be hard, since javaFX engine is built
> ontop of a JVM.
>
>
> -----Messaggio originale-----
> Da: Andrey Razumovsky [mailto:razumovsky.andrey@gmail.com]
> Inviato: lunedì 8 marzo 2010 9.37
> A: user@cayenne.apache.org
> Oggetto: Re: Cayenne and GWT
>
> John,
>
> I committed the prototype of the project:
> http://svn.apache.org/repos/asf/cayenne/sandbox/cayenne-gwt/
>
> It is build using Cayenne 3.0RC2 and GWT 2.0.0 (haven't tried, but almost
> sure previous versions of GWT will work too).
> You can get some insight of how to use it looking at test project (in
> src/test/). In fact, only two points are required to enable
> synchronization:
> 1. Classes are generared in client folder of your project (e.g.
> foo.bar.client package)
> 2. your foo.bar.FooBar.gwt.xml includes this line;
> <inherits name="org.apache.cayenne.Cayenne"/>
>
> Of course this project is startup and never used in production, so anything
> can not work.
>
> Note that faults cannot be resolved on GWT client side
> (FaultFailureException will be thrown), so, to send linked objects to
> client, you'll need to prefetch them.
>
> 2010/3/8 John Armstrong <si...@gmail.com>
>
> > 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.andrey@gmail.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 <si...@gmail.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
> > > > <ra...@gmail.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 <si...@gmail.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
> > > > >> <ra...@gmail.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 <si...@siberian.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
> > >
> >
>
>
>
> --
> Andrey
>
>
--
Andrey
R: Cayenne and GWT
Posted by Emanuele Maiarelli <em...@mengozzi.com>.
Nice work, i did something like that in the past, but i used json
serialization, and skipped GTW, cause GTW widgets are very poor, unless you
plug Ext GW, but Ext libs are performace killers (I tried em on both IE and
Mozilla but they never run smooth as u expect). I'm hoping in javaFX, where
porting cayenne clients shouldn't be hard, since javaFX engine is built
ontop of a JVM.
-----Messaggio originale-----
Da: Andrey Razumovsky [mailto:razumovsky.andrey@gmail.com]
Inviato: lunedì 8 marzo 2010 9.37
A: user@cayenne.apache.org
Oggetto: Re: Cayenne and GWT
John,
I committed the prototype of the project:
http://svn.apache.org/repos/asf/cayenne/sandbox/cayenne-gwt/
It is build using Cayenne 3.0RC2 and GWT 2.0.0 (haven't tried, but almost
sure previous versions of GWT will work too).
You can get some insight of how to use it looking at test project (in
src/test/). In fact, only two points are required to enable synchronization:
1. Classes are generared in client folder of your project (e.g.
foo.bar.client package)
2. your foo.bar.FooBar.gwt.xml includes this line;
<inherits name="org.apache.cayenne.Cayenne"/>
Of course this project is startup and never used in production, so anything
can not work.
Note that faults cannot be resolved on GWT client side
(FaultFailureException will be thrown), so, to send linked objects to
client, you'll need to prefetch them.
2010/3/8 John Armstrong <si...@gmail.com>
> 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.andrey@gmail.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 <si...@gmail.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
> > > <ra...@gmail.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 <si...@gmail.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
> > > >> <ra...@gmail.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 <si...@siberian.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
> >
>
--
Andrey
Re: Cayenne and GWT
Posted by Andrey Razumovsky <ra...@gmail.com>.
John,
I committed the prototype of the project:
http://svn.apache.org/repos/asf/cayenne/sandbox/cayenne-gwt/
It is build using Cayenne 3.0RC2 and GWT 2.0.0 (haven't tried, but almost
sure previous versions of GWT will work too).
You can get some insight of how to use it looking at test project (in
src/test/). In fact, only two points are required to enable synchronization:
1. Classes are generared in client folder of your project (e.g.
foo.bar.client package)
2. your foo.bar.FooBar.gwt.xml includes this line;
<inherits name="org.apache.cayenne.Cayenne"/>
Of course this project is startup and never used in production, so anything
can not work.
Note that faults cannot be resolved on GWT client side
(FaultFailureException will be thrown), so, to send linked objects to
client, you'll need to prefetch them.
2010/3/8 John Armstrong <si...@gmail.com>
> 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.andrey@gmail.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 <si...@gmail.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
> > > <ra...@gmail.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 <si...@gmail.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
> > > >> <ra...@gmail.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 <si...@siberian.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
> >
>
--
Andrey
Re: Cayenne and GWT
Posted by John Armstrong <si...@gmail.com>.
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.andrey@gmail.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 <si...@gmail.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
> > <ra...@gmail.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 <si...@gmail.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
> > >> <ra...@gmail.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 <si...@siberian.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
>