Re: [gwt-contrib] Re: GWT 2.0.1 breaks incubator 2.0 ... is a new release emminent ?
I didn't get the chance to test it out, due to corporate red tape :-( David On Tue, Feb 9, 2010 at 3:51 PM, John LaBanca wrote: > I'll take a look and make sure we can use the incubator jar with GWT 2.0. > Thanks, > John LaBanca > jlaba...@google.com > > > On Tue, Feb 9, 2010 at 8:35 AM, newnoise wrote: >> >> acutally i get the errors in the version downloaded today also. >> >> >> On 8 Feb., 16:09, John LaBanca wrote: >> > Wow, 2010 already. Fixed. >> > >> > Thanks, >> > John LaBanca >> > jlaba...@google.com >> > >> > On Sat, Feb 6, 2010 at 8:52 AM, jim n wrote: >> > > can you name it 2010x please? >> > >> > > On Feb 4, 8:19 am, Ray Ryan wrote: >> > > > And the jar is posted. All better? >> > >> > > > On Thu, Feb 4, 2010 at 7:15 AM, Ray Ryan wrote: >> > > > > Sorry, we'll get a 2.0.1 incubator jar up today. >> > >> > > > > On Thu, Feb 4, 2010 at 7:04 AM, stuckagain >> > > wrote: >> > >> > > > >> Hi, >> > >> > > > >> The changes to CurrencyData and CurrencyList as described in the >> > > > >> release note of GWT 2.0.1 has impact on the current GWT incubator >> > > > >> CurrencyWidget. Is there a new release planned ? It seems to be >> > > > >> fixed >> > > > >> in the trunk of incubator. >> > >> > > > >> This is the compilation error. >> > >> > > > >> [ERROR] Errors in >> > > > >> 'jar:file:/W:/rlsCOTS/gwtincubator/JAVA/lib/gwt- >> > > > >> >> > > > >> incubator.jar!/com/google/gwt/widgetideas/client/CurrencyWidget.java' >> > > > >> [java] [ERROR] Line 46: The import >> > > > >> com.google.gwt.i18n.client.impl.CurrencyData cannot be resolved >> > > > >> [java] [ERROR] Line 47: The import >> > > > >> com.google.gwt.i18n.client.impl.CurrencyList cannot be resolved >> > > > >> [java] [ERROR] Line 107: CurrencyData cannot be >> > > > >> resolved >> > > > >> to a type >> > > > >> [java] [ERROR] Line 122: CurrencyData cannot be >> > > > >> resolved >> > > > >> to a type >> > > > >> [java] [ERROR] Line 122: CurrencyList cannot be >> > > > >> resolved >> > > > >> [java] [ERROR] Line 123: CurrencyData cannot be >> > > > >> resolved >> > > > >> to a type >> > > > >> [java] [ERROR] Line 124: CurrencyData cannot be >> > > > >> resolved >> > > > >> to a type >> > > > >> [java] [ERROR] Line 181: CurrencyData cannot be >> > > > >> resolved >> > > > >> to a type >> > >> > > > >> David >> > >> > > > >> -- >> > > > >>http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > >> > > > > -- >> > > > > I wish this were a Wave >> > >> > > > -- >> > > > I wish this were a Wave >> > >> > > -- >> > >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] Adds hovering style to StackLayoutPanel (issue 4561).
Reviewers: , Please review this at http://gwt-code-reviews.appspot.com/143801 Affected files: M user/src/com/google/gwt/user/client/ui/StackLayoutPanel.java M user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css M user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css M user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css M user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css M user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css M user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RFC: sharded linking
I've replied before but don't see it here, if it turns up ignore this dupe. I don't maintain any linkers but I have experimented with multi- machine builds. The current Precompile, CompilePerms, and Link implementation has the nice feature that the CompilePerms step does not require access to the source code being compiled. This makes it very, very much easier to deploy additional CompilePerms workers as they don't need to check out source code etc. I like the plan for being able to perform some linking in parallel but I wouldn't like to lose the ability to deploy a useful CompilePerms worker that does not need source code access. If performing Java parsing, creating AST and generating artifacts is something that may need to be parallelized for some builds then I'd like it if that was done in an additional step so that people could choose whether or not to run that on multiple machines while still being able to run the CompilePerms steps on multiple machines. On Feb 9, 4:31 pm, Lex Spoon wrote: > This is a design doc about speeding up the link phase of GWT. If you don't > maintain a linker, and if you don't have a multi-machine GWT build, then > none of this should matter to you. If you do maintain a linker, let's make > sure your linker can be updated with the proposed changes. If you do have a > multi-machine build, or if you have some ideas about them, then perhaps you > can help us get the best speed benefit possible out of this. > > I want to speed up linking for multi-machine builds in two ways: > > 1. Allow more parts of linking to run in parallel. In particular, anything > that happens once per permutation and does not need information from other > permutations can run in parallel. As an example, the iframe linker chunks > the JavaScript of each permutation into multiple
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Yes, many times its too hard to customize things. Sometimes it make sense to use private or package protected. But i think the HandlerManager gets used so widely that it should be customizable On 9 Feb., 23:57, Nathan Wells wrote: > As a developer I absolutely agree with Mr. Ryan here... I hope that > this isn't taken the wrong way, but it's so difficult to customize any > given tool that GWT hands us. The eventual answer always seems to be > "make a custom build" which is extremely hard to sell to anyone other > than a GWT developer. > > For additional related information, see the following issue: > > http://code.google.com/p/google-web-toolkit/issues/detail?id=3628 > > On Feb 9, 10:14 am, Ray Ryan wrote: > > > On Tue, Feb 9, 2010 at 9:09 AM, wrote: > > > Warning: better arguments against setHandlerManager below: > > > > My concern is that it is too easy to add handlers to a Widget and then > > > set a new HandlerManager, expecting the old handlers to be transferred > > > to the new HandlerManager. What would be the correct thing to do here? > > > We can't transfer handlers because the HandlerRegistrations are linked > > > to the old HandlerManager. > > > Why would I expect that? I'd use such a call expecting it to allow me to > > swap different sets of handlers around, e.g. a widget that has two very > > different modes (edit v. nav). > > > > Also, we've been trying to move to a model where we add Event Handlers > > > in a widget's constructor instead of overriding onBrowserEvent(). Those > > > handlers will be lost when we switch to a new HandlerManager, unless we > > > unregister the old ones and register new ones. That complicates the > > > widget creation process. > > > I hope you mean add event handling capabilities at constructor time, not > > actual handler instances. If you mean the latter, that's a dreadful idea. > > > I still don't buy this argument. If I swap it out, I can swap it in. > > > > If we require that the user specify the one and only HandlerManager when > > > the first handler is added, then we avoid these problems. > > > I really think this is over protective, and the kind of thing that makes our > > widgets too hard to customize. > > > >http://gwt-code-reviews.appspot.com/138801 > > > -- > > I wish this were a Wave > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RFC: sharded linking
I may have misunderstood the proposal but I've experimented a little with multi machine builds so I'll comment based on that. One very nice feature of the current system is that the CompilePerms step does not need access to the source code being compiled. This is a significant benefit as it makes it very easy to setup a new machine to perform CompilePerms work. Without this each CompilePerms machine would have to checkout the source to compile, a significant amount of work and potentially difficult to configure. My experiments showed most of the time being spent in the current Precompile step, but that is because I was not generating a large number of permutations. I imagine the use case for multi machine builds is that you're doing a build for QA or release that needs to include all languages etc, certainly 10s of permutations. One big machine with access to the source to run Precompile in parallel on multiple pages and then being able to simply make available lots of dumb CompilePerms workers that need just GWT installed would be a big advantage here. Or, Precompile different pages on different machines (using some out of band distribution system) and then use a farm of dumb workers to CompilePerms. Individual developers probably use dev mode or just build a single language. Making it possible to run portions of the linkers as part of CompilePerms would certainly be a benefit and I'm all for the "reduced serialization" plan. On Feb 9, 4:31 pm, Lex Spoon wrote: > This is a design doc about speeding up the link phase of GWT. If you don't > maintain a linker, and if you don't have a multi-machine GWT build, then > none of this should matter to you. If you do maintain a linker, let's make > sure your linker can be updated with the proposed changes. If you do have a > multi-machine build, or if you have some ideas about them, then perhaps you > can help us get the best speed benefit possible out of this. > > I want to speed up linking for multi-machine builds in two ways: > > 1. Allow more parts of linking to run in parallel. In particular, anything > that happens once per permutation and does not need information from other > permutations can run in parallel. As an example, the iframe linker chunks > the JavaScript of each permutation into multiple
[gwt-contrib] Re: Change RichTextAreaImpl and subclasses to not be coupled to Widget/RichTextArea
Reviewers: jgw, jlabanca,
http://gwt-code-reviews.appspot.com/139801/diff/1/3
File
user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplIE6.java
(right):
http://gwt-code-reviews.appspot.com/139801/diff/1/3#newcode96
Line 96: if
(@com.google.gwt.user.client.impl.DOMImpl::isMyListener(Ljava/lang/Object;)(elem.__listener))
{
On 2010/02/09 19:47:05, jlabanca wrote:
Why is this needed again? Is it possible that the listener is in a
different
module?
This check will in most cases not be needed. However GWT is doing this
check also on the other cases where it is accessing the __listener
attribute (DOMImplStandard for example). When you create the
RichTextAreaImpl in module one and a second module sets up the attribute
on the iframe element, you will need this check (you should normally not
od that).
If you think we should not do this safty check, we can remove it here.
Description:
At the moment you cannot use the RichTextAreaImpl class without the
Widget class. If you have a custom class that implements the
EventListener interface and sets up the "__listener" attribute that gets
used with the RichTextAreaImpl you will get an execption. This patch
changes the RichTextAreaImpl classes to not be coupled to Widget but be
bound to the EventListener interface.
It also decouples it from the RichTextArea class. The only reason the
RichTextArea is linked is because of the initialize event.
With this changes you are able to use the wonderful RichTextAreaImpl
classes in any custom EventListener and any custom class that implements
HasInitializeHandlers.
Please review this at http://gwt-code-reviews.appspot.com/139801
Affected files:
user/src/com/google/gwt/user/client/ui/RichTextArea.java
user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImpl.java
user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplIE6.java
user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplSafari.java
user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplStandard.java
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
The danger is that if you add handlers, and than later in your code call setHandlerManager with a new HandlerManager. If we dont check for a prior existing HandlerManager, all old HandlerRegistration's will be lost. If you dont know what happened, you will search forever why your old handlers are not working. You wont have the problem with a createHandlerManager method. On 9 Feb., 17:55, Ray Ryan wrote: > If you're right that swapping HMs midstream is a bad idea, I think you need > a better argument than "it's a bad idea." What's the actual danger? If I'm > making my own HM I'm already pretty savvy. Why tie my hands? > > But yes, if you win that point, I agree with the change to replace setHM(HM) > with HM createHM() -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
On 2010/02/09 16:46:27, Ray Ryan wrote: Sorry, I came in mid-conversation. My -1 was in defense of setHandlerManager(), seeing no harm in allowing a widget to swap around its HM if it wants to. I'm totally in favor of allowing a custom HM to be used. For the ListModel also an own HandlerRegistration (ListRegistration) and an own HandlerManager will be needed. I think it is a good point to open it up for widgets too. I will change the patchfile to use a createHandlerManager method. http://gwt-code-reviews.appspot.com/138801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Patch for RichTextEditor
Sebastian,
Sorry it's taken so long for anyone to respond. This sounds like useful
functionality, and I would suggest creating an issue (
http://code.google.com/p/google-web-toolkit/issues/) and a patch for public
discussion (http://gwt-code-reviews.appspot.com/). That way it will be
easier for people to try out your patch and refine it.
Cheers,
joel.
On Fri, Jan 22, 2010 at 9:55 AM, Sebastian wrote:
> Hello,
>
> I was missing the ability to format a block with - tags. I
> researched the topic and build a patch which allows to insert block
> tags. It makes use of the FormatBlock command.
>
> I would like to ask, if you are interested in the patch and discuss
> the coding decision I took.
>
> 1)
> I couldn't find any guidance on testing. I have tested with Safari 4,
> Firefox 3.5, IE 6, IE 8 and IE 8 in IE 7 mode.
>
> 2)
> Currently only the tags to , , and work
> stable across browsers. To limit the choice of tags, I have created an
> enum to limit the possible values.
>
> public static enum BlockTag {
>H1, H2, H3, H4, H5, H6, PRE, ADDRESS, P;
> final String OPEN = "<";
> final String CLOSE = ">";
> public String toTag() {
>return OPEN+name()+CLOSE;
> }
>}
>
> The advantage is that you cannot provide the wrong tags. The
> disadvantage is that you cannot provide tags which are for example
> supported in newer browser versions.
>
> The rest of the tag is just a new method in RichTextAreaImplStd.
> public void formatBlock(RichTextArea.BlockTag blockTag) {
>execCommand("FormatBlock", blockTag.toTag());
> }
>
> Shall I leave it that way or turn it into a String parameter?
>
> 3)
> Should I create a bug tracking entry for this?
>
> If somebody is interested, here are some links, I found interesting
> while exploring the topic.
>
> http://discerning.com/topics/software/ttw.html
> http://help.dottoro.com/ljcvtcaw.php
> http://www.quirksmode.org/dom/execCommand.html
>
> Best Regards
>
> Sebastian Hennebrueder
>
> --
> http://groups.google.com/group/Google-Web-Toolkit-Contributors
>
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Hi Ray, all, I believe changing HMs mid stream is dangerous: 1. Say your (nav & edit) widget fires events that are common to both modes (i.e. a simple onOpen) and the widget is by default in nav mode 2 Say A registers an onOpen handler (which gets added to hm1 -- the default HM) then later switches to edit mode (and hm2 kicks in) 3. A will not see the onOpen events while on edit mode! If your nav & edit widet stays always in one mode, then createHM would do the trick. But if it switches modes you have to make sure there is no overlapping sets of events ... Andi On Tue, Feb 9, 2010 at 11:55 AM, Ray Ryan wrote: > If you're right that swapping HMs midstream is a bad idea, I think you need > a better argument than "it's a bad idea." What's the actual danger? If I'm > making my own HM I'm already pretty savvy. Why tie my hands? > > But yes, if you win that point, I agree with the change to replace > setHM(HM) with HM createHM() > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
Sven, you're arguing both sides here. You want things to be more customizable in general, but with your specific patch you're trying to be as restrictive as you can to achieve your personal goal. I'm assuming that if we provide an unrestricted setHandlerManager we would also provide a getHandlerManager. It doesn't seem like rocket science to expect someone to check for an existing one if before clobbering it. I'm also assuming that these methods are protected, not part of every widget's public api. I also would argue against providing both createHM and setHM. Redundant API is confusing API, another unfortunate trait of our widget set. Lazy creation can happen in the default implementation of getHM. A custom widget author could override that method to maintain laziness, or call setHM from their constructor to keep ours from ever seeing the light of day. On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken wrote: > The danger is that if you add handlers, and than later in your code > call setHandlerManager with a new HandlerManager. If we dont check for > a prior existing HandlerManager, all old HandlerRegistration's will be > lost. If you dont know what happened, you will search forever why your > old handlers are not working. > > You wont have the problem with a createHandlerManager method. > > > > On 9 Feb., 17:55, Ray Ryan wrote: > > If you're right that swapping HMs midstream is a bad idea, I think you > need > > a better argument than "it's a bad idea." What's the actual danger? If > I'm > > making my own HM I'm already pretty savvy. Why tie my hands? > > > > But yes, if you win that point, I agree with the change to replace > setHM(HM) > > with HM createHM() > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
My last two cents: This discussion is a classic example of why the GWT widgets are so locked down. GWT Contributors, do you trust yourselves or don't you? On Wed, Feb 10, 2010 at 7:27 AM, Andi Mullaraj wrote: > Hi Ray, all, > > I believe changing HMs mid stream is dangerous: > > 1. Say your (nav & edit) widget fires events that are common to both modes > (i.e. a simple onOpen) and the widget is by default in nav mode > 2 Say A registers an onOpen handler (which gets added to hm1 -- the default > HM) then later switches to edit mode (and hm2 kicks in) > 3. A will not see the onOpen events while on edit mode! > > If your nav & edit widet stays always in one mode, then createHM would do > the trick. But if it switches modes you have to make sure there is no > overlapping sets of events ... > > Andi > > > > > > > On Tue, Feb 9, 2010 at 11:55 AM, Ray Ryan wrote: > >> If you're right that swapping HMs midstream is a bad idea, I think you >> need a better argument than "it's a bad idea." What's the actual danger? If >> I'm making my own HM I'm already pretty savvy. Why tie my hands? >> >> But yes, if you win that point, I agree with the change to replace >> setHM(HM) with HM createHM() >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
On 10 Feb., 16:28, Ray Ryan wrote: > Sven, you're arguing both sides here. You want things to be more > customizable in general, but with your specific patch you're trying to be as > restrictive as you can to achieve your personal goal. Both patches have the same restriction, once a handlermanager is set or the default one created, there is no way back to change it. I am also ok with a setHandlerManager without restrictions. But than people will have the problem that they will loose handlerregistrations, if they dont know what they are doing (and yes, there are these people). I wanted to make this patch as much fool proof as possible. It should be customaziable, but in a way, that you cannot brake it. I dont think that you really need to change the handlermanager during runtime after you set the first one. You also cannot change the element of a widget once you set the first one. > > I'm assuming that if we provide an unrestricted setHandlerManager we would > also provide a getHandlerManager. It doesn't seem like rocket science to > expect someone to check for an existing one if before clobbering it. I'm > also assuming that these methods are protected, not part of every widget's > public api. Yes sure, protected. They should not be public. > > I also would argue against providing both createHM and setHM. Redundant API > is confusing API, another unfortunate trait of our widget set. Lazy creation > can happen in the default implementation of getHM. A custom widget author > could override that method to maintain laziness, or call setHM from their > constructor to keep ours from ever seeing the light of day. I dont want to add boths. There is no need for it. One approach is more than sufficient. With both ways you would be able to change the default handlermanager (which is the goal in the end). > > On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken > wrote: > > > > > The danger is that if you add handlers, and than later in your code > > call setHandlerManager with a new HandlerManager. If we dont check for > > a prior existing HandlerManager, all old HandlerRegistration's will be > > lost. If you dont know what happened, you will search forever why your > > old handlers are not working. > > > You wont have the problem with a createHandlerManager method. > > > On 9 Feb., 17:55, Ray Ryan wrote: > > > If you're right that swapping HMs midstream is a bad idea, I think you > > need > > > a better argument than "it's a bad idea." What's the actual danger? If > > I'm > > > making my own HM I'm already pretty savvy. Why tie my hands? > > > > But yes, if you win that point, I agree with the change to replace > > setHM(HM) > > > with HM createHM() > > > -- > >http://groups.google.com/group/Google-Web-Toolkit-Contributors > > -- > I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RFC: sharded linking
What you describe, Alex, is available via the "Compiler" entry point, though it hasn't been particularly well documented. There is a PermutationWorkerFactory that can create CompilePerms workers. The default worker factory spawns Java VMs on the same machine, but it is possible to write a replacement worker that uses ssh or whatnot to do the work on a separate machine. The way to plug in a replacement worker factory is to set the Java property gwt.jjs.permutationWorkerFactory . That said, I thought the reason for existence of Precompile, CompilePerms, and Link is to get the best build time but at the expense of needing extra configuration. We are finding that by spending a few seconds copying source code over, we save 10+ minutes in Precompile and 10+ minutes in Link. Is copying source code so inconvenient that it would be worth having a slower build? I would have thought any of the following would work to move source code from one machine to another: 1. rsync 2. jar + scp 3. "svn up" on the slave machines Do any of those seem practical for your situation, Alex? Overall, it's easy to provide an extra build staging as an option, but we support a number of build stagings already Lex -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
On Wed, Feb 10, 2010 at 10:27 AM, Andi Mullaraj wrote: > I believe changing HMs mid stream is dangerous: > > 1. Say your (nav & edit) widget fires events that are common to both modes > (i.e. a simple onOpen) and the widget is by default in nav mode > 2 Say A registers an onOpen handler (which gets added to hm1 -- the default > HM) then later switches to edit mode (and hm2 kicks in) > 3. A will not see the onOpen events while on edit mode! > > If your nav & edit widet stays always in one mode, then createHM would do > the trick. But if it switches modes you have to make sure there is no > overlapping sets of events ... > Another option to achieve this with potentially less danger is to maintain a stack of HandlerManagers. If one HM doesn't handle an event, it goes down to the next one. Then, if you want to have some modal event handling logic, you push a new HM on the stack with its own set of event handlers. When you are done with the modal logic, you pop it off the stack. Event types not handled by the modal event handler fall through to the main one, so in your example onOpen would still get handled properly. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I still think my proposal solves this for both cases. We add a protected createHandlerManager, which is more restrictive because it is only called once per widget. We also make getHandlerManager() protected, which allows users to replace the HandlerManager if they really want to by overriding getHandlerManager to return one of many. It would be up to the developer to add a setHandlerManager() method in their own widgets that would change the return value of getHandlerManager(), so its intentionally more difficult and therefore forces the developer to think about it a little more. Thanks, John LaBanca jlaba...@google.com On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken wrote: > > > On 10 Feb., 16:28, Ray Ryan wrote: > > Sven, you're arguing both sides here. You want things to be more > > customizable in general, but with your specific patch you're trying to be > as > > restrictive as you can to achieve your personal goal. > > Both patches have the same restriction, once a handlermanager is set > or the default one created, there is no way back to change it. I am > also ok with a setHandlerManager without restrictions. But than people > will have the problem that they will loose handlerregistrations, if > they dont know what they are doing (and yes, there are these people). > I wanted to make this patch as much fool proof as possible. It should > be customaziable, but in a way, that you cannot brake it. > > I dont think that you really need to change the handlermanager during > runtime after you set the first one. You also cannot change the > element of a widget once you set the first one. > > > > > I'm assuming that if we provide an unrestricted setHandlerManager we > would > > also provide a getHandlerManager. It doesn't seem like rocket science to > > expect someone to check for an existing one if before clobbering it. I'm > > also assuming that these methods are protected, not part of every > widget's > > public api. > Yes sure, protected. They should not be public. > > > > > I also would argue against providing both createHM and setHM. Redundant > API > > is confusing API, another unfortunate trait of our widget set. Lazy > creation > > can happen in the default implementation of getHM. A custom widget author > > could override that method to maintain laziness, or call setHM from their > > constructor to keep ours from ever seeing the light of day. > > I dont want to add boths. There is no need for it. One approach is > more than sufficient. With both ways you would be able to change the > default handlermanager (which is the goal in the end). > > > > On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken < > sven.brun...@googlemail.com>wrote: > > > > > > > > > The danger is that if you add handlers, and than later in your code > > > call setHandlerManager with a new HandlerManager. If we dont check for > > > a prior existing HandlerManager, all old HandlerRegistration's will be > > > lost. If you dont know what happened, you will search forever why your > > > old handlers are not working. > > > > > You wont have the problem with a createHandlerManager method. > > > > > On 9 Feb., 17:55, Ray Ryan wrote: > > > > If you're right that swapping HMs midstream is a bad idea, I think > you > > > need > > > > a better argument than "it's a bad idea." What's the actual danger? > If > > > I'm > > > > making my own HM I'm already pretty savvy. Why tie my hands? > > > > > > But yes, if you win that point, I agree with the change to replace > > > setHM(HM) > > > > with HM createHM() > > > > > -- > > >http://groups.google.com/group/Google-Web-Toolkit-Contributors > > > > -- > > I wish this were a Wave > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RFC: sharded linking
On Wed, Feb 10, 2010 at 10:45 AM, Lex Spoon wrote: > What you describe, Alex, is available via the "Compiler" entry point, > though it hasn't been particularly well documented. There is a > PermutationWorkerFactory that can create CompilePerms workers. The default > worker factory spawns Java VMs on the same machine, but it is possible to > write a replacement worker that uses ssh or whatnot to do the work on a > separate machine. The way to plug in a replacement worker factory is to set > the Java property gwt.jjs.permutationWorkerFactory . > > > That said, I thought the reason for existence of Precompile, CompilePerms, > and Link is to get the best build time but at the expense of needing extra > configuration. We are finding that by spending a few seconds copying source > code over, we save 10+ minutes in Precompile and 10+ minutes in Link. > > Is copying source code so inconvenient that it would be worth having a > slower build? I would have thought any of the following would work to move > source code from one machine to another: > > 1. rsync > 2. jar + scp > 3. "svn up" on the slave machines > > Do any of those seem practical for your situation, Alex? > > Overall, it's easy to provide an extra build staging as an option, but we > support a number of build stagings already > What does make it difficult is that you can't have a pool of worker machines that can build any project that are asked of them without copying the sources to the worker for each request. For a large project, this can get problematic especially when you have to send the transitive dependencies. Besides, what is gained by having the user have to arrange this copying themselves rather than the current method of sending it as part of the compile process? For example, distributed C/C++ compilers send the preprocessed source to the worker nodes, so they don't have to have the source or the same include files, we currently send the AST which is a representation of the source, etc. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
I forgot about that nuance of your proposal. I like. @jat: the stack idea is nifty, but expanding the scope of the patch even worse than I am. And JL's proposal would let one implement that. On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca wrote: > I still think my proposal solves this for both cases. We add a protected > createHandlerManager, which is more restrictive because it is only called > once per widget. > > We also make getHandlerManager() protected, which allows users to replace > the HandlerManager if they really want to by overriding getHandlerManager to > return one of many. It would be up to the developer to add a > setHandlerManager() method in their own widgets that would change the return > value of getHandlerManager(), so its intentionally more difficult and > therefore forces the developer to think about it a little more. > > Thanks, > John LaBanca > jlaba...@google.com > > > On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken < > sven.brun...@googlemail.com> wrote: > >> >> >> On 10 Feb., 16:28, Ray Ryan wrote: >> > Sven, you're arguing both sides here. You want things to be more >> > customizable in general, but with your specific patch you're trying to >> be as >> > restrictive as you can to achieve your personal goal. >> >> Both patches have the same restriction, once a handlermanager is set >> or the default one created, there is no way back to change it. I am >> also ok with a setHandlerManager without restrictions. But than people >> will have the problem that they will loose handlerregistrations, if >> they dont know what they are doing (and yes, there are these people). >> I wanted to make this patch as much fool proof as possible. It should >> be customaziable, but in a way, that you cannot brake it. >> >> I dont think that you really need to change the handlermanager during >> runtime after you set the first one. You also cannot change the >> element of a widget once you set the first one. >> >> > >> > I'm assuming that if we provide an unrestricted setHandlerManager we >> would >> > also provide a getHandlerManager. It doesn't seem like rocket science to >> > expect someone to check for an existing one if before clobbering it. I'm >> > also assuming that these methods are protected, not part of every >> widget's >> > public api. >> Yes sure, protected. They should not be public. >> >> > >> > I also would argue against providing both createHM and setHM. Redundant >> API >> > is confusing API, another unfortunate trait of our widget set. Lazy >> creation >> > can happen in the default implementation of getHM. A custom widget >> author >> > could override that method to maintain laziness, or call setHM from >> their >> > constructor to keep ours from ever seeing the light of day. >> >> I dont want to add boths. There is no need for it. One approach is >> more than sufficient. With both ways you would be able to change the >> default handlermanager (which is the goal in the end). >> > >> > On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken < >> sven.brun...@googlemail.com>wrote: >> > >> > >> > >> > > The danger is that if you add handlers, and than later in your code >> > > call setHandlerManager with a new HandlerManager. If we dont check for >> > > a prior existing HandlerManager, all old HandlerRegistration's will be >> > > lost. If you dont know what happened, you will search forever why your >> > > old handlers are not working. >> > >> > > You wont have the problem with a createHandlerManager method. >> > >> > > On 9 Feb., 17:55, Ray Ryan wrote: >> > > > If you're right that swapping HMs midstream is a bad idea, I think >> you >> > > need >> > > > a better argument than "it's a bad idea." What's the actual danger? >> If >> > > I'm >> > > > making my own HM I'm already pretty savvy. Why tie my hands? >> > >> > > > But yes, if you win that point, I agree with the change to replace >> > > setHM(HM) >> > > > with HM createHM() >> > >> > > -- >> > >http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > >> > -- >> > I wish this were a Wave >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RFC: sharded linking
there's a fairly large repository based elephant in the room named maven. On Feb 10, 2010, at 7:58 AM, John Tamplin wrote: > On Wed, Feb 10, 2010 at 10:45 AM, Lex Spoon wrote: > What you describe, Alex, is available via the "Compiler" entry point, though > it hasn't been particularly well documented. There is a > PermutationWorkerFactory that can create CompilePerms workers. The default > worker factory spawns Java VMs on the same machine, but it is possible to > write a replacement worker that uses ssh or whatnot to do the work on a > separate machine. The way to plug in a replacement worker factory is to set > the Java property gwt.jjs.permutationWorkerFactory . > > > That said, I thought the reason for existence of Precompile, CompilePerms, > and Link is to get the best build time but at the expense of needing extra > configuration. We are finding that by spending a few seconds copying source > code over, we save 10+ minutes in Precompile and 10+ minutes in Link. > > Is copying source code so inconvenient that it would be worth having a slower > build? I would have thought any of the following would work to move source > code from one machine to another: > > 1. rsync > 2. jar + scp > 3. "svn up" on the slave machines > > Do any of those seem practical for your situation, Alex? > > Overall, it's easy to provide an extra build staging as an option, but we > support a number of build stagings already > > What does make it difficult is that you can't have a pool of worker machines > that can build any project that are asked of them without copying the sources > to the worker for each request. For a large project, this can get > problematic especially when you have to send the transitive dependencies. > > Besides, what is gained by having the user have to arrange this copying > themselves rather than the current method of sending it as part of the > compile process? For example, distributed C/C++ compilers send the > preprocessed source to the worker nodes, so they don't have to have the > source or the same include files, we currently send the AST which is a > representation of the source, etc. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7542 committed - Adding null checks to all History methods to ensure that History is en...
Revision: 7542
Author: gwt.mirror...@gmail.com
Date: Wed Feb 10 08:08:40 2010
Log: Adding null checks to all History methods to ensure that History is
enabled.
http://gwt-code-reviews.appspot.com/138805
http://code.google.com/p/google-web-toolkit/source/detail?r=7542
Added:
/trunk/user/test/com/google/gwt/user/HistoryDisabledTest.gwt.xml
/trunk/user/test/com/google/gwt/user/client/HistoryDisabledTest.java
/trunk/user/test/com/google/gwt/user/client/impl
/trunk/user/test/com/google/gwt/user/client/impl/HistoryImplDisabled.java
Modified:
/trunk/user/src/com/google/gwt/user/client/History.java
/trunk/user/test/com/google/gwt/user/UISuite.java
===
--- /dev/null
+++ /trunk/user/test/com/google/gwt/user/HistoryDisabledTest.gwt.xml Wed
Feb 10 08:08:40 2010
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ class="com.google.gwt.user.client.impl.HistoryImplDisabled">
+
+
+
===
--- /dev/null
+++ /trunk/user/test/com/google/gwt/user/client/HistoryDisabledTest.java
Wed Feb 10 08:08:40 2010
@@ -0,0 +1,90 @@
+/*
+ * 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.user.client;
+
+import com.google.gwt.event.logical.shared.ValueChangeEvent;
+import com.google.gwt.event.logical.shared.ValueChangeHandler;
+import com.google.gwt.event.shared.HandlerRegistration;
+import com.google.gwt.junit.client.GWTTestCase;
+
+/**
+ * Tests for {...@link History} when History is disabled. Most of these tests
are
+ * just assuring that we don't hit an NPE or JS error.
+ */
+public class HistoryDisabledTest extends GWTTestCase {
+
+ @Override
+ public String getModuleName() {
+return "com.google.gwt.user.HistoryDisabledTest";
+ }
+
+ @SuppressWarnings("deprecation")
+ public void testAddHistoryListener() {
+HistoryListener listener = new HistoryListener() {
+ public void onHistoryChanged(String historyToken) {
+ }
+};
+History.addHistoryListener(listener);
+History.removeHistoryListener(listener);
+ }
+
+ public void testAddValueChangeHandler() {
+HandlerRegistration reg = History.addValueChangeHandler(new
ValueChangeHandler() {
+ public void onValueChange(ValueChangeEvent event) {
+ }
+});
+assertNull(reg);
+ }
+
+ public void testFireCurrentHistoryState() {
+HandlerRegistration reg = History.addValueChangeHandler(new
ValueChangeHandler() {
+ public void onValueChange(ValueChangeEvent event) {
+fail("Handler should not have been added.");
+ }
+});
+assertNull(reg);
+History.fireCurrentHistoryState();
+ }
+
+ @SuppressWarnings("deprecation")
+ public void testOnHistoryChanged() {
+HandlerRegistration reg = History.addValueChangeHandler(new
ValueChangeHandler() {
+ public void onValueChange(ValueChangeEvent event) {
+fail("Handler should not have been added.");
+ }
+});
+assertNull(reg);
+History.onHistoryChanged("test");
+ }
+
+ public void testGetToken() {
+assertEquals("", History.getToken());
+ }
+
+ public void testNewItem() {
+HandlerRegistration reg = History.addValueChangeHandler(new
ValueChangeHandler() {
+ public void onValueChange(ValueChangeEvent event) {
+fail("Handler should not have been added.");
+ }
+});
+assertNull(reg);
+
+History.newItem("test");
+assertEquals("", History.getToken());
+History.newItem("test", true);
+assertEquals("", History.getToken());
+ }
+}
===
--- /dev/null
+++
/trunk/user/test/com/google/gwt/user/client/impl/HistoryImplDisabled.java
Wed Feb 10 08:08:40 2010
@@ -0,0 +1,26 @@
+/*
+ * 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.user.client.impl;
+
+/**
+ * An implementation of history that is disabled.
+
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
On Wed, Feb 10, 2010 at 10:56 AM, John LaBanca wrote: > We also make getHandlerManager() protected, which allows users to replace > the HandlerManager if they really want to by overriding getHandlerManager to > return one of many. It would be up to the developer to add a > setHandlerManager() method in their own widgets that would change the return > value of getHandlerManager(), so its intentionally more difficult and > therefore forces the developer to think about it a little more. > The javadoc for getHandlerManager would have to say that the result can't be cached and should be called each time you need one. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RFC: sharded linking
On Wed, Feb 10, 2010 at 11:01 AM, James Northrup wrote: > there's a fairly large repository based elephant in the room named maven. > I'm not sure what that has to do with sharding a compile of a GWT application across a build farm. -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7543 committed - HTTPRequest has been deprecated since GWT 1.5 in exchange for RequestB...
Revision: 7543
Author: gwt.mirror...@gmail.com
Date: Wed Feb 10 08:14:42 2010
Log: HTTPRequest has been deprecated since GWT 1.5 in exchange for
RequestBuilder. This patch removes it completely.
http://gwt-code-reviews.appspot.com/139804/show
http://code.google.com/p/google-web-toolkit/source/detail?r=7543
Deleted:
/trunk/user/src/com/google/gwt/user/client/HTTPRequest.java
/trunk/user/src/com/google/gwt/user/client/impl/HTTPRequestImpl.java
/trunk/user/test/com/google/gwt/http/client/HTTPRequestTest.java
Modified:
/trunk/tools/api-checker/config/gwt20_21userApi.conf
/trunk/user/test/com/google/gwt/http/HTTPSuite.java
===
--- /trunk/user/src/com/google/gwt/user/client/HTTPRequest.java Fri Oct 16
14:48:33 2009
+++ /dev/null
@@ -1,125 +0,0 @@
-/*
- * Copyright 2007 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.user.client;
-
-/**
- * This class allows you to make asynchronous HTTP requests to the
originating
- * server.
- *
- * @deprecated As of GWT 1.5, replaced by
- * {...@link com.google.gwt.http.client.RequestBuilder
RequestBuilder}.
- */
-...@deprecated
-public class HTTPRequest {
-
- /**
- * Makes an asynchronous HTTP GET to a remote server.
- *
- * @param url the absolute url to GET
- * @param handler the response handler to be notified when either the
request
- * fails, or is completed successfully
- * @return false if the invocation fails to issue
- */
- public static boolean asyncGet(String url, ResponseTextHandler handler) {
-return asyncGetImpl(null, null, url, handler);
- }
-
- /**
- * Makes an asynchronous HTTP GET to a remote server.
- *
- * @param url the absolute url to GET
- * @param handler the response handler to be notified when either the
request
- * fails, or is completed successfully
- * @return false if the invocation fails to issue
- */
- public static boolean asyncGet(String user, String pwd, String url,
- ResponseTextHandler handler) {
-return asyncGetImpl(user, pwd, url, handler);
- }
-
- /**
- * Makes an asynchronous HTTP POST to a remote server.
- *
- * @param url the absolute url to which the POST data is delivered
- * @param postData the data to post
- * @param handler the response handler to be notified when either the
request
- * fails, or is completed successfully
- * @return false if the invocation fails to issue
- */
- public static boolean asyncPost(String url, String postData,
- ResponseTextHandler handler) {
-return asyncPostImpl(null, null, url, postData, handler);
- }
-
- /**
- * Makes an asynchronous HTTP POST to a remote server.
- *
- * @param url the absolute url to which the POST data is delivered
- * @param postData the data to post
- * @param handler the response handler to be notified when either the
request
- * fails, or is completed successfully
- * @return false if the invocation fails to issue
- */
- public static boolean asyncPost(String user, String pwd, String url,
- String postData, ResponseTextHandler handler) {
-return asyncPostImpl(user, pwd, url, postData, handler);
- }
-
- private static native boolean asyncGetImpl(String user, String pwd,
String url,
- ResponseTextHandler handler) /*-{
-var xmlHttp = @com.google.gwt.xhr.client.XMLHttpRequest::create()();
-try {
- xmlHttp.open("GET", url, true);
- xmlHttp.setRequestHeader("Content-Type", "text/plain;
charset=utf-8");
- xmlHttp.onreadystatechange = $entry(function() {
-if (xmlHttp.readyState == 4) {
- $wnd.setTimeout(function() {
-xmlHttp.onreadystatechange =
@com.google.gwt.user.client.impl.HTTPRequestImpl::nullFunc;
- }, 0);
-
handl...@com.google.gwt.user.client.responsetexthandler::onCompletion(Ljava/lang/String;)(xmlHttp.responseText
|| "");
-}
- });
- xmlHttp.send('');
- return true;
-} catch (e) {
- xmlHttp.onreadystatechange =
@com.google.gwt.user.client.impl.HTTPRequestImpl::nullFunc;
- return false;
-}
- }-*/;
-
- private static native boolean asyncPostImpl(String user, String pwd,
String url,
- String postData, ResponseTextHandler handler) /*-{
-var xmlHttp = @com.google.gwt.xhr.client.XMLHttpRequest::create()();
-try {
- xmlHttp.open("POST", url, true);
-
[gwt-contrib] [google-web-toolkit] r7544 committed - tr...@7542 was merged into this branch...
Revision: 7544
Author: jlaba...@google.com
Date: Wed Feb 10 08:16:46 2010
Log: tr...@7542 was merged into this branch
Adding null checks to all History methods to ensure that History is
enabled.
svn merge -c7542 --ignore-ancestry
https://google-web-toolkit.googlecode.com/svn/trunk
http://code.google.com/p/google-web-toolkit/source/detail?r=7544
Added:
/releases/2.0/user/test/com/google/gwt/user/HistoryDisabledTest.gwt.xml
/releases/2.0/user/test/com/google/gwt/user/client/HistoryDisabledTest.java
/releases/2.0/user/test/com/google/gwt/user/client/impl
/releases/2.0/user/test/com/google/gwt/user/client/impl/HistoryImplDisabled.java
Modified:
/releases/2.0/branch-info.txt
/releases/2.0/user/src/com/google/gwt/user/client/History.java
/releases/2.0/user/test/com/google/gwt/user/UISuite.java
===
--- /dev/null
+++ /releases/2.0/user/test/com/google/gwt/user/HistoryDisabledTest.gwt.xml
Wed Feb 10 08:16:46 2010
@@ -0,0 +1,22 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ class="com.google.gwt.user.client.impl.HistoryImplDisabled">
+
+
+
===
--- /dev/null
+++
/releases/2.0/user/test/com/google/gwt/user/client/HistoryDisabledTest.java
Wed Feb 10 08:16:46 2010
@@ -0,0 +1,90 @@
+/*
+ * 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.user.client;
+
+import com.google.gwt.event.logical.shared.ValueChangeEvent;
+import com.google.gwt.event.logical.shared.ValueChangeHandler;
+import com.google.gwt.event.shared.HandlerRegistration;
+import com.google.gwt.junit.client.GWTTestCase;
+
+/**
+ * Tests for {...@link History} when History is disabled. Most of these tests
are
+ * just assuring that we don't hit an NPE or JS error.
+ */
+public class HistoryDisabledTest extends GWTTestCase {
+
+ @Override
+ public String getModuleName() {
+return "com.google.gwt.user.HistoryDisabledTest";
+ }
+
+ @SuppressWarnings("deprecation")
+ public void testAddHistoryListener() {
+HistoryListener listener = new HistoryListener() {
+ public void onHistoryChanged(String historyToken) {
+ }
+};
+History.addHistoryListener(listener);
+History.removeHistoryListener(listener);
+ }
+
+ public void testAddValueChangeHandler() {
+HandlerRegistration reg = History.addValueChangeHandler(new
ValueChangeHandler() {
+ public void onValueChange(ValueChangeEvent event) {
+ }
+});
+assertNull(reg);
+ }
+
+ public void testFireCurrentHistoryState() {
+HandlerRegistration reg = History.addValueChangeHandler(new
ValueChangeHandler() {
+ public void onValueChange(ValueChangeEvent event) {
+fail("Handler should not have been added.");
+ }
+});
+assertNull(reg);
+History.fireCurrentHistoryState();
+ }
+
+ @SuppressWarnings("deprecation")
+ public void testOnHistoryChanged() {
+HandlerRegistration reg = History.addValueChangeHandler(new
ValueChangeHandler() {
+ public void onValueChange(ValueChangeEvent event) {
+fail("Handler should not have been added.");
+ }
+});
+assertNull(reg);
+History.onHistoryChanged("test");
+ }
+
+ public void testGetToken() {
+assertEquals("", History.getToken());
+ }
+
+ public void testNewItem() {
+HandlerRegistration reg = History.addValueChangeHandler(new
ValueChangeHandler() {
+ public void onValueChange(ValueChangeEvent event) {
+fail("Handler should not have been added.");
+ }
+});
+assertNull(reg);
+
+History.newItem("test");
+assertEquals("", History.getToken());
+History.newItem("test", true);
+assertEquals("", History.getToken());
+ }
+}
===
--- /dev/null
+++
/releases/2.0/user/test/com/google/gwt/user/client/impl/HistoryImplDisabled.java
Wed Feb 10 08:16:46 2010
@@ -0,0 +1,26 @@
+/*
+ * 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 spe
Re: [gwt-contrib] Proposed API Change - Remove HTTPRequest
The beast has been slain as of r7543: http://code.google.com/p/google-web-toolkit/source/detail?r=7543 Thanks, John LaBanca jlaba...@google.com On Thu, Feb 4, 2010 at 5:28 PM, Ray Ryan wrote: > Kill it! KI ITTT! > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7545 committed - add window.resize{By,To} and window.move{By,To}. Modify LayoutTest to ...
Revision: 7545
Author: gwt.mirror...@gmail.com
Date: Wed Feb 10 08:19:52 2010
Log: add window.resize{By,To} and window.move{By,To}. Modify LayoutTest to
use the
new Window.resizeTo.
Note the TestResizeHandler does not fire on resize. Need to investigate.
http://code.google.com/p/google-web-toolkit/source/detail?r=7545
Modified:
/trunk/user/src/com/google/gwt/user/client/Window.java
/trunk/user/test/com/google/gwt/layout/client/LayoutTest.java
/trunk/user/test/com/google/gwt/user/client/WindowTest.java
===
--- /trunk/user/src/com/google/gwt/user/client/Window.java Fri Nov 20
06:32:19 2009
+++ /trunk/user/src/com/google/gwt/user/client/Window.java Wed Feb 10
08:19:52 2010
@@ -670,6 +670,37 @@
return $doc.title;
}-*/;
+ /**
+ * Moves a window's left and top edge to a specified number of pixels
relative
+ * to its current coordinates.
+ *
+ * NOTE: In Chrome, this method only works with windows created by
+ * Window.open().
+ *
+ *
+ * @param dx A positive or a negative number that specifies how many
pixels
+ * to move the left edge by
+ * @param dy A positive or a negative number that specifies how many
+ * pixels to move the top edge by
+ */
+ public static native void moveBy(int dx, int dy) /*-{
+$wnd.moveBy(dx, dy);
+ }-*/;
+
+ /**
+ * Moves a window's left and top edge to the specified coordinates.
+ *
+ * NOTE: In Chrome, this method only works with windows created by
+ * Window.open().
+ *
+ *
+ * @param x The left coordinate
+ * @param y The top coordinate
+ */
+ public static native void moveTo(int x, int y) /*-{
+$wnd.moveTo(x, y);
+ }-*/;
+
/**
* Opens a new browser window. The "name" and "features" arguments are
* specifiedpublic static void removeWindowScrollListener(WindowScrollListener
listener) {
BaseListenerWrapper.WrapWindowScroll.remove(handlers, listener);
}
+
+ /**
+ * Resizes the window by the specified width and height. This method
moves the
+ * bottom right corner of the window by the specified number of pixels
+ * defined. The top left corner will not be moved (it stays in its
original
+ * coordinates).
+ *
+ * NOTE: In Chrome, this method only works with windows created by
+ * Window.open().
+ *
+ *
+ * @param width A positive or a negative number that specifies how many
pixels
+ * to resize the width by
+ * @param height A positive or a negative number that specifies how many
+ * pixels to resize the height by
+ */
+ public static native void resizeBy(int width, int height) /*-{
+$wnd.resizeBy(width, height);
+ }-*/;
+
+ /**
+ * Resizes the window to the specified width and height.
+ *
+ * NOTE: In Chrome, this method only works with windows created by
+ * Window.open().
+ *
+ *
+ * @param width The width of the window, in pixels
+ * @param height The height of the window, in pixels
+ */
+ public static native void resizeTo(int width, int height) /*-{
+$wnd.resizeTo(width, height);
+ }-*/;
/**
* Scroll the window to the specified position.
===
--- /trunk/user/test/com/google/gwt/layout/client/LayoutTest.java Mon Jan
25 08:52:17 2010
+++ /trunk/user/test/com/google/gwt/layout/client/LayoutTest.java Wed Feb
10 08:19:52 2010
@@ -36,6 +36,7 @@
import com.google.gwt.layout.client.Layout.Alignment;
import com.google.gwt.layout.client.Layout.Layer;
import com.google.gwt.user.client.Window;
+import com.google.gwt.user.client.WindowTest;
/**
* Tests for the {...@link Layout} class.
@@ -421,6 +422,9 @@
@Override
protected void gwtSetUp() throws Exception {
+// ensure enough sizes for this test
+WindowTest.ResizeHelper.resizeTo(800, 600);
+
Window.enableScrolling(false);
Document doc = Document.get();
@@ -445,6 +449,7 @@
Window.enableScrolling(true);
Document.get().getBody().removeChild(parent);
layout.onDetach();
+WindowTest.ResizeHelper.restoreSize();
}
private void assertLeftRightTopBottomUnitsMakeSense(Element elem) {
===
--- /trunk/user/test/com/google/gwt/user/client/WindowTest.java Wed Nov 18
14:56:30 2009
+++ /trunk/user/test/com/google/gwt/user/client/WindowTest.java Wed Feb 10
08:19:52 2010
@@ -17,6 +17,8 @@
import com.google.gwt.core.client.JavaScriptException;
import com.google.gwt.event.logical.shared.ResizeEvent;
+import com.google.gwt.event.logical.shared.ResizeHandler;
+import com.google.gwt.event.shared.HandlerRegistration;
import com.google.gwt.http.client.UrlBuilder;
import com.google.gwt.junit.DoNotRunWith;
import com.google.gwt.junit.Platform;
@@ -226,6 +228,164 @@
}
});
}
+
+ /**
+ * Calculates the sizes for Window extras such as border, menu, tool
bar, and
+ * stores the original sizes to restore at the end of test.
+ */
+ public static f
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
@John: hm2 could indeed handle onOpen and hm1 would never get a chance to notify its registered handlers :( So I'd gues the event has to be pushed down in all cases ... which pretty much takes us to "one" HM setup. I also think that createHM is enough. In general, though components usually have setters/getters for their properties, a good API makes obvious where the developer has to interveene (in the setters or getters) in order to customize. In particular, if we had a createHM, wouldn't it defy the purpose to have an (overridable) getHM. In other words, why not have getHM replace the createHM? Andi On Wed, Feb 10, 2010 at 10:54 AM, John Tamplin wrote: > On Wed, Feb 10, 2010 at 10:27 AM, Andi Mullaraj wrote: > >> I believe changing HMs mid stream is dangerous: >> >> 1. Say your (nav & edit) widget fires events that are common to both modes >> (i.e. a simple onOpen) and the widget is by default in nav mode >> 2 Say A registers an onOpen handler (which gets added to hm1 -- the >> default HM) then later switches to edit mode (and hm2 kicks in) >> 3. A will not see the onOpen events while on edit mode! >> >> If your nav & edit widet stays always in one mode, then createHM would do >> the trick. But if it switches modes you have to make sure there is no >> overlapping sets of events ... >> > > Another option to achieve this with potentially less danger is to maintain > a stack of HandlerManagers. If one HM doesn't handle an event, it goes down > to the next one. Then, if you want to have some modal event handling logic, > you push a new HM on the stack with its own set of event handlers. When you > are done with the modal logic, you pop it off the stack. Event types not > handled by the modal event handler fall through to the main one, so in your > example onOpen would still get handled properly. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Proposed API Change - Remove HTTPRequest
Huzzah! On Feb 10, 2010 8:20 AM, "John LaBanca" wrote: The beast has been slain as of r7543: http://code.google.com/p/google-web-toolkit/source/detail?r=7543 Thanks, John LaBanca jlaba...@google.com On Thu, Feb 4, 2010 at 5:28 PM, Ray Ryan wrote: > Kill it! KI ITTT! > > > > > > -- > > 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: Adds hovering style to StackLayoutPanel (issue 4561).
LGTM http://gwt-code-reviews.appspot.com/143801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: RFC: sharded linking
i'm only chiming in on the 3 letters RFC in the topic. the usecases being described as a point of deliberation, defining dependancies, repository access, and bundling automation, are well solved items in the maven stable. how hard can it be to define a multiproject descriptor, assign "channels" of build-stage progression, and have a top-level project build coordinated by one maven instance publish artifacts to sucessive build-channels served elsewhere by daemons which trigger maven sub-builds? even if a GWT build is not in itself a maven project, there's very few reasons why a synthetic maven pom cannot be fashioned for a build-node graph to unify conventions of scm, artifact, versioning, and build hooks to prior documented art and tools. On Feb 10, 2010, at 8:12 AM, John Tamplin wrote: > On Wed, Feb 10, 2010 at 11:01 AM, James Northrup > wrote: > there's a fairly large repository based elephant in the room named maven. > > I'm not sure what that has to do with sharding a compile of a GWT application > across a build farm. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7546 committed - Received Sven Brunken's CLA electronically.
Revision: 7546 Author: jlaba...@google.com Date: Wed Feb 10 08:33:13 2010 Log: Received Sven Brunken's CLA electronically. http://code.google.com/p/google-web-toolkit/source/detail?r=7546 Modified: /CLA-SIGNERS === --- /CLA-SIGNERSWed Feb 3 13:33:59 2010 +++ /CLA-SIGNERSWed Feb 10 08:33:13 2010 @@ -23,5 +23,6 @@ sandymac (William Alexander McArthur, Jr) saschah (Sascha Haeberling) spacelenny (David Evans) +sven.brun...@googlemail.com (Sven Brunken) t.bro...@gmail.com (Thomas Broyer) rich...@zschech.net (Richard Zschech) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Add the ability to change the default HandlerManager of a Widget
The argument seems to revolve around changing HandlerManagers resulting in the loss of registered handlers. Is it possible that the HandlerManager and the set of registered handlers aren't really the same thing and need to be separated? Would everyone be happy if you could call setHandlerManager() and the new manager would still service the same set of handlers that existed previously? On Wed, Feb 10, 2010 at 10:59 AM, Ray Ryan wrote: > I forgot about that nuance of your proposal. I like. > @jat: the stack idea is nifty, but expanding the scope of the patch even > worse than I am. And JL's proposal would let one implement that. > > On Wed, Feb 10, 2010 at 7:56 AM, John LaBanca wrote: >> >> I still think my proposal solves this for both cases. We add a protected >> createHandlerManager, which is more restrictive because it is only called >> once per widget. >> We also make getHandlerManager() protected, which allows users to replace >> the HandlerManager if they really want to by overriding getHandlerManager to >> return one of many. It would be up to the developer to add a >> setHandlerManager() method in their own widgets that would change the return >> value of getHandlerManager(), so its intentionally more difficult and >> therefore forces the developer to think about it a little more. >> Thanks, >> John LaBanca >> jlaba...@google.com >> >> >> On Wed, Feb 10, 2010 at 10:44 AM, Sven Brunken >> wrote: >>> >>> >>> On 10 Feb., 16:28, Ray Ryan wrote: >>> > Sven, you're arguing both sides here. You want things to be more >>> > customizable in general, but with your specific patch you're trying to >>> > be as >>> > restrictive as you can to achieve your personal goal. >>> >>> Both patches have the same restriction, once a handlermanager is set >>> or the default one created, there is no way back to change it. I am >>> also ok with a setHandlerManager without restrictions. But than people >>> will have the problem that they will loose handlerregistrations, if >>> they dont know what they are doing (and yes, there are these people). >>> I wanted to make this patch as much fool proof as possible. It should >>> be customaziable, but in a way, that you cannot brake it. >>> >>> I dont think that you really need to change the handlermanager during >>> runtime after you set the first one. You also cannot change the >>> element of a widget once you set the first one. >>> >>> > >>> > I'm assuming that if we provide an unrestricted setHandlerManager we >>> > would >>> > also provide a getHandlerManager. It doesn't seem like rocket science >>> > to >>> > expect someone to check for an existing one if before clobbering it. >>> > I'm >>> > also assuming that these methods are protected, not part of every >>> > widget's >>> > public api. >>> Yes sure, protected. They should not be public. >>> >>> > >>> > I also would argue against providing both createHM and setHM. Redundant >>> > API >>> > is confusing API, another unfortunate trait of our widget set. Lazy >>> > creation >>> > can happen in the default implementation of getHM. A custom widget >>> > author >>> > could override that method to maintain laziness, or call setHM from >>> > their >>> > constructor to keep ours from ever seeing the light of day. >>> >>> I dont want to add boths. There is no need for it. One approach is >>> more than sufficient. With both ways you would be able to change the >>> default handlermanager (which is the goal in the end). >>> > >>> > On Tue, Feb 9, 2010 at 9:11 AM, Sven Brunken >>> > wrote: >>> > >>> > >>> > >>> > > The danger is that if you add handlers, and than later in your code >>> > > call setHandlerManager with a new HandlerManager. If we dont check >>> > > for >>> > > a prior existing HandlerManager, all old HandlerRegistration's will >>> > > be >>> > > lost. If you dont know what happened, you will search forever why >>> > > your >>> > > old handlers are not working. >>> > >>> > > You wont have the problem with a createHandlerManager method. >>> > >>> > > On 9 Feb., 17:55, Ray Ryan wrote: >>> > > > If you're right that swapping HMs midstream is a bad idea, I think >>> > > > you >>> > > need >>> > > > a better argument than "it's a bad idea." What's the actual danger? >>> > > > If >>> > > I'm >>> > > > making my own HM I'm already pretty savvy. Why tie my hands? >>> > >>> > > > But yes, if you win that point, I agree with the change to replace >>> > > setHM(HM) >>> > > > with HM createHM() >>> > >>> > > -- >>> > >http://groups.google.com/group/Google-Web-Toolkit-Contributors >>> > >>> > -- >>> > I wish this were a Wave >>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > > > -- > I wish this were a Wave > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Use cellIndex and sectionRowIndex in HTMLTable::getCellForEvent
On 2010/02/09 10:01:28, tbroyer wrote: Ping! ;-) I just updated the patch to account for recent changes to trunk, and am running tests now. http://gwt-code-reviews.appspot.com/125806 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Trivial fix for issue 3956 ("REGRESSION: r5292 broke Opera support for History")
On 2010/02/09 10:02:48, tbroyer wrote: Ping! Thanks. It seems to work fine locally. Running full tests now (very doubtful anything will fail). http://gwt-code-reviews.appspot.com/126812 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Use cellIndex and sectionRowIndex in HTMLTable::getCellForEvent
http://gwt-code-reviews.appspot.com/125806/diff/1/4 File user/src/com/google/gwt/user/client/ui/HTMLTable.java (right): http://gwt-code-reviews.appspot.com/125806/diff/1/4#newcode251 Line 251: UIObject.setStylePrimaryName(getRawElement(row, column), You need some kind of check here before calling getRawElement. Since we call prepareCell in setStyleName, you should call prepareCell here. http://gwt-code-reviews.appspot.com/125806 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix for KeyPressEvent.getCharCode and overall key events improvements
Looks good, but I'm going to test it carefully before submitting.
http://gwt-code-reviews.appspot.com/142801/diff/1/4
File user/src/com/google/gwt/event/dom/client/KeyPressEvent.java
(right):
http://gwt-code-reviews.appspot.com/142801/diff/1/4#newcode66
Line 66: public int getNativeCharCode() {
I don't think we need to add this method since it does the same thing as
getCharCode().
http://gwt-code-reviews.appspot.com/142801
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix for KeyPressEvent.getCharCode and overall key events improvements
http://gwt-code-reviews.appspot.com/142801/diff/1/4
File user/src/com/google/gwt/event/dom/client/KeyPressEvent.java
(right):
http://gwt-code-reviews.appspot.com/142801/diff/1/4#newcode66
Line 66: public int getNativeCharCode() {
On 2010/02/10 17:04:43, jlabanca wrote:
I don't think we need to add this method since it does the same thing
as
getCharCode().
It returns an int, rather than char -- non-BMP characters are encoded as
two Java chars using surrogate pairs, or one int as a Unicode codepoint.
http://gwt-code-reviews.appspot.com/142801
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix for KeyPressEvent.getCharCode and overall key events improvements
On 2010/02/10 17:04:43, jlabanca wrote:
Looks good, but I'm going to test it carefully before submitting.
http://gwt-code-reviews.appspot.com/142801/diff/1/4
File user/src/com/google/gwt/event/dom/client/KeyPressEvent.java
(right):
http://gwt-code-reviews.appspot.com/142801/diff/1/4#newcode66
Line 66: public int getNativeCharCode() {
I don't think we need to add this method since it does the same thing
as
getCharCode().
The first message on the linked thread suggests that the W3C "has
finally settled" on a standard for keyboard events. The lack of such a
standard is one reason this stuff is such a mess in the first place.
Does anyone know where this is specified? Last time I looked (and PPK
seems to confirm this), there was no standard for these properties.
It would also be really helpful to add a few tests. That would also help
illuminate the expected behavior, which is kind of difficult to follow
at present. We now have Document.create*Event() and
Element.dispatchEvent(), which I believe makes this tractable.
http://gwt-code-reviews.appspot.com/142801
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Trivial fix for issue 3956 ("REGRESSION: r5292 broke Opera support for History")
LGTM http://gwt-code-reviews.appspot.com/126812 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7548 committed - Fixes a bug where switch(this) doesn't work if the type...
Revision: 7548
Author: sp...@google.com
Date: Tue Feb 9 11:36:21 2010
Log: Fixes a bug where switch(this) doesn't work if the type
of this is a non-null enum type.
http://code.google.com/p/google-web-toolkit/source/detail?r=7548
Modified:
/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
/trunk/user/test/com/google/gwt/dev/jjs/test/CompilerTest.java
===
--- /trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
Mon Feb 8 08:29:30 2010
+++ /trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
Tue Feb 9 11:36:21 2010
@@ -1783,7 +1783,7 @@
JStatement processStatement(SwitchStatement x) {
SourceInfo info = makeSourceInfo(x);
JExpression expression = dispProcessExpression(x.expression);
- if (expression.getType() instanceof JClassType) {
+ if (isEnumType(expression.getType())) {
// Must be an enum; synthesize a call to ordinal().
expression = new JMethodCall(info, expression,
program.getIndexedMethod("Enum.ordinal"));
@@ -2401,6 +2401,24 @@
"Could not determine the desired box type");
}
}
+
+/**
+ * Check whether the specified type is definitely for an enum class.
+ *
+ * @param type The type being tested
+ * @return whether it is certainly an enum
+ */
+private boolean isEnumType(JType type) {
+ if (type instanceof JClassType) {
+return ((JClassType) type).isEnumOrSubclass() != null;
+ }
+
+ if (type instanceof JNonNullType) {
+return isEnumType(((JNonNullType) type).getUnderlyingType());
+ }
+
+ return false;
+}
private SourceInfo makeSourceInfo(Statement x) {
int startLine = Util.getLineNumber(x.sourceStart,
===
--- /trunk/user/test/com/google/gwt/dev/jjs/test/CompilerTest.java Mon Jun
15 17:51:24 2009
+++ /trunk/user/test/com/google/gwt/dev/jjs/test/CompilerTest.java Tue Feb
9 11:36:21 2010
@@ -66,6 +66,25 @@
private interface Bm2Listener extends
EventListener {
int handleEvent(E be);
}
+
+ /**
+ * Used in {...@link #testSwitchOnEnumTypedThis()}.
+ */
+ private static enum ChangeDirection {
+NEGATIVE, POSITIVE;
+
+public String getText() {
+ switch (this) {
+case POSITIVE:
+ return "POSITIVE";
+case NEGATIVE:
+ return "NEGATIVE";
+default:
+ throw new IllegalArgumentException("Unhandled change direction: "
+ + this);
+ }
+}
+ }
private static class ConcreteSub extends AbstractSuper {
public static String foo() {
@@ -1065,7 +1084,12 @@
public void testSubclassStaticInnerAndClinitOrdering() {
new CheckSubclassStaticInnerAndClinitOrdering();
}
-
+
+ public void testSwitchOnEnumTypedThis() {
+assertEquals("POSITIVE", ChangeDirection.POSITIVE.getText());
+assertEquals("NEGATIVE", ChangeDirection.NEGATIVE.getText());
+ }
+
public void testSwitchStatement() {
switch (0) {
case 0:
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7549 committed - Use JAnnotation API for ArtificialRescue...
Revision: 7549
Author: b...@google.com
Date: Wed Feb 10 02:57:10 2010
Log: Use JAnnotation API for ArtificialRescue
Patch by: bobv
Review by: scottb
http://code.google.com/p/google-web-toolkit/source/detail?r=7549
Added:
/trunk/dev/core/src/com/google/gwt/dev/jjs/ArtificialRescueRecorder.java
Modified:
/trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java
/trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JAnnotation.java
/trunk/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
/trunk/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaAST.java
===
--- /dev/null
+++
/trunk/dev/core/src/com/google/gwt/dev/jjs/ArtificialRescueRecorder.java
Wed Feb 10 02:57:10 2010
@@ -0,0 +1,138 @@
+/*
+ * 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.dev.jjs;
+
+import com.google.gwt.core.client.impl.ArtificialRescue;
+import com.google.gwt.core.client.impl.ArtificialRescue.Rescue;
+import com.google.gwt.dev.jjs.ast.Context;
+import com.google.gwt.dev.jjs.ast.HasEnclosingType;
+import com.google.gwt.dev.jjs.ast.JAnnotation;
+import com.google.gwt.dev.jjs.ast.JDeclaredType;
+import com.google.gwt.dev.jjs.ast.JField;
+import com.google.gwt.dev.jjs.ast.JNode;
+import com.google.gwt.dev.jjs.ast.JProgram;
+import com.google.gwt.dev.jjs.ast.JReferenceType;
+import com.google.gwt.dev.jjs.ast.JVisitor;
+import com.google.gwt.dev.jjs.impl.JsniRefLookup;
+import com.google.gwt.dev.util.JsniRef;
+
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
+/**
+ * Process ArtificialRescue annotations.
+ */
+public class ArtificialRescueRecorder {
+ private class Recorder extends JVisitor {
+private JDeclaredType currentClass;
+
+@Override
+public void endVisit(JAnnotation x, Context ctx) {
+ if (x.getType() == artificialRescueType) {
+ArtificialRescue annotation = JAnnotation.createAnnotation(
+ArtificialRescue.class, x);
+for (Rescue rescue : annotation.value()) {
+ process(rescue);
+}
+ }
+}
+
+@Override
+public void endVisit(JDeclaredType x, Context ctx) {
+ assert currentClass == x;
+}
+
+@Override
+public boolean visit(JDeclaredType x, Context ctx) {
+ currentClass = x;
+
+ /*
+ * We only care about annotations declared on the type itself, so we
can
+ * skip the traversal of fields and methods.
+ */
+ accept(x.getAnnotations());
+ return false;
+}
+
+private void process(Rescue rescue) {
+ assert rescue != null : "rescue";
+
+ String typeName = rescue.className();
+ JReferenceType classType = (JReferenceType)
program.getTypeFromJsniRef(typeName);
+ String[] fields = rescue.fields();
+ boolean instantiable = rescue.instantiable();
+ String[] methods = rescue.methods();
+
+ assert classType != null : "classType " + typeName;
+ assert fields != null : "fields";
+ assert methods != null : "methods";
+
+ if (instantiable) {
+currentClass.addArtificialRescue(classType);
+
+// Make sure that a class literal for the type has been allocated
+program.getLiteralClass(classType);
+ }
+
+ if (classType instanceof JDeclaredType) {
+List toRescue = new ArrayList();
+Collections.addAll(toRescue, fields);
+Collections.addAll(toRescue, methods);
+
+for (String name : toRescue) {
+ JsniRef ref = JsniRef.parse("@" + classType.getName() + "::" +
name);
+ final String[] errors = {null};
+ HasEnclosingType node = JsniRefLookup.findJsniRefTarget(ref,
program,
+ new JsniRefLookup.ErrorReporter() {
+public void reportError(String error) {
+ errors[0] = error;
+}
+ });
+ if (errors[0] != null) {
+// Should have been caught by ArtificialRescueChecker
+throw new InternalCompilerException(
+"Unable to artificially rescue " + name + ": " +
errors[0]);
+ }
+
+ currentClass.addArtificialRescue((JNode) node);
+ if (node instanceof JField) {
+JField field = (JField) node;
+if (!field.isFinal()) {
+ field.setVolatile();
+}
+ }
+}
+ }
+}
+ }
+
+ public static void exec(JProgra
[gwt-contrib] MenuBar highlight style is not always removed when it loses focus
Reviewers: jgw, Description: When the MenuBar loses focus, the selected item in the topmost MenuBar remains selected. This occurs in any of the following cases: 1. Click an item in a submenu 2. Tab away 3. Close sub menus with escape Fix: We now use some better logic to deselect the top most item. This patch does the following: 1. Adds a blur handler to handle the simple case. 2. Listens for the Tab key to be pressed, just as we do with the Escape key. 3. Does not reselect the parent menu if the child menu was close with autoHide. Testing: === Manually verified extensively on FF, Chrome, IE, and Safari. Also added unit tests and verified that they pass on FF, Chrome, IE, and Safari. Please review this at http://gwt-code-reviews.appspot.com/141804 Affected files: user/src/com/google/gwt/user/client/ui/MenuBar.java user/test/com/google/gwt/user/client/ui/MenuBarTest.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7550 committed - Add prev/next buttons to the paging table...
Revision: 7550
Author: gwt.mirror...@gmail.com
Date: Wed Feb 10 13:26:31 2010
Log: Add prev/next buttons to the paging table
Make 'favorite' and 'notes' fields persist in the app cache
http://code.google.com/p/google-web-toolkit/source/detail?r=7550
Added:
/trunk/bikeshed/src/com/google/gwt/cells/client/CheckboxCell.java
/trunk/bikeshed/src/com/google/gwt/list/client/Column.java
Modified:
/trunk/bikeshed/src/com/google/gwt/cells/client/ButtonCell.java
/trunk/bikeshed/src/com/google/gwt/cells/client/TextCell.java
/trunk/bikeshed/src/com/google/gwt/list/client/PagingTableListView2.java
/trunk/bikeshed/src/com/google/gwt/sample/datawidgets/client/ApplicationCache.java
/trunk/bikeshed/src/com/google/gwt/sample/datawidgets/client/DataBackedWidgets.java
/trunk/bikeshed/src/com/google/gwt/sample/datawidgets/shared/StockQuote.java
===
--- /dev/null
+++ /trunk/bikeshed/src/com/google/gwt/cells/client/CheckboxCell.java Wed
Feb 10 13:26:31 2010
@@ -0,0 +1,45 @@
+/*
+ * 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.cells.client;
+
+import com.google.gwt.dom.client.Element;
+import com.google.gwt.dom.client.InputElement;
+import com.google.gwt.dom.client.NativeEvent;
+
+public class CheckboxCell extends Cell {
+
+ @Override
+ public void render(Boolean data, StringBuilder sb) {
+sb.append("");
+ }
+
+ @Override
+ public void onBrowserEvent(Element parent, Boolean value, NativeEvent
event,
+ Mutator mutator) {
+if (mutator == null) {
+ return;
+}
+
+if ("change".equals(event.getType())) {
+ InputElement input = parent.getFirstChild().cast();
+ mutator.mutate(value, input.isChecked());
+}
+ }
+}
===
--- /dev/null
+++ /trunk/bikeshed/src/com/google/gwt/list/client/Column.java Wed Feb 10
13:26:31 2010
@@ -0,0 +1,40 @@
+/**
+ *
+ */
+package com.google.gwt.list.client;
+
+import com.google.gwt.cells.client.Cell;
+import com.google.gwt.cells.client.Mutator;
+import com.google.gwt.dom.client.Element;
+import com.google.gwt.dom.client.NativeEvent;
+
+public abstract class Column {
+ private final Cell cell;
+ private Mutator mutator;
+
+ public Column(Cell cell) {
+this.cell = cell;
+ }
+
+ public void onBrowserEvent(Element elem, final T object, NativeEvent
event) {
+cell.onBrowserEvent(elem, getValue(object), event, new Mutator()
{
+ public void mutate(C unused, C after) {
+mutator.mutate(object, after);
+ }
+});
+ }
+
+ public void render(T object, StringBuilder sb) {
+cell.render(getValue(object), sb);
+ }
+
+ public void setMutator(Mutator mutator) {
+this.mutator = mutator;
+ }
+
+ protected abstract C getValue(T object);
+
+ protected Cell getCell() {
+return cell;
+ }
+}
===
--- /trunk/bikeshed/src/com/google/gwt/cells/client/ButtonCell.java Tue
Feb 9 11:11:52 2010
+++ /trunk/bikeshed/src/com/google/gwt/cells/client/ButtonCell.java Wed Feb
10 13:26:31 2010
@@ -1,5 +1,23 @@
+/*
+ * 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.cells.client;
+import com.google.gwt.dom.client.Element;
+import com.google.gwt.dom.client.NativeEvent;
+
public class ButtonCell extends Cell {
@Override
@@ -10,4 +28,16 @@
}
sb.append("");
}
-}
+
+ @Override
+ public void onBrowserEvent(Element parent, String value, NativeEvent
event,
+ Mutator mutator) {
+if (mutator == null) {
+ return;
+}
+
+if ("mouseup".equals(event.getType())) {
+ mutator.mutate(value, null);
+}
+ }
+}
===
--- /trunk/bikeshed/src/com/google/gwt/cells/client/TextCell.java Tue Feb
9 11:11:52 2010
+++ /trunk/bikeshed/src/com/google/gwt/cells/client/TextCell.java Wed Feb
10 13:26:31 2010
[gwt-contrib] [google-web-toolkit] r7551 committed - Change RichTextAreaImpl and subclasses to not be coupled to Widget/Ric...
Revision: 7551
Author: gwt.mirror...@gmail.com
Date: Wed Feb 10 06:13:42 2010
Log: Change RichTextAreaImpl and subclasses to not be coupled to
Widget/RichTextArea:
http://gwt-code-reviews.appspot.com/139801
Patch by: sven.brunken
Review by: jlabanca
http://code.google.com/p/google-web-toolkit/source/detail?r=7551
Modified:
/trunk/user/src/com/google/gwt/user/client/ui/RichTextArea.java
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImpl.java
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplIE6.java
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplSafari.java
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplStandard.java
===
--- /trunk/user/src/com/google/gwt/user/client/ui/RichTextArea.java Thu
Feb 4 04:42:51 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/RichTextArea.java Wed Feb
10 06:13:42 2010
@@ -579,7 +579,7 @@
public RichTextArea() {
setElement(impl.getElement());
setStyleName("gwt-RichTextArea");
-impl.setWidget(this);
+impl.setOwner(this);
}
public HandlerRegistration addInitializeHandler(InitializeHandler
handler) {
===
---
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImpl.java
Thu Feb 4 04:42:51 2010
+++
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImpl.java
Wed Feb 10 06:13:42 2010
@@ -15,6 +15,7 @@
*/
package com.google.gwt.user.client.ui.impl;
+import com.google.gwt.event.logical.shared.HasInitializeHandlers;
import com.google.gwt.event.logical.shared.InitializeEvent;
import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Element;
@@ -32,7 +33,7 @@
public class RichTextAreaImpl {
protected Element elem;
- protected RichTextArea richTextWidget;
+ protected HasInitializeHandlers owner;
public RichTextAreaImpl() {
elem = createElement();
@@ -73,13 +74,22 @@
public void setHTML(String html) {
DOM.setElementProperty(elem, "value", html);
}
+
+ public void setOwner(HasInitializeHandlers owner) {
+this.owner = owner;
+ }
public void setText(String text) {
DOM.setElementProperty(elem, "value", text);
}
+ /**
+ * @deprecated as of GWT 2.1, use {...@link
#setOwner(HasInitializeHandlers)}
+ * instead
+ */
+ @Deprecated
public void setWidget(RichTextArea richTextWidget) {
-this.richTextWidget = richTextWidget;
+setOwner(richTextWidget);
}
public void uninitElement() {
@@ -96,8 +106,8 @@
protected void onElementInitialized() {
hookEvents();
-if (richTextWidget != null) {
- InitializeEvent.fire(richTextWidget);
+if (owner != null) {
+ InitializeEvent.fire(owner);
}
}
}
===
---
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplIE6.java
Thu Feb 4 04:42:51 2010
+++
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplIE6.java
Wed Feb 10 06:13:42 2010
@@ -93,10 +93,12 @@
var handler = $entry(function() {
if (elem.__listener) {
-// Weird: this code has the context of the script frame, but we
need the
-// event from the edit iframe's window.
-var evt = elem.contentWindow.event;
-
elem.__listen...@com.google.gwt.user.client.ui.widget::onBrowserEvent(Lcom/google/gwt/user/client/Event;)(evt);
+if
(@com.google.gwt.user.client.impl.DOMImpl::isMyListener(Ljava/lang/Object;)(elem.__listener))
{
+ // Weird: this code has the context of the script frame, but we
need the
+ // event from the edit iframe's window.
+ var evt = elem.contentWindow.event;
+
elem.__listen...@com.google.gwt.user.client.eventlistener::onBrowserEvent(Lcom/google/gwt/user/client/Event;)(evt);
+}
}
});
===
---
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplSafari.java
Thu Jul 16 17:54:03 2009
+++
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplSafari.java
Wed Feb 10 06:13:42 2010
@@ -39,7 +39,9 @@
elem.__gwt_handler = function(evt) {
if (elem.__listener) {
-
elem.__listen...@com.google.gwt.user.client.ui.widget::onBrowserEvent(Lcom/google/gwt/user/client/Event;)(evt);
+if
(@com.google.gwt.user.client.impl.DOMImpl::isMyListener(Ljava/lang/Object;)(elem.__listener))
{
+
elem.__listen...@com.google.gwt.user.client.eventlistener::onBrowserEvent(Lcom/google/gwt/user/client/Event;)(evt);
+}
}
};
===
---
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplStandard.java
Thu Feb 4 04:42:51 2010
+++
/trunk/user/src/com/google/gwt/user/client/ui/impl/RichTextAreaImplStandard.java
Wed Feb 10 06:13:42 2010
@@ -306,7 +306,9 @@
elem.__gwt_handler = $entry(functio
[gwt-contrib] Re: Change RichTextAreaImpl and subclasses to not be coupled to Widget/RichTextArea
committed as r7551 http://gwt-code-reviews.appspot.com/139801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7552 committed - http://gwt-code-reviews.appspot.com/143801
Revision: 7552
Author: j...@google.com
Date: Wed Feb 10 08:44:48 2010
Log: http://gwt-code-reviews.appspot.com/143801
http://code.google.com/p/google-web-toolkit/source/detail?r=7552
Modified:
/trunk/user/src/com/google/gwt/user/client/ui/StackLayoutPanel.java
/trunk/user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css
/trunk/user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css
/trunk/user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark.css
/trunk/user/src/com/google/gwt/user/theme/dark/public/gwt/dark/dark_rtl.css
/trunk/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard.css
/trunk/user/src/com/google/gwt/user/theme/standard/public/gwt/standard/standard_rtl.css
===
--- /trunk/user/src/com/google/gwt/user/client/ui/StackLayoutPanel.java Tue
Jan 26 10:19:07 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/StackLayoutPanel.java Wed
Feb 10 08:44:48 2010
@@ -19,6 +19,10 @@
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
import com.google.gwt.event.dom.client.HasClickHandlers;
+import com.google.gwt.event.dom.client.MouseOutEvent;
+import com.google.gwt.event.dom.client.MouseOutHandler;
+import com.google.gwt.event.dom.client.MouseOverEvent;
+import com.google.gwt.event.dom.client.MouseOverHandler;
import com.google.gwt.event.logical.shared.BeforeSelectionEvent;
import com.google.gwt.event.logical.shared.BeforeSelectionHandler;
import com.google.gwt.event.logical.shared.HasBeforeSelectionHandlers;
@@ -46,6 +50,8 @@
* .gwt-StackLayoutPanel the panel itself
* .gwt-StackLayoutPanel .gwt-StackLayoutPanelHeader applied to
each
* header widget
+ * .gwt-StackLayoutPanel .gwt-StackLayoutPanelHeader-hovering
applied to each
+ * header widget on mouse hover
* .gwt-StackLayoutPanel .gwt-StackLayoutPanelContent applied to
each
* child widget
*
@@ -99,6 +105,14 @@
public HandlerRegistration addClickHandler(ClickHandler handler) {
return this.addDomHandler(handler, ClickEvent.getType());
}
+
+public HandlerRegistration addMouseOutHandler(MouseOutHandler handler)
{
+ return this.addDomHandler(handler, MouseOutEvent.getType());
+}
+
+public HandlerRegistration addMouseOverHandler(MouseOverHandler
handler) {
+ return this.addDomHandler(handler, MouseOverEvent.getType());
+}
}
private static class LayoutData {
@@ -116,6 +130,7 @@
private static final String WIDGET_STYLE = "gwt-StackLayoutPanel";
private static final String CONTENT_STYLE
= "gwt-StackLayoutPanelContent";
private static final String HEADER_STYLE = "gwt-StackLayoutPanelHeader";
+ private static final String HEADER_STYLE_HOVERING
= "gwt-StackLayoutPanelHeader-hovering";
private static final int ANIMATION_TIME = 250;
@@ -468,7 +483,7 @@
assert (index >= 0) && (index < getWidgetCount()) : "Index out of
bounds";
}
- private void insert(final Widget child, Header header, double headerSize,
+ private void insert(final Widget child, final Header header, double
headerSize,
int beforeIndex) {
assert (beforeIndex >= 0) && (beforeIndex <=
getWidgetCount()) : "beforeIndex out of bounds";
@@ -501,6 +516,18 @@
}
});
+header.addMouseOutHandler(new MouseOutHandler() {
+ public void onMouseOut(MouseOutEvent event) {
+header.removeStyleName(HEADER_STYLE_HOVERING);
+ }
+});
+
+header.addMouseOverHandler(new MouseOverHandler() {
+ public void onMouseOver(MouseOverEvent event) {
+header.addStyleName(HEADER_STYLE_HOVERING);
+ }
+});
+
if (selectedIndex == -1) {
// If there's no visible widget, display the first one. The layout
will
// be updated onLoad().
===
---
/trunk/user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css
Tue Jan 26 10:19:07 2010
+++
/trunk/user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome.css
Wed Feb 10 08:44:48 2010
@@ -1095,6 +1095,9 @@
padding: 3px;
text-align: center;
}
+.gwt-StackLayoutPanel .gwt-StackLayoutPanelHeader-hovering {
+ background: #d3def6 url(images/hborder.png) repeat-x 0px -1464px;
+}
.gwt-StackLayoutPanel .gwt-StackLayoutPanelContent {
border: 1px solid #bb;
border-bottom: 0px;
===
---
/trunk/user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css
Tue Jan 26 10:19:07 2010
+++
/trunk/user/src/com/google/gwt/user/theme/chrome/public/gwt/chrome/chrome_rtl.css
Wed Feb 10 08:44:48 2010
@@ -1096,6 +1096,9 @@
padding: 3px;
text-align: center;
}
+.gwt-StackLayoutPanel .gwt-StackLayoutPanelHeader-hovering {
+ background: #d3def6 url(images/hborder.png) repeat-x 0px -1464px;
+}
.gwt-StackLayoutPanel .gwt-StackLayoutPanelContent {
border: 1px solid #bb;
border-bottom
[gwt-contrib] Re: Refactor SessionHandler and BrowserChannelClient to allow other OOPHM clients than HtmlUnit
I quickly looked at the changes and they look okay. We can get this patch into trunk sooner than a few weeks. @tbroyer: Can you update the patch to address John's concerns? Basically, just push methods, as appropriate, from SessionHandler to SessionHandlerClient and SessionHandlerServer that gets rid of any UnsupportedOperationExceptions. http://gwt-code-reviews.appspot.com/114801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7553 committed - http://gwt-code-reviews.appspot.com/126812
Revision: 7553 Author: j...@google.com Date: Wed Feb 10 08:57:18 2010 Log: http://gwt-code-reviews.appspot.com/126812 http://code.google.com/p/google-web-toolkit/source/detail?r=7553 Modified: /trunk/user/src/com/google/gwt/user/History.gwt.xml === --- /trunk/user/src/com/google/gwt/user/History.gwt.xml Tue Apr 28 09:11:39 2009 +++ /trunk/user/src/com/google/gwt/user/History.gwt.xml Wed Feb 10 08:57:18 2010 @@ -30,7 +30,13 @@ - + + + + + + + -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Fix for KeyPressEvent.getCharCode and overall key events improvements
On 2010/02/10 17:20:07, jgw wrote: The first message on the linked thread suggests that the W3C "has finally settled" on a standard for keyboard events. The lack of such a standard is one reason this stuff is such a mess in the first place. Does anyone know where this is specified? Last time I looked (and PPK seems to confirm this), there was no standard for these properties. See http://www.w3.org/TR/DOM-Level-3-Events/ keypress is deprecated in favor of a new textInput (which is also fired when pasting text, for instance) They now even included a table explaining what keyCode and charCode are in keydown/keypress/keyup events in IE7, FF 3, Safari 3.1 and Opera 9.5. It would also be really helpful to add a few tests. That would also help illuminate the expected behavior, which is kind of difficult to follow at present. We now have Document.create*Event() and Element.dispatchEvent(), which I believe makes this tractable. I don't think we could have real "tests", as the keyCode and charCode are passed explicitly as arguments to Document.create*Event() Moreover, dispatching keydown/keypress/keyup events to an InputElement doesn't change its value (tested in Chrome stable). Did you have something specific in mind? (a "museum" sample could help manually check things though) http://gwt-code-reviews.appspot.com/142801 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] [google-web-toolkit] r7554 committed - http://gwt-code-reviews.appspot.com/125806
Revision: 7554
Author: j...@google.com
Date: Wed Feb 10 09:13:44 2010
Log: http://gwt-code-reviews.appspot.com/125806
http://code.google.com/p/google-web-toolkit/source/detail?r=7554
Modified:
/trunk/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
/trunk/user/src/com/google/gwt/user/client/impl/ElementMapperImpl.java
/trunk/user/src/com/google/gwt/user/client/ui/HTMLTable.java
===
--- /trunk/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
Fri Nov 20 16:10:50 2009
+++ /trunk/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
Wed Feb 10 09:13:44 2010
@@ -71,13 +71,12 @@
public native Element getChild(Element elem, int index) /*-{
var count = 0, child = elem.firstChild;
while (child) {
- var next = child.nextSibling;
if (child.nodeType == 1) {
if (index == count)
return child;
++count;
}
- child = next;
+ child = child.nextSibling;
}
return null;
===
--- /trunk/user/src/com/google/gwt/user/client/impl/ElementMapperImpl.java
Wed Oct 28 09:10:53 2009
+++ /trunk/user/src/com/google/gwt/user/client/impl/ElementMapperImpl.java
Wed Feb 10 09:13:44 2010
@@ -16,7 +16,7 @@
package com.google.gwt.user.client.impl;
-import com.google.gwt.user.client.Element;
+import com.google.gwt.dom.client.Element;
import com.google.gwt.user.client.ui.UIObject;
import java.util.ArrayList;
===
--- /trunk/user/src/com/google/gwt/user/client/ui/HTMLTable.java Tue Jan 26
10:25:12 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/HTMLTable.java Wed Feb 10
09:13:44 2010
@@ -16,12 +16,16 @@
package com.google.gwt.user.client.ui;
import com.google.gwt.dom.client.Document;
+import com.google.gwt.dom.client.Element;
+import com.google.gwt.dom.client.NativeEvent;
+import com.google.gwt.dom.client.TableCellElement;
+import com.google.gwt.dom.client.TableElement;
+import com.google.gwt.dom.client.TableRowElement;
+import com.google.gwt.dom.client.TableSectionElement;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
import com.google.gwt.event.dom.client.HasClickHandlers;
import com.google.gwt.event.shared.HandlerRegistration;
-import com.google.gwt.user.client.DOM;
-import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
import com.google.gwt.user.client.impl.ElementMapperImpl;
import
com.google.gwt.user.client.ui.HasHorizontalAlignment.HorizontalAlignmentConstant;
@@ -75,7 +79,7 @@
*
* @return the cell's element.
*/
-public Element getElement() {
+public com.google.gwt.user.client.Element getElement() {
return getCellFormatter().getElement(rowIndex, cellIndex);
}
@@ -102,7 +106,7 @@
*/
public void addStyleName(int row, int column, String styleName) {
prepareCell(row, column);
- Element td = getCellElement(bodyElem, row, column);
+ Element td = getRawElement(row, column);
UIObject.setStyleName(td, styleName, true);
}
@@ -114,9 +118,9 @@
* @return the column's TD element
* @throws IndexOutOfBoundsException
*/
-public Element getElement(int row, int column) {
+public com.google.gwt.user.client.Element getElement(int row, int
column) {
checkCellBounds(row, column);
- return getCellElement(bodyElem, row, column);
+ return getRawElement(row, column).cast();
}
/**
@@ -168,7 +172,7 @@
*/
public void removeStyleName(int row, int column, String styleName) {
checkCellBounds(row, column);
- Element td = getCellElement(bodyElem, row, column);
+ Element td = getRawElement(row, column);
UIObject.setStyleName(td, styleName, false);
}
@@ -200,8 +204,8 @@
*/
public void setHeight(int row, int column, String height) {
prepareCell(row, column);
- Element elem = getCellElement(bodyElem, row, column);
- DOM.setElementProperty(elem, "height", height);
+ Element elem = getRawElement(row, column);
+ elem.setPropertyString("height", height);
}
/**
@@ -216,8 +220,8 @@
public void setHorizontalAlignment(int row, int column,
HorizontalAlignmentConstant align) {
prepareCell(row, column);
- Element elem = getCellElement(bodyElem, row, column);
- DOM.setElementProperty(elem, "align", align.getTextAlignString());
+ Element elem = getRawElement(row, column);
+ elem.setPropertyString("align", align.getTextAlignString());
}
/**
@@ -231,7 +235,7 @@
*/
public void setStyleName(int row, int column, String styleName) {
prepareCell(row, column);
- UIObject.setStyleName(getCellElement(bodyElem, row, column),
styleName);
+ UIObject.setStyleName(getRawElement(row, column), styleName);
}
/**
@@ -244,7 +248,8 @@
* @thro
[gwt-contrib] Re: CSS Selector Engine
Well count me in for whatever I can do to help get support for a selector engine into GWT or a well supported community project. Admittedly, I am no browser quirk guru (which explains why I love GWT!), but I'll offer my services any way I can. It's obviously not release-grade, but I did throw up a project to provide Java bindings for Sizzle: http://code.google.com/p/gwt-sizzle/ For now, I'm trying to keep it stupid simple. Just the bare minimum to return a set of Nodes, given a selector. Maybe I can eventually get the Sizzle code ported to GWT code to take advantage of deferred binding in the compiler. Thoughts? On Feb 9, 11:37 pm, Bruce Johnson wrote: > And if we can get GwtQuery to the point where a lot of people really like > it, I think we'd seriously consider rolling it into GWT proper. > > > > On Tue, Feb 9, 2010 at 11:34 PM, Ray Cromwell wrote: > > GwtQuery was developed before Gwt 2.0 and it's been a while since it's > > been updated, but I believe it always was the intent for it to be a > > 'proving ground' for bringing CSS selectors and jQuery like > > functionality into GWT core. Besides GWT 2.0 and/or IE8, let me know > > any issues that are most important to you. Perhaps I can grant those > > interested in helping comitter access. > > > -Ray > > > On Tue, Feb 9, 2010 at 8:12 PM, jarrod wrote: > > > Yes, I am quite familiar with the project and have tried using it > > > several times. Unfortunately, it does not work very well with GWT 2.0, > > > does not support IE8, and appears to be dead as far as code > > > maintenance. I certainly wish that weren't the case, but given the > > > outstanding issues and lack of any code commits... what can you do? > > >http://code.google.com/p/gwtquery/issues/list?can=1&q=&colspec=ID+Typ... > > > > On Feb 9, 10:26 pm, John Tamplin wrote: > > >> On Tue, Feb 9, 2010 at 9:51 PM, jarrod > > wrote: > > >> > I have to believe this topic has been broached before, but why does > > >> > GWT not contain any kind of CSS selector engine? > > > >> > More and more I am using GWT to build JavaScript API tools for this > > >> > that or the other, and often this means integration with non-GWT code > > >> > (read: hand-written HTML, CSS and JavaScript). > > > >> > Tool kits like JQuery and Dojo provide great helper methods for > > >> > manipulating the DOM via CSS selectors - a feature that is distinctly > > >> > absent from GWT. And yet, because of the vast differences in browser > > >> > support for various CSS selector methods (and CSS support itself), it > > >> > seems like a perfect fit for GWT, given the deferred binding > > >> > capabilities the compiler offers. > > > >> > I do not believe GWT needs to support all the fancy helper "shortcut" > > >> > methods that other toolkits provide. Most of the extra features like > > >> > animation already have reasonable equivalents in GWT, and JQuery's > > >> > method chaining is just a hard-to-read way of minifying your code - > > >> > something GWT also already does. :-) > > > >> > Probably my favorite CSS engine right now is Sizzle JS (http:// > > >> > sizzlejs.com/) and I can't imagine it would be hard to write GWT > > >> > bindings for this library (it has three public methods in the API!). > > >> > In fact, if I can't find them with a quick Google search, maybe I'll > > >> > start a new project to do so. > > > >> > The bindings would be a good start, but this is definitely a feature > > >> > I'd like to see get first-class support in GWT. > > > >> Have you seenhttp://code.google.com/p/gwtquery/wiki/GettingStarted? > > > >> -- > > >> John A. Tamplin > > >> Software Engineer (GWT), Google > > > > -- > > >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] [google-web-toolkit] r7555 committed - Rolling back due to API checker failure. Not caught by smoke tests for...
Revision: 7555
Author: j...@google.com
Date: Wed Feb 10 17:48:06 2010
Log: Rolling back due to API checker failure. Not caught by smoke tests for
inexplicable reasons.
http://code.google.com/p/google-web-toolkit/source/detail?r=7555
Modified:
/trunk/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
/trunk/user/src/com/google/gwt/user/client/impl/ElementMapperImpl.java
/trunk/user/src/com/google/gwt/user/client/ui/HTMLTable.java
===
--- /trunk/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
Wed Feb 10 09:13:44 2010
+++ /trunk/user/src/com/google/gwt/user/client/impl/DOMImplStandard.java
Wed Feb 10 17:48:06 2010
@@ -71,12 +71,13 @@
public native Element getChild(Element elem, int index) /*-{
var count = 0, child = elem.firstChild;
while (child) {
+ var next = child.nextSibling;
if (child.nodeType == 1) {
if (index == count)
return child;
++count;
}
- child = child.nextSibling;
+ child = next;
}
return null;
===
--- /trunk/user/src/com/google/gwt/user/client/impl/ElementMapperImpl.java
Wed Feb 10 09:13:44 2010
+++ /trunk/user/src/com/google/gwt/user/client/impl/ElementMapperImpl.java
Wed Feb 10 17:48:06 2010
@@ -16,7 +16,7 @@
package com.google.gwt.user.client.impl;
-import com.google.gwt.dom.client.Element;
+import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.ui.UIObject;
import java.util.ArrayList;
===
--- /trunk/user/src/com/google/gwt/user/client/ui/HTMLTable.java Wed Feb 10
09:13:44 2010
+++ /trunk/user/src/com/google/gwt/user/client/ui/HTMLTable.java Wed Feb 10
17:48:06 2010
@@ -16,16 +16,12 @@
package com.google.gwt.user.client.ui;
import com.google.gwt.dom.client.Document;
-import com.google.gwt.dom.client.Element;
-import com.google.gwt.dom.client.NativeEvent;
-import com.google.gwt.dom.client.TableCellElement;
-import com.google.gwt.dom.client.TableElement;
-import com.google.gwt.dom.client.TableRowElement;
-import com.google.gwt.dom.client.TableSectionElement;
import com.google.gwt.event.dom.client.ClickEvent;
import com.google.gwt.event.dom.client.ClickHandler;
import com.google.gwt.event.dom.client.HasClickHandlers;
import com.google.gwt.event.shared.HandlerRegistration;
+import com.google.gwt.user.client.DOM;
+import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
import com.google.gwt.user.client.impl.ElementMapperImpl;
import
com.google.gwt.user.client.ui.HasHorizontalAlignment.HorizontalAlignmentConstant;
@@ -79,7 +75,7 @@
*
* @return the cell's element.
*/
-public com.google.gwt.user.client.Element getElement() {
+public Element getElement() {
return getCellFormatter().getElement(rowIndex, cellIndex);
}
@@ -106,7 +102,7 @@
*/
public void addStyleName(int row, int column, String styleName) {
prepareCell(row, column);
- Element td = getRawElement(row, column);
+ Element td = getCellElement(bodyElem, row, column);
UIObject.setStyleName(td, styleName, true);
}
@@ -118,9 +114,9 @@
* @return the column's TD element
* @throws IndexOutOfBoundsException
*/
-public com.google.gwt.user.client.Element getElement(int row, int
column) {
+public Element getElement(int row, int column) {
checkCellBounds(row, column);
- return getRawElement(row, column).cast();
+ return getCellElement(bodyElem, row, column);
}
/**
@@ -172,7 +168,7 @@
*/
public void removeStyleName(int row, int column, String styleName) {
checkCellBounds(row, column);
- Element td = getRawElement(row, column);
+ Element td = getCellElement(bodyElem, row, column);
UIObject.setStyleName(td, styleName, false);
}
@@ -204,8 +200,8 @@
*/
public void setHeight(int row, int column, String height) {
prepareCell(row, column);
- Element elem = getRawElement(row, column);
- elem.setPropertyString("height", height);
+ Element elem = getCellElement(bodyElem, row, column);
+ DOM.setElementProperty(elem, "height", height);
}
/**
@@ -220,8 +216,8 @@
public void setHorizontalAlignment(int row, int column,
HorizontalAlignmentConstant align) {
prepareCell(row, column);
- Element elem = getRawElement(row, column);
- elem.setPropertyString("align", align.getTextAlignString());
+ Element elem = getCellElement(bodyElem, row, column);
+ DOM.setElementProperty(elem, "align", align.getTextAlignString());
}
/**
@@ -235,7 +231,7 @@
*/
public void setStyleName(int row, int column, String styleName) {
prepareCell(row, column);
- UIObject.setStyleName(getRawElement(row, column), styleName);
+ UIObject.setStyleName(getCellElement(bodyElem, row, column),
styleName)
