>> I would suggest the following >> - default to not needing to specify anything on the @Bind annotation >> if there is only one @load annotation in the class. > >It's possible to bind to values that were loaded in a superclass (if >the loaded property is protected or public). So we can't infer that >the @Bind refers to the @Load that precedes it. Though we possibly >could make the "property" attribute optional and default it to the >@Load that preceded it. Greg, thoughts?
Eh...after having converted all of our tutorials and demos to use the new approach, I haven't found it all that difficult to work with. >> it's not obvious at first glance that the "property" value on @Bind >> actually refers to which @load annotation is referenced. >> >> - rename the property parameter on @Bind to something like >> "loadProperty" or "loadField" >Yeah, it used to be "resource", which was even more confusing :) I'd >be fine with "loadProperty", albeit more verbose. IMO, the "load" is implied, so this seems a bit redundant. >> Also the "name" parameter on the @Bind annotation doesn't make sense >> because it refers to the "id" in the wtkx file. Rather just call the >> field "id". > >Yeah, this was to maintain parity with WTKXSerializer.getObjectByName, >but your argument just transfers -- why is it wtkx:id but >getObjectByName()? Maybe it should be wtkx:name...? IDs are local to the WTKX file, but names can be scoped via namespace, so name is more accurate. I agree that the annotations aren't 100% intuitive, but once you understand how they work, they are very easy to work with. -G
