Thanks, Isaac. If only it allowed us to have separate newline rules for
annotations on fields vs. methods. Unfortunately, turning off newlines for
annotations on "members" would have this unfortunate side-effect:
@Whatever @SomethingBig("blah") void foo() {
}I'm not sure, but I think the cure might be worse than the disease... On Tue, Sep 22, 2009 at 6:42 PM, Isaac Truett <[email protected]> wrote: > Hey guys, > > >> The autoformater will change this to > > > >> @UiField > >> Button closeButton; > > > >> which sucks. I want to fix that for annoations with no arguments, but > > have no > >> idea how to. You have any clue to share? > > > > Bugs the crap out of me too. I can't find any annotation-related > > settings in the code formatter, unfortunately. > > > > Just in case you didn't see this: in Eclipse 3.5 (I haven't looked at > earlier versions) there's an Annotations section on the New Lines tab. > That will let you remove the new lines after annotations, but it > doesn't let you decide based on whether or not the annotation has > arguments. > > > - Isaac > > On Tue, Sep 22, 2009 at 4:50 PM, <[email protected]> wrote: > > > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/3 > > File samples/mail/src/com/google/gwt/sample/mail/client/AboutDialog.java > > (right): > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/3#newcode38 > > Line 38: @UiField Button closeButton; > > On 2009/09/22 20:12:42, Ray Ryan wrote: > >> The autoformater will change this to > > > >> @UiField > >> Button closeButton; > > > >> which sucks. I want to fix that for annoations with no arguments, but > > have no > >> idea how to. You have any clue to share? > > > > Bugs the crap out of me too. I can't find any annotation-related > > settings in the code formatter, unfortunately. > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/8 > > File samples/mail/src/com/google/gwt/sample/mail/client/Mail.java > > (right): > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/8#newcode68 > > Line 68: // Add the outer panel to the RootPanel, so that it will be > > On 2009/09/22 20:12:42, Ray Ryan wrote: > >> RootLayoutPanel > > > > Done. > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/10 > > File samples/mail/src/com/google/gwt/sample/mail/client/MailDetail.java > > (right): > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/10#newcode44 > > Line 44: subject.setInnerHTML(item.subject); > > On 2009/09/22 20:12:42, Ray Ryan wrote: > >> Should put a comment here explaining how shockingly dangerous it would > > be to > >> take user provided text as innerHTML in a production app for XSS > > reasons, and > >> that we're assuming that our server has done the appropriate escaping. > > > > Done. > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/13 > > File samples/mail/src/com/google/gwt/sample/mail/client/MailList.java > > (right): > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/13#newcode236 > > Line 236: table.setHTML(i, 0, " "); > > On 2009/09/22 20:12:42, Ray Ryan wrote: > >> ditto > > > > These are static strings, which are always safe. > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/16 > > File samples/mail/src/com/google/gwt/sample/mail/client/Shortcuts.ui.xml > > (right): > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/16#newcode24 > > Line 24: <g:header size='4'><g:Label styleName='{style.stackHeader}' > > text='Mailboxes'/></g:header> > > On 2009/09/22 20:12:42, Ray Ryan wrote: > >> <g:header size='4'><g:Label styleName='{style.stackHeader}'> > >> Mailboxes > >> </g:Label/></g:header> > > > >> and likewise below > > > > Done. > > > > 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#newcode82 > > Line 82: writer.die("Child must be one of {north, south, east, west, > > center}"); > > On 2009/09/22 20:12:42, Ray Ryan wrote: > >> writer.die("In %s, child must be one of {north, south, east, west, > > center}", > >> elem); > > > >> here and below and throughout the parsers > > > >> Also, is it legal to have more than one child of a particular > > direction? > > > > die(): done. > > > > It is indeed legal to have more than one widget in a direction, in any > > order. > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/24#newcode88 > > Line 88: writer.die("Dock must contain a single child widget."); > > On 2009/09/22 20:12:42, Ray Ryan wrote: > >> redundant, this check is performed by consumeSingleChildElement > > > > Done. > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/25 > > File > > user/src/com/google/gwt/uibinder/parsers/StackLayoutPanelParser.java > > (right): > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/25#newcode80 > > Line 80: return child.getNamespaceUri().equals(parent.getNamespaceUri()) > > On 2009/09/22 20:12:42, Ray Ryan wrote: > >> We need to bake this into an AbstractElementParser, don't we? > > > > Probably so. Would have been useful. Next time around... > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/28 > > File user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java > > (right): > > > > http://gwt-code-reviews.appspot.com/68805/diff/1/28#newcode191 > > Line 191: public void insertEast(Widget widget, double size, Widget > > before) { > > On 2009/09/22 20:12:42, Ray Ryan wrote: > >> It's all of these insert methods that made me think you'd be better > > off allowing > >> only a single widget in each position. > > > > Perhaps, but it's still pretty useful to have any number of them. The > > insert() case is kind of annoying to write from my end, but it's pretty > > useful from the developer's end. > > > > http://gwt-code-reviews.appspot.com/68805 > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
