On Tue, Sep 22, 2009 at 12:23 PM, <j...@google.com> wrote: > 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. >
XMLElement already has it. :-) > > 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. Oh, there certainly is. > > > http://gwt-code-reviews.appspot.com/68805 > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
