Multiple gwt-rpc calls and UI

[Mike Dee]

What is a preferable way to do multiple gwt-rpc calls to setup a UI?
In particular, we have a view that requires several successive calls
(order is important) to the database to setup. This is necessary
because there is a stateful part to our app. For example, first we
have to load A and once we have A we can then load B and C.

What I've been doing is to start the chain of events in the view's
onLoad. I make a call to load A. The handler for it then kicks off
loading B and C, in onSuccess().

Is this a good way to go about doing this? Opinions appreciated.

[KevMo]

Have you tried making an RPC that returns A, B, & C at the same time?

[Frank]

The option to call the next RPC event in the onSuccess() of the
previous one is a good way to achieve this.
But the option KevMo gives is actually better if possible.

[-sowdri-]

Mike, this is exactly where DTO pattern has to be used. 

1. Just create a DTO which encapsulated all the objects required at startup. 
2. And expose a new service, which would do all the sequential calls on the server and construct the dto and return. 
   

Remember, a server call is the most costliest operation in terms of time for the client. Coupled that with making it sequential, (adding to the startup time) its going to take ages). 

Note: RF btw has request batching :)

Hope this helps!

[Mike Dee]

I've been looking into this for the past few days.

RequestFactory seems like it could be a solution. It would solve
other problems too, such as being able to selectively expose the
fields of entity classes. Some of our entity classes would not
translate over to GWT.

However, my initial impression of RF is that it is unappealing. It
reminds me of things like Corba and early versions of J2EE with entity
(EntityProxy) and session (ValueProxy) beans. With j2ee there was
also the notion of container managed persistence, which we see RF
moving towards. In our case, we already have a wonderful data model
in POJO. Why create all these extra layers of software just to find a
way to display some portion of the model in a browser? Seems like
overkill and over-complication. Plus our app is more than just CRUD
and I don't see RF making things easier in that case.

Another option is to simply try and move as much of our model into the
GWT client as possible. In my first attempt to port over an existing
web app, I end up having lots of RPC calls that simply operate on
objects in the session (and never hit the database). If these objects
could be made to work on the client side, then much of the work could
be moved there too while minimizing stuff sent over the wire. The
session variables would go away, along with RPC calls to access them.
In general, the client would maintain the state, which is a huge
advantage. RPC calls could then be very similar to web service calls
that actually do work.

I'm looking into this latter option. If that doesn't work out, then I
will have to consider RF. One possibility is to use RF with simply
ValueProxy's. This kind of reminds me of how early j2ee developers
largely avoided EntityBeans in favor of SessionBeans!

Mike

On Dec 14, 11:47 pm, -sowdri- <sow...@gmail.com> wrote:
> Mike, this is exactly where DTO pattern has to be used.
>

>    1. Just create a DTO which encapsulated all the objects required at
>    startup.
>    2. And expose a new service, which would do all the sequential calls on

[Thomas Broyer]

I haven't followed the discussion at all, but RF using only ValueProxy looks a lot like GWT-RPC (major difference is the need to edit() in a context). It's definitely not only about CRUD.