GWT 1.5 RC2 includes a number of enhancements and fixes above and beyond those included in the first release candidate. Please see the release notes included in the installation archive for details. We will be continuing to update the public documentation and posting further fun technical details on the Google Web Toolkit blog soon:
Hi, I just un-Tared the Linux version and it generates this error:
tar: gwt-linux-1.5.1/doc: Not found in archive
tar: Error exit delayed from previous errors
On Aug 12, 8:48 pm, "Bruce Johnson" <br...@google.com> wrote:
> GWT 1.5 RC2 includes a number of enhancements and fixes above and beyond
> those included in the first release candidate. Please see the release notes
> included in the installation archive for details. We will be continuing to
> update the public documentation and posting further fun technical details on
> the Google Web Toolkit blog soon:
I updated from 1.5 RC1 to 1.5 RC2 and RPC stopped working in hosted
browser, because client generates differend hash codes for classes and
so server can't find .gwt.rpc file. Compiled version works fine. I
checked all libs twice and I see no problem on my side. Any hint?
2008-08-13 10:27:44,395 INFO / - ERROR: The serialization policy file
'/gofer/gui/A518A9F1A9E3C9FE6760F7DC389F98B1.gwt.rpc' was not found;
did you forget to include it in this deployment?
2008-08-13 10:27:44,396 INFO / - WARNING: Failed to get the
SerializationPolicy 'A518A9F1A9E3C9FE6760F7DC389F98B1' for module
'http://localhost:8080/gofer/gui/'; a legacy, 1.3.3 compatible,
serialization policy will be used. You may experience
SerializationExceptions as a result.
2008-08-13 10:27:44,445 WARN / - Exception while dispatching incoming
RPC call
com.google.gwt.user.client.rpc.SerializationException: Type
'com.mwaysolutions.gofer2.client.dto.pipeline.GetChannelsResult' was
not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and
did not have a custom field serializer. For security purposes, this
type will not be serialized.
at
com.google.gwt.user.server.rpc.impl.LegacySerializationPolicy.validateSeria lize(LegacySerializationPolicy.java:
140)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.seriali ze(ServerSerializationStreamWriter.java:
585)
I have client and server projects separated. Model objects for both
server and client are the same, except for transient fields.
Thanks for help in advance!
I assume that by hash code you mean the strong name of the serialization policy file. The fact that this changed should not cause a problem if you updated both the client and server to 1.5 RC2.
On Wed, Aug 13, 2008 at 4:36 AM, Martin <m.zd...@gmail.com> wrote:
> hello
> I updated from 1.5 RC1 to 1.5 RC2 and RPC stopped working in hosted > browser, because client generates differend hash codes for classes and > so server can't find .gwt.rpc file. Compiled version works fine. I > checked all libs twice and I see no problem on my side. Any hint?
> 2008-08-13 10:27:44,395 INFO / - ERROR: The serialization policy file > '/gofer/gui/A518A9F1A9E3C9FE6760F7DC389F98B1.gwt.rpc' was not found; > did you forget to include it in this deployment? > 2008-08-13 10:27:44,396 INFO / - WARNING: Failed to get the > SerializationPolicy 'A518A9F1A9E3C9FE6760F7DC389F98B1' for module > 'http://localhost:8080/gofer/gui/'; a legacy, 1.3.3 compatible, > serialization policy will be used. You may experience > SerializationExceptions as a result. > 2008-08-13 10:27:44,445 WARN / - Exception while dispatching incoming > RPC call > com.google.gwt.user.client.rpc.SerializationException: Type > 'com.mwaysolutions.gofer2.client.dto.pipeline.GetChannelsResult' was > not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and > did not have a custom field serializer. For security purposes, this > type will not be serialized. > at
> com.google.gwt.user.server.rpc.impl.LegacySerializationPolicy.validateSeria lize(LegacySerializationPolicy.java: > 140) > at
> I have client and server projects separated. Model objects for both > server and client are the same, except for transient fields. > Thanks for help in advance!
I had updated both client and server GWT libraries and recompiled
client and restarted server. For sure I had also deleted old GWT 1.5
RC1 before. Then I tested on linux and my college on windows, but both
behaved in the same way described above. What has changed in RPC since
1.5 RC1? When debugging I see request from the client with such hash
that <hash>.gwt.rpc doesn't exist on the server. What classes/methods
should I debug to give you more information?
On Aug 13, 2:52 pm, "Miguel Méndez" <mmen...@google.com> wrote:
> I assume that by hash code you mean the strong name of the serialization
> policy file. The fact that this changed should not cause a problem if you
> updated both the client and server to 1.5 RC2.
Would it be worth mentioning in the release notes that you completely removed public static void onHistoryChanged(String historyToken) from the History class between 1.5.0 and 1.5.1? I mean, it's been there since 1.0.
Now you can write a history token without firing the listeners, but you can't fire the listeners without writing a history token. I'm sure there must be a good reason for the change, but I can't think of one.
What is the recommended debugging technique when it works in hosted
mode but not in browser mode?
I seem to have a problem adding items to a Tree, or more specifically,
a Map that holds extra meta data. No issues in hosted mode, breaks in
browser mode. Also works fine with RC1
On Aug 12, 8:48 pm, "Bruce Johnson" <br...@google.com> wrote:
> GWT 1.5 RC2 includes a number of enhancements and fixes above and beyond
> those included in the first release candidate. Please see the release notes
> included in the installation archive for details. We will be continuing to
> update the public documentation and posting further fun technical details on
> the Google Web Toolkit blog soon:
I've also got bitten by this problem, and have not found a solution to it yet. I have a file in the public web directory called <hashvalue>.gwt.rpc, however when gwt loads the SerializationPolicy, the strongname is another hashvalue. Where does the strongname come from?
I've you solve it, please report back your solution.
> I updated from 1.5 RC1 to 1.5 RC2 and RPC stopped working in hosted > browser, because client generates differend hash codes for classes and > so server can't find .gwt.rpc file. Compiled version works fine. I > checked all libs twice and I see no problem on my side. Any hint?
> 2008-08-13 10:27:44,395 INFO / - ERROR: The serialization policy file > '/gofer/gui/A518A9F1A9E3C9FE6760F7DC389F98B1.gwt.rpc' was not found; > did you forget to include it in this deployment? > 2008-08-13 10:27:44,396 INFO / - WARNING: Failed to get the > SerializationPolicy 'A518A9F1A9E3C9FE6760F7DC389F98B1' for module > 'http://localhost:8080/gofer/gui/'; a legacy, 1.3.3 compatible, > serialization policy will be used. You may experience > SerializationExceptions as a result. > 2008-08-13 10:27:44,445 WARN / - Exception while dispatching incoming > RPC call > com.google.gwt.user.client.rpc.SerializationException: Type > 'com.mwaysolutions.gofer2.client.dto.pipeline.GetChannelsResult' was > not assignable to 'com.google.gwt.user.client.rpc.IsSerializable' and > did not have a custom field serializer. For security purposes, this > type will not be serialized. > at > com.google.gwt.user.server.rpc.impl.LegacySerializationPolicy.validateSeria lize(LegacySerializationPolicy.java: > 140) > at > com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.seriali ze(ServerSerializationStreamWriter.java: > 585)
> I have client and server projects separated. Model objects for both > server and client are the same, except for transient fields. > Thanks for help in advance!
-- Med vänlig hälsning, Hugo Hallqvist Dokad Software AB www.dokad.se
I'm not sure which extraction utility you're using to untar the distribution, but if it offers a preview of what is included in the tar file, can you verify that the 'doc' folder is listed? If not, you might want to try downloading the GWT 1.5 RC2 distro one more time as it's possible that the current version you're trying to untar was corrupted during the download process.
> Hi, I just un-Tared the Linux version and it generates this error: > tar: gwt-linux-1.5.1/doc: Not found in archive > tar: Error exit delayed from previous errors
> On Aug 12, 8:48 pm, "Bruce Johnson" <br...@google.com> wrote: > > Hi everyone,
> > I'd like to announce that we've posted a second release candidate > > for GWT 1.5 on the downloads page here:
> > GWT 1.5 RC2 includes a number of enhancements and fixes above and beyond > > those included in the first release candidate. Please see the release > notes > > included in the installation archive for details. We will be continuing > to > > update the public documentation and posting further fun technical details > on > > the Google Web Toolkit blog soon:
Something you might want to double-check is that the .gwt-cache folder
generated during hosted mode runs and GWT compiles is deleted. I'm not
positive that this is what's causing this particular problem, but it could
be that some meta info stored in the .gwt-cache directory is misinforming
hosted mode that the new <md5>.gwt.rpc file isn't available.
> I had updated both client and server GWT libraries and recompiled
> client and restarted server. For sure I had also deleted old GWT 1.5
> RC1 before. Then I tested on linux and my college on windows, but both
> behaved in the same way described above. What has changed in RPC since
> 1.5 RC1? When debugging I see request from the client with such hash
> that <hash>.gwt.rpc doesn't exist on the server. What classes/methods
> should I debug to give you more information?
> On Aug 13, 2:52 pm, "Miguel Méndez" <mmen...@google.com> wrote:
> > I assume that by hash code you mean the strong name of the serialization
> > policy file. The fact that this changed should not cause a problem if
> you
> > updated both the client and server to 1.5 RC2.
I've cc'ed Joel to see if he can shed some more light on why this change occurred. The only reason I could think of that would make the removal of onHistoryChanged from the History class a good thing is the fact that it seems like it wouldn't make too much sense to fire history listeners without writing a history token, but I guess there's no reason to take away flexibility that was always there for that one-off case where this ability is actually useful.
In any case, we should definitely add the method removal to the release notes if this change sticks.
Cheers, -Sumit Chandel
On 8/13/08, Ian Bambury <ianbamb...@gmail.com> wrote:
> Would it be worth mentioning in the release notes that you completely > removed public static void onHistoryChanged(String historyToken) from the > History class between 1.5.0 and 1.5.1? I mean, it's been there since 1.0.
> Now you can write a history token without firing the listeners, but you > can't fire the listeners without writing a history token. > I'm sure there must be a good reason for the change, but I can't think of > one.
One thing you could try is compiling your application using the -style PRETTY flag. That should produce readable JavaScript code that you can debug in, say, FireBug if your application is breaking in Firefox (sub-in whichever other developer extension / plug-in for the browser which your application is breaking). If you can narrow the problem down to the bits of generated JavaScript that are causing the problem, please feel free to post back here or start a new thread with the details.
> What is the recommended debugging technique when it works in hosted > mode but not in browser mode?
> I seem to have a problem adding items to a Tree, or more specifically, > a Map that holds extra meta data. No issues in hosted mode, breaks in > browser mode. Also works fine with RC1
> On Aug 12, 8:48 pm, "Bruce Johnson" <br...@google.com> wrote:
> > Hi everyone,
> > I'd like to announce that we've posted a second release candidate > > for GWT 1.5 on the downloads page here:
> > GWT 1.5 RC2 includes a number of enhancements and fixes above and beyond > > those included in the first release candidate. Please see the release > notes > > included in the installation archive for details. We will be continuing > to > > update the public documentation and posting further fun technical details > on > > the Google Web Toolkit blog soon:
Sumit, thanks for the hint, but I had removed .gwt-cache yet before
without any success. Miguel has mailed me wether I am using -noserver
for testing which I really am. So maybe he has some clues to help me.
I am still waiting for his reply and for the solution. Thanks.
This was actually there by accident originally (for ancient and now irrelevant historical reasons), and we decided (perhaps overzealously) to remove it, because it was difficult to fathom what purpose it would be used for. How exactly were you using it?
On Wed, Aug 13, 2008 at 10:39 AM, Ian Bambury <ianbamb...@gmail.com> wrote: > Would it be worth mentioning in the release notes that you completely > removed public static void onHistoryChanged(String historyToken) from the > History class between 1.5.0 and 1.5.1? I mean, it's been there since 1.0.
> Now you can write a history token without firing the listeners, but you > can't fire the listeners without writing a history token. > I'm sure there must be a good reason for the change, but I can't think of > one.
When history changes (due to the user pressing a browser button) the onHistoryChange fires and I set up state for the app. That's fine.
If someone follows a bookmark to my site (say http://examples.roughian.com/#Panels~Frame) then I need to set up that particular configuration for them, so the last thing I do when creating the site is
History.onHistoryChanged(History.getToken());
You can't do a newItem() because the history item is already set, doesn't change and therefore doesn't fire the onChange event.
That's why I noticed it.
Luckily, all my menus cascade, so the main widget passes the rest of the token to the Panel widget which then displays the Frame page, but there could be situations where there are a number of history listeners responding to different sections of the token.
But as a more general rule, is it a good idea to remove something (especially without consulting the users or even documenting the change when you release it) just because *you* can't think of a way to use it? The GWT team did with setStyleName etc when 1.4 came out and had to backtrack because you couldn't think of any reason why users might want to remove a style after they had added it.
You are producing a (damn fine) framework, but just because something isn't useful to you when creating a framework, it doesn't mean that it isn't useful when *using* a framework.
And you'll never guess all the ways people use what you provide. I'm currently using a DVD as a drinks coaster, and a hard disk as a paperweight.
> This was actually there by accident originally (for ancient and now > irrelevant historical reasons), and we decided (perhaps overzealously) to > remove it, because it was difficult to fathom what purpose it would be used > for. How exactly were you using it?
> On Wed, Aug 13, 2008 at 10:39 AM, Ian Bambury <ianbamb...@gmail.com>wrote:
>> Would it be worth mentioning in the release notes that you completely >> removed public static void onHistoryChanged(String historyToken) from the >> History class between 1.5.0 and 1.5.1? I mean, it's been there since 1.0.
>> Now you can write a history token without firing the listeners, but you >> can't fire the listeners without writing a history token. >> I'm sure there must be a good reason for the change, but I can't think of >> one.
I do see your point, although I should point out that the setStyleName() fiasco was an attempt to reconcile two API's that couldn't safely coexist with one-another (i.e. setStyleName() really just blows away everything done by the others, and vice versa -- but we just had to give up on protecting people from that situation). In this case, History.onHistoryChanged() was a complete accident -- though I see how it could be useful. @scottb, jat: When we decided to pull this out, I think we probably overstepped a bit. Would either of you object to putting it back?
On Thu, Aug 14, 2008 at 8:34 AM, Ian Bambury <ianbamb...@gmail.com> wrote: > Hi Joel,
> I was using it like this:
> When history changes (due to the user pressing a browser button) the > onHistoryChange fires and I set up state for the app. That's fine.
> If someone follows a bookmark to my site (say > http://examples.roughian.com/#Panels~Frame) then I need to set up that > particular configuration for them, so the last thing I do when creating the > site is
> History.onHistoryChanged(History.getToken());
> You can't do a newItem() because the history item is already set, doesn't > change and therefore doesn't fire the onChange event.
> That's why I noticed it.
> Luckily, all my menus cascade, so the main widget passes the rest of the > token to the Panel widget which then displays the Frame page, but there > could be situations where there are a number of history listeners responding > to different sections of the token.
> But as a more general rule, is it a good idea to remove something > (especially without consulting the users or even documenting the change when > you release it) just because *you* can't think of a way to use it? The GWT > team did with setStyleName etc when 1.4 came out and had to backtrack > because you couldn't think of any reason why users might want to remove a > style after they had added it.
> You are producing a (damn fine) framework, but just because something isn't > useful to you when creating a framework, it doesn't mean that it isn't > useful when *using* a framework.
> And you'll never guess all the ways people use what you provide. I'm > currently using a DVD as a drinks coaster, and a hard disk as a paperweight.
>> This was actually there by accident originally (for ancient and now >> irrelevant historical reasons), and we decided (perhaps overzealously) to >> remove it, because it was difficult to fathom what purpose it would be used >> for. How exactly were you using it?
>> On Wed, Aug 13, 2008 at 10:39 AM, Ian Bambury <ianbamb...@gmail.com>wrote:
>>> Would it be worth mentioning in the release notes that you completely >>> removed public static void onHistoryChanged(String historyToken) from >>> the History class between 1.5.0 and 1.5.1? I mean, it's been there since >>> 1.0.
>>> Now you can write a history token without firing the listeners, but you >>> can't fire the listeners without writing a history token. >>> I'm sure there must be a good reason for the change, but I can't think of >>> one.
>> Stuff the environment - Print this email >> _______________________________________
On Thu, Aug 14, 2008 at 11:31 AM, Joel Webber <j...@google.com> wrote: > @scottb, jat: When we decided to pull this out, I think we probably > overstepped a bit. Would either of you object to putting it back?
In the previous implementation, things would get confused if you called it in certain scenarios on certain browsers. I think the way it is currently implemented, it should always be safe to call HistoryImpl.fireHistoryChanged to just trigger the handlers. One question that remains is should that set the current token or not (both GWT's idea of it and the URL, or just one of them) -- otherwise it seems like you could get anomalous behavior, but it seems like we would need to do lots of testing to make sure things still worked properly across all platforms.
I am not opposed to adding the functionality, just saying that I don't think it is a trivial addition. Also, I don't really like the name -- it seems like it should be fireOnHistoryChanged or similar.
-- John A. Tamplin Software Engineer (GWT), Google
Q: What is the "right" way to make sure the initial history token takes effect without necessarily writing additional code? I think the answer to that question determines the right course of action. Adding it back, deprecating it, and documenting the appropriate solution might be one good solution.
On Thu, Aug 14, 2008 at 11:31 AM, Joel Webber <j...@google.com> wrote: > I do see your point, although I should point out that the setStyleName() > fiasco was an attempt to reconcile two API's that couldn't safely coexist > with one-another (i.e. setStyleName() really just blows away everything done > by the others, and vice versa -- but we just had to give up on protecting > people from that situation). In this case, History.onHistoryChanged() was a > complete accident -- though I see how it could be useful. > @scottb, jat: When we decided to pull this out, I think we probably > overstepped a bit. Would either of you object to putting it back?
> On Thu, Aug 14, 2008 at 8:34 AM, Ian Bambury <ianbamb...@gmail.com> wrote:
>> Hi Joel,
>> I was using it like this:
>> When history changes (due to the user pressing a browser button) the >> onHistoryChange fires and I set up state for the app. That's fine.
>> If someone follows a bookmark to my site (say >> http://examples.roughian.com/#Panels~Frame) then I need to set up that >> particular configuration for them, so the last thing I do when creating the >> site is
>> History.onHistoryChanged(History.getToken());
>> You can't do a newItem() because the history item is already set, doesn't >> change and therefore doesn't fire the onChange event.
>> That's why I noticed it.
>> Luckily, all my menus cascade, so the main widget passes the rest of the >> token to the Panel widget which then displays the Frame page, but there >> could be situations where there are a number of history listeners responding >> to different sections of the token.
>> But as a more general rule, is it a good idea to remove something >> (especially without consulting the users or even documenting the change when >> you release it) just because *you* can't think of a way to use it? The GWT >> team did with setStyleName etc when 1.4 came out and had to backtrack >> because you couldn't think of any reason why users might want to remove a >> style after they had added it.
>> You are producing a (damn fine) framework, but just because something >> isn't useful to you when creating a framework, it doesn't mean that it isn't >> useful when *using* a framework.
>> And you'll never guess all the ways people use what you provide. I'm >> currently using a DVD as a drinks coaster, and a hard disk as a paperweight.
>>> This was actually there by accident originally (for ancient and now >>> irrelevant historical reasons), and we decided (perhaps overzealously) to >>> remove it, because it was difficult to fathom what purpose it would be used >>> for. How exactly were you using it?
>>> On Wed, Aug 13, 2008 at 10:39 AM, Ian Bambury <ianbamb...@gmail.com>wrote:
>>>> Would it be worth mentioning in the release notes that you completely >>>> removed public static void onHistoryChanged(String historyToken) from >>>> the History class between 1.5.0 and 1.5.1? I mean, it's been there since >>>> 1.0.
>>>> Now you can write a history token without firing the listeners, but you >>>> can't fire the listeners without writing a history token. >>>> I'm sure there must be a good reason for the change, but I can't think >>>> of one.
>>> Stuff the environment - Print this email >>> _______________________________________
> One thing you could try is compiling your application using the -style > PRETTY flag. That should produce readable JavaScript code that you can debug > in, say, FireBug if your application is breaking in Firefox (sub-in > whichever other developer extension / plug-in for the browser which your > application is breaking). If you can narrow the problem down to the bits of > generated JavaScript that are causing the problem, please feel free to post > back here or start a new thread with the details.
>> What is the recommended debugging technique when it works in hosted >> mode but not in browser mode?
>> I seem to have a problem adding items to a Tree, or more specifically, >> a Map that holds extra meta data. No issues in hosted mode, breaks in >> browser mode. Also works fine with RC1
>> On Aug 12, 8:48 pm, "Bruce Johnson" <br...@google.com> wrote:
>> > Hi everyone,
>> > I'd like to announce that we've posted a second release candidate >> > for GWT 1.5 on the downloads page here:
>> > GWT 1.5 RC2 includes a number of enhancements and fixes above and beyond >> > those included in the first release candidate. Please see the release >> notes >> > included in the installation archive for details. We will be continuing >> to >> > update the public documentation and posting further fun technical >> details on >> > the Google Web Toolkit blog soon:
Here's another idea: What if, at the moment you add a history listener, that listener gets a synchronous callback with the current history token? Wouldn't that "do the right thing" in almost every case and remove the former need for onHistoryChanged to get the first event? I'm guessing a significant number of history-based GWT apps navigate back/forward correctly but fail the bookmark test due to not processing the initial token; this would most likely fix them.
Meanwhile, apps that are handling it correctly would get a compile error against onHistoryChanged. I guess the missing piece in this scheme would be a way to tell those developers that it's not needed any longer?
Either way, this definitely will need a release-notes callout.
On Thu, Aug 14, 2008 at 1:54 PM, Scott Blum <sco...@google.com> wrote: > Q: What is the "right" way to make sure the initial history token takes > effect without necessarily writing additional code? > I think the answer to that question determines the right course of action. > Adding it back, deprecating it, and documenting the appropriate solution > might be one good solution.
> On Thu, Aug 14, 2008 at 11:31 AM, Joel Webber <j...@google.com> wrote:
>> I do see your point, although I should point out that the setStyleName() >> fiasco was an attempt to reconcile two API's that couldn't safely coexist >> with one-another (i.e. setStyleName() really just blows away everything done >> by the others, and vice versa -- but we just had to give up on protecting >> people from that situation). In this case, History.onHistoryChanged() was a >> complete accident -- though I see how it could be useful. >> @scottb, jat: When we decided to pull this out, I think we probably >> overstepped a bit. Would either of you object to putting it back?
>> On Thu, Aug 14, 2008 at 8:34 AM, Ian Bambury <ianbamb...@gmail.com>wrote:
>>> Hi Joel,
>>> I was using it like this:
>>> When history changes (due to the user pressing a browser button) the >>> onHistoryChange fires and I set up state for the app. That's fine.
>>> If someone follows a bookmark to my site (say >>> http://examples.roughian.com/#Panels~Frame) then I need to set up that >>> particular configuration for them, so the last thing I do when creating the >>> site is
>>> History.onHistoryChanged(History.getToken());
>>> You can't do a newItem() because the history item is already set, doesn't >>> change and therefore doesn't fire the onChange event.
>>> That's why I noticed it.
>>> Luckily, all my menus cascade, so the main widget passes the rest of the >>> token to the Panel widget which then displays the Frame page, but there >>> could be situations where there are a number of history listeners responding >>> to different sections of the token.
>>> But as a more general rule, is it a good idea to remove something >>> (especially without consulting the users or even documenting the change when >>> you release it) just because *you* can't think of a way to use it? The GWT >>> team did with setStyleName etc when 1.4 came out and had to backtrack >>> because you couldn't think of any reason why users might want to remove a >>> style after they had added it.
>>> You are producing a (damn fine) framework, but just because something >>> isn't useful to you when creating a framework, it doesn't mean that it isn't >>> useful when *using* a framework.
>>> And you'll never guess all the ways people use what you provide. I'm >>> currently using a DVD as a drinks coaster, and a hard disk as a paperweight.
>>>> This was actually there by accident originally (for ancient and now >>>> irrelevant historical reasons), and we decided (perhaps overzealously) to >>>> remove it, because it was difficult to fathom what purpose it would be used >>>> for. How exactly were you using it?
>>>> On Wed, Aug 13, 2008 at 10:39 AM, Ian Bambury <ianbamb...@gmail.com>wrote:
>>>>> Would it be worth mentioning in the release notes that you completely >>>>> removed public static void onHistoryChanged(String historyToken) from >>>>> the History class between 1.5.0 and 1.5.1? I mean, it's been there since >>>>> 1.0.
>>>>> Now you can write a history token without firing the listeners, but you >>>>> can't fire the listeners without writing a history token. >>>>> I'm sure there must be a good reason for the change, but I can't think >>>>> of one.
>>>> Stuff the environment - Print this email >>>> _______________________________________
That'll still mess with apps like mine which call onHistoryChanged on the *listener* to initialize state. I'll get a double dose. Just something to be aware of. And it wouldn't hurt to have an addHistoryListener(HistoryListener listener, boolean initialize) to specifically request that I *not* receive the current token in case I'm messing with listeners in the normal course of operations.
On Thu, Aug 14, 2008 at 2:48 PM, Scott Blum <sco...@google.com> wrote: > Here's another idea: > What if, at the moment you add a history listener, that listener gets a > synchronous callback with the current history token? Wouldn't that "do the > right thing" in almost every case and remove the former need for > onHistoryChanged to get the first event? I'm guessing a significant number > of history-based GWT apps navigate back/forward correctly but fail the > bookmark test due to not processing the initial token; this would most > likely fix them. > Meanwhile, apps that are handling it correctly would get a compile error > against onHistoryChanged. I guess the missing piece in this scheme would be > a way to tell those developers that it's not needed any longer? > Either way, this definitely will need a release-notes callout.
> On Thu, Aug 14, 2008 at 1:54 PM, Scott Blum <sco...@google.com> wrote:
>> Q: What is the "right" way to make sure the initial history token takes >> effect without necessarily writing additional code? >> I think the answer to that question determines the right course of action. >> Adding it back, deprecating it, and documenting the appropriate solution >> might be one good solution.
>> On Thu, Aug 14, 2008 at 11:31 AM, Joel Webber <j...@google.com> wrote:
>>> I do see your point, although I should point out that the setStyleName() >>> fiasco was an attempt to reconcile two API's that couldn't safely coexist >>> with one-another (i.e. setStyleName() really just blows away everything done >>> by the others, and vice versa -- but we just had to give up on protecting >>> people from that situation). In this case, History.onHistoryChanged() was a >>> complete accident -- though I see how it could be useful. >>> @scottb, jat: When we decided to pull this out, I think we probably >>> overstepped a bit. Would either of you object to putting it back?
>>> On Thu, Aug 14, 2008 at 8:34 AM, Ian Bambury <ianbamb...@gmail.com> >>> wrote:
>>>> Hi Joel,
>>>> I was using it like this:
>>>> When history changes (due to the user pressing a browser button) the >>>> onHistoryChange fires and I set up state for the app. That's fine.
>>>> If someone follows a bookmark to my site (say >>>> http://examples.roughian.com/#Panels~Frame) then I need to set up that >>>> particular configuration for them, so the last thing I do when creating the >>>> site is
>>>> You can't do a newItem() because the history item is already set, >>>> doesn't change and therefore doesn't fire the onChange event.
>>>> That's why I noticed it.
>>>> Luckily, all my menus cascade, so the main widget passes the rest of the >>>> token to the Panel widget which then displays the Frame page, but there >>>> could be situations where there are a number of history listeners responding >>>> to different sections of the token.
>>>> But as a more general rule, is it a good idea to remove something >>>> (especially without consulting the users or even documenting the change when >>>> you release it) just because *you* can't think of a way to use it? The GWT >>>> team did with setStyleName etc when 1.4 came out and had to backtrack >>>> because you couldn't think of any reason why users might want to remove a >>>> style after they had added it.
>>>> You are producing a (damn fine) framework, but just because something >>>> isn't useful to you when creating a framework, it doesn't mean that it isn't >>>> useful when *using* a framework.
>>>> And you'll never guess all the ways people use what you provide. I'm >>>> currently using a DVD as a drinks coaster, and a hard disk as a paperweight.
>>>>> This was actually there by accident originally (for ancient and now >>>>> irrelevant historical reasons), and we decided (perhaps overzealously) to >>>>> remove it, because it was difficult to fathom what purpose it would be used >>>>> for. How exactly were you using it?
>>>>> On Wed, Aug 13, 2008 at 10:39 AM, Ian Bambury <ianbamb...@gmail.com> >>>>> wrote:
>>>>>> Would it be worth mentioning in the release notes that you completely >>>>>> removed public static void onHistoryChanged(String historyToken) from the >>>>>> History class between 1.5.0 and 1.5.1? I mean, it's been there since 1.0.
>>>>>> Now you can write a history token without firing the listeners, but >>>>>> you can't fire the listeners without writing a history token. >>>>>> I'm sure there must be a good reason for the change, but I can't think >>>>>> of one.
>>>>> Stuff the environment - Print this email >>>>> _______________________________________
This is exactly the case I have to specifically code for (initial token), and the implementation I had to change when this method got dropped.
(I realize there may be code out there that would break under this proposal, but I agree that getting the initial token case to "just work" is important)
Fred On 8/14/08, Scott Blum <sco...@google.com> wrote:
> Here's another idea: > What if, at the moment you add a history listener, that listener gets a > synchronous callback with the current history token? Wouldn't that "do the > right thing" in almost every case and remove the former need for > onHistoryChanged to get the first event? I'm guessing a significant number > of history-based GWT apps navigate back/forward correctly but fail the > bookmark test due to not processing the initial token; this would most > likely fix them.
> Meanwhile, apps that are handling it correctly would get a compile error > against onHistoryChanged. I guess the missing piece in this scheme would be > a way to tell those developers that it's not needed any longer?
> Either way, this definitely will need a release-notes callout.
> On Thu, Aug 14, 2008 at 1:54 PM, Scott Blum <sco...@google.com> wrote:
>> Q: What is the "right" way to make sure the initial history token takes >> effect without necessarily writing additional code? >> I think the answer to that question determines the right course of action. >> Adding it back, deprecating it, and documenting the appropriate solution >> might be one good solution.
>> On Thu, Aug 14, 2008 at 11:31 AM, Joel Webber <j...@google.com> wrote:
>>> I do see your point, although I should point out that the setStyleName() >>> fiasco was an attempt to reconcile two API's that couldn't safely coexist >>> with one-another (i.e. setStyleName() really just blows away everything >>> done >>> by the others, and vice versa -- but we just had to give up on protecting >>> people from that situation). In this case, History.onHistoryChanged() was >>> a >>> complete accident -- though I see how it could be useful. >>> @scottb, jat: When we decided to pull this out, I think we probably >>> overstepped a bit. Would either of you object to putting it back?
>>> On Thu, Aug 14, 2008 at 8:34 AM, Ian Bambury <ianbamb...@gmail.com>wrote:
>>>> Hi Joel,
>>>> I was using it like this:
>>>> When history changes (due to the user pressing a browser button) the >>>> onHistoryChange fires and I set up state for the app. That's fine.
>>>> If someone follows a bookmark to my site (say >>>> http://examples.roughian.com/#Panels~Frame) then I need to set up that >>>> particular configuration for them, so the last thing I do when creating >>>> the >>>> site is
>>>> You can't do a newItem() because the history item is already set, >>>> doesn't >>>> change and therefore doesn't fire the onChange event.
>>>> That's why I noticed it.
>>>> Luckily, all my menus cascade, so the main widget passes the rest of the >>>> token to the Panel widget which then displays the Frame page, but there >>>> could be situations where there are a number of history listeners >>>> responding >>>> to different sections of the token.
>>>> But as a more general rule, is it a good idea to remove something >>>> (especially without consulting the users or even documenting the change >>>> when >>>> you release it) just because *you* can't think of a way to use it? The >>>> GWT >>>> team did with setStyleName etc when 1.4 came out and had to backtrack >>>> because you couldn't think of any reason why users might want to remove >>>> a >>>> style after they had added it.
>>>> You are producing a (damn fine) framework, but just because something >>>> isn't useful to you when creating a framework, it doesn't mean that it >>>> isn't >>>> useful when *using* a framework.
>>>> And you'll never guess all the ways people use what you provide. I'm >>>> currently using a DVD as a drinks coaster, and a hard disk as a >>>> paperweight.
>>>>> This was actually there by accident originally (for ancient and now >>>>> irrelevant historical reasons), and we decided (perhaps overzealously) >>>>> to >>>>> remove it, because it was difficult to fathom what purpose it would be >>>>> used >>>>> for. How exactly were you using it?
>>>>> On Wed, Aug 13, 2008 at 10:39 AM, Ian Bambury >>>>> <ianbamb...@gmail.com>wrote:
>>>>>> Would it be worth mentioning in the release notes that you completely >>>>>> removed public static void onHistoryChanged(String historyToken) from >>>>>> the History class between 1.5.0 and 1.5.1? I mean, it's been there >>>>>> since >>>>>> 1.0.
>>>>>> Now you can write a history token without firing the listeners, but >>>>>> you >>>>>> can't fire the listeners without writing a history token. >>>>>> I'm sure there must be a good reason for the change, but I can't think >>>>>> of one.
>>>>> Stuff the environment - Print this email >>>>> _______________________________________
On Thu, Aug 14, 2008 at 2:55 PM, Isaac Truett <itru...@gmail.com> wrote:
> That'll still mess with apps like mine which call onHistoryChanged on > the *listener* to initialize state. I'll get a double dose. Just > something to be aware of. And it wouldn't hurt to have an > addHistoryListener(HistoryListener listener, boolean initialize) to > specifically request that I *not* receive the current token in case > I'm messing with listeners in the normal course of operations.
Good points. Let me take another stab at this then...
1) We add History.fireCurrentHistoryState() or something like it; the recommended way to ensure all your listeners get the initial state token at the end of onModuleLoad.
2) We deprecate onHistoryChanged() but leave it in to avoid breaking; it simply fires the provided token to all attached listeners with no internal state change. The deprecation doc suggests fireCurrentHistoryState().
3) Maybe, we add the addHistoryListener(HistoryListener listener, boolean fireCurrentHistoryState), which does what you might imagine, and leave the existing addHistoryListener alone.
On Thu, Aug 14, 2008 at 3:22 PM, Scott Blum <sco...@google.com> wrote: > On Thu, Aug 14, 2008 at 2:55 PM, Isaac Truett <itru...@gmail.com> wrote:
>> That'll still mess with apps like mine which call onHistoryChanged on >> the *listener* to initialize state. I'll get a double dose. Just >> something to be aware of. And it wouldn't hurt to have an >> addHistoryListener(HistoryListener listener, boolean initialize) to >> specifically request that I *not* receive the current token in case >> I'm messing with listeners in the normal course of operations.
> Good points. Let me take another stab at this then... > 1) We add History.fireCurrentHistoryState() or something like it; the > recommended way to ensure all your listeners get the initial state token at > the end of onModuleLoad. > 2) We deprecate onHistoryChanged() but leave it in to avoid breaking; it > simply fires the provided token to all attached listeners with no internal > state change. The deprecation doc suggests fireCurrentHistoryState(). > 3) Maybe, we add the addHistoryListener(HistoryListener listener, boolean > fireCurrentHistoryState), which does what you might imagine, and leave the > existing addHistoryListener alone. > Thoughts?
What I want (what I had) is a way to fire the listeners with the current history token.
Being able to call them with a different token but not have a history item written was useful, too (i.e. I can put the app in a state which I don't want in the history stack) but that is not strictly history, is it?
So if we're not going to get onHistoryChanged() back, I expect I'll end up rolling my own AppStateChangeListener and call that from a single history listener.
But 1) would be halfway between 1.5.1 and what all the other versions had. Which is less of a backward step from my point of view.
If you are gong to change it then 2) doesn't matter.
3) seems no use whatsoever since it means you have to keep track of the order you add history listeners so you can make the last one fire with the 'true' option. and you may not alway know.
On Thu, Aug 14, 2008 at 3:22 PM, Scott Blum <sco...@google.com> wrote:> > Good points. Let me take another stab at this then...
> 1) We add History.fireCurrentHistoryState() or something like it; the > recommended way to ensure all your listeners get the initial state token at > the end of onModuleLoad.
> 2) We deprecate onHistoryChanged() but leave it in to avoid breaking; it > simply fires the provided token to all attached listeners with no internal > state change. The deprecation doc suggests fireCurrentHistoryState().
> 3) Maybe, we add the addHistoryListener(HistoryListener listener, boolean > fireCurrentHistoryState), which does what you might imagine, and leave the > existing addHistoryListener alone. > Thoughts?
