Hi all, I've been off-list for a bit. Good to see the discussion has
been continuing in my absense :)
For the record, I'm not in love with the current 'Place' manager
implementation in 'gwt-presenter'. I've gone through about 4 different
designs, and this is the one I hate the least so far. My ne
I call them BusinessException and BusinessUncheckedException
BusinessException has the message key and an array of parameters, so I
can build pretty error messages in the client side.
On Fri, Jul 24, 2009 at 11:11 AM, Eduardo Nunes wrote:
> I use exceptions in this way:
>
> - RuntimeException fo
I use exceptions in this way:
- RuntimeException for all those things that shouldn't happen in a
normal environment. For example, databases/files problems, requests of
objects using wrong ids (something like the user changed the id in the
url to a wrong one). And I just shown a default error mess
On Jul 23, 3:11 pm, Eduardo Nunes wrote:
> Shouldn't the server errors be treated as unchecked exceptions
> (extends RuntimeException)? Maybe a solution could be three
methods,
I've found my self coding RE's for just about everything now. I think
they are the most undervalued part of the Java
> 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-com
@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
Shouldn't the server errors be treated as unchecked exceptions
(extends RuntimeException)? Maybe a solution could be three methods,
one for failures (unchecked exceptions), one for errors (checked
exceptions) and another one for success.
What do you think?
Best regards,
On Thu, Jul 23, 2009 at
Small note...
> could show it next to the sign-in button for example). The generic
> AsyncCallback#onFailure processing is only used for unexpected server
> errors. On a successful login, then either the presenter or the
If you prefer to have your failed authentication throw an exception
(which
On 23 juil, 10:20, Kwhit wrote:
> I think Jason has hit the nail on the head.
>
> The reason I got uncomfortable with the HasXxx's is that they expose
> the internal workings of the Viewer (Display in RR's terms). The name
> getSelectionButton() is a clue. The presenter doesn't and shouldn't
>
See above positing
...
2/ Define Viewer interface (without thinking about how the Viewer
might be implemented)
...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, sen
I think Jason has hit the nail on the head.
The reason I got uncomfortable with the HasXxx's is that they expose
the internal workings of the Viewer (Display in RR's terms). The name
getSelectionButton() is a clue. The presenter doesn't and shouldn't
care about how the Viewer decides how to trip
On Jul 22, 6:59 am, Daniel Wellman 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 get
On Jul 22, 3:51 am, Thomas Broyer 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 th
On Jul 22, 2:46 am, Kwhit wrote:
> * 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 el
On 22 juil, 04:07, "Jason A. Beranek" wrote:
> 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 pres
A short update on the original posting.
I've now implemented the pattern I suggested in the original post in a
reference application and it's running.
My goals for doing the work were to address two issues:
1/ My GWT/GAE productivity: after a short learning curve it had sped
up but it slowed ri
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 a
On Tue, Jul 21, 2009 at 7:07 PM, Thomas Broyer wrote:
>
>
>
> On 15 juil, 21:36, David Peterson 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
On 15 juil, 21:36, David Peterson 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
About the gwt-presenter library, I found some points that I would like
talk to you:
- When I extend WidgetPresenter/BasicPresenter I have to implement
many abstract methods, is it really necessary to set those methods as
abstract? Isn't it better to provide an empty default implementation?
I know
I really think it's a purely philosophical decision - I can see how it
would work fine with EventBus, I'm just choosing not to, basically.
For me the line in the sand is that events are about information,
commands are about action. Your mileage may vary :)
David
On Jul 18, 7:22 am, Kwhit wrote:
On Jul 15, 9:36 pm, David Peterson wrote:
- Thinking further, I think it's better to separate the EventBus from
- the Command system somewhat. The reason being that generally, events
- are used to update on changes that have already happened, or are
about
- to happen. They don't trigger the actua
Fair point :)
On Jul 16, 9:32 pm, Daniel Jue wrote:
> Alejandro's source code is here:
>
> http://code.google.com/p/puntosoft/
>
> > Anyway, there are ways to do it of course. I'll be interested to see
> > your solution if you make it public :)
>
>
--~--~-~--~~~---~--
Alejandro's source code is here:
http://code.google.com/p/puntosoft/
> Anyway, there are ways to do it of course. I'll be interested to see
> your solution if you make it public :)
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
Hi Alejandro,
Firstly, you can absolutely do it using the same EventBus. I just
don't think it's that great a fit, personally. But if what you have
works, use it :)
> > Thinking further, I think it's better to separate the EventBus from
> > the Command system somewhat. The reason being that gene
Hi David,
On Wed, Jul 15, 2009 at 4:36 PM, David Peterson wrote:
>
> Thinking further, I think it's better to separate the EventBus from
> the Command system somewhat. The reason being that generally, events
> are used to update on changes that have already happened, or are about
> to happen. The
Thinking further, I think it's better to separate the EventBus from
the Command system somewhat. The reason being that generally, events
are used to update on changes that have already happened, or are about
to happen. They don't trigger the actual event itself.
For example, you have a 'CreateUse
I forget to post the link:
http://puntosoft2k.appspot.com/Showcase.html#ContactWidgetEventBus
Thanks.
On Tue, Jul 14, 2009 at 1:43 PM, Alejandro D. Garin wrote:
> Hi,
>
> I wrote an implementation (first try) based on the Command Pattern and
> EventBus described in the Ray Google IO Talk. (what
Hi,
I wrote an implementation (first try) based on the Command Pattern and
EventBus described in the Ray Google IO Talk. (what I understand from the
slides).
The working example is trivial but the code uses an event bus (using gwt
HandleManager) and the command pattern for the RPC Service.
Commen
There's certainly nothing to stop you, and you could even just add
your own RPC Event and have a listener trigger the server-side call.
In fact, in my own implementation of Ray's example (http://
code.google.com/p/gwt-dispatch), the Action and Response are both
interfaces, so you could just have t
Hi Kwhit,
I believe that this is what I have been calling the Controller
(Event Bus, passing Events (Command Objects)). Perhaps why I have
had some difficulty working with others (GWT) MVC frameworks of late.
So I have a Event Object (Command) with a Object value field
http://cvs.adligo.org
31 matches
Mail list logo
