Cool, I've filed
http://code.google.com/p/google-web-toolkit/issues/detail?id=6701.

Can I get an LGTM and submit this thing?


On Wed Aug 17 09:58:03 GMT-700 2011, Rafael Castro wrote:

> Awesome, I like #1 too. I was driving to work this morning and thinking
> about it: #2 actually encourages bad behavior, because it'll seem it's OK to
> fiddle with the elements between calling bind and attaching, and it's really
> not. We _could_ make an effort to make it work, but it's much better to make
> the flow clearer this way: if you're using lazy widgets, your elements have
> to be lazy too.
>
> On Wed, Aug 17, 2011 at 9:41 AM, Ray Ryan 
> <[email protected]<http://www.google.com/url?sa=D&q=mailto%3Arjrjr%40google.com>
> > wrote:
>
> I like #1 too. I think we should try to narrow the visibility of
> PotentialElement as much as we can.
>
> So #1 means two things , right?
>
> • Widgets are seated in their @UiFields immediately
> • In an IsRenderable owner, Element and subclasses are only available via
> LazyDomElement, and @UiField Element is a compile time error
>
> I've tweaked the test a bit (will update soon), and I'm happy to report
> that composites around non-IsRenderables work as expected, with element
> fields filled immediately. Given that I don't think we need to delay the
> switch to using lazy widget builder by default.
>
>
> On Wed Aug 17 06:14:52 GMT-700 2011, Hermes Freitas wrote:
>
> WidgetInterpreter and WidgetPlaceholderInterpreter shouldn't output
> LazyDomElement. Rafa, do you remember why? I don't think this aggregates any
> performance gain for us,  am I missing something?
>
> And I vote for #1
>
> On Tue, Aug 16, 2011 at 10:10 PM, Rafael Castro 
> <[email protected]<http://www.google.com/url?sa=D&q=mailto%3Ardcastro%40google.com>
> > wrote:
>
> +hermes
>
> Good point, this is really tricky. The problem here is that we don't
> actually have the DOM element until the widget is attached. I see 2 options:
> 1-) We force the UiField to be a LazyDomElement, so this is explicit.
> 2-) We use PotentialElement with a resolver that throws an Exception (i.e.,
> it's only really resolved when it's attached).
>
> what do you think?
>
> ps.: really nice tests, thanks for putting them together!
>
> On Tue, Aug 16, 2011 at 5:13 PM, 
> <[email protected]<http://www.google.com/url?sa=D&q=mailto%3Arjrjr%40google.com>
> > wrote:
>
> On 2011/08/17 00:12:24, rjrjr wrote:
>
> Ready for review.
>
> Rafa, this turned up one issue that concerns me: most @UiField fields
> are not filled in until the widget is attached to the dom, but we're not
> consistent about it. See the big comment in testDeep.
>
>
> http://gwt-code-reviews.**appspot.com/1527804/<http://www.google.com/url?sa=D&q=http%3A%2F%2Fgwt-code-reviews.appspot.com%2F1527804%2F>
>
>
>
>
>
> --
> --Hermes Freitas
>
>
>

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

Reply via email to