[gwt-contrib] Re: Building GWT Apps
Hi Papick, There have been several discussions related to this topic in the users' forum. I posted a tutorial in my blog about exactly what you're looking for: http://blog.salvadordiaz.fr/2009/04/29/keep-your-source-tree-clean-gwt/ Hope that helps, Salvador On May 4, 1:01 pm, P.G.Taboada pgtabo...@googlemail.com wrote: Hi, thanks for the GWT 1.6 release and for reviewing how GWT apps are build. I like the new approach, but I have a problem with generating the app into my web-app folder. As far as I can tell from the command line options I can't configure output and input web-folders separately. If I am right, I will again need some sort of maven/ ant tricks to generate the app/ start the dev console. Would it be possible to add such an option, so I can change where to read the ressources from, and where to generate the into? Would make the project layout in the SCM and the build scripts so much easier. It also would help me to easy plain vanilla maven/ ant. Or did I miss something? brgds, Papick ps: I searched the group, but I could not find similar topics. Sorry if this has already been discussed. I can't imagine I am the only one running into this one... --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] GWT-Incubator: GlassPanel changes
Hi, We are currently moving to the GWT 1.6 release and also updated to the latest incubator. I am having a problem with the GlassPanel widget in the incubator and looked a bit into the implementation. It has a functionality that it automatically grabs the focus. This functionality is not what we wanted so in a previous version if had just overriden the setFocus method to override this behaviour. We are using the GlassPanel to only block part of our UI when input fields are changed by the user. The side effect is that now when the user changes the input field, after one character, the GlassPanel is shown and the user has to click on the input field again to continue entering data. Could this automatically grabbing the focus be made optional ? Right now I can only see a solution by copying the code and deleting this unwanted functionality since the rework of the component no longer allows me to change the behaviour. the GlassPanel should be usable in more situations than just to block the complete window. I also see in the code that in onAttach a FocusPanelImpl is attached to the root panel... does this mean that every time I remove the GlassPanel from the page and reattach that it will add another FocusPanelImpl ? That looks like a leak to me (the onDetach does not remove it unless I overlooked it ?) Another comment is the usage of a WindowResizeListener. Isn't this duplicate code from the ResizableWidgetCollection ? David --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Event model improvements ?
Hellu, I am porting my app to 1.6.4 and bounce my head against a few issues of the new event model. At first, this wouldn't be a big issue as long as you can add your own modifications, but I can't. What restrict me is to inject my own HandlerManager such that I can add my own behavior like adding an interceptor (optional: async interceptor), checks like maximum, duplicates, changing the source, etc... :(.. Why isn't it possible to be able to change the HandlerManager, what is the idea behind this? How I make it work now: extends all basic widgets like Label en TextBox and override the add**Listeners(...) method to bypass them to my own HandlerManager, which is contained in a so called Observer object. The overridden widget also overriddes the onBrowserEvent method and pass it on to the Observer object that will inform the listeners... This is very cumberslume and I hoped I would be able to solve it in the new event model. But I still can't and have to do it with a lot of code around it to make it work which isn't very friendly ofcouse... I noticed a few more disadvantages of the new event model that I posted here: http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/7d4e53c26cac6ae2# The related enhancement request: http://code.google.com/p/google-web-toolkit/issues/detail?id=3628q=HandlerManager If I read the announcements of the new event model it has all kind of advantages like the less code that is needed. However, this is what I experience like explained above. Does the gwt dev team look at this pratical issues and how it will exactly be used in complex systems ?... I am sorry, I know that the gwt dev team is doing their best but I sometimes have my doubts about that as I already had previous discusssions about strange usage of the gwt code, for example: the lack of some primitive interfaces. I understand that the gwt dev team wants to overcome a lock-in situation, but please realize that on the otherside it leads to strange (large) code to implement complex functionality which normally in swing or swt isn't that difficult. Just my thoughts, Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT-Incubator: GlassPanel changes
On 5 mai, 10:15, stuckagain david.no...@gmail.com wrote: Hi, We are currently moving to the GWT 1.6 release and also updated to the latest incubator. I am having a problem with the GlassPanel widget in the incubator and looked a bit into the implementation. It has a functionality that it automatically grabs the focus. This functionality is not what we wanted so in a previous version if had just overriden the setFocus method to override this behaviour. We are using the GlassPanel to only block part of our UI when input fields are changed by the user. The side effect is that now when the user changes the input field, after one character, the GlassPanel is shown and the user has to click on the input field again to continue entering data. Could this automatically grabbing the focus be made optional ? Right now I can only see a solution by copying the code and deleting this unwanted functionality since the rework of the component no longer allows me to change the behaviour. the GlassPanel should be usable in more situations than just to block the complete window. I agree, and even in those situations, when used in combination with a modal popup panel, grabbing the focus isn't strictly necessary either (note that PopupPanel does not grab the focus, instead it eats up every event not targeted at the modal popup panel). I do believe actually that the lightbox effect should be done by the popup panel (when modal), as it would also solve issue 1186 [1] (defaulting to being fully transparent) [1] http://code.google.com/p/google-web-toolkit/issues/detail?id=1186 I also see in the code that in onAttach a FocusPanelImpl is attached to the root panel... does this mean that every time I remove the GlassPanel from the page and reattach that it will add another FocusPanelImpl ? That looks like a leak to me (the onDetach does not remove it unless I overlooked it ?) As said on the JavaDoc for this FocusPanelImpl class, it removes itself (it does this as soon as it gains the focus, which it grabs as soon as it's attached to the document). Another comment is the usage of a WindowResizeListener. Isn't this duplicate code from the ResizableWidgetCollection ? GlassPanel has unfortunately not been updated for a while (including for GWT 1.6: uses WindowResizeListener instead of ResizeHandler, EventPreview instead of NativePreviewHandler, etc.). Maybe it's time to rewrite it, and/or split it into more a set of widgets, each one specialized on one thing (lightbox+dialog, cover part of the page, etc.) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT-Incubator: GlassPanel changes
Hi, I just created a trimmed down GlassPanel that only contains what we need. Just as a thought on bug 1186, why not deprecate the ListBox widget and replace it with a custom widget. The standard listbox in the browser is underpowered when it comes to styling. I would like to put more than just strings in there. If that were the case then all these tricks to get dialogs to render correctly while dragging or to cancel events are no longer needed in IE6. David On Tue, May 5, 2009 at 12:49 PM, Thomas Broyer t.bro...@gmail.com wrote: On 5 mai, 10:15, stuckagain david.no...@gmail.com wrote: Hi, We are currently moving to the GWT 1.6 release and also updated to the latest incubator. I am having a problem with the GlassPanel widget in the incubator and looked a bit into the implementation. It has a functionality that it automatically grabs the focus. This functionality is not what we wanted so in a previous version if had just overriden the setFocus method to override this behaviour. We are using the GlassPanel to only block part of our UI when input fields are changed by the user. The side effect is that now when the user changes the input field, after one character, the GlassPanel is shown and the user has to click on the input field again to continue entering data. Could this automatically grabbing the focus be made optional ? Right now I can only see a solution by copying the code and deleting this unwanted functionality since the rework of the component no longer allows me to change the behaviour. the GlassPanel should be usable in more situations than just to block the complete window. I agree, and even in those situations, when used in combination with a modal popup panel, grabbing the focus isn't strictly necessary either (note that PopupPanel does not grab the focus, instead it eats up every event not targeted at the modal popup panel). I do believe actually that the lightbox effect should be done by the popup panel (when modal), as it would also solve issue 1186 [1] (defaulting to being fully transparent) [1] http://code.google.com/p/google-web-toolkit/issues/detail?id=1186 I also see in the code that in onAttach a FocusPanelImpl is attached to the root panel... does this mean that every time I remove the GlassPanel from the page and reattach that it will add another FocusPanelImpl ? That looks like a leak to me (the onDetach does not remove it unless I overlooked it ?) As said on the JavaDoc for this FocusPanelImpl class, it removes itself (it does this as soon as it gains the focus, which it grabs as soon as it's attached to the document). Another comment is the usage of a WindowResizeListener. Isn't this duplicate code from the ResizableWidgetCollection ? GlassPanel has unfortunately not been updated for a while (including for GWT 1.6: uses WindowResizeListener instead of ResizeHandler, EventPreview instead of NativePreviewHandler, etc.). Maybe it's time to rewrite it, and/or split it into more a set of widgets, each one specialized on one thing (lightbox+dialog, cover part of the page, etc.) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT-Incubator: GlassPanel changes
I'll admit to not having used the incubator GlassPanel in a while, but its setFocus() behavior does sound like something that should be optional, for precisely the reasons you describe. I do want to point out that it would be pretty unreasonable to actually deprecate the native ListBox/select element. It's a normal part of HTML forms, and our goal is most definitely not to make everything work as long as you only use the controls and elements we bless. On Tue, May 5, 2009 at 8:24 AM, David david.no...@gmail.com wrote: Hi, I just created a trimmed down GlassPanel that only contains what we need. Just as a thought on bug 1186, why not deprecate the ListBox widget and replace it with a custom widget. The standard listbox in the browser is underpowered when it comes to styling. I would like to put more than just strings in there. If that were the case then all these tricks to get dialogs to render correctly while dragging or to cancel events are no longer needed in IE6. David On Tue, May 5, 2009 at 12:49 PM, Thomas Broyer t.bro...@gmail.com wrote: On 5 mai, 10:15, stuckagain david.no...@gmail.com wrote: Hi, We are currently moving to the GWT 1.6 release and also updated to the latest incubator. I am having a problem with the GlassPanel widget in the incubator and looked a bit into the implementation. It has a functionality that it automatically grabs the focus. This functionality is not what we wanted so in a previous version if had just overriden the setFocus method to override this behaviour. We are using the GlassPanel to only block part of our UI when input fields are changed by the user. The side effect is that now when the user changes the input field, after one character, the GlassPanel is shown and the user has to click on the input field again to continue entering data. Could this automatically grabbing the focus be made optional ? Right now I can only see a solution by copying the code and deleting this unwanted functionality since the rework of the component no longer allows me to change the behaviour. the GlassPanel should be usable in more situations than just to block the complete window. I agree, and even in those situations, when used in combination with a modal popup panel, grabbing the focus isn't strictly necessary either (note that PopupPanel does not grab the focus, instead it eats up every event not targeted at the modal popup panel). I do believe actually that the lightbox effect should be done by the popup panel (when modal), as it would also solve issue 1186 [1] (defaulting to being fully transparent) [1] http://code.google.com/p/google-web-toolkit/issues/detail?id=1186 I also see in the code that in onAttach a FocusPanelImpl is attached to the root panel... does this mean that every time I remove the GlassPanel from the page and reattach that it will add another FocusPanelImpl ? That looks like a leak to me (the onDetach does not remove it unless I overlooked it ?) As said on the JavaDoc for this FocusPanelImpl class, it removes itself (it does this as soon as it gains the focus, which it grabs as soon as it's attached to the document). Another comment is the usage of a WindowResizeListener. Isn't this duplicate code from the ResizableWidgetCollection ? GlassPanel has unfortunately not been updated for a while (including for GWT 1.6: uses WindowResizeListener instead of ResizeHandler, EventPreview instead of NativePreviewHandler, etc.). Maybe it's time to rewrite it, and/or split it into more a set of widgets, each one specialized on one thing (lightbox+dialog, cover part of the page, etc.) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: GWT-Incubator: GlassPanel changes
I'm with Joel on keeping the native ListBox. There's no reason that it can't co-exist with other implementations, such as the incubator's DropDownListBox. On Tue, May 5, 2009 at 9:13 AM, Joel Webber j...@google.com wrote: I'll admit to not having used the incubator GlassPanel in a while, but its setFocus() behavior does sound like something that should be optional, for precisely the reasons you describe. I do want to point out that it would be pretty unreasonable to actually deprecate the native ListBox/select element. It's a normal part of HTML forms, and our goal is most definitely not to make everything work as long as you only use the controls and elements we bless. On Tue, May 5, 2009 at 8:24 AM, David david.no...@gmail.com wrote: Hi, I just created a trimmed down GlassPanel that only contains what we need. Just as a thought on bug 1186, why not deprecate the ListBox widget and replace it with a custom widget. The standard listbox in the browser is underpowered when it comes to styling. I would like to put more than just strings in there. If that were the case then all these tricks to get dialogs to render correctly while dragging or to cancel events are no longer needed in IE6. David On Tue, May 5, 2009 at 12:49 PM, Thomas Broyer t.bro...@gmail.com wrote: On 5 mai, 10:15, stuckagain david.no...@gmail.com wrote: Hi, We are currently moving to the GWT 1.6 release and also updated to the latest incubator. I am having a problem with the GlassPanel widget in the incubator and looked a bit into the implementation. It has a functionality that it automatically grabs the focus. This functionality is not what we wanted so in a previous version if had just overriden the setFocus method to override this behaviour. We are using the GlassPanel to only block part of our UI when input fields are changed by the user. The side effect is that now when the user changes the input field, after one character, the GlassPanel is shown and the user has to click on the input field again to continue entering data. Could this automatically grabbing the focus be made optional ? Right now I can only see a solution by copying the code and deleting this unwanted functionality since the rework of the component no longer allows me to change the behaviour. the GlassPanel should be usable in more situations than just to block the complete window. I agree, and even in those situations, when used in combination with a modal popup panel, grabbing the focus isn't strictly necessary either (note that PopupPanel does not grab the focus, instead it eats up every event not targeted at the modal popup panel). I do believe actually that the lightbox effect should be done by the popup panel (when modal), as it would also solve issue 1186 [1] (defaulting to being fully transparent) [1] http://code.google.com/p/google-web-toolkit/issues/detail?id=1186 I also see in the code that in onAttach a FocusPanelImpl is attached to the root panel... does this mean that every time I remove the GlassPanel from the page and reattach that it will add another FocusPanelImpl ? That looks like a leak to me (the onDetach does not remove it unless I overlooked it ?) As said on the JavaDoc for this FocusPanelImpl class, it removes itself (it does this as soon as it gains the focus, which it grabs as soon as it's attached to the document). Another comment is the usage of a WindowResizeListener. Isn't this duplicate code from the ResizableWidgetCollection ? GlassPanel has unfortunately not been updated for a while (including for GWT 1.6: uses WindowResizeListener instead of ResizeHandler, EventPreview instead of NativePreviewHandler, etc.). Maybe it's time to rewrite it, and/or split it into more a set of widgets, each one specialized on one thing (lightbox+dialog, cover part of the page, etc.) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Hierarchy of property values?
Before I started working up a patch for this, I thought it was worth floating the basic idea for comment: I recently wanted an app with special interfaces for mobile browsers (specificially, iphone and android). No problem; we redefined user.agent to allow those values, and to provide a property provider for them. However, it turns out that both are WebKit, like Safari, and in a lot of cases, all the Safari rebindings were correct for the mobile ones, too. So I wanted a way to express that iphone was just like Safari, unless explicitly noted otherwise. What would people think about a GWT XML directive like: property-value-inherits property=user.agent value=iphone inherits=safari/ ...with all of the field names up for debate, as well as the basic concept. The same mechanism could be used to specialize user agents by version, i.e. ie-base could be inherited by ie6 and ie8. Other, similar concepts I've heard discussed include a when-property-begins-with .../ or when-property-matches .../ formulation, but I'm not sure either of them let me do the notion of inheritance that I wanted. (They do cover the version number problem, however.) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Hierarchy of property values?
Also, Bob raised the question of generators and their sensitivity to user.agent values (or other properties, perhaps), and whether we would need GeneratorContext.propertyValueMatches(String actual, String possiblyInherited) or the like. I was focused on rule selection, so I hadn't thought about it, but I'm not sure it would be needed: the generator is, after all, still generating for safari, and not doing anything special for iphone or android; the inheritance is just asserting that the generated code is also applicable for iphone. When we do an anywhen-property-is...//any today, as I understand it, the generator does get a chance to do different work for each user agent, but may also return the same classname to do the same job once for all... my value-inheritance would effectively force the second case. If you want something different, you want a specific rule, not the implicit inheritance. No? On Tue, May 5, 2009 at 10:16 AM, Freeland Abbott fabb...@google.com wrote: Before I started working up a patch for this, I thought it was worth floating the basic idea for comment: I recently wanted an app with special interfaces for mobile browsers (specificially, iphone and android). No problem; we redefined user.agent to allow those values, and to provide a property provider for them. However, it turns out that both are WebKit, like Safari, and in a lot of cases, all the Safari rebindings were correct for the mobile ones, too. So I wanted a way to express that iphone was just like Safari, unless explicitly noted otherwise. What would people think about a GWT XML directive like: property-value-inherits property=user.agent value=iphone inherits=safari/ ...with all of the field names up for debate, as well as the basic concept. The same mechanism could be used to specialize user agents by version, i.e. ie-base could be inherited by ie6 and ie8. Other, similar concepts I've heard discussed include a when-property-begins-with .../ or when-property-matches .../ formulation, but I'm not sure either of them let me do the notion of inheritance that I wanted. (They do cover the version number problem, however.) --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add name to Anchor tag using GWT Anchor widget
I tried doing Anchor.setName(abc) and we are using IE 6 . On render, when we see the source, inside the a , name is not gettign set. Is it a bug? On May 4, 6:34 pm, Joel Webber j...@google.com wrote: Anchor.setName() simply calls AnchorElement.setName(), which translates to the simple expression anchor.element.name = whatever. This behavior is tested in AnchorTest.testSetterRoundtrip(), and is asserted to show up properly as a DOM attribute. If you're seeing this not stick on some browser or under some circumstances, please file an issue. But do make sure to include sample code that exhibits the problem, as it at least appears to work properly in the tests. On Sun, May 3, 2009 at 4:11 AM, Iyer aruniye...@gmail.com wrote: I am creatign a hyperlink in a webpage using Anchor Widget in GWt but though i set the name on anchor tag, when page renders and view the source , I dont see the anchor tag having the name set. Is it possible to gwt the name generated for the anchor tag using GWT widget?- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Hierarchy of property values?
Here's my original email to Freeland: What does this mean for generators that are sensitive to the user.agent property (or any other property that may be extended)? Imagine that a common component has a CssResource with an @if user.agent safari rule. The end-developer comes along and extends the safari rule with iphone and android extensions. It's no longer just a simple string comparison to determine if the user.agent value the generator is looking for actually matches the permutation that's currently running. If you choose to go this route, GeneratorContext will need a boolean propertyMatches(String propName, String value) method to handle the hierarchical case and all existing generators that are sensitive to any deferred-binding properties will have to be updated to this API to prevent spurious breaks. Furthermore, based on Freeland's reply: If the iphone value just maps onto the safari value for everything but rule-selection purposes, how could you then write @if user.agent iphone to dial in presentation in a bit more? The ClientBundle system returns differently-named types for each permutation based on feedback from the individual ResourceGenerators, (e.g. MyResources_en_US_safari). My basic point is that the specific value of the deferred-binding property is meaningless in the presence of extension values and the only useful question is does this match as opposed to asking is this equal. Developers who write Generator that use deferred-binding properties to alter code-generation must update to a new API in order to prevent flaky behavior. -- Bob Vawter Google Web Toolkit Team --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add name to Anchor tag using GWT Anchor widget
If I understand correctly, you're checking for changes to the DOM when you view the source of your page? When you change the DOM with GWT (or javascript in general), the source of the page doesn't change. I think a better approach would be to write some code to ask the element what its name is, at runtime. On Tue, May 5, 2009 at 10:31 AM, Iyer aruniye...@gmail.com wrote: I tried doing Anchor.setName(abc) and we are using IE 6 . On render, when we see the source, inside the a , name is not gettign set. Is it a bug? -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Allow users to disable keyboard support in FastTree
Reviewers: rjrjr, Description: This patch allows users to disable keyboard navigation support in FastTree, which is sometimes desirable if a child widget handles keyboard support itself (natively or not). For example, you might want to disable keyboard support if your FastTree contains a TextBox or TextArea, in which the user might use the arrow keys to navigate to a cursor position. You might also disable keyboard if the Tree contains a very large item, as doing so would allow the user to scroll using the up/down arrow keys. Please review this at http://gwt-code-reviews.appspot.com/32801 Affected files: src-demo/com/google/gwt/gen2/demo/fasttree/client/FastTreeDemo.java src/com/google/gwt/gen2/complexpanel/client/FastTree.java test/com/google/gwt/gen2/complexpanel/client/FastTreeTest.java --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Allow users to disable keyboard support in FastTree
LGTM Nice. I like the test in particular. Hurray for fake events! But that said, did you run the test on IE? I've been bitten by its event handling lately. http://gwt-code-reviews.appspot.com/32801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Allow users to disable keyboard support in FastTree
The tests pass on FF, IE and Chrome. committed as r1649 Thanks, John LaBanca jlaba...@google.com On Tue, May 5, 2009 at 11:04 AM, rj...@google.com wrote: LGTM Nice. I like the test in particular. Hurray for fake events! But that said, did you run the test on IE? I've been bitten by its event handling lately. http://gwt-code-reviews.appspot.com/32801 --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Add name to Anchor tag using GWT Anchor widget
I am viewing the source on render of the jsp , infact full source, where in all the elements of anchor tag will eb updated except the name attribute of the anchor tag. say href, font for the hyperlink text but the name doesnt get updated. On May 5, 7:46 pm, Alex Rudnick a...@google.com wrote: If I understand correctly, you're checking for changes to the DOM when you view the source of your page? When you change the DOM with GWT (or javascript in general), the source of the page doesn't change. I think a better approach would be to write some code to ask the element what its name is, at runtime. On Tue, May 5, 2009 at 10:31 AM, Iyer aruniye...@gmail.com wrote: I tried doing Anchor.setName(abc) and we are using IE 6 . On render, when we see the source, inside the a , name is not gettign set. Is it a bug? -- Alex Rudnick swe, gwt, atl --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] for review: trivial ant patch
John, I noticed that ant buildonly doesn't rebuild the tools directory (which I care about for soyc, for example)... I think it should, yes? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- Index: build.xml === --- build.xml (revision 5320) +++ build.xml (working copy) @@ -11,7 +11,7 @@ property name=gwt.apicheck.oldroot value=../gwt-1.5/ - target name=buildonly depends=dev, user, servlet, jni description=Build without docs/samples + target name=buildonly depends=dev, user, servlet, jni, tools description=Build without docs/samples gwt.ant dir=distro-source / /target
[gwt-contrib] Re: for review: trivial ant patch
On Tue, May 5, 2009 at 1:43 PM, Freeland Abbott fabb...@google.com wrote: I noticed that ant buildonly doesn't rebuild the tools directory (which I care about for soyc, for example)... I think it should, yes? Well, the more things that are added the less useful it becomes for what I used it for, which was quick builds of the jars. Maybe there should be multiple targets, or maybe it should be renamed to nosamples and mean explicitly everything but the samples. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: for review: trivial ant patch
I can equally just add tools as a thing I know to build, yes... the question is what's the desired semantic of buildonly? Happy either way, since ant buildonly tools works for me for now. On Tue, May 5, 2009 at 1:52 PM, John Tamplin j...@google.com wrote: On Tue, May 5, 2009 at 1:43 PM, Freeland Abbott fabb...@google.comwrote: I noticed that ant buildonly doesn't rebuild the tools directory (which I care about for soyc, for example)... I think it should, yes? Well, the more things that are added the less useful it becomes for what I used it for, which was quick builds of the jars. Maybe there should be multiple targets, or maybe it should be renamed to nosamples and mean explicitly everything but the samples. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] I've implemented Java stack trace support for web mode
I have a working implementation which produces stack traces representing the original Jave source code when Javascript exceptions occur in web mode. I plan to deploy this in production on my site, typeracer.com in my next release. I'd like to polish up my implementation over the next few weeks, measure performance, and present it at Google I/O at the end of the month. We've talked about adding similar features to the GWT compiler in the past on this forum, but my site couldn't wait (I was getting too many cryptic exceptions logged from users), so I decided to go ahead and do it my way. I ended up doing it externally to GWT, without any changes to the GWT compiler or any other code. Are there any new developments on this front in the core GWT code? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on UsingOOPHM in google-web-toolkit
Comment by mihai.ile: I am getting errors (build went ok), but on launching from Eclipse in ubuntu, I see the swing window but on the jetty tab I get errors like: javax.servlet.Servlet 00:00:01.490 [WARN] failed jsp javax.servlet.UnavailableException: Servlet class org.apache.jasper.servlet.JspServlet is not a javax.servlet.Servlet 00:00:01.492 [WARN] failed default javax.servlet.UnavailableException: Servlet class org.mortbay.jetty.servlet.DefaultServlet is not a javax.servlet.Servlet Any ideas on this? For more information: http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Comment on UsingOOPHM in google-web-toolkit
Comment by mihai.ile: never mind, I have no Idea, I created a new project and now it works with the same jars build earlier... For more information: http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: I've implemented Java stack trace support for web mode
Are there any new developments on this front in the core GWT code? The reason I ask is to be sure that I'm not duplicating your efforts and wasting my time. On Tue, May 5, 2009 at 4:31 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: I have a working implementation which produces stack traces representing the original Jave source code when Javascript exceptions occur in web mode. I plan to deploy this in production on my site, typeracer.com in my next release. I'd like to polish up my implementation over the next few weeks, measure performance, and present it at Google I/O at the end of the month. We've talked about adding similar features to the GWT compiler in the past on this forum, but my site couldn't wait (I was getting too many cryptic exceptions logged from users), so I decided to go ahead and do it my way. I ended up doing it externally to GWT, without any changes to the GWT compiler or any other code. Are there any new developments on this front in the core GWT code? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: I've implemented Java stack trace support for web mode
Alex, Do check out com.google.gwt.core.client.impl.StackTraceCreator (in trunk). If I'm understanding your proposal correctly, there may be a great deal of overlap there. Cheers, joel. On Tue, May 5, 2009 at 6:47 PM, Alex Epshteyn alexander.epsht...@gmail.comwrote: Are there any new developments on this front in the core GWT code? The reason I ask is to be sure that I'm not duplicating your efforts and wasting my time. On Tue, May 5, 2009 at 4:31 PM, Alex Epshteyn alexander.epsht...@gmail.com wrote: I have a working implementation which produces stack traces representing the original Jave source code when Javascript exceptions occur in web mode. I plan to deploy this in production on my site, typeracer.com in my next release. I'd like to polish up my implementation over the next few weeks, measure performance, and present it at Google I/O at the end of the month. We've talked about adding similar features to the GWT compiler in the past on this forum, but my site couldn't wait (I was getting too many cryptic exceptions logged from users), so I decided to go ahead and do it my way. I ended up doing it externally to GWT, without any changes to the GWT compiler or any other code. Are there any new developments on this front in the core GWT code? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
