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 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 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 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 wrote: >> > > On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy > > >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 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)
>
> Collection 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 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 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 > 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 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 >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 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 > > > > -- >
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, ggeorg 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)
Collection 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 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 @@ -- 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 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 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 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 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 >>> 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 wrote: >>> > > On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy >> > >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 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 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 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 > > 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 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 > >>> 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 wrote: > >>> > > On Wed, Jan 20, 2010 at 6:52 AM, monkeyboy >>> > >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 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"));
+
+List 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 */
+}
===
--- /trunk/user/src/com/google/gwt/resources/css/CssGene
[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
