@kwhittingham
I found your implementation interesting.
The current implementation:
>
> * Adds a generic RPC mechanism (the pipe)
>
> * Doesn't use the command pattern. Instead everything is an event.
> Selected events from the event bus are sent over the pipe and
> responses are fired back. This makes the pipe invisible - no more
> coding service interfaces
I found myself thinking about this and then landing on the philosophically
rocky shore of "cause and effect", and how to delineate an event from a
command. This was probably because I was thinking of the word "action",
which uses the same neurons as"event" in my brain.
Are your responses also in the form of events, where the traditional
response value is the "payload" of a new event object? For either server
error or validation error, are you sending back a different event, or
setting a flag inside the expected return event?
>
> * I've added a layer (Stratus) on top of Bigtable-JDO inspired by
> Grails create, find, update, delete
>
> * Added a NullPipe and mock implementation of Stratus - I can now run
> end-to-end testing: presenters to database - i.e. everything but the
> composite itself without deploying to GAE. 7 unit test files run in
> around 0.5 seconds and developing is fun again!
>
>
> Findings so far
>
> * Ray's presentation was really helpful
>
> * Commands as events (aka asychronicity on steroids!): I'm kinda OK
> with this. I'm aware of David's posting above so I'm not 100% sure
> although still positive about my implementation. You do loose the
> procedural feel of the service call and AsyncCallback return although
> it is really asynchronous. I expected it to be difficult to test but
> it's not. I need more experience with it
Unless you grew your event bus's intelligence, you would also lose
batching. Even undo could be tricky. I'm guessing inside your event bus
you have something like
if eventX.isRPCEvent() {
service.takethisEvent(eventx,new callback<Event>{...onsuccess(Event
resultEvent){ fireEvent(resultEvent)}
};
}
Do you have a separate, server side event bus to do things like batching or
compound events (Previously compound actions)? Also do you ever have one
event that goes to the server, but two events coming back? I guess your
onSuccess could expect an ArrayList<Event> and just get back a list of size
one in most cases. Then it would support multiple events back from the
server, except it would get them all at one time.
>
>
> * I moved the definition of the Viewer (RR's Display interface) to the
> Presentation interface. Sorry Ray, it was in the wrong place
>
> * I dropped the idea of using HasClickHanders, HasValues, ... in favor
> of methods like getPassword(), and addSignInClickHandler() in the
> Viewer interface. I think it's a very elegant idea but it doesn't sit
> well with EasyMock and I prefer tested code to elegant code and don't
> think I loose much
I also didn't like those two particular return types since my 3rd party
widgets (Smartgwt) don't support those interfaces. And wrapping each 3rd
party widget I want to use in an adapter class that implements those
interfaces...it seems like too much work for the benefit.
> I still need to figure out a position on places / history (see posts
> above). My real application makes heavy use of History and I like it a
> lot. But I still don't have a comfortable pattern that joins the
> viewers and history together yet.
What pattern would you say you are using now?
Along with someone else in a previous email, I also did not understand the
reason behind
void startProcessing(); and
void stopProcessing();
in the Display interface of gwt-presenter. Is that intended for making the
view/display modal or turning an animated gif on and off during an async
call?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
