How to use GWTP with custom REST APIs instead of default dispatcher?

[marius andreiana]

Hi,

I'm trying to use GWTP for a client-side only project, which relies on
a non-Java backend with REST APIs. We're working with data using
RequestBuilder.

What would be the right approach to use GWTP in this case to work with
Model?

Is there anything from dispatch.* that we can use? Should this package
be ignored completely and use just custom events as described at
http://arcbees.wordpress.com/2010/08/24/gwt-platform-event-best-practice/
?

Right now I'm thinking the ResponsePresenter will issue server
requests directly using RequestBuilder, instead of
dispatcher.execute(). Then RequestBuilder's callback
onResponseReceived will fire a custom event, and the Presenter will
listen to these custom events.
I'm wondering if there's a better solution using something like
SendTextToServer() in the basicsample.

Thanks

[Christian Goudreau]

Well, dispatch module in that case won't be needed, we're thinking about doing a command pattern like help for request builder, but that become a little bit unpredictable since we don't know anything about the backend server.

Btw, RequestBuilder also let you define a callBack, you'll then have text in that callBack that you need to convert back to data readable by your app.

Anyway, that's not something I ever done, but it's something I want to look into in a near future, in the meanwhile, here's where I would start:

http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet.html

Cheers,

--
Christian Goudreau

www.arcbees.com

[marius andreiana]

Thanks Christian,

I've looked briefly on Restlet, but I find native RequestBuilder
easier to use.

According to your advice, I won't be looking into dispatch module.
From your experience, does this sound like a sane approach?

> > Right now I'm thinking the ResponsePresenter will issue server
> > requests directly using RequestBuilder, instead of
> > dispatcher.execute(). Then RequestBuilder's callback
> > onResponseReceived will fire a custom event, and the Presenter will
> > listen to these custom events.

(I'm just getting started with gwt & MVP).

Thanks


On Aug 26, 5:36 pm, Christian Goudreau <goudreau.christ...@gmail.com>
wrote:

> Well, dispatch module in that case won't be needed, we're thinking about
> doing a command pattern like help for request builder, but that become a
> little bit unpredictable since we don't know anything about the backend
> server.
>
> Btw, RequestBuilder also let you define a callBack, you'll then have text in
> that callBack that you need to convert back to data readable by your app.
>
> Anyway, that's not something I ever done, but it's something I want to look
> into in a near future, in the meanwhile, here's where I would start:http://wiki.restlet.org/docs_2.0/13-restlet/275-restlet/144-restlet.html
>
> Cheers,
>
> On Thu, Aug 26, 2010 at 10:24 AM, marius andreiana <
>
>
>
>
>
> marius.andrei...@gmail.com> wrote:
> > Hi,
>
> > I'm trying to use GWTP for a client-side only project, which relies on
> > a non-Java backend with REST APIs. We're working with data using
> > RequestBuilder.
>
> > What would be the right approach to use GWTP in this case to work with
> > Model?
>
> > Is there anything from dispatch.* that we can use? Should this package
> > be ignored completely and use just custom events as described at

> >http://arcbees.wordpress.com/2010/08/24/gwt-platform-event-best-pract...

[Christian Goudreau]

According to your advice, I won't be looking into dispatch module.

From your experience, does this sound like a sane approach?

It depends, seriously the basic example isn't a good example. If data that you retrieve has to be updated inside the place you call your custom dispatcher (I'm assuming that you'll do your own abstraction of RequestBuilder to let you do your request more easily), you won't have to fire any event, only use event when you have to update other presenter then the one that actually done the call.

Common use case is that you will do your call inside the place that need it those data.

I strongly suggest that you take a look into more advanced sample instead of the basic one.

Cheers,

--
Christian Goudreau

www.arcbees.com

[Denis Labaye]

On my two previous GWT projects I used MVP with non GWT-RPC backends,
but still, we used the command pattern for all RPC calls.

It's a bit of extra work but I recommand it:
* Responsibilities are clearer : The logic of dealing with an Action
Result is decoupled from serializing/deserializing Actions/Results
(code / unit tests are clearer)
* You have a central point where all RPC calls are made (easier to
troubleshoot, put logging, caching, ...)
* You can build an alternative 'dummy' implementation of DispatchAsync
which return test data, so you can easily have a full client-side app
working without a server running.

We used the classes from dispatch.* (it was the gwt-dispatch
framework, but this is the same in GWTP).

The nice thing is that from the point of view of the presenters
there's no difference with 'regular' dispatch :
* You inject an instance of AsyncDispatch in the presenters
* Presenters use AsyncDispatch to send Actions and get Results.

Now the extra work :
* You need a custom implementation of
com.gwtplatform.dispatch.client.AsyncDispatch (only one by backend),
and inject it in the presenters.
* Then you need a custom Handler for each Action/Result pair, this
handler will serialize/deserialize your RPC calls. Each handler must
be registred with your custom AsyncDispatch at app startup.

Cheers,

Denis

On Aug 26, 4:44 pm, marius andreiana <marius.andrei...@gmail.com>
wrote:

[Philippe Beaudoin]

Thanks for your input Denis. I actually thought of a similar pattern,
although I'm glad to see somebody tried it successfully. From the
looks of it, there could be a lot of reusable elements put straight
into GWTP. For example we could add a REST implementation of dispatch
and maybe a mechanism to customize serialization? Or json
out-of-the-box? If anybody uses such a pattern and can contribute a
bit of code, it would be an excellent addition, I believe.

What do you think?

Cheers,

Philippe

[Denis Labaye]

I think it would be great to have basic support for non GWT-RPC
backend in GWTP dispatch.

We just need a few support classes, a good example and documentation.

I'm not confortable with the fact that GWT users are forced to use a
GWT-RPC backend in order to implements best practices (MVP + command
pattern for RPC) : GWT is a great client-side UI framework, but it
shouldn't dictate how the backend is implemented :)

I could do :
1/ The few classes in GWTP to support "non GWT-RPC" GWTP dispatch.
2/ A simple working code example.
3/ And the corresponding documentation.

I would do this against GWTP trunk code.

Cheers,

Denis

PS : About "out-of-the-box JSON" I'm not sure what you mean : If we
plug a GWT UI on a existing JSON server, we'll probably use overlays,
so the user will write the implementation anyway, I'm not sure what
the framework could do about that.



On Aug 27, 4:46 pm, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:

[Philippe Beaudoin]

Thanks for proposing this Denis! I have created an issue to track
progress on that feature:
http://code.google.com/p/gwt-platform/issues/detail?id=179
I've made you a committer, so it's easy for you to update the doc in
the wiki. However, please work on this in a branch or a clone. (Don't
forget to add your name to the AUTHORS file.)

Cheers,

Philippe

P-S. Ok, forget the part about json. I don't have a clear enough view
of the final result.

[opn]

I'd love to see that feature, that would make life a lot easier!
Currently me and my mate are struggling a bit with gwtp + json via php
on the backend.

Hope to see it soon : )

[marius andreiana]

On Aug 28, 12:47 pm, opn <opn...@googlemail.com> wrote:
> I'd love to see that feature, that would make life a lot easier!

Same here!

I can help at least with docs and testing. Denis, just please let me
know when ;)

[Ivar V.]

It would be great to have this built in to GWTP !
I'm new to GWT and am looking to integrate with a REST backend in
Rails.

[marius andreiana]

On Aug 27, 11:32 pm, Denis Labaye <denis.lab...@gmail.com> wrote:
> PS : About "out-of-the-box JSON" I'm not sure what you mean : If we
> plug a GWT UI on a existing JSON server, we'll probably use overlays,
> so the user will write the implementation anyway, I'm not sure what
> the framework could do about that.

We are not using overlays, but http://code.google.com/p/piriti/
With it, we have a clear "Model" in MVP. Here's an example on how to
use with JSON
http://code.google.com/p/piriti/wiki/JSONMapping
and it also has XML support.

Piriti trunk version can also generate JSON, not only read it:
http://groups.google.com/group/piriti/browse_thread/thread/7d0c276e8cfcfcf8
so we have full REST requests support for building send/receive
bodies.

Would your implementation continue to allow us to use Piriti?
Should the gwtp REST dispatcher support also use it?

[Christian Goudreau]

I love piriti :D I will surely think about this if I'm the one to work on that Issue (When I'll get some time off)

Cheers,

--
Christian Goudreau

www.arcbees.com

[Yannis Gonianakis]

It seems I've missed this discussion..

I think I can help to the out-of-the-box JSON part.
Actually, I discovered this thread just before starting a new one for
that reason.

In the project I currently work on, we only use the gwtp mvp module
(without the dispatch module) since we have rails backend.
I have build a very simple abstraction API to the RequestBuilder so
that I can easily send requests to the backend and handle the
responses (both, from "central" places) .. The main goal was to test
our requests easily (with a mocking framework).
To give you an example:

private RequestManager requestManager;

@Inject
public MyPresenter(RequestManager requestManager) {
this.requestManager = requestManager;
}
... somewhere in the presenter ...

requestManager.doGet(url, new RequestCallback() {
@Override
public void onSuccess(Request request, Response response) {
// we use java overlays to parse the json
MyModel model = MyModel.fromJson(response.getText());
}
});
}

I think it is similar to the way DispatchAsync is used (but I never
used it, so..).

What do you think of a new gwtp module, say for example:
<inherits name="com.gwtplatform.http.HTTP" />
to be used by anyone who has a REST backend?

If you like the idea I can contribute with the code,

--
Yannis

[Philippe Beaudoin]

Hi Yannis,

Thanks a lot for this proposal. I think a lot of people would like
such a simple dispatch mechanism. I don't know if it is concurrent or
complementary to what Denis is proposing to work on. From the issue
(http://code.google.com/p/gwt-platform/issues/detail?id=179) it looks
like Denis has contributed an example already. You might want to check
it out and see if it is compatible with your proposal.

@Denis: What are your thoughts on Yannis' approach?

In all cases, I'd love to see the code you propose, Yannis. If you
have the time, you can setup a GWTP clone and push it there. What do
you think?

Cheers,

Philippe

[Yannis Gonianakis]

Hello,
I took a quick look into the example provided by Denis and as far as I
can understand it, we are trying to achieve exactly the same thing in
totally different ways. Davis is trying to encapsulate or I would say
to "hide" the usage of RequestBuilder in ActionHandlers while I am
suggesting a totally command-pattern-free separated gwtp module which
uses only the RequestBuilder and related classes.

I can't tell the advantages of Denis approach since I 've never used
dispatch module. The most obvious part to me, is that we will have a
single dispatch solution in gwtp regardless of the backend..

To indicate some key points of my proposal:
1. very simple to use and to test
2. feels more "natural" as it is free from the command pattern which I
find kind weird to use in a REST setup
3. a central place dispatching all requests
4. a central place handling all responses and applying common handling
for e.g. error cases like 500 Internal server error etc ..
5. to send a new request you don't have to write more code than the
example in my previous post

I will either setup a GWTP clone to push some code or write a simple
example to illustrate the usage of my proposal, because it will need
quite an effort to factor out the code from my current project in
order to share it.
--
Yannis


On Sep 10, 1:51 am, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:

[Denis Labaye]

Hi Yannis,

>Davis is trying to encapsulate or I would say

>to "hide" the usage of RequestBuilder in ActionHandlers

That's the whole point ...

The point is to decouple the clients (the Presenters) from the implementation (how the RPC calls are made).

This allow to change the implementation to be swapped out, without the Presenters being affected at all.

For example, imagine you start with Json, but in the course of the project you realise that you'll need to use a Servlet proxy because you need to access resources from outside your domain. So you need to swap RequestBuilder for GWT-RPC, If you have everything behind DispatchAsync it will be transparent for your Presenters.

OK maybee swapping backend is not the most common scenario, but here's another one : 

You can build an in-memory test client side implementation of DispatchAsync, all Actions will be executed on the client side. It allow to fully test your GWT app without having a server. Very useful for example to track hard-to-find bugs, deploy in a mobile phone for early testing (just copy the js files on the phone and open it there), distribute demo version of your app in a zip, ...

Maybee I didn't understood your approch, could you give an example of an RPC call on the presenter side ?

Cheers, 

Denis

[Christian Goudreau]

There's other good points for client side like being able to commonly share a cache, batch, queue system without actually having to reinventing the wheel.

Like Denis said, it will allow you to swap implementation without having to change client side code at all (presenters).

I think the overhead of the command pattern worth the effort, especially since we're making effort into giving tools that will generate your actions.

Cheers,

--
Christian Goudreau

www.arcbees.com

[Denis Labaye]

I think it's relatively easy to build a generic : RestActionHandler on top of the DispatchAsync (the DispatchAsyncRequestBuilderImpl, the one in http://code.google.com/p/gwt-platform/issues/detail?id=179)

From the client (Presenters) point of view it would look like this : 

        dispatch.execute(new RestAction("findClientsById?id=1"), new AsyncCallback<RestActionResult>() {

   @Override

            public void onSuccess(RestActionResult actionResult) {

MyModel myModel = (MyModel) actionResult.getResult();

// do something with myModel ...

            }

        });

That way you don't have to write an Action/Result/Handler trio for each RPC calls.

But there's some problems with this : The String in the RestAction is not type safe.

And If you want to perform specific actions in the dispatcher (caching, error handling, ...), depending on the action, then you'll end up parsing the strings in the RestAction to decide what to do. Also you'll be in trouble if the format of the rest interface changes.

Cheers, 

Denis

[Christian Goudreau]

I think I prefer bind them instead... like :

bind(DispatchAsync.class).annotatedWith(RestDispatch.class).to(RestDispatchAsync.class);

bind(DispatchAsync.class).annotatedWith(RPCDispatch.class).to(RPCDispatchAsync.class);

bind(DispatchAsync.class).annotatedWith(TestDispatch.class).to(TestDispatchAsync.class);

Then we could use any of them and even a combinaison in our presenters :

public myPresenter(@RestDispatch final DispatchAsync restDispatchAsync, @RPCDispatch final DispatchAsync rpcDispatchAsync)

What do you think ?

Names are only for examples :D

Cheers,

--
Christian Goudreau

www.arcbees.com

[Christian Goudreau]

Forgot to say that for the Rest implementation, I would add something to bind an action to a specific url either with Gin or with a config file.

Cheers,

--
Christian Goudreau

www.arcbees.com

[Denis Labaye]

IMHO the Presenter shouldn't have to choose a different DispatchAsync for different Actions.

It shouldn't be even aware that Action A is done by GWT-RPC and Action B by Rest. "it's just a RPC call" :)

There should be only one DispatchAsync by Presenter.

The "dispatch" of the Action (choosing which backend to call) should be done by DispatchAsync, so it would be a dispatcher of dispatcher.

Anyway mixed backends seems a rather exotic scenario.

With SOP, it would mean either : 

* The same domain served by different backend (depending on the request), I never heard of this scenario.

* Or using cross site request with JSONP, which have problematic security issues.

Cheers, 

Denis

[Christian Goudreau]

Yeah well, I agree that In a same presenter, maybe not. But in two different presenter, the use of two different methods ie : Rpc or Rest could be something useful. Think about someone that his application is on AppEngine, but that some of his data are in a more "private" server (My boss actually asked me this... even though I don't agree with them)

My proposition allow something even more flexible and only one change is needed, the annotation. If I want to bring thing back to AppEngine I can either remove the annotation (if I setted a default) or change it. 

Cheers,

--
Christian Goudreau

www.arcbees.com

[Philippe Beaudoin]

Another approach would be for the DispatchAsync to decide which
implementation to use based on the action. i.e. We could have a
DispatchAsyncComposite with a bunch of DispatchAsync and a map that
tells which action goes to which DispatchAsync.

On Fri, Sep 10, 2010 at 9:12 AM, Christian Goudreau

[Philippe Beaudoin]

A bit like action validators. ;)

[Yannis Gonianakis]

I can clearly see your point now and I have to admit that it makes
sense. I agree that flexibility is always an objective and more
importantly it makes you feel good :)
(e.g. even if you never swap your backend you feel good knowing that
you could do that if you'd like to :) )

I said before that "we are trying to achieve exactly the same thing"
but thats not true. My suggestion accommodates only for plain HTTP
requests and is not designed for RPC. I never had to combine these two
and always was thinking of them as two distinct things. I presumed
that if someone needed RPC he could use gwtp dispatch module. But the
challenge for me in gwt so far was the GWT+rails integration. I just
needed a convenient way to write and test my requests/responses to the
backend. Thus, I thought a supplementary module would become handy.

So, even though GWTP provides tools that will generate Actions/
Results, I still believe that in my case RPC+command pattern style
would be "weird" to write.

I think the question is simplicity vs flexibility and in my opinion
there is not a unique answer. You have to decide based on your
requirements.

In sum, it would be great to see Denis' approach added as a feature in
GWTP,
Keep up the good work!
--
Yannis

[Philippe Beaudoin]

I was wondering if Dennis' feature could use your implementation for
request-based rpcs? This way we could expose both features: a simple
mechanism for HTTP requests if you want low-level access, but a bit
higher level than GWT's native code. And a higher level
Dispatcher-over-HTTP-requests if you want to use a command pattern.

Just a half-baked thought...

Philippe

[Yannis Gonianakis]

This half-baked thought cross my mind too.. :)
A quick answer would be yes. After all, my implementation is nothing
more than an abstraction to the RequestBuilder and the
RequestCallback.

I think I could spent some time trying to "integrate" it with dispatch-
without-gwtrpc example and see what happens.
--
Yannis


On Sep 10, 10:28 pm, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:

[marius andreiana]

Stupid question on Denis' sample:
In the original sample/project I don't get any warnings. When trying
to port it to another project, using gwtp-0.4, in
DispatchAsyncRequestBuilderImpl, for this line (and undo)

public <A extends Action<R>, R extends Result> void execute(final A
action,
final AsyncCallback<R> callback) {
I get the error
The return type is incompatible with DispatchAsync.execute(A,
AsyncCallback<R>)

Indeed, this
http://code.google.com/p/gwt-platform/source/browse/src/com/gwtplatform/dispatch/client/DispatchAsync.java
shows it should return a DispatchRequest, and this hasn't changed
since 0.3.

What can I do to convince it to accept void as return?

[marius andreiana]

Actually it used to be void in gwtp 0.3

http://code.google.com/p/gwt-platform/source/diff?spec=svn49fe9dc3a1f2ddc6c43fbb9dcd65971b4c49f231&r=fba37887c9ba846710b86029e0ff9e32cda7f55b&format=side&path=/src/com/gwtplatform/dispatch/client/DispatchAsync.java&old_path=/src/com/gwtplatform/dispatch/client/DispatchAsync.java&old=125ac959fd3eaaaba466892f861a08615ce555c7

Could the sample be updated to gwtp 0.4?

Thanks


On Sep 12, 1:35 pm, marius andreiana <marius.andrei...@gmail.com>
wrote:

> Stupid question on Denis' sample:
> In the original sample/project I don't get any warnings. When trying
> to port it to another project, using gwtp-0.4, in
> DispatchAsyncRequestBuilderImpl, for this line (and undo)
>
>    public <A extends Action<R>, R extends Result> void execute(final A
> action,
>                         final AsyncCallback<R> callback) {
> I get the error
>    The return type is incompatible with DispatchAsync.execute(A,
> AsyncCallback<R>)
>

> Indeed, thishttp://code.google.com/p/gwt-platform/source/browse/src/com/gwtplatfo...

[Denis Labaye]

Well spotted !

I made some changes in the sample : 

* use Json with GWT Overlays, as it more relevant than manual String parsing in this kind of scenario

* updated to use gwtp-0.4.jar

See the new sample : http://code.google.com/p/gwt-platform/issues/detail?id=179

[marius andreiana]

Thanks Denis!

I've added some comments to the code review.

Before learning about gwtp's dispatch, I was also considering
implementing this like Yannis described.
Basically, a request consists of
* URL
* method (PUT, POST, ...)
* headers (we have custom headers per request, e.g. Authentication
token)
* request body (JSON for us, others have XML, we are using Piriti as
it supports both)
* request response (JSON or XML, again using Pirite to parse it)
My initial approach was like Yannis, because it's so much less code to
write.

In your sample, a REST request would look like
create item
request: POST /items
request body: {"name": "asdf"}
response body: none

list items
request: GET /items
request body: none
response body:
{
items: [
"name": "asdf"
}


I'm not sure how easy would be to modify the backend to accept these
requests. If it would be possible, I'd like to work on using Piriti
data models, e.g.
public class CreateItemActionModel {
@JsonField
public String name;
}
for Action and Response, and then see how to minimize the amount of
code one needs to write for implementing a request.

Opinions?

On Sep 12, 2:36 pm, Denis Labaye <denis.lab...@gmail.com> wrote:
> Well spotted !
>
> I made some changes in the sample :
> * use Json with GWT Overlays, as it more relevant than manual String parsing
> in this kind of scenario
> * updated to use gwtp-0.4.jar
>
> See the new sample :http://code.google.com/p/gwt-platform/issues/detail?id=179
>
> On Sun, Sep 12, 2010 at 12:43 PM, marius andreiana <
>
>
>
> marius.andrei...@gmail.com> wrote:
> > Actually it used to be void in gwtp 0.3
>

> >http://code.google.com/p/gwt-platform/source/diff?spec=svn49fe9dc3a1f...

[marius andreiana]

On Sep 13, 12:27 pm, marius andreiana <marius.andrei...@gmail.com>
wrote:

> I'm not sure how easy would be to modify the backend to accept these
> requests. If it would be possible, I'd like to work on using Piriti
> data models, e.g.

PS: it would really help if the sample would be in trunk, so I can
send changes as diffs.

[Denis Labaye]

Hi Marius, 

> I'm not sure how easy would be to modify the backend to accept these requests. 

I don't know your scenerio but ideally you wouldn't touch the backend and the frontend.

All the mapping between the text response from you backend and your domain objects used on the client side would be done in the Handlers.

In the sample I used Json with GWT Overlays because I thought it was more representative of this scenario, it could have been XML, or more exotic format.

DispatchAsync don't define a protocole between the client and server, it just abstract the RPC from the client side point of view (Presenters). 

GWT is a client side technology, IMHO you shouldn't have to change your backend at all.

Your client side app should be able to plug to it without modification. And Dispatch aims to minimise the impact of differents backend on the architecture of the the client side.

> If it would be possible, I'd like to work on using Piriti

I don't know Pirti, what it is ? 

Cheers, 

Denis

[Ümit]

On Sep 13, 2:38 pm, Denis Labaye <denis.lab...@gmail.com> wrote:
> Hi Marius,

>
>
> I don't know Pirti, what it is ?
>

Pirti is a JSON and XML mapper which allows to easily map Plain Old
Java Objects to JSON or XML and the other way around. (http://
code.google.com/p/piriti/)

I updated your sample application so that Pitri is used for the model
objects instead of manual Javascript Overaly Types. Actually you don't
have to change a lot. Here are the changes:

Item class:

Instead of deriving from Javascript Object you use following
implementation:

public class Item
{
public interface ItemReader extends JsonReader<ItemReader> {}
public static final ItemReader JSON =
GWT.create(ItemReader.class);

@JsonField Double id;

public final long getId() { return id;}

// define other fields as above
}


GetAllItemsActionHandler class:

Here you have to change the extractResult Method to use the JsonReader
to create the Item List:

public GetAllItemsActionResult extractResult(final
com.google.gwt.http.client.Response response) {

return new
GetAllItemsActionResult(Item.JSON.readList(response.getText()));
}


The good thing about Pitri is that it supports external mapping,
references and inheritance and you don't have to play around with the
native JSNI methods/overlay types.

Hope this helps.

Btw. I used your non-RPC implementation of the command pattern/
dispatch for one of my projects (I use pylons/python backend with JSON
responses) and it works great.
So thanks for your effort.

cheers

[marius andreiana]

Good to see more contributions :) This really calls for importing the
sample archive into GWTP samples repository. Denis, what do you think
about adding it there?

Denis, I was referring to change the back-end in your sample to
actually be REST, instead of RPC-like. I'm not sure hard it's to make
App Engine expose REST APIs instead of RPC. I've seen some use Restlet
framework for that.

[marius andreiana]

I've attached an updated sample using Pirite to
http://code.google.com/p/gwt-platform/issues/detail?id=179

Proposed next steps:
* Denis, would you please update app engine backend for create item,
so it is REST compliant? It should work like this

request: POST /items
request body: {"name": "asdf"}
response body: none

* After this, I would update the sample to use Piriti also to send
data to back-end using a model.

* I'll look then at possibility of getting rid of all Action, Result
and Handler classes per request, and have some generic ones for all
requests, accepting and returning Models.

What do you think?

On Sep 13, 9:56 pm, marius andreiana <marius.andrei...@gmail.com>
wrote:

[Denis Labaye]

Pirite seems very interesting, seems to ease the parsing of XML / Json, which is very intersting when using a non GWT-RPC backend.

Sure I can update the sample to have a more "rest compliant" backend.

But I am a bit concern about using attachements to update the sample, I would rather use a proper revision control system, like Mercurial :)

@philippe : Can I "update" the sample currently in code review with the latest changes ? Or is it "frozen" during the review ? 

Cheers, 

Denis

[Philippe Beaudoin]

Denis:

Feel free to upgrade it and send a new patchset. Please make sure you
add a short message to the code review to indicate which patch sets
should be reviewed.

Philippe

[marius andreiana]

On Sep 14, 9:17 am, Denis Labaye <denis.lab...@gmail.com> wrote:
>> But I am a bit concern about using attachements to update the sample, I
> would rather use a proper revision control system, like Mercurial :)

Same here :)

Would you please import the project to gwtp samples repository? If you
import your original code (with existing code review feedback
integrated), I can submit a new code review for my changes. Or feel
free to include them in your commit, but please review first (I've
also left 2 TODO's which I can address later, low priority now).

[marius andreiana]

On Sep 14, 9:17 am, Denis Labaye <denis.lab...@gmail.com> wrote:

> Pirite seems very interesting, seems to ease the parsing of XML / Json,
> which is very intersting when using a non GWT-RPC backend.

Here are the relevant Piriti docs
http://code.google.com/p/piriti/wiki/JsonReader
http://code.google.com/p/piriti/wiki/JsonWriter

(it also has XmlReader, no writer yet)

[Harald Pehl]

Hi all,

I'm the author of Piriti. Marius pointed me to this discussion. Let me
first say that I really like GWTP - great work!
I would love to see support for Piriti in GWTP. So if I can contribute
in any way or if you have questions don't hesistate to ask.

@Marius:
I looked at the dispatch-without-gwtrpc code attached to
http://code.google.com/p/gwt-platform/issues/detail?id=179. Concerning
your question about how to simplify the setup: I decided not to use a
common model-superclass like "DataModel" because I didn't want to
depend the model on Piriti. In the current version of Piriti you can
use external mappings (see http://code.google.com/p/piriti/wiki/Features#External_Mappings)
to fully remove dependencies to Piriti from the model. I'm not that
familiar with GWTP / gwt-dispatch, but I would suggest to inject an
instance of JsonReader<T> and JsonWriter<T> to some kind of generic
action handler.

- Harald


On Sep 14, 10:07 am, Philippe Beaudoin <philippe.beaud...@gmail.com>
wrote:

[marius andreiana]

Thanks Harald for jumping in and for your suggestion! I'll give it a
shot hopefully this evening.

On Sep 14, 12:58 pm, Harald Pehl <harald.p...@googlemail.com> wrote:
> Hi all,
>
> I'm the author of Piriti. Marius pointed me to this discussion. Let me
> first say that I really like GWTP - great work!
> I would love to see support for Piriti in GWTP. So if I can contribute
> in any way or if you have questions don't hesistate to ask.
>
> @Marius:

> I looked at the dispatch-without-gwtrpc code attached tohttp://code.google.com/p/gwt-platform/issues/detail?id=179. Concerning

> your question about how to simplify the setup: I decided not to use a
> common model-superclass like "DataModel" because I didn't want to
> depend the model on Piriti. In the current version of Piriti you can

> use external mappings (seehttp://code.google.com/p/piriti/wiki/Features#External_Mappings)

[Denis Labaye]

I may understood uncorrectly, but I thought it was the point of the code review http://codereview.appspot.com/2171043/, ... that you commented :)

[opn]

When i copy over some files and not even use them in my project i get:

inconvertible types
found : java.lang.Class<A>
required: java.lang.Class<com.gwtplatform.dispatch.shared.Action<?>>

it happens here:

@SuppressWarnings("unchecked")
public <A extends Action<R>, R extends Result> void addHandler(
final RequestBuilderActionHandler<A, R> handler) {
handlersMap.put((Class<Action<?>>) handler.getActionType(),
handler);
}

in DispatchAsyncRequestBuilderImpl.java

I seem to be the only one...what could it be?

nice to see something happening in this topic!

On Sep 13, 11:25 pm, marius andreiana <marius.andrei...@gmail.com>
wrote:
> I've attached an updated sample using Pirite  tohttp://code.google.com/p/gwt-platform/issues/detail?id=179

[marius andreiana]

Denis or anybody,

Any chance to get the latest sample committed in repository?
(it's in code review for >1 week, I'd like to get the latest source
and poke on it)

Thanks

[Denis Labaye]

I would like to see it committed too.

But maybee it would make more sense to modify it to use Brendan's new ClientSideActionHandler.

See my comments : http://code.google.com/p/gwt-platform/issues/detail?id=179

Cheers, 

Denis