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 < [email protected]> 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 <[email protected]> > > > 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:[email protected]] > > Inviato: lunedì 8 marzo 2010 9.37 > > A: [email protected] > > 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 <[email protected]> > > > > > 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 < > > > [email protected]> 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 <[email protected]> > > > > > > > > > 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 > > > > > <[email protected]> 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 <[email protected]> > > > > > > > > > > > >> 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 > > > > > >> <[email protected]> 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 <[email protected]> > > > > > >> > > > > > > >> >> 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 >
