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.andre..mail.com]
Inviato: marted́ 9 marzo 2010 22.34
A: use..ayenne.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 <emanuel..engozzi.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.andre..mail.com]
> Inviato: luned́ 8 marzo 2010 9.37
> A: use..ayenne.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 <siberia..mail.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.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
> > >
> >
>
>
>
> --
> Andrey
>
>
-- Andrey
This archive was generated by hypermail 2.0.0 : Wed Mar 10 2010 - 23:09:25 EST