[gwt-contrib] Re: [gwt-eng] building on windows requires the command-line version of svn?
FWIW, the fact that the build now assumes that the svn on your path is the one that created the working directory causes build breaks on my machine. I don't know if this is something that we want to deal with, but adding calls to svn does introduce another environmental assumption. SVNKit is a java based svn1.5 lib that could free us from having to depend on the svn executable (assuming there are no licensing issues). http://svnkit.com/ /kel On Thu, Sep 25, 2008 at 11:22 PM, Freeland Abbott < [EMAIL PROTECTED]> wrote: > Here's the patch, Alex... sorry. The first-cut at this branding was > careful about "what if they don't have it," but used which > was unhappy on ant 1.6.5; the second task implementation wasn't (but should > have been) so careful. > (@Scott, by the way, to answer a prior questoin, I did look at the ant > Execute.java stuff... I wasn't convinced it added much for a > non-daemon-style process, and it'd require either moving the task into tools > as a binary and/or putting the ant sources into tools so we'd have them to > compile against. I wasn't convinced that was a better answer than my > runCommand()) > > > > On Thu, Sep 25, 2008 at 9:35 PM, Freeland Abbott <[EMAIL PROTECTED]>wrote: > >> Mm. That'll be my rework to get ant 1.6.5 back in the game; I should >> allow those execution failures (with resulting svn branding of >> [EMAIL PROTECTED])... >> >> >> On Thu, Sep 25, 2008 at 6:34 PM, Alex Rudnick <[EMAIL PROTECTED]> wrote: >> >>> >>> I was trying to build the trunk on my windows install -- I didn't have >>> the command line version of svn, just tortoise, and I got the message >>> "cannot launch command svn info", referencing line 208 of >>> common.ant.xml. If we require particular svn tools for the build, >>> should we write that down somewhere in the README file for Eclipse? Or >>> maybe somewhere else in the docs? >>> >>> -- >>> Alex Rudnick >>> swe, gwt, atl >>> >>> >>> >> > > > > -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: [gwt-eng] building on windows requires the command-line version of svn?
Here's the patch, Alex... sorry. The first-cut at this branding was careful about "what if they don't have it," but used which was unhappy on ant 1.6.5; the second task implementation wasn't (but should have been) so careful. (@Scott, by the way, to answer a prior questoin, I did look at the ant Execute.java stuff... I wasn't convinced it added much for a non-daemon-style process, and it'd require either moving the task into tools as a binary and/or putting the ant sources into tools so we'd have them to compile against. I wasn't convinced that was a better answer than my runCommand()) On Thu, Sep 25, 2008 at 9:35 PM, Freeland Abbott <[EMAIL PROTECTED]> wrote: > Mm. That'll be my rework to get ant 1.6.5 back in the game; I should allow > those execution failures (with resulting svn branding of [EMAIL PROTECTED] > )... > > > On Thu, Sep 25, 2008 at 6:34 PM, Alex Rudnick <[EMAIL PROTECTED]> wrote: > >> >> I was trying to build the trunk on my windows install -- I didn't have >> the command line version of svn, just tortoise, and I got the message >> "cannot launch command svn info", referencing line 208 of >> common.ant.xml. If we require particular svn tools for the build, >> should we write that down somewhere in the README file for Eclipse? Or >> maybe somewhere else in the docs? >> >> -- >> Alex Rudnick >> swe, gwt, atl >> >> >> >> > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~--- svninfotask-r3683.patch Description: Binary data
[gwt-contrib] [google-web-toolkit commit] r3683 - trunk/user/test/com/google/gwt/user/client/ui
Author: [EMAIL PROTECTED]
Date: Thu Sep 25 15:23:23 2008
New Revision: 3683
Modified:
trunk/user/test/com/google/gwt/user/client/ui/HiddenTest.java
trunk/user/test/com/google/gwt/user/client/ui/HistoryTest.java
Log:
Fix checkstyle warnings.
Modified: trunk/user/test/com/google/gwt/user/client/ui/HiddenTest.java
==
--- trunk/user/test/com/google/gwt/user/client/ui/HiddenTest.java
(original)
+++ trunk/user/test/com/google/gwt/user/client/ui/HiddenTest.java Thu Sep
25 15:23:23 2008
@@ -34,7 +34,7 @@
// Expected
}
try {
- Hidden d = new Hidden((String)null);
+ Hidden d = new Hidden((String) null);
fail("expected null pointer exception");
} catch (NullPointerException e) {
// Expected
Modified: trunk/user/test/com/google/gwt/user/client/ui/HistoryTest.java
==
--- trunk/user/test/com/google/gwt/user/client/ui/HistoryTest.java
(original)
+++ trunk/user/test/com/google/gwt/user/client/ui/HistoryTest.java Thu Sep
25 15:23:23 2008
@@ -15,14 +15,14 @@
*/
package com.google.gwt.user.client.ui;
-import java.util.ArrayList;
-
import com.google.gwt.dom.client.Document;
import com.google.gwt.dom.client.Element;
import com.google.gwt.junit.client.GWTTestCase;
import com.google.gwt.user.client.History;
import com.google.gwt.user.client.HistoryListener;
import com.google.gwt.user.client.Timer;
+
+import java.util.ArrayList;
/**
* Tests for the history system.
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3682 - trunk/user/test/com/google/gwt/user/client
Author: [EMAIL PROTECTED]
Date: Thu Sep 25 14:39:27 2008
New Revision: 3682
Modified:
trunk/user/test/com/google/gwt/user/client/WindowTest.java
Log:
Fixing build breakage (WindowTest.testLocation() implicitly depended upon
the
current url not having a trailing # character).
Patch by: jgw
Review by: knorton (desk check)
Modified: trunk/user/test/com/google/gwt/user/client/WindowTest.java
==
--- trunk/user/test/com/google/gwt/user/client/WindowTest.java (original)
+++ trunk/user/test/com/google/gwt/user/client/WindowTest.java Thu Sep 25
14:39:27 2008
@@ -61,6 +61,11 @@
// testing reload, replace, and assign seemed to hang our junit
harness.
// Therefore only testing subset of Location that is testable.
+// Use History to get the #hash part of the url into a known state (if
the
+// url has somehow been set to http://host/#, location.hash returns the
+// empty string, but location.href includes the trailing hash).
+History.newItem("foo");
+
// As we have no control over these values we cannot assert much about
them.
String hash = Window.Location.getHash();
String host = Window.Location.getHost();
@@ -76,7 +81,7 @@
assertEquals(host, hostName + ":" + port);
assertEquals(href, protocol + "//" + host + path + query + hash);
}
-
+
public void testLocationParsing() {
Map> map;
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: wrapping existing element too restrictive maybe....
He Thomas, thanks for the tip.
Tried it, and it works just fine.
Thanks, appearantly your also more creative then me :(
-- Ed
On Sep 25, 10:53 am, Thomas Broyer <[EMAIL PROTECTED]> wrote:
> On 24 sep, 17:13, Ed <[EMAIL PROTECTED]> wrote:
>
> > Thanks Joel,
>
> > I think I understand you but let me overview my situation and fire
> > some questions.
>
> > My situation is legal situation I think:
> > I have a man part of the page that I want to use to show some static
> > information. There for I put the main page aside like explained above
> > and add the HTML text widget that is then shown. The user then simple
> > toggles between the two.
>
> Two options:
> Some HTML
>
> ...
> // Initialize the GWT part
> RootPanel.get("b").add(...);
> ...
> // toggle between the two parts
> RootPanel.get("a").setVisible(false);
> RootPanel.get("b").setVisible(true);
>
> or:
>
>Some HTML
>
> ...
> // Initialize the GWT part
> RootPanel.get("container").add(myPanel);
> ...
> // toggle
> RootPanel.get("a").setVisible(false);
> myPanel.setVisible(true);
>
> No need to detach/attach your components/elements.
>
> (note that instead of creating a RootPanel for the static HTML part,
> you can also use:
>UIObject.setVisible(Document.get().getElementById("a"), false);
> )
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Ahhh the famous "lock-in" reason. Yep, understandable... --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> > > You lost me here. I think I misunderstand something. > If the compiler get ride of the overridden code, "causing code bloat" > isn't a reason to not allow subclassing like you mention above, not? > Ah! I see the misunderstanding, nope, that was the justification for why it could be done efficiently, not why it should be done. The justification for why it should be done is different: If we allow subclasses, then we have to make pretty strong guarantees about how the default calendar view and month selector are implemented. That means that if GWT 2.0, if we figure out an awesome new way to write the default calendar view that blows the socks off of the old implementation, we wouldn't be able to switch to it. > > On Sep 25, 5:26 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > > do not cause code bloat. > > > Isn't the GWT compiler smart enough to overcome this? > > > I hope so. I have a quite a lot of gwt classes and many subclasses for > > > simple OO reasons :( > > > > Yep, that is actually my point - that the compiler is smart enough > > to aggressively get rid of unused code, so the defaults will be > completely > > dropped in favor of your custom code. > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> > > > do not cause code bloat. > Isn't the GWT compiler smart enough to overcome this? > I hope so. I have a quite a lot of gwt classes and many subclasses for > simple OO reasons :( > > Yep, that is actually my point - that the compiler is smart enough to aggressively get rid of unused code, so the defaults will be completely dropped in favor of your custom code. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> Yep, that is actually my point - that the compiler is smart enough > to aggressively get rid of unused code, so the defaults will be completely > dropped in favor of your custom code. You lost me here. I think I misunderstand something. If the compiler get ride of the overridden code, "causing code bloat" isn't a reason to not allow subclassing like you mention above, not? On Sep 25, 5:26 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > do not cause code bloat. > > Isn't the GWT compiler smart enough to overcome this? > > I hope so. I have a quite a lot of gwt classes and many subclasses for > > simple OO reasons :( > > Yep, that is actually my point - that the compiler is smart enough > to aggressively get rid of unused code, so the defaults will be completely > dropped in favor of your custom code. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Thanks for your answers Emily, > Did you look at the date picker in gen2? The Css class there is public. Nope. Where can I find this? (the source of incubator or core ?...) I looked around in GWT and incubator site... but... I think I am looking with my eyes closed :( > Actually, and I know you are going to hate this answer, Don't worry ;) > do not cause code bloat. Isn't the GWT compiler smart enough to overcome this? I hope so. I have a quite a lot of gwt classes and many subclasses for simple OO reasons :( > We may also, if there is enough demand for it, introduce > AbstractMonthSelector and AbstractCalendarView which are specifically +1 +1, but probably have them done soon :) > The month and calendar view APIs are not designed for the date picker Waaaa you guys are strict > picker, it will work with the new event system and css resources, which will > make it more useable for you in the long run. Will this come available in the incubator? Or where can I read some more about these gen2 components (idea, pan, roadmap, etc..). Isn't the current DatePicker not already using the new event system? What is this new css resouces ? Do you mean the CssResource in the incubator? -- Ed On Sep 25, 3:50 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > I think in general the DatePicker should be made more usable. Here are > > a few things I don't understand: > > - I am not allowed to use the DatePicker.Styles class. Why not ? As I > > want to use it in my own selector just like happens in the > > SimpleMonthSelector. > > Did you look at the date picker in gen2? The Css class there is public. > > > > > - The SimpleMonthSelector isn't usable. The method should be splitup > > in smaller protected methods such that this functionality can be used > > and the subclass can compose his own functionality. I am case I need > > to only change the listeners but those are set in the setup, such that > > I need to override the whole setup, but I need the other functionality > > in setup for the buttons and stuff and the styles, especially as this > > latter one is needed as I can't access the Style class (previous > > point). > > Actually, and I know you are going to hate this answer, > SimpleMonthSelector (now called DefaultMonthSelector) is not designed for > extension at all, neither is SimpleCalendarView (now called > DefaultCalendarView). > > The current pattern is to have you take the implementations, copy and modify > them to your needs. Once you do so, and use your modified month and view > selectors, the default ones will not be included in your compilation and so > do not cause code bloat. This way, we don't have to worry about those of you > extending the default extenders and can instead worry about the vast number > of people using the date picker widget. Before submitting the widget, we > will run tests to make sure that the defaults can be cleanly copied to > another package without causing any compilation errors. > > We may also, if there is enough demand for it, introduce > AbstractMonthSelector and AbstractCalendarView which are specifically > designed for extension (may even try to convince Isaac to write them :-). > > > - Why do I need to subclass DatePicker to use my own MonthSelector?... > > Why is this DatePicker constructor protected and not public ? > > The month and calendar view APIs are not designed for the date picker > consumer, instead they are meant for people extending DatePicker. > Therefore, if you look at the public API, you will see that there is no > public use of either class in date picker. In specific, rather then users > trying to figure out which month selectors go with which calendar views, > they should have a set number of pre-canned choices. > > > > > I am thinking about copying the whole DatePicker to my own space as I > > can't use it like this :(... but I do want to use it... > > I think in your case, that is a terrific idea, as that way you will get the > fine-grain control you want and can refactor the classes at will. You might > want to hold off a few days though, wait until the gen2 date > picker stabilizes. As it, while much less stable then the current date > picker, it will work with the new event system and css resources, which will > make it more useable for you in the long run. > > Cheers, > > Emily > > > > > > > -- Ed > > > On Sep 25, 12:44 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > Are you extending MonthSelector or DatePickerComponent? MonthSelector is > > > public, so if you are extending that, could you create an issue, as that > > > should darn well work, though you will have to create a new subclass of > > > DatePicker to use your new month selector as well. > > > > On Wed, Sep 24, 2008 at 6:00 PM, Ed <[EMAIL PROTECTED]> wrote: > > > > > Why is the class DatePickerComponent of the DatePicker protected ? I > > > > want to add my own MonthSelector, but when I do this, it throws an > > > > access exception becau
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Check out the thread: RR: Introducing the gen2 incubator packageFeel free to respond to that thread if you have any questions in order to maintain thread coherence. On Thu, Sep 25, 2008 at 11:21 AM, Ed <[EMAIL PROTECTED]> wrote: > > Ooppsss, found the gen2 components :(.. > But why are the not the same as the "normal" incubator components? > What is the plan and idea behind this ? > > -- Ed > > On Sep 25, 5:14 pm, Ed <[EMAIL PROTECTED]> wrote: > > Thanks for your answers Emily, > > > > > Did you look at the date picker in gen2? The Css class there is public. > > > > Nope. Where can I find this? (the source of incubator or core ?...) > > I looked around in GWT and incubator site... but... I think I am > > looking with my eyes closed :( > > > > > Actually, and I know you are going to hate this answer, > > > > Don't worry ;) > > > > > do not cause code bloat. > > > > Isn't the GWT compiler smart enough to overcome this? > > I hope so. I have a quite a lot of gwt classes and many subclasses for > > simple OO reasons :( > > > > > We may also, if there is enough demand for it, introduce > > > AbstractMonthSelector and AbstractCalendarView which are specifically > > > > +1 +1, but probably have them done soon :) > > > > > The month and calendar view APIs are not designed for the date picker > > > > Waaaa you guys are strict > > > > > picker, it will work with the new event system and css resources, which > will > > > make it more useable for you in the long run. > > > > Will this come available in the incubator? Or where can I read some > > more about these gen2 components (idea, pan, roadmap, etc..). > > Isn't the current DatePicker not already using the new event system? > > What is this new css resouces ? Do you mean the CssResource in the > > incubator? > > > > -- Ed > > > > On Sep 25, 3:50 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > > > > I think in general the DatePicker should be made more usable. Here > are > > > > a few things I don't understand: > > > > - I am not allowed to use the DatePicker.Styles class. Why not ? As I > > > > want to use it in my own selector just like happens in the > > > > SimpleMonthSelector. > > > > > Did you look at the date picker in gen2? The Css class there is public. > > > > > > - The SimpleMonthSelector isn't usable. The method should be splitup > > > > in smaller protected methods such that this functionality can be used > > > > and the subclass can compose his own functionality. I am case I need > > > > to only change the listeners but those are set in the setup, such > that > > > > I need to override the whole setup, but I need the other > functionality > > > > in setup for the buttons and stuff and the styles, especially as this > > > > latter one is needed as I can't access the Style class (previous > > > > point). > > > > > Actually, and I know you are going to hate this answer, > > > SimpleMonthSelector (now called DefaultMonthSelector) is not designed > for > > > extension at all, neither is SimpleCalendarView (now called > > > DefaultCalendarView). > > > > > The current pattern is to have you take the implementations, copy and > modify > > > them to your needs. Once you do so, and use your modified month and > view > > > selectors, the default ones will not be included in your compilation > and so > > > do not cause code bloat. This way, we don't have to worry about those > of you > > > extending the default extenders and can instead worry about the vast > number > > > of people using the date picker widget. Before submitting the widget, > we > > > will run tests to make sure that the defaults can be cleanly copied to > > > another package without causing any compilation errors. > > > > > We may also, if there is enough demand for it, introduce > > > AbstractMonthSelector and AbstractCalendarView which are specifically > > > designed for extension (may even try to convince Isaac to write them > :-). > > > > > > - Why do I need to subclass DatePicker to use my own > MonthSelector?... > > > > Why is this DatePicker constructor protected and not public ? > > > > > The month and calendar view APIs are not designed for the date picker > > > consumer, instead they are meant for people extending DatePicker. > > > Therefore, if you look at the public API, you will see that there is no > > > public use of either class in date picker. In specific, rather then > users > > > trying to figure out which month selectors go with which calendar > views, > > > they should have a set number of pre-canned choices. > > > > > > I am thinking about copying the whole DatePicker to my own space as I > > > > can't use it like this :(... but I do want to use it... > > > > > I think in your case, that is a terrific idea, as that way you will get > the > > > fine-grain control you want and can refactor the classes at will. You > might > > > want to hold off a few days though, wait until the gen2 date > > > picker stabilizes. As it, while much less stable then the curre
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Ooppsss, found the gen2 components :(.. But why are the not the same as the "normal" incubator components? What is the plan and idea behind this ? -- Ed On Sep 25, 5:14 pm, Ed <[EMAIL PROTECTED]> wrote: > Thanks for your answers Emily, > > > Did you look at the date picker in gen2? The Css class there is public. > > Nope. Where can I find this? (the source of incubator or core ?...) > I looked around in GWT and incubator site... but... I think I am > looking with my eyes closed :( > > > Actually, and I know you are going to hate this answer, > > Don't worry ;) > > > do not cause code bloat. > > Isn't the GWT compiler smart enough to overcome this? > I hope so. I have a quite a lot of gwt classes and many subclasses for > simple OO reasons :( > > > We may also, if there is enough demand for it, introduce > > AbstractMonthSelector and AbstractCalendarView which are specifically > > +1 +1, but probably have them done soon :) > > > The month and calendar view APIs are not designed for the date picker > > Waaaa you guys are strict > > > picker, it will work with the new event system and css resources, which will > > make it more useable for you in the long run. > > Will this come available in the incubator? Or where can I read some > more about these gen2 components (idea, pan, roadmap, etc..). > Isn't the current DatePicker not already using the new event system? > What is this new css resouces ? Do you mean the CssResource in the > incubator? > > -- Ed > > On Sep 25, 3:50 pm, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > > I think in general the DatePicker should be made more usable. Here are > > > a few things I don't understand: > > > - I am not allowed to use the DatePicker.Styles class. Why not ? As I > > > want to use it in my own selector just like happens in the > > > SimpleMonthSelector. > > > Did you look at the date picker in gen2? The Css class there is public. > > > > - The SimpleMonthSelector isn't usable. The method should be splitup > > > in smaller protected methods such that this functionality can be used > > > and the subclass can compose his own functionality. I am case I need > > > to only change the listeners but those are set in the setup, such that > > > I need to override the whole setup, but I need the other functionality > > > in setup for the buttons and stuff and the styles, especially as this > > > latter one is needed as I can't access the Style class (previous > > > point). > > > Actually, and I know you are going to hate this answer, > > SimpleMonthSelector (now called DefaultMonthSelector) is not designed for > > extension at all, neither is SimpleCalendarView (now called > > DefaultCalendarView). > > > The current pattern is to have you take the implementations, copy and modify > > them to your needs. Once you do so, and use your modified month and view > > selectors, the default ones will not be included in your compilation and so > > do not cause code bloat. This way, we don't have to worry about those of you > > extending the default extenders and can instead worry about the vast number > > of people using the date picker widget. Before submitting the widget, we > > will run tests to make sure that the defaults can be cleanly copied to > > another package without causing any compilation errors. > > > We may also, if there is enough demand for it, introduce > > AbstractMonthSelector and AbstractCalendarView which are specifically > > designed for extension (may even try to convince Isaac to write them :-). > > > > - Why do I need to subclass DatePicker to use my own MonthSelector?... > > > Why is this DatePicker constructor protected and not public ? > > > The month and calendar view APIs are not designed for the date picker > > consumer, instead they are meant for people extending DatePicker. > > Therefore, if you look at the public API, you will see that there is no > > public use of either class in date picker. In specific, rather then users > > trying to figure out which month selectors go with which calendar views, > > they should have a set number of pre-canned choices. > > > > I am thinking about copying the whole DatePicker to my own space as I > > > can't use it like this :(... but I do want to use it... > > > I think in your case, that is a terrific idea, as that way you will get the > > fine-grain control you want and can refactor the classes at will. You might > > want to hold off a few days though, wait until the gen2 date > > picker stabilizes. As it, while much less stable then the current date > > picker, it will work with the new event system and css resources, which will > > make it more useable for you in the long run. > > > Cheers, > > > Emily > > > > -- Ed > > > > On Sep 25, 12:44 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > > > Are you extending MonthSelector or DatePickerComponent? MonthSelector > > > > is > > > > public, so if you are extending that, could you create an issue, as that > > > > should darn w
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> And it doesn't give me any problems.
extending DatePicker isn't the problem. Extending the MonthSelector is
the problem.
Which extends the DatePickercomponent which is package protect. When I
change this to public, it works fine, so it must be that.
On Sep 25, 3:39 pm, "Isaac Truett" <[EMAIL PROTECTED]> wrote:
> Ed,
>
> Extending MonthSelector definitely is possible. I have this:
>
> public class MyDatePicker extends DatePIcker {
> public MyDatePIcker() {
> super(new MyMonthSelector(), new SimpleCalendarView(), new
> CalendarModel());
> }
>
> static class MyMonthSelector extends MonthSelector {
> ...
> }
>
> }
>
> And it doesn't give me any problems.
>
> Would it be possible for you to post your modified DatePickerDemo to
> show us where that exception is coming from?
>
> Thanks,
> Isaac
>
> On Thu, Sep 25, 2008 at 9:22 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
> >> The same error occurs when I extend the MonthSelector. Please verify
> >> this?
>
> > I will see if I can get it to repro, thanks!
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> > I think in general the DatePicker should be made more usable. Here are > a few things I don't understand: > - I am not allowed to use the DatePicker.Styles class. Why not ? As I > want to use it in my own selector just like happens in the > SimpleMonthSelector. Did you look at the date picker in gen2? The Css class there is public. > > - The SimpleMonthSelector isn't usable. The method should be splitup > in smaller protected methods such that this functionality can be used > and the subclass can compose his own functionality. I am case I need > to only change the listeners but those are set in the setup, such that > I need to override the whole setup, but I need the other functionality > in setup for the buttons and stuff and the styles, especially as this > latter one is needed as I can't access the Style class (previous > point). Actually, and I know you are going to hate this answer, SimpleMonthSelector (now called DefaultMonthSelector) is not designed for extension at all, neither is SimpleCalendarView (now called DefaultCalendarView). The current pattern is to have you take the implementations, copy and modify them to your needs. Once you do so, and use your modified month and view selectors, the default ones will not be included in your compilation and so do not cause code bloat. This way, we don't have to worry about those of you extending the default extenders and can instead worry about the vast number of people using the date picker widget. Before submitting the widget, we will run tests to make sure that the defaults can be cleanly copied to another package without causing any compilation errors. We may also, if there is enough demand for it, introduce AbstractMonthSelector and AbstractCalendarView which are specifically designed for extension (may even try to convince Isaac to write them :-). > - Why do I need to subclass DatePicker to use my own MonthSelector?... > Why is this DatePicker constructor protected and not public ? > The month and calendar view APIs are not designed for the date picker consumer, instead they are meant for people extending DatePicker. Therefore, if you look at the public API, you will see that there is no public use of either class in date picker. In specific, rather then users trying to figure out which month selectors go with which calendar views, they should have a set number of pre-canned choices. > > I am thinking about copying the whole DatePicker to my own space as I > can't use it like this :(... but I do want to use it... > I think in your case, that is a terrific idea, as that way you will get the fine-grain control you want and can refactor the classes at will. You might want to hold off a few days though, wait until the gen2 date picker stabilizes. As it, while much less stable then the current date picker, it will work with the new event system and css resources, which will make it more useable for you in the long run. Cheers, Emily > > > -- Ed > > > > > > > On Sep 25, 12:44 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote: > > Are you extending MonthSelector or DatePickerComponent? MonthSelector is > > public, so if you are extending that, could you create an issue, as that > > should darn well work, though you will have to create a new subclass of > > DatePicker to use your new month selector as well. > > > > On Wed, Sep 24, 2008 at 6:00 PM, Ed <[EMAIL PROTECTED]> wrote: > > > > > Why is the class DatePickerComponent of the DatePicker protected ? I > > > want to add my own MonthSelector, but when I do this, it throws an > > > access exception because this class it protected :( > > > > -- > > "There are only 10 types of people in the world: Those who understand > > binary, and those who don't" > > > -- "There are only 10 types of people in the world: Those who understand binary, and those who don't" --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
Ed,
Extending MonthSelector definitely is possible. I have this:
public class MyDatePicker extends DatePIcker {
public MyDatePIcker() {
super(new MyMonthSelector(), new SimpleCalendarView(), new CalendarModel());
}
static class MyMonthSelector extends MonthSelector {
...
}
}
And it doesn't give me any problems.
Would it be possible for you to post your modified DatePickerDemo to
show us where that exception is coming from?
Thanks,
Isaac
On Thu, Sep 25, 2008 at 9:22 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>>
>> The same error occurs when I extend the MonthSelector. Please verify
>> this?
>
> I will see if I can get it to repro, thanks!
>
>
> >
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3681 - in trunk/user: src/com/google/gwt/user/client/impl test/com/google/gwt/user/client/ui
Author: [EMAIL PROTECTED]
Date: Thu Sep 25 06:25:15 2008
New Revision: 3681
Modified:
trunk/user/src/com/google/gwt/user/client/impl/HistoryImplSafari.java
trunk/user/test/com/google/gwt/user/client/ui/HistoryTest.java
Log:
Fixes Safari history issues stemming from setting location.hash to the empty
string.
Patch by: jgw
Review by: jat
Issues: 2905, 2909
Modified:
trunk/user/src/com/google/gwt/user/client/impl/HistoryImplSafari.java
==
--- trunk/user/src/com/google/gwt/user/client/impl/HistoryImplSafari.java
(original)
+++ trunk/user/src/com/google/gwt/user/client/impl/HistoryImplSafari.java
Thu Sep 25 06:25:15 2008
@@ -59,9 +59,9 @@
@Override
protected void nativeUpdate(String historyToken) {
if (isOldSafari) {
- nativeUpdateImpl(historyToken);
+ oldNativeUpdate(historyToken);
} else {
- super.nativeUpdate(historyToken);
+ newNativeUpdate(historyToken);
}
}
@@ -79,7 +79,16 @@
@com.google.gwt.user.client.impl.HistoryImpl::fireHistoryChangedImpl(Ljava/lang/String;)($wnd.__gwt_historyToken);
}-*/;
- private native void nativeUpdateImpl(String historyToken) /*-{
+ private native void newNativeUpdate(String historyToken) /*-{
+// Safari gets into a weird state (issue 2905) when setting the hash
+// component of the url to an empty string, but works fine as long as
you
+// at least add a '#' to the end of the url. So we get around this by
+// recreating the url, rather than just setting location.hash.
+$wnd.location = $wnd.location.href.split('#')[0] + '#' +
+
[EMAIL PROTECTED]::encodeFragment(Ljava/lang/String;)(historyToken);
+ }-*/;
+
+ private native void oldNativeUpdate(String historyToken) /*-{
// Use a bizarre meta refresh trick to update the url's hash, without
// creating a history entry.
var meta = $doc.createElement('meta');
Modified: trunk/user/test/com/google/gwt/user/client/ui/HistoryTest.java
==
--- trunk/user/test/com/google/gwt/user/client/ui/HistoryTest.java
(original)
+++ trunk/user/test/com/google/gwt/user/client/ui/HistoryTest.java Thu Sep
25 06:25:15 2008
@@ -15,13 +15,15 @@
*/
package com.google.gwt.user.client.ui;
+import java.util.ArrayList;
+
+import com.google.gwt.dom.client.Document;
+import com.google.gwt.dom.client.Element;
import com.google.gwt.junit.client.GWTTestCase;
import com.google.gwt.user.client.History;
import com.google.gwt.user.client.HistoryListener;
import com.google.gwt.user.client.Timer;
-import java.util.ArrayList;
-
/**
* Tests for the history system.
*
@@ -275,6 +277,33 @@
}
});
History.newItem(token);
+ }
+
+ /**
+ * Test that using an empty history token works properly. There have been
+ * problems (see issue 2905) with this in the past on Safari.
+ */
+ public void testEmptyHistoryToken() {
+final ArrayList counter = new ArrayList();
+
+addHistoryListenerImpl(new HistoryListener() {
+ public void onHistoryChanged(String historyToken) {
+counter.add(new Object());
+assertFalse("Browser is borked by empty history token",
isBorked());
+ }
+});
+
+History.newItem("x");
+History.newItem("");
+
+assertEquals("Expected two history events", 2, counter.size());
+ }
+
+ // Used by testEmptyHistoryToken() to catch a bizarre failure mode on
Safari.
+ private static boolean isBorked() {
+Element e = Document.get().createDivElement();
+e.setInnerHTML("string");
+return e.getInnerHTML().length() == 0;
}
@Override
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: a code review - issues2905_2909_r3674.patch
As far as I can tell, both 2905 and 2909 are fixed by this patch. Committed as r3681. On Wed, Sep 24, 2008 at 2:41 PM, Joel Webber <[EMAIL PROTECTED]> wrote: > Glad to hear it. The patch is against trunk, but we can always merge it > down into 1.5 if necessary. > > > On Wed, Sep 24, 2008 at 2:40 PM, Sam Gross <[EMAIL PROTECTED]> wrote: > >> FWIW, the patch fixes issue 2905 for me. >> What version of GWT will this patch target? >> -Sam >> >> On Wed, Sep 24, 2008 at 1:51 PM, Joel Webber <[EMAIL PROTECTED]> wrote: >> >>> John, >>> I'd like you to have a look at the following changes to Safari's history >>> implementation. They're meant to work around the bizarre issues caused by >>> setting Safari's location.hash to an empty string. Please pay particular >>> attention to the ugly URL rewriting code I added to HistoryImplSafari. >>> >>> Patch by: jgw >>> Review by: jat >>> Issues: 2905, 2909 >>> Affected files: >>> M user/test/com/google/gwt/user/client/ui/HistoryTest.java >>> M user/src/com/google/gwt/user/client/impl/HistoryImplSafari.java >>> >>> >>> >>> >>> >> > --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
> > > The same error occurs when I extend the MonthSelector. Please verify > this? I will see if I can get it to repro, thanks! --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: RR: 1.6 Event handler proposal
> > > This MouseHandler would, internally, add the 6 different types of > mouse event handlers. > Well, ideally you would have one handler instance which you implemented all the handler methods on, but that is besides the point, an easy way to add multiple logically grouped handlers to objects would definitely be worth it. We are exploring a couple of ways to do that right now, but the fall back is providing handler adapters for at least key and mouse events. Once we nail down the current design, those convenience methods will be built on top of what we already have. --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Testtime audit of CSS used for GWT widgets.
It would be possible to do something like this, but we would have to find a
sneaky way to get this implemented such that it goes away entirely when
*not* testing. All of the style methods currently get inlined out of
existence by design, and we definitely couldn't afford to lose that for
production apps.
Side note: Most of the methods in the old DOM interface just pass through to
their equivalent Element methods, so it would still only be necessary to
change them in one place.
On Wed, Sep 24, 2008 at 2:59 PM, Paul Hammant <[EMAIL PROTECTED]> wrote:
> The idea would be for me to be able to assert that a change has occured.
> Imagine the simplest implementation of this would be a string buffer.
>
> assertFalse(recorder.toString().contains("\nStyle changed");
> myWidget.doSomething();
> assertTrue(recorder.toString().contains("\nStyle changed");
> assertJournalledStylesExistInCSSResource(recorder.toString(),
> cssResource);
>
> If you can journal changes for more than styles, all the better. If you
> can bake-in (partial) xpath then that'd be great too.
>
> - Paul
>
>
> On Sep 24, 2008, at 11:36 AM, Ray Ryan wrote:
>
>
>> [+ Google-Web-Toolkit-Contributors, and Scott and Joel in particular]
>>
>> So the idea here is to add a hook that allows an observer to keep a
>> log of CSS operations? Why just CSS and not DOM operations in general?
>>
>> The DOM class itself is probably the wrong place, as I believe it's
>> all but deprecated by the com.google.gwt.dom.client package. It would
>> also be good if a facility like this were in a spot that is accessible
>> to testing code only.
>>
>> Perhaps Scott or Joel could offer guidance on what hooks to establish
>> where?
>>
>> rjrjr
>>
>> On Wed, Sep 24, 2008 at 10:03 AM, Paul Hammant <[EMAIL PROTECTED]>
>> wrote:
>>
>>> It would be nice in a test, to do
>>>
>>> DOM.journalCSSChanges(myCSSRecorder);
>>>
>>> // my GWTTestCase logic
>>>
>>> CSSChanges ccsc = myCSSRecorder.getCSSChanges();
>>>
>>> // validate against a CSS file resource
>>>
>>> // assert the right transitions happened during the test.
>>>
>>> ---
>>>
>>> Why? Well because we're increasingly testing functionality in GWT tests,
>>> and not validating any modifications of the DOM in any way. It would be
>>> too
>>> brittle to go deep here, but would be nice to assert things line "one and
>>> only one style changes happened". "all styles used have matching entries
>>> in
>>> a given resource"
>>>
>>> Thoughts?
>>>
>>> - Paul
>>>
>>>
>>>
>> >>
>>
>
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: wrapping existing element too restrictive maybe....
On 24 sep, 17:13, Ed <[EMAIL PROTECTED]> wrote:
> Thanks Joel,
>
> I think I understand you but let me overview my situation and fire
> some questions.
>
> My situation is legal situation I think:
> I have a man part of the page that I want to use to show some static
> information. There for I put the main page aside like explained above
> and add the HTML text widget that is then shown. The user then simple
> toggles between the two.
Two options:
Some HTML
...
// Initialize the GWT part
RootPanel.get("b").add(...);
...
// toggle between the two parts
RootPanel.get("a").setVisible(false);
RootPanel.get("b").setVisible(true);
or:
Some HTML
...
// Initialize the GWT part
RootPanel.get("container").add(myPanel);
...
// toggle
RootPanel.get("a").setVisible(false);
myPanel.setVisible(true);
No need to detach/attach your components/elements.
(note that instead of creating a RootPanel for the static HTML part,
you can also use:
UIObject.setVisible(Document.get().getElementById("a"), false);
)
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
I made a little mistake in my last post above. I am not extending the DatePickerComponent as I write above, as you can also see in the example code and the text below it. -- Ed --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] [google-web-toolkit commit] r3680 - changes/jat/oophm-branch/plugins/xpcom
Author: [EMAIL PROTECTED]
Date: Thu Sep 25 00:38:37 2008
New Revision: 3680
Modified:
changes/jat/oophm-branch/plugins/xpcom/FFSessionHandler.cpp
changes/jat/oophm-branch/plugins/xpcom/JavaObject.cpp
Log:
Checkpoint XPCOM plugin that completely passes HostedTest, including
toString.
There are still some issues to resolve:
1) freeing Java values is disabled, because the JavaObject wrapper can get
finalized after the session is disconnected, in which case it points to
invalid data.
2) when running a long stream of tests, I get a weird crash just trying to
convert a value to a string for debugging. Even with firefox debug
symbols
loaded, without a debug compile it is hard to tell what is going wrong
as
the optimization hampers debugging.
3) the argument stack could be improved, and tied into a fix for #1 above.
However, I think the general outline is close enough that people can start
taking a look at it to go into branches/oophm.
Modified: changes/jat/oophm-branch/plugins/xpcom/FFSessionHandler.cpp
==
--- changes/jat/oophm-branch/plugins/xpcom/FFSessionHandler.cpp (original)
+++ changes/jat/oophm-branch/plugins/xpcom/FFSessionHandler.cpp Thu Sep 25
00:38:37 2008
@@ -96,7 +96,6 @@
}
// TODO(jat): what to do here?
}
- Debug::log(Debug::Info) << "toStringTearOff=" << JS_ValueToString(ctx,
toStringTearOff) << Debug::flush;
}
FFSessionHandler::~FFSessionHandler(void) {
Modified: changes/jat/oophm-branch/plugins/xpcom/JavaObject.cpp
==
--- changes/jat/oophm-branch/plugins/xpcom/JavaObject.cpp (original)
+++ changes/jat/oophm-branch/plugins/xpcom/JavaObject.cpp Thu Sep 25
00:38:37 2008
@@ -26,15 +26,15 @@
static JSClass JavaObjectClass = {
"GWTJavaObject", /* class name */
- JSCLASS_HAS_PRIVATE | JSCLASS_HAS_RESERVED_SLOTS(1), // |
JSCLASS_NEW_ENUMERATE, /* flags */
+ JSCLASS_HAS_PRIVATE | JSCLASS_HAS_RESERVED_SLOTS(1) |
JSCLASS_NEW_ENUMERATE, /* flags */
JS_PropertyStub, /* add property */
JS_PropertyStub, /* delete property */
JavaObject::getProperty, /* get property */
JavaObject::setProperty, /* set property */
- JS_EnumerateStub, //
reinterpret_cast(JavaObject::enumerate), /* enumerate */
- JS_ResolveStub, // JavaObject::resolve, /* resolve */
+ reinterpret_cast(JavaObject::enumerate), /* enumerate */
+ JS_ResolveStub, /* resolve */
JS_ConvertStub, // JavaObject::convert, /* convert */
JavaObject::finalize, /* finalize */ //TODO
@@ -86,11 +86,13 @@
Debug::log(Debug::Error) << "Could not set reserved slot" <<
Debug::flush;
return NULL;
}
- // define toString (TODO: some way to avoid doing this each time)
-// if (!JS_DefineFunction(ctx, obj, "toString", JavaObject::toString, 0,
0)) {
-//Debug::log(Debug::Error) << "Could not define toString method on
object"
-//<< Debug::flush;
-// }
+ // define toString (TODO: some way to avoid doing this each time)
+#if 1
+ if (!JS_DefineFunction(ctx, obj, "toString", JavaObject::toString, 0,
0)) {
+Debug::log(Debug::Error) << "Could not define toString method on
object"
+<< Debug::flush;
+ }
+#endif
return obj;
}
@@ -99,20 +101,21 @@
SessionData* data = JavaObject::getSessionData(ctx, obj);
int objectRef = JavaObject::getObjectId(ctx, obj);
if (JSVAL_IS_STRING(id)) {
-// only support toString
JSString* str = JSVAL_TO_STRING(id);
-Debug::log(Debug::Error) << "Getting string property "
-<< JS_ValueToString(ctx, id) << Debug::flush;
#if 1
if ((JS_GetStringLength(str) == 8) && !strncmp("toString",
JS_GetStringBytes(str), 8)) {
*vp = data->getToStringTearOff();
- Debug::log(Debug::Info) << "toString tear-off returned for JavaObj("
- << objectRef << ").toString: " << JS_ValueToString(ctx, *vp)
- << Debug::flush;
+ return JS_TRUE;
+}
+if ((JS_GetStringLength(str) == 2) && !strncmp("id",
+ JS_GetStringBytes(str), 2)) {
+ *vp = INT_TO_JSVAL(objectRef);
return JS_TRUE;
}
#endif
+Debug::log(Debug::Error) << "Getting unexpected string property "
+<< JS_ValueToString(ctx, id) << Debug::flush;
return JS_FALSE;
}
if (!JSVAL_IS_INT(id)) {
@@ -154,31 +157,8 @@
return JS_TRUE;
}
-// TODO(jat): is this actually needed, as we don't instantiate lazy
properties?
-JSBool JavaObject::resolve(JSContext* ctx, JSObject* obj, jsval id) {
- Debug::log(Debug::Spam) << "JavaObject::resolve obj=" << obj << "
(objId="
- << JavaObject::getObjectId(ctx, obj) << "), id="
- << JS_ValueToString(ctx, id) << Debug::flush;
-#if 0
- if (JSVAL_IS_INT(id)) {
-// dispatch id
-return JS_TRUE;
- } else if (JSVAL_IS_STRING(id)) {
-// currently only support toString
-JSString* str = JS
[gwt-contrib] Re: DatePicker DatePickerComponent protected ?
I am extending the DatePickerComponent directly, as the MonthSelector
isn't very usable.
I have added the implementation for setAllowableDateRange() as I only
want people to be able to select years.
I am extending the SimpleMonthSelector:
public class MyMonthSelector extends SimpleMonthSelector {
The same error occurs when I extend the MonthSelector. Please verify
this?
I do get this error:
[ERROR] Uncaught exception escaped
java.lang.IllegalAccessError: tried to access class
com.google.gwt.widgetideas.datepicker.client.DatePickerComponent from
class com.google.gwt.demos.datepicker.client.DatePickerDemo
$MyMonthSelector
at com.google.gwt.demos.datepicker.client.DatePickerDemo
$MyMonthSelector.access$0(DatePickerDemo.java:1)
at com.google.gwt.demos.datepicker.client.DatePickerDemo
$MyMonthSelector$2.onClick(DatePickerDemo.java:404)
at
com.google.gwt.user.client.ui.ClickListenerCollection.fireClick(ClickListenerCollection.java:
34)
I think in general the DatePicker should be made more usable. Here are
a few things I don't understand:
- I am not allowed to use the DatePicker.Styles class. Why not ? As I
want to use it in my own selector just like happens in the
SimpleMonthSelector.
- The SimpleMonthSelector isn't usable. The method should be splitup
in smaller protected methods such that this functionality can be used
and the subclass can compose his own functionality. I am case I need
to only change the listeners but those are set in the setup, such that
I need to override the whole setup, but I need the other functionality
in setup for the buttons and stuff and the styles, especially as this
latter one is needed as I can't access the Style class (previous
point).
- Why do I need to subclass DatePicker to use my own MonthSelector?...
Why is this DatePicker constructor protected and not public ?
I am thinking about copying the whole DatePicker to my own space as I
can't use it like this :(... but I do want to use it...
-- Ed
On Sep 25, 12:44 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> Are you extending MonthSelector or DatePickerComponent? MonthSelector is
> public, so if you are extending that, could you create an issue, as that
> should darn well work, though you will have to create a new subclass of
> DatePicker to use your new month selector as well.
>
> On Wed, Sep 24, 2008 at 6:00 PM, Ed <[EMAIL PROTECTED]> wrote:
>
> > Why is the class DatePickerComponent of the DatePicker protected ? I
> > want to add my own MonthSelector, but when I do this, it throws an
> > access exception because this class it protected :(
>
> --
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
