> 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?
Yes currently all inter-component communications is via events on the
client side - the payload doesn't look like events on the server. I
did try it but dropped the idea of a server side event bus. Events are
not reused so different events come back from the server. It's
experimental - it works but I don't have enough experience yet to
claim it's a good or better idea.
I use 'modelettes' for want of a better word which are litle bits of
the core application model that travel twixt server and client. With
response time latency and keeping bandwidth at reasonable levels in
mind I want to keep what goes to the server in chunks (not like Google
Wave that can do character by character). What I think will be the
next big thing is a focus on services - encapsulation revisited but
for different reasons. This has led me to having 'service providers'
on the server as a layer above, and providing core business logic for,
the core model objects: Person, Account, ... The service providers
have a
"response = process(request)" interface. When the SPs are loaded they
announce which requests they would like to process to the server end
of the pipe which will call them when the requests come in.
> 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)}
>
> };
> }
Your're right. I'll try and think of a way of addressing this. It may
be that I have to step back and find a place for commands a bit.
> Do you have a separate, server side event bus to do things...
See above
> ...Also do you ever have one
> event that goes to the server, but two events coming back?...
Not yet. I've built in a mechanism for SPs to passively listen to
completed processing of requests which could be used to piggy back
events but I haven't used it yet (YAGNI?).
>> * I dropped the idea of using HasClickHanders, HasValues, ... in favor
> 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
I'm reviewing this at the moment in the light of Thomas B's merciless
but very correct post above.
>> I still need to figure out a position on places / history (see posts
>What pattern would you say you are using now?
I am using History and think it's great. I don't have a clear,
describable pattern yet
> Along with someone else in a previous email, I also did not understand the
> reason behind void startProcessing(); and void stopProcessing();
Not sure
---
I'm going to try and post the code to the group next week so you can
look for yourself
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
