So, let me try to clear up what I'm afraid about in more detail. The
lazy widgets code generation splits attribute creation and access by
creating 2 methods build_XYZ(), and get_XYZ(). All setters are called
in the build_XYZ() part, so you'd have something like this:
private void build_layoutData() {
this.layoutData = GWT.create(LayoutDataType.class); // or
owner.layoutData if it's provided
this.layoutData.setLeft(15);
this.layoutData.setComplexAttribute(get_otherObject());
}
private void build_otherObject() {
this.otherObject = GWT.create(OtherObjectType.class); // or
owner.layoutData if it's provided
this.otherObject.setRight(15);
this.otherObject.setColor("#FFF");
}
private OtherObjectType get_otherObject() {
return this.otherObject;
}
private LayoutDataType get_layoutData() {
return this.layoutData;
}
The only way this can work is if build_otherObject() is called before
build_layoutData(). I don't think there's anything in the code right
now that guarantees this. There is the notion of "per-type precedence"
and we do look at direct links. That means that we always create
resources before ui:fields, and that we look at some signals to see
which ui:fields should be created before the other, but I'm pretty
sure that logic won't get this new flow.
Makes sense?
On Tue, Sep 6, 2011 at 8:52 AM, Ray Ryan <rj...@google.com> wrote:
>
>
> On Monday, September 5, 2011, wrote:
>>
>> I wouldn't see that as a problem. From my understanding, the generated
>> code always generates where all field declarations are at the top, then
>> all the setters are called and lastly all event listeners are created
>> (for UiHandler methods).
>>
>> Where I would see the problem, however, is with constructor parameters.
>> In this case, order of ui:with declarations would matter.
>>
>> You also have to watch out for cyclic dependencies, but that's the same
>> for any development.
>>
>> Fortunately, with the way this code was modified, if the nested
>> <ui:attributes> is missing, the behavior falls back to original
>> behavior. More complex object creation should be done in the owner
>> class.
>
> Could you remind us what the original behavior is? The failure mode needs to
> be better than bad code gen. Basically we need unit tests covering the cases
> you point out.
>>
>> On 2011/09/05 17:23:57, rdcastro wrote:
>>>
>>> What worried me at first was having one of the attributes being set to
>>> a value that's also defined via ui:with, because I think that then our
>>> precedence scheme may break. I'm afraid that if you have something
>>> like this:
>>
>>> <ui:with type="some.LayoutData" field="layoutData">
>>> <ui:attributes left="15" complexAttribute="{otherObject}" >
>>> </ui:with>
>>
>>> <ui:with type="some.LayoutData" field="otherObject">
>>> <ui:attributes right="15" color="#FFF" >
>>> </ui:with>
>>
>>> we are not guaranteed to build otherObject before you do
>>> layoutData.setComplexAttribute(otherObject);
>>
>>> On Fri, Sep 2, 2011 at 3:56 PM, <mailto:rj...@google.com> wrote:
>>> > Thanks for the test.
>>> >
>>> > Rafa, I've lost track of what to worry about wrt the ordering.
>>
>> Should we
>>>
>>> > be tossing a LazyPanel or something like that into his test to shake
>>> > things out?
>>> >
>>> > http://gwt-code-reviews.appspot.com/1524803/
>>> >
>>
>>
>>
>> http://gwt-code-reviews.appspot.com/1524803/
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
