[gwt-contrib] incubator and compatability with gwt 2.1

[Cameron Braid]

What is the plan to bring incubator into compatability with gwt 2.1 ?

Cheers

Cameron

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] incubator and gwt 2.1

[Cameron Braid]

What is the plan to bring incubator into compatability with gwt 2.1 ?

Cheers

Cameron

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] gwt-incubator version compatible with GWT 2.1

[Cameron Braid]

Just curious when the gwt-incubator will become compatible with GWT 2.1?

Cameron

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

[gwt-contrib] Re: Prettier GWT version names for upcoming 2.0 releases

[Cameron Braid]

JBoss use a naming scheme that sorts alphabetically, maybe it is worth
considering

http://www.jboss.org/jbossas/downloads/

Applied to the names in the original email

1) gwt-2.0.0-m1.zip
2) gwt-2.0.0-m2.zip
3) gwt-2.0.0-rc1.zip
4) gwt-2.0.0.zip

They could be :

1) gwt-2.0.0-Beta1.zip (or could just use B1)
2) gwt-2.0.0-Beta2.zip
3) gwt-2.0.0-CR1.zip  (candidate for release)
4) gwt-2.0.0-GA.zip

Cam




2009/8/28 Andrew Bowers 

> The current problem we are trying to solve is that it is hard to know which
> build is a major release for those who aren't intimate.
> For 1.6, the golden release was 1.6.4, which is thoroughly confusing to a
> general user who doesn't follow the development cycle. If you only care
> about the final release, you expect that you would migrate to 1.6.0 as the
> final release and 1.6.1 would be an update to that.
>
> If someone is commenting
> on a bug in a pre-release build, something labeled 1.6.0-RC1, then they will 
> know what build they are using. If they don't, then they probably shouldn't 
> be using it.
>
> I strongly believe this use case trumps the other issues.
>
> On Thu, Aug 13, 2009 at 12:01 PM, Scott Blum  wrote:
>
>> On Thu, Aug 13, 2009 at 2:41 PM, Kelly Norton  wrote:
>>
>>> fwiw, I've never found myself sorting GWT distros but I do find myself
>>> wanting to uniquely identify them all the time. Why do you think people will
>>> be so eager to ignore part of the label? I would actually be surprised if
>>> any form of naming fixes the few incidences of the conversation you mention.
>>> I tend to think those are because people really do think they are using the
>>> release ... only to realize later they never updated their project.
>>>
>>
>> Heh, sorry, that was probably not the best way of making this point: I
>> think more obvious is usually better, because you don't have to think about
>> it.  This means less wasted time, and less chance of confusion.
>>
>> Don't get me wrong, I'm not saying the current system is perfect or that
>> we shouldn't change it.  I'm sure there are better things than we're doing
>> right now, which might help with the problem of identifying a release vs. a
>> milestone or rc.  But I do think a system where the numeric portion of the
>> version is non-unique invites confusion.
>>
>> What if we were more consistent with the parentheticals, like in the GWT 
>> release
>> notes
>> ?
>>
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Inlining nocache.js

[Cameron Braid]

I'd be keen to see this land in trunk !

Cam

2009/8/7 John Tamplin 

> On Fri, Aug 7, 2009 at 3:51 AM, George Georgovassilis <
> g.georgovassi...@gmail.com> wrote:
>
>>
>> I'd like to save first time visitors that roundtrip to fetch
>> nocache.js. Instead I've declared the module HTML page as non-
>> cacheable (works nice thanks to E-Tag) and moved images and GWT-
>> compiler output to a fully cacheable directory.
>>
>> After inlining nocache.js into the module HTML I had to change the
>> paths to the XYZ.cache.html permutations, but couldn't get RPC to work
>> reliably across all browsers.
>>
>> Is there a way to do this cleanly?
>>
>
> There is a Google-internal linker that does this, and will be cleaned up
> and moved to GWT itself in the near future.  I don't know an exact timeframe
> for this however.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: naming runAsync calls

[Cameron Braid]

All good points.

Would interfaces be supported as well ?

Are there any dangers of allowing arbitrary classes (or interfaces) to be
used as monikers ?

i.e from your example, would there be anything wrong with using
EmailCompositionView.class as the moniker ?

void onComposeButtonClicked() {
>  GWT.runAsync(EmailCompositionView.class, new AsyncCallback() {
>public void onError(Throwable e) { ... }
>   public void onSucess() {
> new EmailCompositionView().activate();
> }
>   });
>>
>>
I guess the compiler would have to verify that each call to runAsync uses a
unique moniker - is there anything else ?

Must the moniker class exists in your own module ?

Would you only allow leaf classes to be used as monikers, i.e. could you use
OfficeSuiteSplitPoint.class as a moniker ?

Cam

2009/6/25 Bruce Johnson 

> Four additional arguments in favor of using "split point moniker classes"
> is that they
> 1) are easier to find within an IDE (i.e. "Show References" in your IDE
> from a moniker class declaration would show you the associated runAsync
> call),
> 2) can take advantage of inheritance as a way to group split points into
> meaningful families (which would make them more easily browsable and
> navigable in javadoc and in an IDE),
> 3) can be javadoc'ed to explain what they do, and
> 4) they could potentially be augmented with additional hints to the code
> splitter using annotations (these are a stretch; Lex might be able to think
> of more realistic example annotations)
>
> /**
>  * Split points in this hierarchy relate to the email functionality within
> the office suite.
>  */
> class EmailSplitPoint extends OfficeSuiteSplitPoint {
> }
>
> /**
>  * This split point carves out all heavyweight functionality related to
> composing emails,
>  * most importantly, the rich text area clases.
>  */
> @ProhibitPreloading
> @MustBeExclusiveFragment
> class EmailCompositionSplitPoint extends EmailSplitPoint {
> }
>
> // ... elsewhere ...
>
> void onComposeButtonClicked() {
>   GWT.runAsync(EmailCompositionSplitPoint.class, new AsyncCallback() {
> public void onError(Throwable e) { ... }
> public void onSucess() {
>   new EmailCompositionView().activate();
> }
>   });
>
> }
>
> On Wed, Jun 24, 2009 at 6:50 PM, Cameron Braid wrote:
>
>> Each of these different libraries would be enclosed within a unique GWT
>> module therefore when you refer to the split point name, can't you just use
>> the module name + split point name ?
>>
>> in module ThirdParty :
>>
>> GWT.runAsync("one", new RunAsyncCallback() { ... });
>>
>> in MyModule :
>>
>> GWT.runAsync("one", new RunAsyncCallback() { ... });
>>
>> > value="MyModule#one" />
>> > value="ThirdParty#one" />
>>
>> Cam
>>
>> 2009/6/25 Lex Spoon 
>>
>>
>>> On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoon wrote:
>>> > Overall, unless I missed something,
>>>
>>> Okay, Bruce pointed out a new constraint to me: if different libraries
>>> name their runAsync calls, then we want to able to refer to those
>>> calls reliably even if different libraries choose the same name.  This
>>> isn't an issue immediately, but it likely will be in the future.
>>>
>>> Thinking about libraries, I would add another constraint: we don't
>>> want libraries to have to expose their implementation.  Library
>>> writers should ideally be able to document a named runAsync call
>>> without exposing the precise arrangement of their internal classes.
>>>
>>> After some discussion at the office, a tweak to option 4 fixes things
>>> up handily.  Instead of passing in a string to the method, act like a
>>> Java framework and require passing in a class literal.  A typical use
>>> in application code would pass in the enclosing top-level class:
>>>
>>> package org.foodity.impl;
>>> class Cookies {
>>>  ...
>>>  GWT.runAsync(Cookies.class, new RunAsyncCallback() { ... });
>>>  ...
>>> }
>>>
>>> A library writer could instead specify a public class, so as not to
>>> expose their internal factoring.
>>>
>>> A user of the name in a gwt.xml file would use the fully qualified
>>> version:
>>>
>>> >>  name="compiler.splitpoint.initial.sequence"
>>>  value="org.foodity.impl.Cookies" />
>>>
>>> A user in another Java file would use imports to make the name short:
>>>
>>> import org.foodity.impl.Cookies;
>>>
>>> RunAsyncQueue.startPrefetching(Cookies.class);
>>>
>>>
>>> Thoughts?  The main downside I know of is the one John Tamplin has
>>> pointed out: if there are multiple runAsync calls within a single
>>> class -- as sometimes happens -- then the programmer has to code up
>>> some new classes that will only be used for naming.  Can we live with
>>> that?
>>>
>>> Lex
>>>
>>>
>>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: naming runAsync calls

[Cameron Braid]

Each of these different libraries would be enclosed within a unique GWT
module therefore when you refer to the split point name, can't you just use
the module name + split point name ?

in module ThirdParty :

GWT.runAsync("one", new RunAsyncCallback() { ... });

in MyModule :

GWT.runAsync("one", new RunAsyncCallback() { ... });




Cam

2009/6/25 Lex Spoon 

>
> On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoon wrote:
> > Overall, unless I missed something,
>
> Okay, Bruce pointed out a new constraint to me: if different libraries
> name their runAsync calls, then we want to able to refer to those
> calls reliably even if different libraries choose the same name.  This
> isn't an issue immediately, but it likely will be in the future.
>
> Thinking about libraries, I would add another constraint: we don't
> want libraries to have to expose their implementation.  Library
> writers should ideally be able to document a named runAsync call
> without exposing the precise arrangement of their internal classes.
>
> After some discussion at the office, a tweak to option 4 fixes things
> up handily.  Instead of passing in a string to the method, act like a
> Java framework and require passing in a class literal.  A typical use
> in application code would pass in the enclosing top-level class:
>
> package org.foodity.impl;
> class Cookies {
>  ...
>  GWT.runAsync(Cookies.class, new RunAsyncCallback() { ... });
>  ...
> }
>
> A library writer could instead specify a public class, so as not to
> expose their internal factoring.
>
> A user of the name in a gwt.xml file would use the fully qualified version:
>
>   name="compiler.splitpoint.initial.sequence"
>  value="org.foodity.impl.Cookies" />
>
> A user in another Java file would use imports to make the name short:
>
> import org.foodity.impl.Cookies;
>
> RunAsyncQueue.startPrefetching(Cookies.class);
>
>
> Thoughts?  The main downside I know of is the one John Tamplin has
> pointed out: if there are multiple runAsync calls within a single
> class -- as sometimes happens -- then the programmer has to code up
> some new classes that will only be used for naming.  Can we live with
> that?
>
> Lex
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: naming runAsync calls

[Cameron Braid]

You could always change the signiture of  GWT.runAsync to include a String
parameter as the first parameter.  I must be a literal in code, and would be
optimized out / ignored by the compiler :

   GWT.runAsync("foo", new RunAsyncCallback() {

Cam


2009/6/20 Lex Spoon 

>
> There are multiple reasons that people end up wanting a way to name
> calls to runAsync.  One of them is the specification of an initial
> load sequence that I just implemented.  Looking ahead, they would be
> useful for prefetch requests.  It's hard to say "download fragment Foo
> if you can", if you don't have a way to name fragment "Foo".
>
>
> To name the calls, ideal would be if a Java annotation could be put on
> the method call.  Unfortunately, Java annotations cannot currently be
> placed on a method call.  One fallback would be to annotate the class
> that is passed into the call.  This is problematic, too, however,
> because in Java 5 and 6 you can't annotate an anonymous inner class.
>
> As a next best approach, what would people think of annotating the
> surrounding method?  In practice, there is only one runAsync call
> within a single method.  We could, at least to start with, insist that
> any named runAsync must be in its own method.  Note that this is never
> a real constraint on people's code, because they can always split out
> a large method into two smaller ones, each of which has its own
> runAsync call.  It would look like this:
>
>  @RunAsyncName("CwBasicButton")
>  @Override
>  protected void asyncOnInitialize(final AsyncCallback callback) {
>GWT.runAsync(new RunAsyncCallback() {
>
>  public void onFailure(Throwable caught) {
>callback.onFailure(caught);
>  }
>
>  public void onSuccess() {
>callback.onSuccess(onInitialize());
>  }
>});
>  }
>
>
> Since typical programs have well under 100 calls to runAsync, I don't
> think any sort of hierarchical naming scheme is necessary.  Simple
> identifiers, such as "CwBasicButton", look like they would work.
>
> This looks like a straightforward and easily understood way to name
> calls to runAsync.  What do others think?
>
> Lex
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Changing JsArray to JsArray

[Cameron Braid]

Unfortunately I wasn't able to attend Google I/O, however I did watch a few
of the sessions online.

I signed up for the sandbox, but it appears that google aren't going to
grant access to non IO attendees for a little while yet.

I'd appreciate an invite, but I understand if that's not feasible.

Cheers

Cameron

2009/6/17 Ray Cromwell 

> Cameron, were you at Google I/O or did you sign up for the sandbox? I can
> ask a Googler to invite you if not.
> -Ray
>
>
> On Mon, Jun 15, 2009 at 6:21 PM, Cameron Braid wrote:
>
>>
>> 2009/6/16 Bruce Johnson 
>>
>>> I'm starting to make a bit o' progress on this. I'll send out a design
>>> doc "real soon now".
>>>
>>> BTW, anyone on the Contributors list here have Wave sandbox accounts?
>>> Sure would be easier to discuss this in a wave...
>>>
>>
>> No :(
>>
>> But if you are offering invites, send one this way :)  Otherwise, its
>> probably wise to keep the discussion in a place where all interested parties
>> can participate.
>>
>>
>> Cam
>>
>>
>>
>>
>>
>>
>>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Changing JsArray to JsArray

[Cameron Braid]

2009/6/16 Bruce Johnson 

> I'm starting to make a bit o' progress on this. I'll send out a design doc
> "real soon now".
>
> BTW, anyone on the Contributors list here have Wave sandbox accounts? Sure
> would be easier to discuss this in a wave...
>

No :(

But if you are offering invites, send one this way :)  Otherwise, its
probably wise to keep the discussion in a place where all interested parties
can participate.


Cam

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] I've submitted a new issue with a patch for a bug in IFrameLinker which causes HTML Parsing Error (KB927917) in IE8/IE7/IE6

[Cameron Braid]

The issues arises because the selection script mutates the DOM by inserting
an iframe element into the body before the body tag has completed.

The only time this issue arises is when the compiled script completes
loading before the host page finished loading.

i.e. there are two sequences of events that can occur, and only one exibits
the bug :

This one avoids the bug (and is the most frequent occurance due to timings)

* host page starts loading
* selection script starts loading
* selection script XHR begins to load the compiled script
* host page completes loading which closes the BODY
* selection script XHR completes and appends the IFRAME to the BODY

This one exibits the bug :

* host page starts loading
* selection script starts loading
* selection script XHR begins to load the compiled script
* selection script XHR completes and appends the IFRAME to the BODY
* FAIL

The fix changes the flow of events to this :

* host page starts loading
* selection script starts loading
* selection script inserts a DIV element via document.write into the BODY.
This DIV is closed.
* selection script XHR begins to load the compiled script
* selection script XHR completes and appends the IFRAME to the DIV element
avoiding the bug since the new DIV element is closed

http://code.google.com/p/google-web-toolkit/issues/detail?id=3717

Cheers

Cameron

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: gwt TRUNK seems to be to restrictive for what GWT.create can return

[Cameron Braid]

I've updated the patch against the current SVN trunk... And added a 'sanity'
(i..e not very thorough) test method into GwtQueryCoreTest to verify that it
works

Cheers

Cam

2009/5/17 Ray Cromwell 

>
> Ok, i'll check out the patch. I suspect after Google I/O that the # of
> users/contributors will go up a lot, and things will be supported a
> lot better,
>
> -Ray
>
>
> On Sun, May 17, 2009 at 2:28 AM, Cameron Braid 
> wrote:
> > I am checking out the new gwt query code now.
> >
> > I was using a custom patched version of gwtquery 0.3
> > http://code.google.com/p/gwtquery/issues/detail?id=5&can=4
> >
> > So I will just have to re-do this patch before I can continue.
> >
> > Kind Regards
> >
> > Cameron
> >
> > 2009/5/17 Ray Cromwell 
> >>
> >> Cameron,
> >>   Did you check out a recent version of GQuery? I've been checking in
> >> a lot of changes recently because I've revamped it for Google I/O
> >> re-release. It now implements about 98% of all jQuery functions.  I've
> >> haven't looked at the older rebind rules, but there should be a
> >> fall-thru for non-matched browers to SelectorEngineImplJS. But John
> >> could be right, it could be that the fall-thru isn't working and IE8
> >> is resolving to no binding.
> >>
> >> -Ray
> >>
> >>
> >>
> >> On Sat, May 16, 2009 at 7:41 PM, Cameron Braid 
> >> wrote:
> >> > I am tryng gwt trunk r5406 and have run into issues with GWT's
> >> > rebinding.
> >> >
> >> > here are some errors from my different modules :
> >> >
> >> >  [java][ERROR] Errors in
> >> >
> >> >
> 'jar:file:/media/home/cameronbraid/.m2/repository/gwtquery/gwtquery/0.3-a/gwtquery-0.3-a.jar!/gwtquery/client/SelectorEngine.java'
> >> >  [java]   [ERROR] Line 20:  Rebind result
> >> > 'gwtquery.client.impl.SelectorEngineImpl' cannot be abstract
> >> >
> >> >  [java][ERROR] Errors in
> >> >
> >> >
> 'jar:file:/media/home/cameronbraid/.m2/repository/com/google/gwt/incubator/gwt-incubator/r1539/gwt-incubator-r1539.jar!/com/google/gwt/gen2/logging/impl/client/ClientConsoleLogHandlerImpl.java'
> >> >  [java]   [ERROR] Line 206:  Rebind result
> >> >
> >> >
> 'com.google.gwt.gen2.logging.impl.client.ClientConsoleLogHandlerImpl.Impl'
> >> > must be a class
> >> >
> >> >  [java][ERROR] Errors in
> >> >
> >> >
> 'jar:file:/media/home/cameronbraid/.m2/repository/com/extjs/gxt/1.2.2-r1236/gxt-1.2.2-r1236.jar!/com/extjs/gxt/ui/client/widget/form/NumberPropertyEditor.java'
> >> >  [java]   [ERROR] Line 29:  Rebind result
> >> > 'com.google.gwt.i18n.client.constants.NumberConstants' must be a class
> >> >
> >> > These errors didn't occur using an older GWT trunk version r4619
> >> >
> >> > Cheers
> >> >
> >> > Cameron
> >> >
> >> > >
> >> >
> >>
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: gwt TRUNK seems to be to restrictive for what GWT.create can return

[Cameron Braid]

Thanks for the fast reply, and the explanation.

Kind Regards

Cameron


2009/5/17 John Tamplin 

> On Sat, May 16, 2009 at 10:41 PM, Cameron Braid wrote:
>
>> I am tryng gwt trunk r5406 and have run into issues with GWT's rebinding.
>>
>>
>> here are some errors from my different modules :
>>
>>  [java][ERROR] Errors in
>> 'jar:file:/media/home/cameronbraid/.m2/repository/gwtquery/gwtquery/0.3-a/gwtquery-0.3-a.jar!/gwtquery/client/SelectorEngine.java'
>>  [java]   [ERROR] Line 20:  Rebind result
>> 'gwtquery.client.impl.SelectorEngineImpl' cannot be abstract
>>
>>  [java][ERROR] Errors in
>> 'jar:file:/media/home/cameronbraid/.m2/repository/com/google/gwt/incubator/gwt-incubator/r1539/gwt-incubator-r1539.jar!/com/google/gwt/gen2/logging/impl/client/ClientConsoleLogHandlerImpl.java'
>>  [java]   [ERROR] Line 206:  Rebind result
>> 'com.google.gwt.gen2.logging.impl.client.ClientConsoleLogHandlerImpl.Impl'
>> must be a class
>>
>>  [java][ERROR] Errors in
>> 'jar:file:/media/home/cameronbraid/.m2/repository/com/extjs/gxt/1.2.2-r1236/gxt-1.2.2-r1236.jar!/com/extjs/gxt/ui/client/widget/form/NumberPropertyEditor.java'
>>  [java]   [ERROR] Line 29:  Rebind result
>> 'com.google.gwt.i18n.client.constants.NumberConstants' must be a class
>>
>> These errors didn't occur using an older GWT trunk version r4619
>>
>
> The first two are probably running into the IE8 changes (where you need the
> ie8 deferred binding rules for user.agent-sensitive bindings).
>
> The NumberConstants change was due to adding runtime locales support, and
> you should no longer be GWT.create'ing it, but instead use
> LocaleInfo.getCurrentLocale().getNumberConstants().  If you really must do
> GWT.create, you can use NumberConstantsImpl but that is an implementation
> class and may change, and you will lose the ability to use runtime locales.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: gwt TRUNK seems to be to restrictive for what GWT.create can return

[Cameron Braid]

I am checking out the new gwt query code now.

I was using a custom patched version of gwtquery 0.3
http://code.google.com/p/gwtquery/issues/detail?id=5&can=4

So I will just have to re-do this patch before I can continue.

Kind Regards

Cameron

2009/5/17 Ray Cromwell 

>
> Cameron,
>   Did you check out a recent version of GQuery? I've been checking in
> a lot of changes recently because I've revamped it for Google I/O
> re-release. It now implements about 98% of all jQuery functions.  I've
> haven't looked at the older rebind rules, but there should be a
> fall-thru for non-matched browers to SelectorEngineImplJS. But John
> could be right, it could be that the fall-thru isn't working and IE8
> is resolving to no binding.
>
> -Ray
>
>
>
> On Sat, May 16, 2009 at 7:41 PM, Cameron Braid 
> wrote:
> > I am tryng gwt trunk r5406 and have run into issues with GWT's rebinding.
> >
> > here are some errors from my different modules :
> >
> >  [java][ERROR] Errors in
> >
> 'jar:file:/media/home/cameronbraid/.m2/repository/gwtquery/gwtquery/0.3-a/gwtquery-0.3-a.jar!/gwtquery/client/SelectorEngine.java'
> >  [java]   [ERROR] Line 20:  Rebind result
> > 'gwtquery.client.impl.SelectorEngineImpl' cannot be abstract
> >
> >  [java][ERROR] Errors in
> >
> 'jar:file:/media/home/cameronbraid/.m2/repository/com/google/gwt/incubator/gwt-incubator/r1539/gwt-incubator-r1539.jar!/com/google/gwt/gen2/logging/impl/client/ClientConsoleLogHandlerImpl.java'
> >  [java]   [ERROR] Line 206:  Rebind result
> >
> 'com.google.gwt.gen2.logging.impl.client.ClientConsoleLogHandlerImpl.Impl'
> > must be a class
> >
> >  [java][ERROR] Errors in
> >
> 'jar:file:/media/home/cameronbraid/.m2/repository/com/extjs/gxt/1.2.2-r1236/gxt-1.2.2-r1236.jar!/com/extjs/gxt/ui/client/widget/form/NumberPropertyEditor.java'
> >  [java]   [ERROR] Line 29:  Rebind result
> > 'com.google.gwt.i18n.client.constants.NumberConstants' must be a class
> >
> > These errors didn't occur using an older GWT trunk version r4619
> >
> > Cheers
> >
> > Cameron
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] gwt TRUNK seems to be to restrictive for what GWT.create can return

[Cameron Braid]

I am tryng gwt trunk r5406 and have run into issues with GWT's rebinding.

here are some errors from my different modules :

 [java][ERROR] Errors in
'jar:file:/media/home/cameronbraid/.m2/repository/gwtquery/gwtquery/0.3-a/gwtquery-0.3-a.jar!/gwtquery/client/SelectorEngine.java'
 [java]   [ERROR] Line 20:  Rebind result
'gwtquery.client.impl.SelectorEngineImpl' cannot be abstract

 [java][ERROR] Errors in
'jar:file:/media/home/cameronbraid/.m2/repository/com/google/gwt/incubator/gwt-incubator/r1539/gwt-incubator-r1539.jar!/com/google/gwt/gen2/logging/impl/client/ClientConsoleLogHandlerImpl.java'
 [java]   [ERROR] Line 206:  Rebind result
'com.google.gwt.gen2.logging.impl.client.ClientConsoleLogHandlerImpl.Impl'
must be a class

 [java][ERROR] Errors in
'jar:file:/media/home/cameronbraid/.m2/repository/com/extjs/gxt/1.2.2-r1236/gxt-1.2.2-r1236.jar!/com/extjs/gxt/ui/client/widget/form/NumberPropertyEditor.java'
 [java]   [ERROR] Line 29:  Rebind result
'com.google.gwt.i18n.client.constants.NumberConstants' must be a class

These errors didn't occur using an older GWT trunk version r4619

Cheers

Cameron

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Getting oophm working

[Cameron Braid]

>
> BTW, OOPHM in trunk (as of earlier this week) supports HostedMode and the
> war format, and webAppCreator will produce a oophm target in the ant build
> file, so you can run it with just ant oophm.  It does not yet create eclipse
> launch configs for OOPHM, but it shouldn't be hard to figure out --
> basically just add gwt-dev-oophm.jar at the head of the classpath for your
> launch config.
>
>

I've been using OOPHM in trunk for months, and I was under the assumption
that it was HostedMode. (Out of Process HostedMode)

Can you please explain what it means to now support HostedMode with OOPHM ?

Thanks

Cameron

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Please expose moveSelectionUp/Down methods in FastTree

[Cameron Braid]

in gwt incubator's FastTree, moveSelectionUp and moveSelectionDown are both
private.

Please either make these methods protected, so that I can subclass FastTree
and make my own public api to call them, or provide a public API to controll
navigation.

It coudld be as simple as adding these two methods :

public void moveSelectionDown() {
moveSelectionDown(curSelection, true);
}
public void moveSelectionUp() {
moveSelectionUp(curSelection);
}

Alternatively, extract the logic from these methods into public static
helpers which I can call to determine the 'previous' and 'next' elements,
and then I can call setSelectedItem

Cheers

Cameron

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] build issue in trunk with 'ant clean buildonly'

[Cameron Braid]

I use "ant clean buildonly" to quickly build gwt without the examples.
However it fails due to missing folders.

I have created an issue to track it, and attached a patch that fixes it.

http://code.google.com/p/google-web-toolkit/issues/detail?id=3370

Cheers

Cameron

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: branches oophm does not compile

[Cameron Braid]

On Wed, Feb 11, 2009 at 11:46 PM, Sebastien  wrote:

>
> Hi,
>
> Oooh it's great ! It works well. Now I can debug and use firebug in
> the same time !
> Can you confirm me that the trunk will be used for the 1.6 M2 ?
> (It seems the 1.6 M1 does not contains the gwt-*oophm jar).
>

As far as I know trunk will be for gwt 1.7, or 2.0 - whatever it gets
called.


>
> Note: During the compilation of GWT, there are lot of logs indicating
> problem of serialization on java.lang.* classes (or primitive fields).
> Theses logs appears in the compilation of my module too ... :-(
>

The log level for the compiler is too verbose

See the -logLevel  parameter for the Compiler :

  -logLevel  The level of logging detail: ERROR, WARN, INFO, TRACE,
DEBUG, SPAM, or ALL

I found that WARN is comparable to gwt 1.5.x

Cheers

Cameron

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: branches oophm does not compile

[Cameron Braid]

I think John means "just put gwt-dev-*oophm*.jar at the head of your
classpath"

Cam

On Tue, Feb 10, 2009 at 12:37 AM, John Tamplin  wrote:

> It compiles, but it needs JDK 1.6.  Unless you need to run JUnitShell you
> can use trunk, where it has been merged - just put gwt-dev-linux.jar at the
> head of your classpath and run GWTShell.  You will also need a plugin from
> the branch.
>
> j...@google.com (from Android)
>
> On Feb 9, 2009 1:52 AM, "Sebastien"  wrote:
>
>
> Hi,
>
> I am trying to use the OOPHM branch and it does not compile (see logs
> at the end) whereas I compile the trunk with success. Does this branch
> can used to try OOPHM under linux ? (I have critical problems with the
> shell / simulator : it crashes after several action => I posted a
> topic into gwt group)
> I following instructions from this blog:
> http://slashgnu.blogspot.com/2008/10/gwt-hosted-mode-in-firefoxlinux.html
>
> Java version: 1.5.0_15-b04
> Ant version: 1.7.1
>
> Thanks in advance for any help
>
> Regards,
> Seb
>
> Logs of the compilation :
> ==
> -filter.src:
>[mkdir] Created dir: /home/sebastien/work/oophm/google-web-toolkit-
> branches-oophm-read-only/build/out/dev/src-filtered
> [copy] Copying 1 file to /home/sebastien/work/oophm/google-web-
> toolkit-branches-oophm-read-only/build/out/dev/src-filtered
>[touch] Creating /home/sebastien/work/oophm/google-web-toolkit-
> branches-oophm-read-only/build/out/dev/src-filtered/gwt.version-0.0.0
>[mkdir] Created dir: /home/sebastien/work/oophm/google-web-toolkit-
> branches-oophm-read-only/build/out/dev/bin
> [gwt.javac] Compiling 3 source files to /home/sebastien/work/oophm/
> google-web-toolkit-branches-oophm-read-only/build/out/dev/bin
> [gwt.javac] Compiling 1 source file to /home/sebastien/work/oophm/
> google-web-toolkit-branches-oophm-read-only/build/out/dev/bin
> [gwt.javac] Compiling 578 source files to /home/sebastien/work/oophm/
> google-web-toolkit-branches-oophm-read-only/build/out/dev/bin
> [gwt.javac] /home/sebastien/work/oophm/google-web-toolkit-branches-
> oophm-read-only/dev/core/src/com/google/gwt/dev/ModulePanel.java:126:
> cannot find symbol
> [gwt.javac] symbol  : method setTabComponentAt
> (int,com.google.gwt.dev.ModulePanel.ClosedTabComponent)
> [gwt.javac] location: class javax.swing.JTabbedPane
> [gwt.javac] tabs.setTabComponentAt(index, new
> ClosedTabComponent());
> [gwt.javac] ^
> [gwt.javac] Note: Some input files use or override a deprecated API.
> [gwt.javac] Note: Recompile with -Xlint:deprecation for details.
> [gwt.javac] Note: Some input files use unchecked or unsafe operations.
> [gwt.javac] Note: Recompile with -Xlint:unchecked for details.
> [gwt.javac] 1 error
> ==
>
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: code review requested - merge OOPHM hosted.html

[Cameron Braid]

Please also include my one liner patch here

http://code.google.com/p/google-web-toolkit/issues/detail?id=3291&q=reporter:cbraid

Cam

On Sat, Feb 7, 2009 at 8:20 AM, John Tamplin  wrote:

> Updated patch -- I had tested only on my local machine, so I didn't notice
> it wasn't picking up gwt.hosted from the URL properly.
>
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: strange compiler error in trunk

[Cameron Braid]

For the benefit of other ExtGWT users out there - Lex provided a patch that
fixes this issue.  See
http://code.google.com/p/google-web-toolkit/issues/detail?id=3304 for the
patch.

Another issue still exists when using ExtGWT's Window class with gwt trunk
and gwt-1.6.  The fix has been implemented and should be released in a
future version.

Cheers

Cameron

On Fri, Jan 16, 2009 at 7:27 PM, Cameron Braid  wrote:

> using gwt r4486 from trunk
>
> The following compiler error only occurs in my gwt modules that depend on
> ExtGWT.
>
> I don't know why it is looking for an implementation of the method on *
> Object* ?
>
> Any clues on why this is happening ?  Is it a bug ?
>
>  [java][ERROR] An internal compiler exception occurred
>  [java] com.google.gwt.dev.jjs.InternalCompilerException: Could not
> find implementation of public abstract void
> handleEvent(com.extjs.gxt.ui.client.event.BaseEvent)  for class (id=1)
>  [java] public class java.lang.Object
>  [java] extends NULL TYPE
>  [java] /*   fields   */
>  [java] private transient int typeId
>  [java] private transient java.lang.Object typeMarker
>  [java] /*   methods   */
>  [java] public void ()
>  [java] public boolean equals(java.lang.Object)
>  [java] protected void finalize() throws java.lang.Throwable
>  [java] public Class getClass()
>  [java] public int hashCode()
>  [java] public java.lang.String toString()
>  [java]
>  [java]
>  [java] at
> com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.findMethodImplementing(GenerateJavaAST.java:2340)
>  [java] at
> com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.findMethodImplementing(GenerateJavaAST.java:2344)
>  [java] at
> com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.addBridgeMethods(GenerateJavaAST.java:379)
>  [java] at
> com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.addBridgeMethods(GenerateJavaAST.java:372)
>  [java] at
> com.google.gwt.dev.jjs.impl.GenerateJavaAST.exec(GenerateJavaAST.java:3044)
>  [java] at
> com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:339)
>  [java] at
> com.google.gwt.dev.Precompile.precompile(Precompile.java:295)
>  [java] at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:171)
>  [java] at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:141)
>  [java] at
> com.google.gwt.dev.GWTCompiler$1.run(GWTCompiler.java:114)
>  [java] at
> com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:84)
>  [java] at
> com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:78)
>  [java] at
> com.google.gwt.dev.GWTCompiler.main(GWTCompiler.java:117)
>
>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: OOPHM in gwt trunk doesn't like ExtGWT's Viewport class

[Cameron Braid]

Ahh.. yeah. I was using the NPAPI plugin. I didn't realise there were two
plugins.  Thanks for pointing that out.

I switched over to the XPCOM plugin, and it works a treat !

Thanks again.

Cameron

On Wed, Feb 4, 2009 at 6:00 PM, John Tamplin  wrote:

> On Wed, Feb 4, 2009 at 2:57 AM, Cameron Braid wrote:
>
>> Using ExtGWT 1.2.1, with this simple entry point
>>
>> public void onModuleLoad() {
>> Viewport vp = new Viewport();
>> RootPanel.get().add(vp);
>> }
>>
>> causes the module to immediately unload with this message in the firebug
>> console :
>>
>> Bad NPObject as private data!
>>
>>
> Are you using the NPAPI plugin?  If so, it has various issues and isn't
> likely to be fixed.  You should use the XPCOM plugin, though what is
> currently available is only FF3-compatible.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] OOPHM in gwt trunk doesn't like ExtGWT's Viewport class

[Cameron Braid]

Using ExtGWT 1.2.1, with this simple entry point

public void onModuleLoad() {
Viewport vp = new Viewport();
RootPanel.get().add(vp);
}

causes the module to immediately unload with this message in the firebug
console :

Bad NPObject as private data!

The hosted mode interface just sates something like this :

00:01:50.501 [INFO] Unloading module Module (Module)

Other ExtGWT classes seem, to work ok, like this simple example :

public void onModuleLoad() {
ContentPanel cp = new ContentPanel();
cp.setHeading("test");
cp.setSize(200,200);
RootPanel.get().add(cp);
}



Cheers

Cameron

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: strange compiler error in trunk

[Cameron Braid]

Any estimates on the timeframe for fixing this ?

Cam

On Wed, Jan 21, 2009 at 5:32 AM, Lex Spoon  wrote:

>
> On Fri, Jan 16, 2009 at 8:46 PM, Cameron Braid 
> wrote:
> > I am using version 1.2.1
> >
> > I created a new module that triggers the compiler error :
> >
> > 
> > 
> > 
> > 
> > 
> >
> > package error.client;
> > import com.extjs.gxt.ui.client.widget.ContentPanel;
> > import com.google.gwt.core.client.EntryPoint;
> > import com.google.gwt.user.client.ui.RootPanel;
> > public class GwtCompilerErrorEntryPoint implements EntryPoint {
> > public void onModuleLoad() {
> > ContentPanel contentPanel = new ContentPanel();
> > contentPanel.setSize(600, 800);
> > RootPanel.get().add(contentPanel);
> > }
> > }
> >
> > An interesting observation - to trigger the exception all that is
> required
> > is to import ContentPanel. The class doesn't even have to be used.  eg.
> this
> > entry point also causes the error :
> >
> > package error.client;
> > import com.extjs.gxt.ui.client.widget.ContentPanel;
> > import com.google.gwt.core.client.EntryPoint;
> > public class GwtCompilerErrorEntryPoint implements EntryPoint {
> > public void onModuleLoad() {
> > }
> > }
>
> Cool, I can reproduce it now.  I've created an issue to track its progress:
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=3304
>
> -Lex
>
>
> >
> >
> > Regards
> >
> > Cameron.
> >
> >
> > On Sat, Jan 17, 2009 at 9:00 AM, Lex Spoon  wrote:
> >>
> >> On Fri, Jan 16, 2009 at 11:28 AM, Lex Spoon  wrote:
> >> > I'll go download ExtGwt now and try to figure out what's going on.  It
> >> > really should find an implementing method, but the precise way it
> >> > checks must be messed up.
> >>
> >> My initial attempt to repro didn't work.
> >>
> >> Cameron, what precise version of ExtGWT are you using?  I downloaded
> >> 1.2.1 from the web site, added GXT as an inherited module of the Hello
> >> sample module, and then compiled Hello.
> >>
> >> This is with revision 4488 of trunk.
> >>
> >> I'm guessing I have the wrong version of ExtGWT.  Another possibility
> >> is that you have a class in your module that is needed to trigger the
> >> bug.
> >>
> >> Lex
> >>
> >>
> >
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: gwt 1.6 PushButton - please add constructor

[Cameron Braid]

Issue created http://code.google.com/p/google-web-toolkit/issues/detail?id=3314

On Jan 26, 12:20 pm, Cameron Braid  wrote:
> Please add the PushButton(Image,Image,ClickHandler) constructor that
> parities the PushButton(Image,Image,ClickListener) of the deprecated
> listener based event system.
>
> Thanks,
>
> Cameron
>
> ### Eclipse Workspace Patch 1.0
> #P gwt-1.6
> Index: user/src/com/google/gwt/user/client/ui/PushButton.java
> ===
> --- user/src/com/google/gwt/user/client/ui/PushButton.java    (revision
> 4528)
> +++ user/src/com/google/gwt/user/client/ui/PushButton.java    (working copy)
> @@ -104,6 +104,17 @@
>    }
>
>    /**
> +   * Constructor for PushButton.
> +   *
> +   * @param upImage image for the default(up) face of the button
> +   * @param downImage image for the down face of the button
> +   * @param handler ClickHandler
> +   */
> +  public PushButton(Image upImage, Image downImage, ClickHandler handler) {
> +    super(upImage, downImage, listener);
> +  }
> +
> +  /**
>     * Constructor for PushButton. The supplied text is used to
>     * construct the default face of the button.
>     *
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] gwt 1.6 PushButton - please add constructor

[Cameron Braid]

Please add the PushButton(Image,Image,ClickHandler) constructor that
parities the PushButton(Image,Image,ClickListener) of the deprecated
listener based event system.

Thanks,

Cameron

### Eclipse Workspace Patch 1.0
#P gwt-1.6
Index: user/src/com/google/gwt/user/client/ui/PushButton.java
===
--- user/src/com/google/gwt/user/client/ui/PushButton.java(revision
4528)
+++ user/src/com/google/gwt/user/client/ui/PushButton.java(working copy)
@@ -104,6 +104,17 @@
   }

   /**
+   * Constructor for PushButton.
+   *
+   * @param upImage image for the default(up) face of the button
+   * @param downImage image for the down face of the button
+   * @param handler ClickHandler
+   */
+  public PushButton(Image upImage, Image downImage, ClickHandler handler) {
+super(upImage, downImage, listener);
+  }
+
+  /**
* Constructor for PushButton. The supplied text is used to
* construct the default face of the button.
*

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: OOPHM development branches

[Cameron Braid]

It looks to be more serious than a warning.  Immediately after this warning
is printed, the module is unloaded and the oophm plugin is disconnected from
the hosted mode server.

Could it be something to do with my module serializing ArrayList ?

Cam

On Tue, Dec 16, 2008 at 8:40 AM, BobV  wrote:

>
> > This isn't a compiler bug, it's caused by hosted mode being perhaps
> slightly
> > overeager?  The deal is, the custom field serializer for Arrays.asList()
> >
> (com.google.gwt.user.client.rpc.core.java.util.Arrays.ArrayList_CustomFieldSerializer),
> > has a method getArray0() that uses a JSNI reference that's only valid
> > against our own JRE emulation classes... it's not valid against a real
> JRE.
> >  This is okay, because the call to that method is guarded by a
> > GWT.isScript() block.
> > Bob, thoughts?
>
> The problem here is that we need to rewrite the JSNI method with the
> numeric dispatch ids before we inject the code into the browser.
> Previously, dispatch was string-based so it wasn't a problem.  We
> could add an @SuppressWarnings("jsni") to the method to squelch
> warnings like this.
>
> --
> Bob Vawter
> Google Web Toolkit Team
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: OOPHM development branches

[Cameron Braid]

On Mon, Dec 15, 2008 at 9:45 AM, Cameron Braid  wrote:

> b) bug in hosted.html - see overlay-hosted.html.patch
>
> The patch for hosted.html is required because I need gwt to support a url
> encoded gwt.hosted value  My webapp re-writes urls to pass along some query
> string parameters from page to page. It converts 127.0.1.1:9997 into
> 127.0.1.1%3A9997 when it url encodes it, and hosted.html currently doesn't
> unescape it.
>
>
I've added an issue to track this bug.

http://code.google.com/p/google-web-toolkit/issues/detail?id=3291&can=4

Its a pretty simple patch - is someone able to check it out and apply it to
trunk ?

Cheers

Cameron

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: strange compiler error in trunk

[Cameron Braid]

I am using version 1.2.1

I created a new module that triggers the compiler error :







package error.client;
import com.extjs.gxt.ui.client.widget.ContentPanel;
import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.RootPanel;
public class GwtCompilerErrorEntryPoint implements EntryPoint {
public void onModuleLoad() {
ContentPanel contentPanel = new ContentPanel();
contentPanel.setSize(600, 800);
RootPanel.get().add(contentPanel);
}
}

An interesting observation - to trigger the exception all that is required
is to import ContentPanel. The class doesn't even have to be used.  eg. this
entry point also causes the error :

package error.client;
import com.extjs.gxt.ui.client.widget.ContentPanel;
import com.google.gwt.core.client.EntryPoint;
public class GwtCompilerErrorEntryPoint implements EntryPoint {
public void onModuleLoad() {
}
}


Regards

Cameron.


On Sat, Jan 17, 2009 at 9:00 AM, Lex Spoon  wrote:

>
> On Fri, Jan 16, 2009 at 11:28 AM, Lex Spoon  wrote:
> > I'll go download ExtGwt now and try to figure out what's going on.  It
> > really should find an implementing method, but the precise way it
> > checks must be messed up.
>
> My initial attempt to repro didn't work.
>
> Cameron, what precise version of ExtGWT are you using?  I downloaded
> 1.2.1 from the web site, added GXT as an inherited module of the Hello
> sample module, and then compiled Hello.
>
> This is with revision 4488 of trunk.
>
> I'm guessing I have the wrong version of ExtGWT.  Another possibility
> is that you have a class in your module that is needed to trigger the
> bug.
>
> Lex
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] strange compiler error in trunk

[Cameron Braid]

using gwt r4486 from trunk

The following compiler error only occurs in my gwt modules that depend on
ExtGWT.

I don't know why it is looking for an implementation of the method on *
Object* ?

Any clues on why this is happening ?  Is it a bug ?

 [java][ERROR] An internal compiler exception occurred
 [java] com.google.gwt.dev.jjs.InternalCompilerException: Could not find
implementation of public abstract void
handleEvent(com.extjs.gxt.ui.client.event.BaseEvent)  for class (id=1)
 [java] public class java.lang.Object
 [java] extends NULL TYPE
 [java] /*   fields   */
 [java] private transient int typeId
 [java] private transient java.lang.Object typeMarker
 [java] /*   methods   */
 [java] public void ()
 [java] public boolean equals(java.lang.Object)
 [java] protected void finalize() throws java.lang.Throwable
 [java] public Class getClass()
 [java] public int hashCode()
 [java] public java.lang.String toString()
 [java]
 [java]
 [java] at
com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.findMethodImplementing(GenerateJavaAST.java:2340)
 [java] at
com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.findMethodImplementing(GenerateJavaAST.java:2344)
 [java] at
com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.addBridgeMethods(GenerateJavaAST.java:379)
 [java] at
com.google.gwt.dev.jjs.impl.GenerateJavaAST$JavaASTGenerationVisitor.addBridgeMethods(GenerateJavaAST.java:372)
 [java] at
com.google.gwt.dev.jjs.impl.GenerateJavaAST.exec(GenerateJavaAST.java:3044)
 [java] at
com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:339)
 [java] at
com.google.gwt.dev.Precompile.precompile(Precompile.java:295)
 [java] at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:171)
 [java] at com.google.gwt.dev.GWTCompiler.run(GWTCompiler.java:141)
 [java] at
com.google.gwt.dev.GWTCompiler$1.run(GWTCompiler.java:114)
 [java] at
com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:84)
 [java] at
com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:78)
 [java] at com.google.gwt.dev.GWTCompiler.main(GWTCompiler.java:117)

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: OOPHM development branches

[Cameron Braid]

I've been giving OOPHM a try and have run into a couple of issues

a) bug in compiler - see attached oophm-stacktrace.txt

b) bug in hosted.html - see overlay-hosted.html.patch

The patch for hosted.html is required because I need gwt to support a url
encoded gwt.hosted value  My webapp re-writes urls to pass along some query
string parameters from page to page. It converts 127.0.1.1:9997 into
127.0.1.1%3A9997 when it url encodes it, and hosted.html currently doesn't
unescape it.

Cheers

Cameron

On Fri, Dec 12, 2008 at 9:41 AM, John Tamplin  wrote:

> On Thu, Dec 11, 2008 at 6:12 PM, Sam Gross  wrote:
>
>> In which branch is OOPHM development taking place?  I see trunk/dev/oophm,
>> but this project seems to cause compile errors for the gwt-user project,
>> since the version of GWTShell in trunk/dev/oophm is missing some expected
>> methods.
>>
>
> The main code will be maintained in trunk -- the plugins will be in
> branches/oophm while we figure out their long-term location.  The idea is
> that we refactor further to reduce the overlaid classes, and then when we
> are ready we just move the files from gwt-dev-oophm into gwt-dev (doing away
> with the various platforms at the same time).
>
> What errors do you get?  I see dev (core and oophm) build errors depending
> on the Java version I use related to inferring generic types (the fix is to
> assign the result of artifacts.find to a local variable before using it in
> the enhanced for, I haven't tracked down exactly why it works some places or
> others and I have some open changes in that area is why I haven't submitted
> them), but nothing specific to OOPHM.  With those fixed in
> StandardGeneratorContext, GWTShell (both core and oophm),
> SelectionScriptLinker, and StandardLinkerContext, it compiles and runs fine
> for me.
>
>
>> What are the key things that need to be done before OOPHM is the default
>> hosted-mode in trunk?
>>
>
> I think the primary thing is time with people using it so we can feel
> confident that it won't break anyone.  The UI needs some improvement (though
> it is usable as-is), and there are some testing issues that need to be
> addressed.  The reason for putting it in trunk as an overlay is so that
> people could test it without breaking people who couldn't use it for
> whatever reason, and to hopefully keep it up to date as the trunk is
> changed.  There is also the issue of competing priorities, as usual.
>
> Next week I have a task to get it OOPHM usable (in its overlay form) for
> some internal projects, so anything preventing it from being useful as it is
> in trunk currently should be shaken out then.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

00:00:37.355 [WARN] Member 'array' in JSNI reference 
'@java.util.Arrays$ArrayList::array' could not be found; expect subsequent 
failures java.lang.NoSuchFieldError: array
   at 
com.google.gwt.dev.shell.CompilingClassLoader$DispatchClassInfoOracle.getDispId(CompilingClassLoader.java:132)
   at 
com.google.gwt.dev.shell.CompilingClassLoader.getDispId(CompilingClassLoader.java:559)
   at 
com.google.gwt.dev.util.Jsni$JsSourceGenWithJsniIdentFixup.visit(Jsni.java:105)
   at com.google.gwt.dev.js.ast.JsNameRef.traverse(JsNameRef.java:120)
   at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:438)
   at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:413)
   at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:96)
   at 
com.google.gwt.dev.js.JsToStringGenerationVisitor.visit(JsToStringGenerationVisitor.java:694)
   at com.google.gwt.dev.js.ast.JsReturn.traverse(JsReturn.java:45)
   at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:438)
   at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:413)
   at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:96)
   at 
com.google.gwt.dev.js.JsToStringGenerationVisitor.printJsBlockOptionalTruncate(JsToStringGenerationVisitor.java:819)
   at 
com.google.gwt.dev.js.JsSourceGenerationVisitor.visit(JsSourceGenerationVisitor.java:48)
   at com.google.gwt.dev.js.ast.JsBlock.traverse(JsBlock.java:43)
   at com.google.gwt.dev.js.ast.JsVisitor.doTraverse(JsVisitor.java:438)
   at com.google.gwt.dev.js.ast.JsVisitor.doAccept(JsVisitor.java:413)
   at com.google.gwt.dev.js.ast.JsVisitor.accept(JsVisitor.java:96)
   at 
com.google.gwt.dev.util.Jsni.generateJavaScriptForHostedMode(Jsni.java:253)
   at com.google.gwt.dev.util.Jsni.getJavaScriptForHostedMode(Jsni.java:240)
   at 
com.google.gwt.dev.shell.ModuleSpaceOOPHM.createNativeMethods(ModuleSpaceOOPHM.java:50)
   at 
com.google.gwt.dev.shell.CompilingClassLoader.injectJsniFor(CompilingClassLoader.java:736)
   at 
com.google.gwt.dev.shell.CompilingClassLoader.findClass(CompilingClassLoader.java:653)
   at java.lang.ClassLoader.loadClass(Cla

[gwt-contrib] Re: Event handlers committed to 1.6, event listeners deprecated

[Cameron Braid]

What is the plan for merging into trunk ?

Cam

On Tue, Nov 18, 2008 at 3:03 PM, Ray Ryan <[EMAIL PROTECTED]> wrote:

> With r4092, the new event handlers have been committed to the 1.6 branch.
> rjrjr
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] IFrameTemplate.js broken for noserver hosted mode in trunk

[Cameron Braid]

hosted.html expects the querystring to contain only the module strongName
where as it curently contains strongName + ".cache.html"

IFrameTemplate.js in maybeInjectFrame() appends .cache.html to the
strongName (line 298).

Either IFrameTemplate.js needs to not append .cache.html for hostedmode, or
hostd.html needds to strip it out.

A suggested fix (which I have verified in my dev environment) is this :

Index: dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js
===
--- dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js(revision
3953)
+++ dev/core/src/com/google/gwt/core/linker/IFrameTemplate.js(working
copy)
@@ -295,7 +295,7 @@
 millis:(new Date()).getTime(),
 type: 'moduleRequested'
   });
-  iframe.contentWindow.location.replace(base + strongName +
'.cache.html');
+  iframe.contentWindow.location.replace(base + strongName +
strongNameExt);
 }
   }

@@ -351,9 +351,12 @@
   });

   var strongName;
+  var strongNameExt;
   if (isHostedMode()) {
 strongName = "hosted.html?__MODULE_FUNC__";
+strongNameExt = "";
   } else {
+strongNameExt = ".cache.html";
 try {
 // __PERMUTATIONS_BEGIN__
   // Permutation logic

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: runAsync fragment loading bug in IE

[Cameron Braid]

On Fri, Nov 7, 2008 at 4:57 AM, Lex Spoon <[EMAIL PROTECTED]> wrote:

>
> On Thu, Nov 6, 2008 at 4:47 AM, Cameron Braid <[EMAIL PROTECTED]>
> wrote:
> > I presume that the __gwtStartLoadingFragment needs to load the fragment
> into
> > the same document as the function resides, therefore the
> $doc.createElement
> > should probably be changed to document.createElement
>
> That sounds logical to me.  Can you verify that this change fixes
> things for you?  -Lex
>


This change does fix things for me


Cam

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] runAsync fragment loading bug in IE

[Cameron Braid]

in trunk IFrameLinker.getModulePrefix

out.print("function __gwtStartLoadingFragment(frag) {");
out.newlineOpt();
out.indentIn();
out.print("  var script = *$doc*.createElement('script');");
out.newlineOpt();
out.print("  script.src = '" + strongName + "-' + frag + '" +
FRAGMENT_EXTENSION + "';");
out.print("  *document*
.getElementsByTagName('head').item(0).appendChild(script);");

The generated javascript runs fine in firefox and safari, however in IE it
errors due to an invalid argument.

The reason is that the script element is created in a different document
(window.parent.document) to the document it is being added to
(window.document)

I presume that the __gwtStartLoadingFragment needs to load the fragment into
the same document as the function resides, therefore the $doc.createElement
should probably be changed to document.createElement

Cheers,

Cameron

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: RR: runAsync merge to trunk

[Cameron Braid]

Are there any design docs for runAsync ?

Cheers

Cameron

On Sat, Oct 18, 2008 at 2:24 AM, Lex Spoon <[EMAIL PROTECTED]> wrote:

> Hi, Bob,
>
> Can you be the main reviewer for the merge of the runAsync branch to
> the trunk?  The attached patch is the outstanding difference between
> trunk and branch, plus a few minor changes.
>
> The overall structure is like this:
>
> 1. JsProgram no longer has a single global block.  It has a number of
> JsFragments, each of which has its own global JsBlock.  If there are
> no calls to runAsync in the program, then there will be exactly one
> JsFragment.
>
> 2. The linkers are updated for this structure, though most of them
> simply fail if there is more than one fragment.
>
> 3. The ControlFlowAnalyzer refactor is included, described in a previous
> email.
>
> 4. FindDeferredSitesVisitors arranges that, for every call to
> runAsync, there is an AsyncLoader class generated for that call.
>
> 5. ReplaceRunAsync actually replaces calls to runAsync with calls into
> AsyncLoaders.  Each call is associated with its own AsyncLoader class.
>
> 6. GenerateJavaScriptAST now generates a map, JavaToJavaScriptMap,
> that associates Java AST nodes to JavaScript AST nodes.  This should
> eventually be done using information recorded in SourceInfos, now that
> JavaScript nodes have a SourceInfo, but unless you see an immediate
> problem it would be nice to do that in a subsequent patch.
>
> 7. CodeSplitter actually splits the program into fragments.  It relies
> on ControlFlowAnalyzer to decide how to split everything up, and it
> uses FragmentExtractor for the nitty gritty mechanics of extracting a
> fragment of code.  Note that extracting a fragment is a little
> trickier than "this statement in, this statement out".  Extracting
> interned strings is one example that doesn't work like that.
>
>
> I think that's it.  Comments are very welcome, both about the
> implementation and the general design.  I would just ask that we
> remember there is more work to be done, and not everything has to be
> in this one already large patch.
>
> Lex
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: gwt compiler issue in 1.5 branch

[Cameron Braid]

Sorry, my mistake.  I had an old jar on the classpath.

r3683 compiles just fine.

Thanks for pointing this out.

Regards

Cameron

On Sat, Sep 27, 2008 at 3:56 PM, Scott Blum <[EMAIL PROTECTED]> wrote:

> Cameron, are you positive you're on r3683?  Your stack trace looks awfully
> fishy.  In particular:
>  [java] at
> com.google.gwt.dev.jjs.impl.MethodInliner.exec(MethodInliner.java:496)
>  [java] at
> com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.compile(JavaToJavaScriptCompiler.java:394)
>
> Cross-reference with:
>
>
> http://code.google.com/p/google-web-toolkit/source/browse/trunk/dev/core/src/com/google/gwt/dev/jjs/JavaToJavaScriptCompiler.java?r=3683#394
>
> I think you've got out-of-whack versions.
>
> On Fri, Sep 26, 2008 at 3:05 AM, Cameron Braid <[EMAIL PROTECTED]>wrote:
>
>> Sorry, I probably didn't explain my self so well.
>>
>> I have been using 1.5.2 successfully, and have moved across to trunk
>> (r3683) to try it out at. and ran into the same issue that I was having a
>> while ago.
>>
>> Cheers,
>>
>> Cameron
>>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: gwt compiler issue in 1.5 branch

[Cameron Braid]

Sorry, I probably didn't explain my self so well.

I have been using 1.5.2 successfully, and have moved across to trunk (r3683)
to try it out at. and ran into the same issue that I was having a while ago.

Cheers,

Cameron


On Fri, Sep 26, 2008 at 5:02 PM, Cameron Braid <[EMAIL PROTECTED]> wrote:

> This issue has come up again in trunk r3683
>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: gwt compiler issue in 1.5 branch

[Cameron Braid]

This issue has come up again in trunk r3683

 [java]Analyzing permutation #1
 [java]   [ERROR] An internal compiler exception occurred
 [java] com.google.gwt.dev.jjs.InternalCompilerException: Could not find
enum values() method
 [java] at
com.google.gwt.dev.jjs.ast.JClassLiteral.(JClassLiteral.java:104)
 [java] at
com.google.gwt.dev.jjs.ast.JProgram.getLiteralClass(JProgram.java:533)
 [java] at
com.google.gwt.dev.jjs.impl.CloneExpressionVisitor.visit(CloneExpressionVisitor.java:119)
 [java] at
com.google.gwt.dev.jjs.ast.JClassLiteral.traverse(JClassLiteral.java:127)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(JVisitor.java:527)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doAccept(JVisitor.java:509)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:65)
 [java] at
com.google.gwt.dev.jjs.impl.CloneExpressionVisitor.cloneExpression(CloneExpressionVisitor.java:68)
 [java] at
com.google.gwt.dev.jjs.impl.MethodInliner$InliningVisitor.createMultiExpressionFromBody(MethodInliner.java:223)
 [java] at
com.google.gwt.dev.jjs.impl.MethodInliner$InliningVisitor.endVisit(MethodInliner.java:120)
 [java] at
com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:124)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(JVisitor.java:527)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor$NodeContext.traverse(JModVisitor.java:154)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor.doAccept(JModVisitor.java:202)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:77)
 [java] at
com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:122)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(JVisitor.java:527)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor$NodeContext.traverse(JModVisitor.java:154)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor.doAccept(JModVisitor.java:192)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:65)
 [java] at
com.google.gwt.dev.jjs.ast.JCastOperation.traverse(JCastOperation.java:57)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(JVisitor.java:527)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor$NodeContext.traverse(JModVisitor.java:154)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor.doAccept(JModVisitor.java:192)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:65)
 [java] at
com.google.gwt.dev.jjs.ast.JDeclarationStatement.traverse(JDeclarationStatement.java:49)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(JVisitor.java:527)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor$ListContext.traverse(JModVisitor.java:100)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor.doAcceptWithInsertRemove(JModVisitor.java:212)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemove(JVisitor.java:81)
 [java] at
com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:36)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(JVisitor.java:527)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor$NodeContext.traverse(JModVisitor.java:154)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor.doAccept(JModVisitor.java:192)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:73)
 [java] at
com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:52)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(JVisitor.java:527)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor$NodeContext.traverse(JModVisitor.java:154)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor.doAccept(JModVisitor.java:192)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:69)
 [java] at
com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:194)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(JVisitor.java:527)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor$ListContext.traverse(JModVisitor.java:100)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor.doAcceptWithInsertRemove(JModVisitor.java:212)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.acceptWithInsertRemove(JVisitor.java:81)
 [java] at
com.google.gwt.dev.jjs.ast.JClassType.traverse(JClassType.java:62)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(JVisitor.java:527)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor$NodeContext.traverse(JModVisitor.java:154)
 [java] at
com.google.gwt.dev.jjs.ast.JModVisitor.doAccept(JModVisitor.java:202)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:77)
 [java] at
com.google.gwt.dev.jjs.ast.JProgram.traverse(JProgram.java:801)
 [java] at
com.google.gwt.dev.jjs.ast.JVisitor.doTraverse(

[gwt-contrib] Re: New JSON API proposal

[Cameron Braid]

When you say spec here, I hope you are referring to a .proto file :)

Cam

On Thu, Aug 28, 2008 at 1:39 AM, Ray Cromwell <[EMAIL PROTECTED]> wrote:

>
> I've find that I use overlay types for everything now and I never
> touch the JSON library. What's really needed IMHO are two things:
>
> 1) a JSON validator (for safe XSS)
> 2) a utility to auto-generate overlays and server-side JSON classes from a
> spec
>
> -Ray
>
> On Wed, Aug 27, 2008 at 4:33 AM, David <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > There is one extra thing that is missing in JSON in GWT: the possibility
> to
> > use the same JSON API on the server side.
> > The current implementation is not available on the server side so I am
> > forced to find another implementation. I would rather use the same
> > implementation since the changes are much higher that they are
> compatible.
> >
> > Why do I need this ? Well in some cases I want to share services between
> a
> > GWT client and other UIs(struts, swing, applet...) and servlets. RPC can
> not
> > be easily reused outside GWT.
> >
> > We also have a a few situations where RPC is too limited (slow script
> > warnings, OutOfMemory. Stack Overflow)... and since even upto GWT 1.5 RC2
> I
> > have seen no evidence of fixes to these rather critical bugs (from our
> > perspective), I need to use a different protocol ... JSON looks to be the
> > most likely candidate.
> >
> > And finally:
> > To make JSON support even better: why not provide the possibility to use
> > JSON to serialize RPC calls. Using introspection you could direct the
> actual
> > JSON format to match what the server side is expecting.
> >
> > The same ideas could be applied to webservices or REST services (with any
> > type of wire format)... it would be nice to have the same approach as the
> > GWT.create for RPC calls.
> >
> > David
> > On Wed, Aug 27, 2008 at 12:26 PM, Reinier Zwitserloot <
> [EMAIL PROTECTED]>
> > wrote:
> >>
> >> I'm not quite happy with the current GWT JSON api. I had something in
> >> mind similar to what I use for my own server side projects. I built
> >> that myself but if you're familiar with as the org.json library at
> >> ( http://www.JSON.org/java/index.html ), this is similar. (I built
> >> this before org.json existed).
> >>
> >>
> >> Should I port it to GWT for inclusion in the standard library? Due to
> >> the way I wrote it, it ports quite easily, so it's not too much
> >> trouble.
> >>
> >> Executive summary of why it's better:
> >>
> >> 1. The current GWT offering is not lenient at all. This is bad, IMO,
> >> because JSON, as an interop language, is all about the leniency. The
> >> web is built on 'be strict in what you output, be lenient in what you
> >> accept', after all. For example, the json value '5' would result in a
> >> NullPointerException if you tried this: JSONValue v = new
> >> JSONNumber(5); String x = v.isString().stringValue(). In practice you
> >> would expect x to contain '5', not an NPE.
> >>
> >> 2. Sensible exceptions. In the above example, 'NPE' is just a weird
> >> exception to throw. This library throws JSONExceptions only, and the
> >> error messages make sense.
> >>
> >> 3. ease of use. My proposal properly handles common scenarios such as
> >> integer contents of JSON data (now you have to use an (int) cast which
> >> is wordy), and makes it -much- easier to work with JSON data that
> >> contains maps (JSONObjects) and lists (JSONArrays). Also handles the
> >> common scenario of JSON servers simply not sending data which is on
> >> their default value, by offering methods that return the JSON value if
> >> it is there, and if it is not there, returning a supplied default
> >> hardcoded into the GWT app.
> >>
> >> 4. Fits into java better. Can return and receive java.util.Lists and
> >> java.util.Maps, as analogies to json arrays and objects.
> >>
> >> 5. Also uses lazy object creation and JS eval() to be efficient, just
> >> like the current offering. However, proposal also includes 'safe
> >> parsing' method, which actually manually parses the JSON. useful if
> >> you don't particularly trust the sender. I admit in a vanilla web app
> >> the situations where you can safely receive JSON from an untrusted
> >> sender are limited, but between google gears and widespread attempts
> >> by HTML5 and the various browsers to support secure ways around the
> >> Same Origin Policy, seemed like a handy addition. I already have the
> >> code tested and ready to do it.
> >>
> >>
> >>
> >> Full API propoal:
> >>
> >> The entire API is built around 1 class, 'JSON'. It has two static
> >> methods to make one: parse, which will take a JSON string and parse
> >> it, and create(), which will take a JSONable construction (any java
> >> 'primitive', a string, null, or a List or Map with no reference loops,
> >> where each value is itself JSONable, and for maps, all keys are
> >> strings).
> >>
> >> The JSON object can be used to read JSON:
> >>
> >> .asString() - takes the JSON object a