Exactly the same, only your implement your service yourself, instead
of relying on the GWTrpc.
You should end up with something similar to (assuming "traditional"
RPC, not the command patten displayed in the Google-IO video):
interface MyService {
void myMethod(..., AsyncCallback<Result>);
}
class MyServiceAsRESTThroughRequestBuilderImplWithALongName implements
MyService {
void myMethod(..., AsyncCallback<Result> cb) {
requestBuilder.sendRequest(..., new RequestCallback() {
void onError(..., Throwable t) {
cb.onError(t);
}
void onResponseReceived(...) {
ok ? cb.onSucces(parsedResult) : cb.onError(parsedError);
}
}
}
}
Pass around a MyService, or a MockMyservice for testing etc...
On Jul 10, 8:51 pm, Zheren <benzhe...@gmail.com> wrote:
> How does this architecture work if I do not have RPC calls? Instead,
> mostly I use RequestBuilder to make REST service calls and update/
> change View depends on onError or onRespondeReceived callback.
>
> Thanks,
>
> On Jul 10, 11:11 am, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > On 10 juil, 15:15, Eduardo Nunes <esnu...@gmail.com> wrote:
>
> > > On Fri, Jul 10, 2009 at 7:10 AM, Thomas Broyer<t.bro...@gmail.com> wrote:
>
> > > > I wouldn't have used an addClickHandler on the View, but rather a
> > > > "HasClickHandlers getAddIssueButton()". Also, I would have named the
> > > > EditIssuePresenter method showIssue(Issue issue) instead of go(Issue
> > > > issue).
> > [...]
> > > > I do think it's the View's responsibility to attach a "child View" at
> > > > the correct "location", maybe along with setting its size and other
> > > > "presentation" properties, but yet the parent View still have to cast
> > > > the child View into a Widget, or each View has to provide a getWidget
> > > > () method just like Eduardo did (the fact that the Presenter also has
> > > > a getWidget() is a different thing, but it would at least have to have
> > > > a getView() method so you can instantiate a "child Presenter" and pass
> > > > it's view to your view to add the view's widget into your own view's
> > > > widgets...)
>
> > > I didn't realize how to implement what you described.
>
> > Pretty easy:
> > - first, replace "Widget getWidget()" in your presenters with "View
> > getView()" and simply implement it as "return view" (instead of
> > "return view.getWidget()"); eventually introduce a generic View
> > interface with a single getWidget() method, and a generic Presenter
> > interface with a single getView() method.
> > - next, introduce a MainPresenter.View interface, and move all the
> > code in MainPresenter dealing Widgets into an implementation of
> > MainPresenter.View; the MainPresenter.View will have methods taking
> > views in argument, and the implementation of MainPresenter.View will
> > get their respective widgets using their getWidget() method.
>
> > ...and instead of your "Widget go(Issue)" method, I'd have two
> > methods: getView() as above (with the view having a getWidget()
> > method) and showIssue(issue).
> > (In Ray Ryan's I/O presentation, see slide #62 which shows an editPhone
> > (Phone) method's implementation)
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
