Re: [gwt-contrib] Re: GWT Incubator Status Update and Schedule
Hi, It would be nice that the GWT team would release some development builds once in a while. That would be very usefull at the point where new things are added to the trunk. This way you can get a lot more input from the community, since it makes it much easier to use a more experimental version of GWT. Compiling from the sources means that we need direct access to the internet, but not all companies allow that. As long as we have some indication of what is mostly stable and what not, we can choose at what point we whish to start using a development build. David On Wed, Jan 20, 2010 at 6:19 PM, monkeyboy dilbert.elbo...@gmail.com wrote: Thank you John for your explanation. Now I understand the reason why you are shutting down the incubator. What I am suggesting is that developers should have a place where they can see what new features (libraries,...) are being developed and not to stumble upon this new features by chance (like I stumbled upon the doc for DataBackedWidgetsDesign for example). You mentioned that you send emails when you start a new project. What do I need to do to receive such an email? I think you guys at Google develop great libraries that are perhaps underused because they are hard to find. Let's take Gin for example (http://code.google.com/p/google-gin/). I think that more people would use it if you had a link to Gin from the GWT Tools and Libraries page. Regards. On Jan 20, 5:29 pm, John LaBanca jlaba...@google.com wrote: Libraries and widgets that we want to incubate will be moved into separate projects. Instead of downloading one incubator jar, you'll be able to (have to) download each project individually. Like Ray said, we're going to commit most new features directly to trunk, but we may still want to incubate some features if they are highly experimental. We often setup a design doc and send out an email when we start a new project, such as the data backed widgets, so the community can be involved. I'm sure we'll keep doing that. The advantage of separate projects is that each project can move along at its own pace. The incubator currently has some very stable features, some highly experimental ones, and some deprecated code, and it isn't obvious which is which (well, except the deprecated stuff). With individual projects, it should be more obvious what the state of the project is. Thanks, John LaBanca jlaba...@google.com On Wed, Jan 20, 2010 at 10:57 AM, monkeyboy dilbert.elbo...@gmail.comwrote: Then, how about a list of new features in the trunk since the last release. That way developers would know if they should become involved in the nontrivial (but not too hard) task of compiling GWT from source. I take the last comment back if such a list exists. I could not find it. Regards. On Jan 20, 4:26 pm, Ray Ryan rj...@google.com wrote: On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy dilbert.elbo...@gmail.com wrote: Hello John. I'm glad to see that PagingScrollTable will make it to the GWT trunk. Even now it is a useful widget but I can't wait to see the final version. I would like to ask a few questions. I am sorry to hear that the incubator will be shut down. I was wandering what (if anything) will replace it. With the incubator I as a developer had access to some tools and widgets that had a great chance to end up in the GWT trunk so I knew that they had a bigger chance to be supported and I dared to include them in my projects (eg. PagingScrollTable). I was burnt a few times with third party gwt libraries found on Google code for which the developer lost interest after a few months and I was left with a buggy library without support. If the incubator is shut down how will we developers be able to find the new widgets and tools that are being incubated by Google developers? It is a bit hard to find them browsing trough Google code. I suggest that You put a couple of links in the Tools and Libraries section of gwt (http://code.google.com/webtoolkit/tools.html). It would be very helpful. Our intention is to be less bashful about developing things right in the trunk. Regards. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: now.. afetr GWT 2.0?
+1 JavaFX/Code GUI Streamlining instead of UIBinder Some mechanism to allow for publishing client/js friendly variants of server side objects to clean up need for DTO's. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Custom element parsers for UiBinder
Hi George, in your solution parsing of an annotated widget will not be custom if the widget is not injected into a field, right? Here's a different idea: http://cafebab3.blogspot.com/2010/01/non-intrusive-gwt-2-mod-2nd-part.html Perhaps it is useful for you... Kind regards Daniel On 8 Jan., 17:30, ggeorg georgopoulos.georg...@gmail.com wrote: Hi Ray, Please have a look at: http://code.google.com/p/google-web-toolkit/issues/detail?id=4461 the attached patch is the simplest patch I could make. It adds support for adding custom ElementParser(s) to UiBinder by tagging each widgets that is using a custom parser with the @ElementParserToUse annotation, e.g.: for GWT Mosaic's LayoutPanel the code is: @ElementParserToUse(className = org.gwt.mosaic.ui.elementparsers.LayoutPanelParser) public class LayoutPanel extends AbsolutePanel implements HasLayoutManager, HasAnimation { ... } After applying the patch, the UiBinderWriter.registerParsers() looks like this: private void registerParsers() { // TODO(rjrjr): Allow third-party parsers to register themselves // automagically addElementParser(com.google.gwt.dom.client.Element, com.google.gwt.uibinder.elementparsers.DomElementParser); // Register widget parsers. addWidgetParser(UIObject); addWidgetParser(HasText); addWidgetParser(HasHTML); addWidgetParser(HasWidgets); addWidgetParser(HTMLPanel); addWidgetParser(DockPanel); addWidgetParser(StackPanel); addWidgetParser(DisclosurePanel); addWidgetParser(TabPanel); addWidgetParser(MenuItem); addWidgetParser(MenuBar); addWidgetParser(RadioButton); addWidgetParser(CellPanel); addWidgetParser(CustomButton); addWidgetParser(DialogBox); addWidgetParser(LayoutPanel); addWidgetParser(DockLayoutPanel); addWidgetParser(StackLayoutPanel); addWidgetParser(TabLayoutPanel); // Register custom widget parsers... (almost automagically) CollectionOwnerField uiFields = ownerClass.getUiFields(); if (uiFields == null) { return; } for (OwnerField uiField : uiFields) { JClassType fieldType = uiField.getType().getRawType().isClass(); String uiClassName = fieldType.getQualifiedSourceName(); if (elementParsers.containsKey(uiClassName)) { continue; } if (fieldType != null fieldType.isAnnotationPresent(ElementParserToUse.class)) { String parserClassName = fieldType.getAnnotation (ElementParserToUse.class).className(); if (parserClassName != null parserClassName.length() 0) { addElementParser(uiClassName, parserClassName); } } } } Kind Regards, George. On Jan 7, 12:04 am, Ray Ryan rj...@google.com wrote: How could I stop you? :-) Would you making an issue tracker entry about this and putting the patch there? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Modifying js code in CompilationResult artifacts
I'm posting to contributors because I think I'm much more likely to get an answer on compilation details here; I hope that's appropriate. If a pre-linker were to remove all CompilationResults from the artifact set, modify the contents of string literals within their js code (with valid results), create new StandardCompilationResults with the modified code and new strongNames (but the same serializedSymbolMaps, statementRanges, and permutationIds), and then add them to the outgoing artifact set, would there be any side effects? Would the rest of the build system (including soyc) be disturbed at all? More specifically, I'm generating a Java class with a placeholder string in it, then replacing that string in compilation results via a (pre) Linker. The replacement string isn't known until link time, and it's important that the resulting artifact have a strong name based in part upon the replacement. The promise of Linkers seems to imply this is fine, but I can't find any examples of a linker modifying CompilationResults and emitting them as new CompilationResults. Obviously this process would not work with or would miss CompilationResults which aren't StandardCompilationResults, but that's fine for now. Are there other assumptions/guarantees made when creating CompilationResults that wouldn't be replicated? Thanks! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: GWT Incubator Status Update and Schedule
Hmm, a nightly build sounds like a cool idea, I wouldn't mind seeing that as well. -- Arthur Kalmenson On Thu, Jan 21, 2010 at 3:28 AM, David david.no...@gmail.com wrote: Hi, It would be nice that the GWT team would release some development builds once in a while. That would be very usefull at the point where new things are added to the trunk. This way you can get a lot more input from the community, since it makes it much easier to use a more experimental version of GWT. Compiling from the sources means that we need direct access to the internet, but not all companies allow that. As long as we have some indication of what is mostly stable and what not, we can choose at what point we whish to start using a development build. David On Wed, Jan 20, 2010 at 6:19 PM, monkeyboy dilbert.elbo...@gmail.com wrote: Thank you John for your explanation. Now I understand the reason why you are shutting down the incubator. What I am suggesting is that developers should have a place where they can see what new features (libraries,...) are being developed and not to stumble upon this new features by chance (like I stumbled upon the doc for DataBackedWidgetsDesign for example). You mentioned that you send emails when you start a new project. What do I need to do to receive such an email? I think you guys at Google develop great libraries that are perhaps underused because they are hard to find. Let's take Gin for example (http://code.google.com/p/google-gin/). I think that more people would use it if you had a link to Gin from the GWT Tools and Libraries page. Regards. On Jan 20, 5:29 pm, John LaBanca jlaba...@google.com wrote: Libraries and widgets that we want to incubate will be moved into separate projects. Instead of downloading one incubator jar, you'll be able to (have to) download each project individually. Like Ray said, we're going to commit most new features directly to trunk, but we may still want to incubate some features if they are highly experimental. We often setup a design doc and send out an email when we start a new project, such as the data backed widgets, so the community can be involved. I'm sure we'll keep doing that. The advantage of separate projects is that each project can move along at its own pace. The incubator currently has some very stable features, some highly experimental ones, and some deprecated code, and it isn't obvious which is which (well, except the deprecated stuff). With individual projects, it should be more obvious what the state of the project is. Thanks, John LaBanca jlaba...@google.com On Wed, Jan 20, 2010 at 10:57 AM, monkeyboy dilbert.elbo...@gmail.com wrote: Then, how about a list of new features in the trunk since the last release. That way developers would know if they should become involved in the nontrivial (but not too hard) task of compiling GWT from source. I take the last comment back if such a list exists. I could not find it. Regards. On Jan 20, 4:26 pm, Ray Ryan rj...@google.com wrote: On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy dilbert.elbo...@gmail.com wrote: Hello John. I'm glad to see that PagingScrollTable will make it to the GWT trunk. Even now it is a useful widget but I can't wait to see the final version. I would like to ask a few questions. I am sorry to hear that the incubator will be shut down. I was wandering what (if anything) will replace it. With the incubator I as a developer had access to some tools and widgets that had a great chance to end up in the GWT trunk so I knew that they had a bigger chance to be supported and I dared to include them in my projects (eg. PagingScrollTable). I was burnt a few times with third party gwt libraries found on Google code for which the developer lost interest after a few months and I was left with a buggy library without support. If the incubator is shut down how will we developers be able to find the new widgets and tools that are being incubated by Google developers? It is a bit hard to find them browsing trough Google code. I suggest that You put a couple of links in the Tools and Libraries section of gwt (http://code.google.com/webtoolkit/tools.html). It would be very helpful. Our intention is to be less bashful about developing things right in the trunk. Regards. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Custom element parsers for UiBinder
Hi Daniel, I think if you do not inject it into a field, you don't need the custom parser to be registered at all, but I am not sure about that. I will check your code later today. Thanks, George. On 01/20/2010 02:01 AM, Daniel Dietrich wrote: Hi George, in your solution parsing of an annotated widget will not be custom if the widget is not injected into a field, right? Here's a different idea: http://cafebab3.blogspot.com/2010/01/non-intrusive-gwt-2-mod-2nd-part.html Perhaps it is useful for you... Kind regards Daniel On 8 Jan., 17:30, ggeorggeorgopoulos.georg...@gmail.com wrote: Hi Ray, Please have a look at: http://code.google.com/p/google-web-toolkit/issues/detail?id=4461 the attached patch is the simplest patch I could make. It adds support for adding custom ElementParser(s) to UiBinder by tagging each widgets that is using a custom parser with the @ElementParserToUse annotation, e.g.: for GWT Mosaic's LayoutPanel the code is: @ElementParserToUse(className = org.gwt.mosaic.ui.elementparsers.LayoutPanelParser) public class LayoutPanel extends AbsolutePanel implements HasLayoutManager, HasAnimation { ... } After applying the patch, the UiBinderWriter.registerParsers() looks like this: private void registerParsers() { // TODO(rjrjr): Allow third-party parsers to register themselves // automagically addElementParser(com.google.gwt.dom.client.Element, com.google.gwt.uibinder.elementparsers.DomElementParser); // Register widget parsers. addWidgetParser(UIObject); addWidgetParser(HasText); addWidgetParser(HasHTML); addWidgetParser(HasWidgets); addWidgetParser(HTMLPanel); addWidgetParser(DockPanel); addWidgetParser(StackPanel); addWidgetParser(DisclosurePanel); addWidgetParser(TabPanel); addWidgetParser(MenuItem); addWidgetParser(MenuBar); addWidgetParser(RadioButton); addWidgetParser(CellPanel); addWidgetParser(CustomButton); addWidgetParser(DialogBox); addWidgetParser(LayoutPanel); addWidgetParser(DockLayoutPanel); addWidgetParser(StackLayoutPanel); addWidgetParser(TabLayoutPanel); // Register custom widget parsers... (almost automagically) CollectionOwnerField uiFields = ownerClass.getUiFields(); if (uiFields == null) { return; } for (OwnerField uiField : uiFields) { JClassType fieldType = uiField.getType().getRawType().isClass(); String uiClassName = fieldType.getQualifiedSourceName(); if (elementParsers.containsKey(uiClassName)) { continue; } if (fieldType != null fieldType.isAnnotationPresent(ElementParserToUse.class)) { String parserClassName = fieldType.getAnnotation (ElementParserToUse.class).className(); if (parserClassName != null parserClassName.length() 0) { addElementParser(uiClassName, parserClassName); } } } } Kind Regards, George. On Jan 7, 12:04 am, Ray Ryanrj...@google.com wrote: How could I stop you? :-) Would you making an issue tracker entry about this and putting the patch there? -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] RR : GWT 2.0.1 : Add support to CssResource for unknown at-rules
Reviewers: Ray Ryan, Message: Review requested. Description: This is a follow-up to http://code.google.com/p/google-web-toolkit/issues/detail?id=3946#c13 Any at-rules that GenerateCssAst is unable to process will be emitted nearly-verbatim into the emitted CSS. Please review this at http://gwt-code-reviews.appspot.com/130817 Affected files: M user/src/com/google/gwt/resources/css/CssGenerationVisitor.java M user/src/com/google/gwt/resources/css/GenerateCssAst.java M user/src/com/google/gwt/resources/css/ast/CssNodeCloner.java A user/src/com/google/gwt/resources/css/ast/CssUnknownAtRule.java M user/src/com/google/gwt/resources/css/ast/CssVisitor.java M user/test/com/google/gwt/resources/ResourcesSuite.java M user/test/com/google/gwt/resources/client/test.css A user/test/com/google/gwt/resources/css/UnknownAtRuleTest.java A user/test/com/google/gwt/resources/css/unknownAtRule.css -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR : GWT 2.0.1 : Add support to CssResource for unknown at-rules
LGTM A nit and a question, but you're good to go http://gwt-code-reviews.appspot.com/130817/diff/1/3 File user/src/com/google/gwt/resources/css/GenerateCssAst.java (right): http://gwt-code-reviews.appspot.com/130817/diff/1/3#newcode239 Line 239: public void ignorableAtRule(String atRule) throws CSSException { method name seems strange. You're processing the atRule, and you might ignore it. Or did I misread? http://gwt-code-reviews.appspot.com/130817/diff/1/3#newcode248 Line 248: + ruleName.substring(1).toLowerCase(); Really? You never camel case? You sure you want to be so forgiving of case errors? http://gwt-code-reviews.appspot.com/130817/diff/1/10 File user/test/com/google/gwt/resources/css/unknownAtRule.css (right): http://gwt-code-reviews.appspot.com/130817/diff/1/10#newcode7 Line 7: /* This should be dropped */ why? http://gwt-code-reviews.appspot.com/130817 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7437 committed - Cosmetic comment change.
Revision: 7437 Author: fabb...@fabbott-svn Date: Thu Jan 21 04:26:27 2010 Log: Cosmetic comment change. http://code.google.com/p/google-web-toolkit/source/detail?r=7437 Modified: /trunk/common.ant.xml === --- /trunk/common.ant.xml Fri Jan 15 11:17:28 2010 +++ /trunk/common.ant.xml Thu Jan 21 04:26:27 2010 @@ -1,6 +1,6 @@ project name=common !-- it's okay for this not to exist, but it gives a place to store - your property settings, if any, persistently. For example, you + personal property settings, if any, persistently. For example, you might use it to set gwt.junit.testcase.includes to a narrower subset of test cases to exercise. -- property file=local.ant.properties / -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR : GWT 2.0.1 : Add support to CssResource for unknown at-rules
On 2010/01/21 16:20:28, Ray Ryan wrote: LGTM A nit and a question, but you're good to go http://gwt-code-reviews.appspot.com/130817/diff/1/3 File user/src/com/google/gwt/resources/css/GenerateCssAst.java (right): http://gwt-code-reviews.appspot.com/130817/diff/1/3#newcode239 Line 239: public void ignorableAtRule(String atRule) throws CSSException { method name seems strange. You're processing the atRule, and you might ignore it. Or did I misread? The interface that defines this method comes from the SAC API. The semantics of a random at-rule in CSS is that a conforming user agent may ignore at-rules that it is unable to process. http://gwt-code-reviews.appspot.com/130817/diff/1/3#newcode248 Line 248: + ruleName.substring(1).toLowerCase(); Really? You never camel case? You sure you want to be so forgiving of case errors? CSS is supposed to be case-insensitive, it makes sense to be lenient here. http://gwt-code-reviews.appspot.com/130817/diff/1/10 File user/test/com/google/gwt/resources/css/unknownAtRule.css (right): http://gwt-code-reviews.appspot.com/130817/diff/1/10#newcode7 Line 7: /* This should be dropped */ why? Comments are eliminated by the tokenizer and aren't a production in the grammar. http://gwt-code-reviews.appspot.com/130817 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR : GWT 2.0.1 : Add support to CssResource for unknown at-rules
LGTM -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] GWT Incubator Status Update and Schedule
Nightly or perhaps less frequent stable snapshot builds is something we'd like to do for sure. Not sure about exactly when, but it's good to know there would be an audience to justify looking into it a bit. On Thursday, January 21, 2010, Arthur Kalmenson arthur.k...@gmail.com wrote: Hmm, a nightly build sounds like a cool idea, I wouldn't mind seeing that as well. -- Arthur Kalmenson On Thu, Jan 21, 2010 at 3:28 AM, David david.no...@gmail.com wrote: Hi, It would be nice that the GWT team would release some development builds once in a while. That would be very usefull at the point where new things are added to the trunk. This way you can get a lot more input from the community, since it makes it much easier to use a more experimental version of GWT. Compiling from the sources means that we need direct access to the internet, but not all companies allow that. As long as we have some indication of what is mostly stable and what not, we can choose at what point we whish to start using a development build. David On Wed, Jan 20, 2010 at 6:19 PM, monkeyboy dilbert.elbo...@gmail.com wrote: Thank you John for your explanation. Now I understand the reason why you are shutting down the incubator. What I am suggesting is that developers should have a place where they can see what new features (libraries,...) are being developed and not to stumble upon this new features by chance (like I stumbled upon the doc for DataBackedWidgetsDesign for example). You mentioned that you send emails when you start a new project. What do I need to do to receive such an email? I think you guys at Google develop great libraries that are perhaps underused because they are hard to find. Let's take Gin for example (http://code.google.com/p/google-gin/). I think that more people would use it if you had a link to Gin from the GWT Tools and Libraries page. Regards. On Jan 20, 5:29 pm, John LaBanca jlaba...@google.com wrote: Libraries and widgets that we want to incubate will be moved into separate projects. Instead of downloading one incubator jar, you'll be able to (have to) download each project individually. Like Ray said, we're going to commit most new features directly to trunk, but we may still want to incubate some features if they are highly experimental. We often setup a design doc and send out an email when we start a new project, such as the data backed widgets, so the community can be involved. I'm sure we'll keep doing that. The advantage of separate projects is that each project can move along at its own pace. The incubator currently has some very stable features, some highly experimental ones, and some deprecated code, and it isn't obvious which is which (well, except the deprecated stuff). With individual projects, it should be more obvious what the state of the project is. Thanks, John LaBanca jlaba...@google.com On Wed, Jan 20, 2010 at 10:57 AM, monkeyboy dilbert.elbo...@gmail.comwrote: Then, how about a list of new features in the trunk since the last release. That way developers would know if they should become involved in the nontrivial (but not too hard) task of compiling GWT from source. I take the last comment back if such a list exists. I could not find it. Regards. On Jan 20, 4:26 pm, Ray Ryan rj...@google.com wrote: On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy dilbert.elbo...@gmail.com wrote: Hello John. I'm glad to see that PagingScrollTable will make it to the GWT trunk. Even now it is a useful widget but I can't wait to see the final version. I would like to ask a few questions. I am sorry to hear that the incubator will be shut down. I w -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: GWT Incubator Status Update and Schedule
developer snapshot releases would be really nice. We build infrequently from trunk and we currently guess what might be a good version to grab our internal snapshot from. Having a developer snapshot would help us when we are looking to grab the latest version for our internal use. Chris On Jan 21, 12:07 pm, Bruce Johnson br...@google.com wrote: Nightly or perhaps less frequent stable snapshot builds is something we'd like to do for sure. Not sure about exactly when, but it's good to know there would be an audience to justify looking into it a bit. On Thursday, January 21, 2010, Arthur Kalmenson arthur.k...@gmail.com wrote: Hmm, a nightly build sounds like a cool idea, I wouldn't mind seeing that as well. -- Arthur Kalmenson On Thu, Jan 21, 2010 at 3:28 AM, David david.no...@gmail.com wrote: Hi, It would be nice that the GWT team would release some development builds once in a while. That would be very usefull at the point where new things are added to the trunk. This way you can get a lot more input from the community, since it makes it much easier to use a more experimental version of GWT. Compiling from the sources means that we need direct access to the internet, but not all companies allow that. As long as we have some indication of what is mostly stable and what not, we can choose at what point we whish to start using a development build. David On Wed, Jan 20, 2010 at 6:19 PM, monkeyboy dilbert.elbo...@gmail.com wrote: Thank you John for your explanation. Now I understand the reason why you are shutting down the incubator. What I am suggesting is that developers should have a place where they can see what new features (libraries,...) are being developed and not to stumble upon this new features by chance (like I stumbled upon the doc for DataBackedWidgetsDesign for example). You mentioned that you send emails when you start a new project. What do I need to do to receive such an email? I think you guys at Google develop great libraries that are perhaps underused because they are hard to find. Let's take Gin for example (http://code.google.com/p/google-gin/). I think that more people would use it if you had a link to Gin from the GWT Tools and Libraries page. Regards. On Jan 20, 5:29 pm, John LaBanca jlaba...@google.com wrote: Libraries and widgets that we want to incubate will be moved into separate projects. Instead of downloading one incubator jar, you'll be able to (have to) download each project individually. Like Ray said, we're going to commit most new features directly to trunk, but we may still want to incubate some features if they are highly experimental. We often setup a design doc and send out an email when we start a new project, such as the data backed widgets, so the community can be involved. I'm sure we'll keep doing that. The advantage of separate projects is that each project can move along at its own pace. The incubator currently has some very stable features, some highly experimental ones, and some deprecated code, and it isn't obvious which is which (well, except the deprecated stuff). With individual projects, it should be more obvious what the state of the project is. Thanks, John LaBanca jlaba...@google.com On Wed, Jan 20, 2010 at 10:57 AM, monkeyboy dilbert.elbo...@gmail.comwrote: Then, how about a list of new features in the trunk since the last release. That way developers would know if they should become involved in the nontrivial (but not too hard) task of compiling GWT from source. I take the last comment back if such a list exists. I could not find it. Regards. On Jan 20, 4:26 pm, Ray Ryan rj...@google.com wrote: On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy dilbert.elbo...@gmail.com wrote: Hello John. I'm glad to see that PagingScrollTable will make it to the GWT trunk. Even now it is a useful widget but I can't wait to see the final version. I would like to ask a few questions. I am sorry to hear that the incubator will be shut down. I w -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Our GWT + JEE Blueprint
Posted an article on our GWT + JEE Blueprint, including what i think is a unique take on our Event Management and RPC. http://sonymathew.blogspot.com/2010/01/gwt-jee-blueprint.html Any thoughts welcome.. Thanks Sony -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Our GWT + JEE Blueprint
Posted an article on our GWT + JEE Blueprint, including what i think is a unique take on Event Management and RPC. http://sonymathew.blogspot.com/2010/01/gwt-jee-blueprint.html Any thoughts welcome.. Thanks Sony -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Modifying js code in CompilationResult artifacts
To add more information I've discovered since I wrote that post, a modified CompilationResult also needs its set of SelectionProperty values copied, its SymbolMap will be deserialized and need to be serialized again to copy it over, and the replacement string will need to be the same length as the placeholder (or statementRanges will need to be modified...) otherwise chunking will cut off outputted js mid- statement. While it's clear that right now CompilationResults are not intended to be modified once created (and there's a good argument that, with the js AST gone and the compilation stage finished, they shouldn't be), the promise of Linkers seems to be in full effect and each part of the Linker subsystem appears to only discover and read CompilationResults from the ArtifactSet pipeline. It does have the feeling of a hack at this point, mostly because of the number of hoops the code has to jump through, but it has the benefit that this Generator+Linker pair can operate and no other part of the build system need know (I think). My code seems to be working, but if anyone has any more insight, or if I'm still missing something, I would really appreciate your thoughts. Thanks. On Jan 20, 6:53 am, Brendan Kenny bcke...@gmail.com wrote: I'm posting to contributors because I think I'm much more likely to get an answer on compilation details here; I hope that's appropriate. If a pre-linker were to remove all CompilationResults from the artifact set, modify the contents of string literals within their js code (with valid results), create new StandardCompilationResults with the modified code and new strongNames (but the same serializedSymbolMaps, statementRanges, and permutationIds), and then add them to the outgoing artifact set, would there be any side effects? Would the rest of the build system (including soyc) be disturbed at all? More specifically, I'm generating a Java class with a placeholder string in it, then replacing that string in compilation results via a (pre) Linker. The replacement string isn't known until link time, and it's important that the resulting artifact have a strong name based in part upon the replacement. The promise of Linkers seems to imply this is fine, but I can't find any examples of a linker modifying CompilationResults and emitting them as new CompilationResults. Obviously this process would not work with or would miss CompilationResults which aren't StandardCompilationResults, but that's fine for now. Are there other assumptions/guarantees made when creating CompilationResults that wouldn't be replicated? Thanks! -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add -bindAddress option, clean up SCL interface
http://gwt-code-reviews.appspot.com/130806/diff/1/2 File dev/core/src/com/google/gwt/core/ext/ServletContainerLauncher.java (right): http://gwt-code-reviews.appspot.com/130806/diff/1/2#newcode70 Line 70: public boolean processArguments(TreeLogger logger, String arguments) { Another way to do this would be to introduce an additional start method that has the arguments argument. http://gwt-code-reviews.appspot.com/130806/diff/1/2#newcode97 Line 97: public void setNormalRequestLogLevel(Type logLevel) { On 2010/01/14 16:59:28, jat wrote: On 2010/01/14 16:50:28, tobyr wrote: Why is this only for non-failing web requests? In general I'm not sure how this is supposed to integrate with other logging systems that are much more sophisticated. For example, in App Engine, which uses java.util.logging configuration, you can control the logging levels of each logger individually. This is GPE request -- they don't want normal request showing up in the logs by default, so previously there was an instanceof hack to call a special method on JettyLauncher to set it. If we are changing the API, it seemed prudent to replace the hack. In particular, this refers to the log level of messages sent to the logger supplied in the start method. If you think this shouldn't be there, we can leave the hack for now. John is correct; we did request this. Toby, you're right that this solution does not integrate well with other logging solutions. However, this is a general problem with the way in which the JettyLauncher SCL was written - it re-routes Jetty's RequestLog messages to the TreeLogger, regardless of the log level that the the requestlog messages were actually logged at - it only pays attention to the response codes (500, 404, 200, etc..). If we want to fix this, we need to do some digging to see how Jetty's RequestLog ties in with other logging frameworks, and then have its messages logged to the TreeLogger based on their log level, as opposed to their response codes. While I agree that we need to figure out if there's a better way that we can handle this, I don't think it should hold up this patch. I'd leave the hack in as-is for now, and we can discuss this issue after this patch lands. http://gwt-code-reviews.appspot.com/130806/diff/1/6 File dev/core/src/com/google/gwt/dev/DevMode.java (right): http://gwt-code-reviews.appspot.com/130806/diff/1/6#newcode84 Line 84: return new String[] {servletContainerLauncher[:args]}; What if the args have spaces in them? http://gwt-code-reviews.appspot.com/130806/diff/1/6#newcode420 Line 420: ui.setCallback(RestartServerEvent.getType(), null); Why is this necessary? Won't this cause the termination of the DevMode process? http://gwt-code-reviews.appspot.com/130806/diff/1/5 File dev/core/src/com/google/gwt/dev/DevModeBase.java (right): http://gwt-code-reviews.appspot.com/130806/diff/1/5#newcode152 Line 152: // this isn't fully accurate, as their is no guarantee we will get nit: their -- there http://gwt-code-reviews.appspot.com/130806/diff/1/5#newcode566 Line 566: protected interface OptionBindAddress { You should doc the difference between the bind address and the connect address, and when each is used in the DevMode implementation. http://gwt-code-reviews.appspot.com/130806/diff/1/3 File dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java (left): http://gwt-code-reviews.appspot.com/130806/diff/1/3#oldcode498 Line 498: public void setBaseLogLevel(TreeLogger.Type baseLogLevel) { We may want to leave this hack in until we decide what to do about the logging issue. That way, we won't hold up this patch. But, now seems the right time to discuss this issue. http://gwt-code-reviews.appspot.com/130806/diff/1/3 File dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java (right): http://gwt-code-reviews.appspot.com/130806/diff/1/3#newcode517 Line 517: if (bindAddress != null) { If bindAddress is null, how do you get the server's IP back out to the dev mode query params? I guess you assume that it is 127.0.0.1? http://gwt-code-reviews.appspot.com/130806 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7441 committed - Add support to CssResource for unknown at-rules....
Revision: 7441 Author: b...@google.com Date: Thu Jan 21 09:47:21 2010 Log: Add support to CssResource for unknown at-rules. Include files missing in original commit. Patch by: bobv Review by: rjrjr http://code.google.com/p/google-web-toolkit/source/detail?r=7441 Added: /trunk/user/src/com/google/gwt/resources/css/ast/CssUnknownAtRule.java /trunk/user/test/com/google/gwt/resources/css/UnknownAtRuleTest.java /trunk/user/test/com/google/gwt/resources/css/unknownAtRule.css Modified: /trunk/user/src/com/google/gwt/resources/css/CssGenerationVisitor.java /trunk/user/src/com/google/gwt/resources/css/GenerateCssAst.java /trunk/user/src/com/google/gwt/resources/css/ast/CssNodeCloner.java /trunk/user/src/com/google/gwt/resources/css/ast/CssVisitor.java /trunk/user/test/com/google/gwt/resources/ResourcesSuite.java /trunk/user/test/com/google/gwt/resources/client/test.css === --- /dev/null +++ /trunk/user/src/com/google/gwt/resources/css/ast/CssUnknownAtRule.java Thu Jan 21 09:47:21 2010 @@ -0,0 +1,42 @@ +/* + * Copyright 2010 Google Inc. + * + * Licensed under the Apache License, Version 2.0 (the License); you may not + * use this file except in compliance with the License. You may obtain a copy of + * the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, WITHOUT + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + * License for the specific language governing permissions and limitations under + * the License. + */ +package com.google.gwt.resources.css.ast; + +/** + * Represents a CSS at-rule that CssResource is unable to process. + */ +public class CssUnknownAtRule extends CssNode { + + private final String rule; + + public CssUnknownAtRule(String rule) { +this.rule = rule; + } + + /** + * Returns the entire unprocessed at-rule declaration. + */ + public String getRule() { +return rule; + } + + public void traverse(CssVisitor visitor, Context context) { +if (visitor.visit(this, context)) { + // Do nothing +} +visitor.endVisit(this, context); + } +} === --- /dev/null +++ /trunk/user/test/com/google/gwt/resources/css/UnknownAtRuleTest.java Thu Jan 21 09:47:21 2010 @@ -0,0 +1,55 @@ +/* + * Copyright 2010 Google Inc. + * + * Licensed under the Apache License, Version 2.0 (the License); you may not + * use this file except in compliance with the License. You may obtain a copy of + * the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an AS IS BASIS, WITHOUT + * WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the + * License for the specific language governing permissions and limitations under + * the License. + */ +package com.google.gwt.resources.css; + +import com.google.gwt.core.ext.TreeLogger; +import com.google.gwt.core.ext.UnableToCompleteException; +import com.google.gwt.dev.util.DefaultTextOutput; +import com.google.gwt.dev.util.TextOutput; +import com.google.gwt.resources.css.ast.CssNode; +import com.google.gwt.resources.css.ast.CssStylesheet; +import com.google.gwt.resources.css.ast.CssUnknownAtRule; + +import junit.framework.TestCase; + +import java.util.List; + +/** + * Tests how CssResource handles stylesheets with unknown at-rules. + */ +public class UnknownAtRuleTest extends TestCase { + private static final String COMPLEX = @complex {\n with: arbitrary;\n stuff: inside;\n}; + private static final String EXTENDED = @-extended-ident {\n \n}; + private static final String SIMPLE = @simple;; + + public void test() throws UnableToCompleteException { +CssStylesheet sheet = GenerateCssAst.exec(TreeLogger.NULL, +getClass().getClassLoader().getResource( +com/google/gwt/resources/css/unknownAtRule.css)); + +ListCssNode nodes = sheet.getNodes(); +assertEquals(3, nodes.size()); +assertEquals(SIMPLE, ((CssUnknownAtRule) nodes.get(0)).getRule()); +assertEquals(COMPLEX, ((CssUnknownAtRule) nodes.get(1)).getRule()); +assertEquals(EXTENDED, ((CssUnknownAtRule) nodes.get(2)).getRule()); + +TextOutput out = new DefaultTextOutput(true); +CssGenerationVisitor v = new CssGenerationVisitor(out); +v.accept(sheet); + +assertEquals(SIMPLE + COMPLEX + EXTENDED, out.toString()); + } +} === --- /dev/null +++ /trunk/user/test/com/google/gwt/resources/css/unknownAtRule.css Thu Jan 21 09:47:21 2010 @@ -0,0 +1,8 @@ +...@simple; +...@complex { + with: arbitrary; + stuff: inside; +} +...@-extended-ident { + /* This should be dropped */ +} === ---
[gwt-contrib] Re: Add -bindAddress option, clean up SCL interface
Will update with the final patch shortly. http://gwt-code-reviews.appspot.com/130806/diff/1/2 File dev/core/src/com/google/gwt/core/ext/ServletContainerLauncher.java (right): http://gwt-code-reviews.appspot.com/130806/diff/1/2#newcode70 Line 70: public boolean processArguments(TreeLogger logger, String arguments) { On 2010/01/21 20:53:18, rdayal wrote: Another way to do this would be to introduce an additional start method that has the arguments argument. Then what about old SCL implementations? They are only going to implement the existing start method, so the best we could do would be to silently drop the arguments in that method -- seems better to have a separate method. http://gwt-code-reviews.appspot.com/130806/diff/1/6 File dev/core/src/com/google/gwt/dev/DevMode.java (right): http://gwt-code-reviews.appspot.com/130806/diff/1/6#newcode84 Line 84: return new String[] {servletContainerLauncher[:args]}; On 2010/01/21 20:53:18, rdayal wrote: What if the args have spaces in them? That's fine as far as this is concerned, obviously you would have to quote it in the shell/etc. http://gwt-code-reviews.appspot.com/130806/diff/1/6#newcode420 Line 420: ui.setCallback(RestartServerEvent.getType(), null); On 2010/01/21 20:53:18, rdayal wrote: Why is this necessary? Won't this cause the termination of the DevMode process? Why would it terminate anything? The effect of this is to tell the UI you are no longer interested in RestartServer events, so presumably the UI won't show the button. If we fail to start the servlet container, there is nothing to restart. http://gwt-code-reviews.appspot.com/130806/diff/1/5 File dev/core/src/com/google/gwt/dev/DevModeBase.java (right): http://gwt-code-reviews.appspot.com/130806/diff/1/5#newcode152 Line 152: // this isn't fully accurate, as their is no guarantee we will get On 2010/01/21 20:53:18, rdayal wrote: nit: their -- there Done. http://gwt-code-reviews.appspot.com/130806/diff/1/3 File dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java (left): http://gwt-code-reviews.appspot.com/130806/diff/1/3#oldcode498 Line 498: public void setBaseLogLevel(TreeLogger.Type baseLogLevel) { On 2010/01/21 20:53:18, rdayal wrote: We may want to leave this hack in until we decide what to do about the logging issue. That way, we won't hold up this patch. But, now seems the right time to discuss this issue. Done. http://gwt-code-reviews.appspot.com/130806/diff/1/3 File dev/core/src/com/google/gwt/dev/shell/jetty/JettyLauncher.java (right): http://gwt-code-reviews.appspot.com/130806/diff/1/3#newcode517 Line 517: if (bindAddress != null) { On 2010/01/21 20:53:18, rdayal wrote: If bindAddress is null, how do you get the server's IP back out to the dev mode query params? I guess you assume that it is 127.0.0.1? If the bind address was not set, then nothing changes here. The new code will use the supplied address and the port returned by ServletContainer.getPort() regardless (unless it is a wildcard address, in which case it uses its best guess of an external IP address for your machine). http://gwt-code-reviews.appspot.com/130806 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors