On 2009/09/22 18:59:16, Ray Ryan wrote: > I'm still reviewing, but I thought I should get this AttributeParser issue in > front of you early.
> http://gwt-code-reviews.appspot.com/68805/diff/1/24 > File user/src/com/google/gwt/uibinder/parsers/DockLayoutPanelParser.java > (right): > http://gwt-code-reviews.appspot.com/68805/diff/1/24#newcode68 > Line 68: UiBinderWriter writer) throws UnableToCompleteException { > By parsing the custom attributes directly, you're breaking {field.references}. > And we don't have a great story on how to deal with it. > This is a real issue here: you can imagine someone wanting to do > size='{preferences.bannerHeight}'. > If you look in BeanParser, you'll see the general mechanism is to find the > appropriate parser via UiBinderWriter#getAttributeParser(XMLAttribute, JParam... > ) and let it do the interpretation. And that's actually a semi-deprecated > wrapper around getAttributeParser(JParam... ) > Perhaps for this CL, it's enough for your parsers to remember to call > getAttributeParser(JParam... ) to get their hands on an instance of > StringAttributeParser? Or we could add > UiBinderWrier#getAttributeParser(JClassType... ). (You could just instantiate a > StringAttributeParser yourself, but that seems like a step in the wrong > direction.) > The parser will give you a Java literal, either a "quotedValue" or "" + > field.ref() + "", so validation will be tricky. You can see why having an > EnumAttributeParser will be a godsend. > That'll be good enough for field references, but it won't bring in i18n--a sign, > maybe, that we should rethink the i18n syntax as well, not sure. Is that an > issue in any of these new parsers? Do they take any user visible text? > We need to find an approach that keeps custom parser authors out of this > business of explicitly choosing which attributes might or might not need special > treatment, but I haven't thought of one yet. One possibility is to make > XMLAttribute aware of the parsers, and replace consumeAttribute(), > consumeDoubleAttribute(), et. al. with consumeAttribute(JParam...) and > consumeAttribute(JClassType...). Is there any reason *not* to just force XMLElement to deal with it in consumeStringAttribute(), et al? I guess you'd have to pass the writer in, but that doesn't sound too bad. This also begs the question of whether there's a simpler "context" struggling to get out of the "writer" class, but that's a question for another time. http://gwt-code-reviews.appspot.com/68805 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
