[gwt-contrib] Re: Testing new GWT RPC implementation (aka deRPC)
Mark,
The SerializedObject contains a circular reference because each child
has a back reference to the parent. So, parent-childrenList-item0-
parent. The code for the new RPC classes appears to serialize
recursively without accounting for circular references (the existing
RemoteService RPC seems to handle without an error). I can't find any
documentation saying the GWT RPC should or should not explicitly
support circular references, so I don't know whether this is a feature
request or a bug.
I tested with your example, and removing the back reference from the
child element removed the InvocationTargetException. Though I didn't
extensively test to make sure no other issues crept up.
-Jason
On Oct 20, 12:47 am, Mark Goerdes mgoer...@googlemail.com wrote:
Hi Thobias,
my example:
public SerializableObject getSerializableObject() {
SerializableObject object = new SerializableObject();
object.add(new SerializableObject());
return object;
}
failed with these objects. As you can see, there is no circle, Child
and Parent are different objects.
Regards,
Mark
On 19 Okt., 23:51, Thoka thobias.karls...@gmail.com wrote:
Hi, perhaps a stupid question, have you tried putting in checks for
the parameters? Like:
public void add(SerializableObject child) {
if (child == this) {
throw new IllegalArgumentException(Cannot add self as
child!);
}
child.setParent(this);
children.add(child);
}
...and same for setParent(...), this does not sound like a GWT
issue. :)
Best regards,
Thobias
On 8 Okt, 08:52, futzi mgoer...@googlemail.com wrote:
Hi Bob,
do you have anything new concerning my problem with tree objects and
rpc?
Regards,
Mark
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Re: rpc vs RequestBuilder
As Thomas Boyer said, there is no way to answer the question of which is better performance wise. Assuming serialization technologies are equivalent for both performance and message size, all other performance costs (e.g., latency, throughput) depend on the server environment, including the hardware, software, and application code. Likewise, pure request handling performance comes from a combination of the performance costs. To me, the benefit to GWT RPC is the abstraction provided. Objects in the GWT client and server code are the same types, providing some productivity benefits when coding since data transfer objects are not required. If these productivity benefits are not important to your efforts or you have higher productivity working with RequestBuilder and Apache/PHP, then Apache/PHP is a good option. My two cents, Jason On Sep 13, 3:37 pm, ben fenster fenster@gmail.com wrote: i know that but i just wanted to know if the performence margin considering having efficient serialization algoritem could be big enough too be worth the invesment in developing such php server side request handler i also wanted to know about shear power of request handling per second ? , i belive that php combined with apache would prove too be much stronger but i would like too hear from someone that checked it out On Sep 13, 4:16 am, Thomas Broyer t.bro...@gmail.com wrote: On 13 sep, 07:50, ben fenster fenster@gmail.com wrote: have anyone checked what is the better way to comunicate with server performence wize rpc or RequestBuilder(using php) It would all depend on your serialization algorithm when not using GWT- RPC; so there's no real answer to your question. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MVP HasClickHandler
I take a little different approach, but you have most of the
fundamentals. The characteristic interface (i.e., Listener in your
example) shouldn't be defined as part of a particular instance of
MyPresenter.View, as that ties the Presenter directly to a specific
view implementation. Also, I would recommend following the Handler
pattern in GWT, as it allows you to utilize some of the Handler
management functions.
Taking your example, here's a possible approach using
SelectionHandlerString instead of MyView.Listener:
public class MyView extend Composite implements MyPresenter.View,
HasSelectionHandlersString {
HasSelectionHandlersString getSelectionSource() {
return this;
}
...
//Do something with a click event (called by the ClickHandler)
void doClick( CLickEvent event ) {
//Retrieve the selection (i.e., item to edit) by processing the
ClickEvent
String selection = getSelectionFromClickEvent( event );
SelectionEvent.fire(this, selection);
}
}
public class MyPresenter implement MyView.Listener {
public interface View {
HasSelectionHandlersString getSelectionSource();
}
...
public void bind(View display){
display.getSelectionSource().addSelectionHandler(new
SelectionHandlerString(){
public void onSelection(SelectionEventString event) {
//Do Something in response to Selection
}
});
};
}
Note that in the example, even though MyView implements the
HasSelectionHandlerString interface directly, the Presenter only
accesses an instance that HasSelectionHandlersString through
View.getSelectionSource(). This allows different View implementations
to implement different sources for the SelectionEvent, reducing
potential coupling between the view and presenter. Hope that helps.
-Jason
On Sep 10, 10:47 am, fonghuangyee fonghuang...@gmail.com wrote:
Thanks for ur advise.
How about if i define a interface ( View Listener ), then my presenter
implement the View Listener?
Example :
public class MyView extend Composite implement MyPresenter.View {
public interface Listerner {
public void onEdit(String id);
}
.
.
Listener listener;
// a List of Button here
button.addClickHandler(new ClickHandler(){
public void onClick(ClickEvent event){
listener.onEdit(id);
}
);
}
public class MyPresenter implement MyView.Listener {
public interface View {
}
public void onEdit(String id){
// Do something here.
};
}
Please correct me if i am following the wrong way.
Thanks.
On Sep 7, 8:32 am, Jason A. Beranek jason.bera...@gmail.com wrote:
One approach I've used is to put some logic in the View to forward a
different event than the purely GUI events to the Presenter. For
example, if you have a table or list of items which can be clicked,
and a click signifies selection of an item, use HasSelectionHandlers()
in the View, and translate in the View which item is selected by the
click. This seems to work for selection use cases, but it makes your
View in theMVPmore Supervising Controller (http://martinfowler.com/
eaaDev/SupervisingPresenter.html) than Passive View (http://
martinfowler.com/eaaDev/PassiveScreen.html).
If you were to need separate handling for each list item being
clicked, then you are likely looking at a Presenter per list item or
at having the View include a factory to add list items and return
handlers (i.e., HasClickHandlers addListItem() ). Any of these
approaches will work, it just depends on what you are looking to do
with each click handler.
V/r,
Jason
On Sep 6, 3:19 am, fonghuangyee fonghuang...@gmail.com wrote:
Hihi ,
After i go through so manyMVPexample, i found that we always use
presenter to get thoseHasClickHandlerfrom Display( Or View) to do
some action. This way works nice for static clickable action, but if
we have some dynamic button ( example a table listing with a list of
clickable action ), then i have to get a list ofHasClickHandler
from
display? and every time i add new row to the table listing, i have to
take care of the handler action, quite troublesome.
any advice?
Thanks.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: MVP HasClickHandler
One approach I've used is to put some logic in the View to forward a different event than the purely GUI events to the Presenter. For example, if you have a table or list of items which can be clicked, and a click signifies selection of an item, use HasSelectionHandlers() in the View, and translate in the View which item is selected by the click. This seems to work for selection use cases, but it makes your View in the MVP more Supervising Controller (http://martinfowler.com/ eaaDev/SupervisingPresenter.html) than Passive View (http:// martinfowler.com/eaaDev/PassiveScreen.html). If you were to need separate handling for each list item being clicked, then you are likely looking at a Presenter per list item or at having the View include a factory to add list items and return handlers (i.e., HasClickHandlers addListItem() ). Any of these approaches will work, it just depends on what you are looking to do with each click handler. V/r, Jason On Sep 6, 3:19 am, fonghuangyee fonghuang...@gmail.com wrote: Hihi , After i go through so many MVP example, i found that we always use presenter to get those HasClickHandler from Display( Or View) to do some action. This way works nice for static clickable action, but if we have some dynamic button ( example a table listing with a list of clickable action ), then i have to get a list of HasClickHandler from display? and every time i add new row to the table listing, i have to take care of the handler action, quite troublesome. any advice? Thanks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: GWT, MVP, and nested widgets
Ian,
Ok, I think I understand what are trying to do. Let me expand a bit on
the addMenuItem( Object i..); example in something a little less
abstract. First, I'm assuming your MenuItem is not equivalent to the
GWT MenuItem class, if it is the solution would be different. Note, I
don't have a full example so mileage may very. The approach is meant
to deal with MVP of list type interfaces, where the list items (i.e.,
MenuItem) bubble events up to a list presenter (i.e. MenuPanel).
The example assumes that instead of each MenuItem reporting
PlaceChange events, MenuItem selection events are bubbled from the UI
up to the MenuPanel presenter (through its view) and the MenuPanel
presenter fires the PlaceChange event. Effectively, a MenuItem's
display becomes a simple widget within MenuPanel's view and doesn't
require its own presenter (the presenter's work is handled by
MenuPanel's presenter).
First, some simple setup:
public class MenuPanel {
interface Display {
void addMenuItem( String label, String token );
HasSelectionHandlersString getMenuItemSelectionButton();
void clearMenuItems();
}
...
}
The above class shows a possible piece of the MenuPanel display
interface. I am assuming in the above that a MenuItem takes a label
that defines how the UI displays the object and the token as you
describe above for the associate place/location when the item is
clicked. In this example, the MenuPanel presenter determines the menu
items required for the current place and calls addMenuItem to tell the
MenuPanel view the MenuItem widgets to construct in the UI. The
clearMenuItem method can be used clear the MenuItems to rebuild the
specific items when the page changes. Notice that I included another
Display method called getMenuItemSelectionButton(), this returns an
object the MenuPanel presenter can add a handler to so it can detect a
MenuItem selection event. Here's an example of the bindDisplay method:
void bindDisplay( Display display ) {
this.display = display;
//Listen for a token selection when the user picks a MenuItem
display.getMenuItemSelectionButton().addSelectionHandler( new
SelectionHandlerString() {
public void onSelection( SelectionEventString event ) {
//Call MenuPanel private method to fire PlaceChangeEvent on
EventBus, selected item represents the Place token
doPlaceChange( new PlaceChangeEvent( event.getSelectedItem() );
});
...
}
With the above in place, the MenuPanel view becomes responsible for
translating the user input on MenuItems (such as a native Click
event) into a logical SelectionEvent
The above approach breaks down if the list items require a lot of data
to build or if the list items require additional logic beyond the
scope of the containing presenter. As I said in my previous post, this
approach also suffers from similar interface management problems as
DTOs.
-Jason
On Sep 2, 7:44 pm, Ian Bambury ianbamb...@gmail.com wrote:
Hi Jason,
Thanks for the reply and suggestions.
My idea was to have the MenuPanelView have a factory method for
MenuItemViews.
The MenuPanel presenter has to determine what menu items are required
depending on whether the user privileges.
I don't really understand how your addMenuItem( Object i ); method would
work.
I can't really have each view just create its own presenter (as a general
principle) as far as I can see. What I want to end up with is a menu item
which fires a PlaceChange event when it is clicked - for this it needs a
token, for example GWT/Panels/SimplePanel (where GWT is an item in the
top-level menu, Panels is an item in the GWT menu, and SimplePanel is a
final page of information to be displayed).
Each menu would set itself up if required by listening for a PlaceChange
event, and if a page recognised it was needed, it would display itself.
This, though, means that the MenuPanel needs to do a bit of setting up for
the menu items and associated pages.
It isn't actually quite the mess it probably sounds. All the hard work is
done in a hierarchy of a few abstract classes, so to create a new menu, all
you really need to is specify the menu text and the page it refers to, But I
do get the feeling I'm stretching the MVP pattern well out of shape in order
to get it all to work.
Ian
http://examples.roughian.com
2009/9/3 Jason A. Beranek jason.bera...@gmail.com
Ian,
When you mention your current solution fetches the MenuItem view from
the MenuPanel view, do you mean the MenuItem view(s) are already in
the MenuPanel view or do you mean the MenuPanel view acts as a factory
for MenuItem views? I have been experimenting a bit with the former,
though I imagine the latter would work. One approach I've also tried
for list based structures that might work for your list of Menu Items
is to make a function on the display interface to add the data
elements to build the MenuItem view from primitives:
interface MenuIPanelView {
void
Re: GWT, MVP, and nested widgets
Ian,
When you mention your current solution fetches the MenuItem view from
the MenuPanel view, do you mean the MenuItem view(s) are already in
the MenuPanel view or do you mean the MenuPanel view acts as a factory
for MenuItem views? I have been experimenting a bit with the former,
though I imagine the latter would work. One approach I've also tried
for list based structures that might work for your list of Menu Items
is to make a function on the display interface to add the data
elements to build the MenuItem view from primitives:
interface MenuIPanelView {
void addMenuItem( Object i );
}
This presents a similar mapping problem to managing DTOs if the data
your are representing in the view changes or the underlying model
object populating that data changes, but it is an option (especially
if the individual MenuItem's events could be bubbled up to the
MenuPanel and reduce code size).
The above are more what I've thought about or tried, and I don't claim
to be any expert. I've been trying to figure if there is some magic
approach that makes composition work, however I haven't seen a clear
winner yet. I hope we'll get from Ray Ryan's sample code when he's
able to put it together. Most non-GWT examples I've looked at seem to
imply that you don't directly instantiate the presenter, but that the
presenter is created when the view is constructed (and the view is
passed as an argument to the presenter at that time). For some reason,
this just feels wrong to me, though I can't put my finger on why this
bidirectional coupling would be an issue since the view is already
tightly coupled to the presenter. I don't know how well such an
approach would work with dependency injection or UI binder (my gut
feel is it wouldn't really).
I'll be interested to see anyone else's thoughts.
-Jason
On Sep 2, 1:22 pm, Ian Bambury ianbamb...@gmail.com wrote:
Hi all,
I have a question for the GWT-MVP experts out there. If there is a more
suitable forum, please let me know.
I have a menu panel which contains a flowpanel for menu items, and another
flowpanel where the required page will display itself when the associated
menu item is clicked.
The MenuPanel presenter is creating menu items and sending the MenuItem
views to the MenuPanel view to be added.
The problem is this: If there are a number of possible MenuPanel views, then
the MenuPanel presenter can't know which MenuItem view it should create
(blue, green, red, text-based, image-based, therefore presumably each
MenuPanel view should decide.
The MenuPanel view can't be the creator of the MenuItems because it doesn't
know which menu items should be created (for example, you might be allowed
to see admin menu items or not - this kind of logic should not be in the
view).
So my current solution is to get the MenuPanel presenter to fetch the
MenuItem view from the MenuPanel view.
Now, if you are still following me, is this what I should be doing? Or have
I completely lost the plot somewhere along the line?
Although there are endless (generally slightly contradictory) explanations
of MVP (and please note that I don't think I need another explanation of
that), there isn't anything I can find that explains how to nail together
the various self-contained MVP widgets - at least, not in a way that allows
an event bus to operate.
Ian
http://examples.roughian.com
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: mvp / gwt-presenter / uibinder
I've run some quick tests on one approach to incorporating UiBinder,
the MVP design pattern, and child view's. Most of the approaches I've
seen in the group have focused on how to add the child View to the
parent View after construction. But, another approach is to return the
child View from the parent View, and bind the View to the child
Presenter within the parent Presenter.
Here is an example. I have two presenters defined: a MainPresenter and
an AccountListViewer. First, the code for AccountListViewer:
public class AccountListViewer {
interface Display {
...
}
Display display;
public void bindDisplay( Display display ) {
this.display = display;
...
}
...
}
The MainPresenter's View/Display interface returns an object
implementing AccountListViewer.Display (similar to the HasValue type
characteristic interfaces in Ray's talk). The MainPresenter then uses
this in its constructor to bind the display to the AccountListViewer
object, as shown in the code below:
public class MainPresenter {
interface Display {
AccountListViewer.Display getAccountListView();
...
}
Display display;
public MainPresenter( AccountListViewer viewer, Display display ) {
this.display = display;
viewer.bindDisplay(display.getAccountListView());
}
...
}
Now, here is the MainView.Display implementation:
MainView.ui.xml
-
ui:UiBinder
xmlns:ui='urn:ui:com.google.gwt.uibinder'
xmlns:g='urn:import:com.google.gwt.user.client.ui'
xmlns:mr='urn:import:com.berahoff.moneyregirstry.client.accounts'
ui:defaultLocale=en_us
ui:generateKeys=com.google.gwt.i18n.rebind.keygen.MD5KeyGenerator
ui:generateFormat=com.google.gwt.i18n.rebind.format.PropertiesFormat
ui:generateFilename=myapp_translate_source
ui:generateLocales=default
g:HTMLPanel
mr:AccountListView ui:field='accountList' /
/g:HTMLPanel
/ui:UiBinder
MainView.java
--
public class MainView extends Composite implements
MainPresenter.Display {
interface Binder extends UiBinderWidget, MainView {}
private static final Binder binder = GWT.create(Binder.class);
@UiField
AccountListViewer.Display accountList;
public MainView() {
initWidget(binder.createAndBindUi(this));
}
public Display getAccountListView() {
return accountList;
}
...
}
Now we have a nice declarative layout of our Widgets according to the
parent without having to force the Display interfaces to really
understand what a Widget is. Note, you should refrain from injecting
child Presenters with a Display instance in this case to avoid
unnecessary object creation.
Some benefits to this approach is that it could allow one set of
developers/designers to work on the View/Display portion of the
application while others work on Presenter logic. Also, changing the
way the UI looks is simply a change to the associated Views and
injections. The one downside I see with this approach is the coupling
between the parent and child View's, however since there is already a
coupling of the parent and child Presenters, this doesn't seem like a
major issue.
Hope this helps some thoughts. I'm still interested to see Ray Ryan's
example once he gets some time to put it together. Hopefully it will
address some of these issues.
-Jason
On Aug 28, 7:11 am, Etienne Neveu nev...@gmail.com wrote:
(Addendum: Thomas's answer beat me to it, but since I noticed it after
writing this post, I will post my answer anyway ;) )
I did not have a dev environment setup when I posted this, so did not
test this. I obviously should have, because I did not see the
recursion in what I was trying to do.
As you guessed it, the problem is that we want to inject the same
Display interface (MyPresenter.Display) in two different places:
- in the view, where we want Gin to use the @Provides factory method
(which creates a new view, injects it into a new presenter, and
returns the view)
- in the presenter, where we do NOT want to call the @Provides method,
but instead bind MyPresenter.Display to MyPresenterView in the
standard way.
Guice's private modules would have solved this problem elegantly but
they are not yet available in
Gin:http://google-guice.googlecode.com/svn/trunk/javadoc/com/google/injec...
Here is what I did instead:
I took as a basis the example project from this good gwt-presenter
tutorial:http://blog.hivedevelopment.co.uk/2009/08/google-web-toolkit-gwt-mvp-...
I created a new Guice binding annotation:
@BindingAnnotation
@Target( { FIELD, PARAMETER, METHOD })
@Retention(RUNTIME)
public @interface ViewForPresenter {
}
I created a new presenter:
public class TestPresenter extends
WidgetPresenterTestPresenter.Display {
public interface Display extends WidgetDisplay {
HasClickHandlers getTestButton();
}
// Notice the @ViewForPresenter annotation here
@Inject
public TestPresenter(@ViewForPresenter Display
Re: Command Pattern, MVP, EventBus
On Jul 22, 3:51 am, Thomas Broyer t.bro...@gmail.com wrote: They're IMO as easy to parse as path-like tokens like Gmail uses; it's just a matter of taste (and how you'd like to model your internal API) Agree that the implementation depends on the model for an applications internal API. Part of me thinks that most of the design patterns Ray presented may not be generalizable into a Presenter, Place, EventBus, or Command Pattern API library that would work for everyone. For everyone who likes a simple key/value structure to place objects (where any large paths are aspects of parsing a value token in an application dependant way), there is someone who likes query-string like tokens. For everyone who thinks an application wide event bus is useful, there's someone that wants to partition an event bus into specific components. And for everyone that wants a series of core classes that represent all Presenter and View interfaces/objects, there are individuals that will prefer to implement M-V-P in their own classes without providing interfaces and abstractions. You bring up a good point regarding preference, and I think its relevant to this thread in considering that there isn't a clear cut approach to the design patterns presented that is right or wrong for any given application. Each developer must pick their poison, so to speak, and make trade off's based on their concerns. Respectfully, Jason --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Command Pattern, MVP, EventBus
On Jul 22, 6:59 am, Daniel Wellman etl...@gmail.com wrote:
So it seems it's a tradeoff in how much test coverage you need --
expose the low-level HasXyz interfaces in your view if you need more
automated test code coverage, or use a gateway interface to the view
which exposes higher-level methods like getPassword(). Using this
gateway means you lose test coverage of which specific widgets are
wired to a given Presenter callback, but you may be able to live with
that risk (a quick manual exploratory test might give you that
confidence).
If you think about it, there is more a spectrum than a clear
separation between HasXyz as a low-level interface and a gateway
interface to the view. Based on Ray's talk, the Display interface for
each presenter is in effect the Gateway interface for the View and the
HasClickHandler or HasValue interface components expose the expect
interaction with that object. While these appear to be low-level, it
all depends on how the View itself is implemented. For example, I
could have a display interface for a UI that displays a list of
contacts having a function like this:
interface Display {
...
HasSelectionHandlersInteger getSelectionButton(){}
..
}
The Display Gateway object specifies that the SelectionButton is
responsible for producing selection events that return the index of
the list item selected. However, from a UI perspective this could be
implemented as a selection on a ComboBox, an HTML List, response to
clicking on a FlexTable row, clicking on a Radio button, or even
clicking a CheckBox next to the list item and then clicking on a Make
Selection button object. The level of granularity depends, like you
said, on how much interaction you want testable using JUnit tests
rather than GWTTestCases, but it is not an either/or choice. I do see
value in having HasXyzHandlers interfaces returned in the View Gateway
interface as a way of testing asynchronous interaction is correct,
since asynchronous interaction cannot be statically verified at
compile time.
-Jason
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Command Pattern, MVP, EventBus
I've been looking at the place service as well, but while I don't agree with exactly the structure in David Peterson's example, I'm not sure if the place service should fire an IssueEditEvent that drives some UI change. From the Ray Ryan presentation, my impression is the Place Service functions as an abstraction between client code/widgets and the History API allowing client code to decouple from the specifics of parsing and generating history tokens. The Place Service in that model is the sole handler of History events, and possibly one of the limited set of interfaces that programmatically set History (though you could use HyperLink widgets as the only means to control the token, however this complicates the creation of tokens). As for the structure of the Place object, one approach is to use a simple key/value pair for the location, for example: #key #key/value This seems to be the same approach used in the current Gmail, and seems like a good approach for some navigation schemes. Personally, I'd avoid more complex representation of Places, as it complicates parsing and Place change processing. However, your mileage may vary. -Jason On Jul 21, 6:55 pm, Eduardo Nunes esnu...@gmail.com wrote: On Tue, Jul 21, 2009 at 7:07 PM, Thomas Broyert.bro...@gmail.com wrote: On 15 juil, 21:36, David Peterson da...@randombits.org wrote: Presenter Pattern API:http://code.google.com/p/gwt-presenter I wouldn't have made the place a part of the presenter (it isn't any different than the presenter registering itself a change handler on History). The whole point of the place service is to decouple your URL patterns from your components: the place service just: - listens to history change events, interprets them and fire appropriate events on the event bus (please display the contact with ID=12345, please display the list of contacts) - listens to events fired by other components and updates the URL (History.newItem(newToken, false)); for instance, when you click on a contact in the contact list, the list fires a picked contact (the one with ID=12345) event, some component listens to it and updates the display to show the contact info, and the place service listens to it, maps it to a history token and updates the History. Or maybe the component that displays the contact fires a contact displayed (the one with ID=12345) event, and the place service listens to this one instead. Good point Thomas. So, the place service would directly call some presenter or talk to the presenter by events. Considering my sample application and the url (http://host/bit.html#edit;issue=1): - the place service would fire an IssueEditEvent with the issue id=1 - the main presenter would take this event and call the appropriated method in the IssueEditPresenter Thanks for the feedback Mr. Broyer, I will make a mix of the gwt-presenter project and mine, implementing this place service as well. Best regards, Maybe this fits into your gwt-dispatch project instead, but that's how I would model the place service. -- Eduardo S. Nuneshttp://e-nunes.com.br --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best practice to implement Command Pattern RPC on server?
David,
The Apache Shindig project (reference implementation of OpenSocial)
provides another approach for registering ActionHandlers. The Shindig
OpenSocial API code uses a HandlerDispatcher to dispatch Action
handling (as opposed to using the Servlet to do this directly). For
application specific registration, you'd write an Application specific
HandlerDispatcher and inject that Dispatcher into your RPC Servlet.
Your RPC Servlet would then do any initial processing on RPC calls,
and then retrieve the ActionHandler from the dispatcher and handle the
request. In this case, as you build new Actions you simply add a new
Handler (or update a previous one to Handle the new action, as
desired).
I haven't tried implementing this same approach, but I don't see any
issues with it at this point. Note that Shindig goes a bit farther as
their Handlers pass of most processes to a Service Provider Interface
that can be replaced with concrete implementation.
You can find the source I referred to at the Shindig SVN repository
(http://incubator.apache.org/shindig/source-repository.html) in /trunk/
java/social-api/src/main/java/org/apache/shindig/social/.
Cheers,
Jason
On Jul 3, 8:18 pm, David Peterson da...@randombits.org wrote:
There are a couple of ways to go about it, and I'm not 100% happy with
my current solution as a 'best practice'. It's a bit convoluted,
really. Current I'm using Guice on the server-side, so I bind them to
'ActionHandler.class', and then a post-config step pulls all
ActionHandler bindings and registers them to my ActionHandlerRegistry.
Binding code:
binder.bind( ActionHandler.class ).annotatedWith( Names.named
( type.getName() ) ).to( type ).in(
Singleton.class );
Linking code:
ListBindingActionHandler bindings = injector
.findBindingsByType( TypeLiteral.get
( ActionHandler.class ) );
for ( BindingActionHandler binding : bindings ) {
actionHandlerRegistry.addHandler( binding.getProvider().get() );
}
A simpler way would be to have an eager singleton which is provided
the actionHandlerRegistry via injection and just adds whatever
handlers you want to it.
David
On Jul 4, 8:06 am, ClusterCougar nwwe...@gmail.com wrote:
Thanks David. That looks like a much better solution. The only reason
I did all those generics was because I was still trying to wrap my
head around the problem. Based on this, I've come up with some ideas
I'm going to try to implement. How do you register your
ActionHandlers?
On Jul 3, 8:55 am, David Peterson da...@randombits.org wrote:
Hey ClusterCougar,
I think your implementation is over-complicated. On the client side,
just stick to two basic interfaces (and concrete implementations there-
of) - Action and Result (I'm using 'Result' rather than 'Response'
because that is often used in HTTP-related APIs), or in your API,
IProcedure and IReturn. The IAttributes, IRemoteProcedure and other
interfaces are unnecessary.
Then, on the server side, I've got 'ActionHandler' classes, which look
something like this:
public interface ActionHandlerA extends ActionR, R extends Result
{
public ClassA getActionType();
public R execute( A action ) throws Exception;
}
You then register your various ActionHandler instances with your
'RPCService' and it just matches up the action passed in with the
appropriate action handler, calls execute and you're off to the races.
Sorry about the incomplete example - the code itself is tied up in the
app I'm using this in at the moment. I hope to make it a bit more
general down the track.
David
On Jun 30, 8:05 pm, ClusterCougar nwwe...@gmail.com wrote:
I thought I posted this last night, but I don't see it. Apologies if
this is a dupe.
I've tried to implement thecommandpatternusing generics, but have
some hangups. You can see my code at
http://code.google.com/p/gwt-command-pattern/
Hangups:
1) Too many parameters. It's just not pretty
2) I have to parameterize the RPCServiceAsync at the class level,
whereas I would like to parameterize at the method level. This is a
constraint of the compiler.
3) All my server-side code actually resides on the client side,
because of the aggressive nature of the GWT compiler. I would add my
voice again asking for a simple annotation or annotations like
on a class: @GWTIgnoreReference(ServerSideClass.class)
and/or a method: @GWTIgnoreMethod
I think there are many justifiable use cases for this type of thing,
and I can't think of any way it would decrease user experience. Does
anyone know if this is a planned feature? Any comments/suggestions on
how to remediate the problems above that I don't know of? Ray Ryan,
are you listening?
Thanks,
On Jun 25, 4:07 pm, Eric erjab...@gmail.com wrote:
On Jun 25, 5:12 pm, Herme Garcia hgar...@peoplecall.com wrote:
Hi,
Re: Best practice to implement Command Pattern RPC on server?
All,
Ok, just relooked and apparently the approach I described above was
part of the 0.8 Shindig release, not the current 0.9. The pattern is
still similar, but the implementation is a bit more confusing if you
look at the Shindig code directly. Other than the references above to
the Shindig source locations, the approach for the most part still
stands (the code is just built with more complex dependency
injection).
Respectfully,
Jason
On Jul 4, 7:42 am, Jason A. Beranek jason.bera...@gmail.com wrote:
David,
The Apache Shindig project (reference implementation of OpenSocial)
provides another approach for registering ActionHandlers. The Shindig
OpenSocial API code uses a HandlerDispatcher to dispatch Action
handling (as opposed to using the Servlet to do this directly). For
application specific registration, you'd write an Application specific
HandlerDispatcher and inject that Dispatcher into your RPC Servlet.
Your RPC Servlet would then do any initial processing on RPC calls,
and then retrieve the ActionHandler from the dispatcher and handle the
request. In this case, as you build new Actions you simply add a new
Handler (or update a previous one to Handle the new action, as
desired).
I haven't tried implementing this same approach, but I don't see any
issues with it at this point. Note that Shindig goes a bit farther as
their Handlers pass of most processes to a Service Provider Interface
that can be replaced with concrete implementation.
You can find the source I referred to at the Shindig SVN repository
(http://incubator.apache.org/shindig/source-repository.html) in /trunk/
java/social-api/src/main/java/org/apache/shindig/social/.
Cheers,
Jason
On Jul 3, 8:18 pm, David Peterson da...@randombits.org wrote:
There are a couple of ways to go about it, and I'm not 100% happy with
my current solution as a 'best practice'. It's a bit convoluted,
really. Current I'm using Guice on the server-side, so I bind them to
'ActionHandler.class', and then a post-config step pulls all
ActionHandler bindings and registers them to my ActionHandlerRegistry.
Binding code:
binder.bind( ActionHandler.class ).annotatedWith( Names.named
( type.getName() ) ).to( type ).in(
Singleton.class );
Linking code:
ListBindingActionHandler bindings = injector
.findBindingsByType( TypeLiteral.get
( ActionHandler.class ) );
for ( BindingActionHandler binding : bindings ) {
actionHandlerRegistry.addHandler( binding.getProvider().get() );
}
A simpler way would be to have an eager singleton which is provided
the actionHandlerRegistry via injection and just adds whatever
handlers you want to it.
David
On Jul 4, 8:06 am, ClusterCougar nwwe...@gmail.com wrote:
Thanks David. That looks like a much better solution. The only reason
I did all those generics was because I was still trying to wrap my
head around the problem. Based on this, I've come up with some ideas
I'm going to try to implement. How do you register your
ActionHandlers?
On Jul 3, 8:55 am, David Peterson da...@randombits.org wrote:
Hey ClusterCougar,
I think your implementation is over-complicated. On the client side,
just stick to two basic interfaces (and concrete implementations there-
of) - Action and Result (I'm using 'Result' rather than 'Response'
because that is often used in HTTP-related APIs), or in your API,
IProcedure and IReturn. The IAttributes, IRemoteProcedure and other
interfaces are unnecessary.
Then, on the server side, I've got 'ActionHandler' classes, which look
something like this:
public interface ActionHandlerA extends ActionR, R extends Result
{
public ClassA getActionType();
public R execute( A action ) throws Exception;
}
You then register your various ActionHandler instances with your
'RPCService' and it just matches up the action passed in with the
appropriate action handler, calls execute and you're off to the races.
Sorry about the incomplete example - the code itself is tied up in the
app I'm using this in at the moment. I hope to make it a bit more
general down the track.
David
On Jun 30, 8:05 pm, ClusterCougar nwwe...@gmail.com wrote:
I thought I posted this last night, but I don't see it. Apologies if
this is a dupe.
I've tried to implement thecommandpatternusing generics, but have
some hangups. You can see my code at
http://code.google.com/p/gwt-command-pattern/
Hangups:
1) Too many parameters. It's just not pretty
2) I have to parameterize the RPCServiceAsync at the class level,
whereas I would like to parameterize at the method level. This is a
constraint of the compiler.
3) All my server-side code actually resides on the client side,
because of the aggressive nature of the GWT compiler. I would add my
voice again asking for a simple
Re: GWT architecture MVP/EventBus (mentioned at Google I/O)
I've struggled with the go(RootPanel.get()) function as well, but
discounted the idea of casting my Presenter.Display interface to a
Widget as it removes an amount of type safety from the presenter and
somewhat defeats the purpose of having a nice generic Display
interface for the Presenter to interact with. One solution I've tried,
which I think is promising, is to add a method to the Display
interface that accepts the Panel object presented to the go function.
For example,
class ContactViewer{
interface Display {
...
void showDisplay( Panel panel );
}
...
public void go( Panel panel ) {
this.display.showDisplay(panel);
}
}
Using this method, a Widget based ContactViewer.Display can add itself
to the supplied Panel object and Mocks can ignore the parameter for
testing purposes. As showing the Display object would be part of UI
testing anyway, this shouldn't effect test cases for the Presenter.
Cheers,
Jason
On Jun 29, 4:19 pm, mabogie mabo...@gmail.com wrote:
check this out:
http://www.webspin.be/
I left out the model (Phone class here) and the command pattern, since
I'm not using it yet.
For your comment on the casting: I'm having trouble with that too.
When I want to attach the widgets to the root panel or whatever other
panel, I can't do anything but cast them. But nobody seems to have a
good solution...
On 29 jun, 23:13, Daniel Jue teamp...@gmail.com wrote:
Does anyone have a working MVP/Eventbus sample of something simple
like the PhoneEditor?
I don't think I'm doing it right. The code from the IO presentation
leaves out enough details so that I'm not sure what to do.
For instance, in my Presenter.class,
I have something like this:
public class Presenter {
...
private Display display;
interface Display {
HasClickHandlers getSaveButton();
HasClickHandlers getCancelButton();
HasClickHandlers getNumberField();
HasClickHandlers getLabelPicker();
}
void editPhone(Phone phone) {
this.phone = Phone.from(phone);
display.getNumberField().setValue(phone.getNumber());
display.getLabelPicker().setValue(phone.getLabel());
}
...}
Obviously, a HasClickHandlers object doesn't have a setValue method.
It doesn't feel like I should be casting to the widget here, since we
went through all the trouble of using the Display interface.
I started looking at Mvp4g, but it seems to go off on a tangent with a
code generation class to wire up presenters and views via
xml.http://code.google.com/p/mvp4g/
It's also intertwined with some mvc4g classes.
I just want something basic that works, so I can seed my project from
there. A minimalist, working command style RPC example would be nice
too.
Anyone? If you're in the DC area, I'll buy you a drink!
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: GWT architecture MVP/EventBus (mentioned at Google I/O)
Ed, I may be missing something from the original presentation, but your description of a limited number of Controllers interacting with your event bus seems identical in principle to a limited number of presenters interacting with the event bus (as in Ray Ryan's talk). Your limit on the number of controllers could be made as a similar limit on Presenters, and the concepts wouldn't really change (other than the location of where the event bus lives). My take away on the event bus is that its still up to the programmer to exercise rigor in cleaning up references. With regard to the MVP design pattern and an event bus, there would seem to be a few ways to handle cleaning up Handlers on unload or navigation: your application could put all event bus handlers in the Presenter and use a Windows.ClosingHandler to place the Windows.Closing event on the event bus for all interested Presenters to handle, or you could supply an event between your Custom Widget/View to transfer the unload/detach event to the Presenter (note, this seems to follow the practice of passing events from View to Presenter as described in the talk. I do not claim to completely understand all aspects, but I like the concept of decoupling that actually seems a bit more logical, and the separation and testing capabilities afford by the MVP design pattern and Event Bus. V/r, Jason --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
