On Tue, Aug 10, 2010 at 6:40 AM, <[email protected]> wrote:

>
> http://gwt-code-reviews.appspot.com/717801/diff/20002/33060
> File user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java
> (right):
>
> http://gwt-code-reviews.appspot.com/717801/diff/20002/33060#newcode54
> user/src/com/google/gwt/app/place/ProxyPlaceToListPlace.java:54: public
> ProxyListPlace go(Place place) {
> Whats confusing is that it saves the record returned by
> proxyPlace().getProxy(), and then I can get the record by calling
> getProxy().  Its a stateful class, but I don't understand why.  Do you
> ever call ProxyPlaceToListPlace.getProxy()?


This is an example of the over-complexity of this approach, which comes of
trying to use a mechanism for apps that do one thing at a time for an app
that is doing several at a time.

Remember that the app can only be in one place at a time. The master list at
the top of the screen needs to be shown with no selection when the app goes
to a ProxyListPlace (it's the thing that shows the list of proxies). And it
needs to stay visible and update its selection when the app moves to a
ProxyPlace (to show the details for a single record). The list on the left
side of the screen needs to maintain its selection in the same way.

A ProxyPlaceToListPlace converter is able to tell you what list a particular
proxy belongs to. An EmployeeRecord is in the EmployeeRecord.class list.
When it figures that out for you, it also holds on to the proxy it looked
at, e.g. to allow you to update your selection — getProxy(). You're right,
though, that's a just plain odd side effect. It made more sense in an
earlier, even more complicated version of this patch last week. I'll try to
drop it before submitting.



>
> http://gwt-code-reviews.appspot.com/717801/diff/20002/33062
> File user/src/com/google/gwt/event/shared/EventBus.java (right):
>
> http://gwt-code-reviews.appspot.com/717801/diff/20002/33062#newcode45
> user/src/com/google/gwt/event/shared/EventBus.java:45: void
> fireEvent(GwtEvent<?> event);
> There are probably a lot of people using it because all HasXXXHandlers
> extend it.  For example, HasClickHandlers extends it and adds
> addBlurHandler.


Oh, okay. Thanks.

>
>
> http://gwt-code-reviews.appspot.com/717801/diff/20002/33070
> File user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java
> (right):
>
> http://gwt-code-reviews.appspot.com/717801/diff/20002/33070#newcode34
> user/src/com/google/gwt/user/client/ui/HasConstrainedValue.java:34: void
> setValues(Collection<T> values, Renderer<T> render);
> Assuming you mean for ImageLoadingCell, I think the renderers had more
> to do with being able to customize loading and error messages than
> building safe HTML.  Either way, we'll need to take a look at how to
> integrate the renderers in ImageLoadingCell with SafeHtmlBuilder,
> because you can't just return an HTML string and call it unsafe.  We
> might need a SafeHtmlRenderer that takes a SafeHtmlBuilder instead of
> returning a String.


Yes. The main point is that a Renderer should strictly be used a source of
plain user readable text, not nascent dom.

>
>
> http://gwt-code-reviews.appspot.com/717801/show
>

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to