Google Web Toolkit: October 2010

Sunday, October 31, 2010

Re: Announcing GWT 2.1

These mails being mark to me

Kindly avoid
Sent on my BlackBerry® from Vodafone

-----Original Message-----
From: Stephen Haberman <stephen@exigencecorp.com>
Sender: google-web-toolkit@googlegroups.com
Date: Sun, 31 Oct 2010 23:32:03
To: <google-web-toolkit@googlegroups.com>
Reply-To: google-web-toolkit@googlegroups.com
Subject: Re: Announcing GWT 2.1

Hi Shawn,

Thanks for the links.

Moving off JDO and Spring MVC (the web framework, not DI) seemed to be
the biggest startup time wins, which is in line with my assertion that
DI itself is not typically the bottleneck.

That being said, the streamhead link:

> http://www.streamhead.com/google-appengine-java-loading-request-analysis/

Was the most interesting because he truly did DI/no-DI comparison
(trusting his approach anyway), and saw base DI adding 1s overhead.

That is more than I would have guessed, but given it's Spring, I guess
I can believe it.

I do enjoy seeing startup time highlighted--way too many pointy haired
managers (or architects) don't think 10s+, 30s+, 60s+ app startups times
affect their developers' productivity. It's terribly frustrating.

Thanks again,
Stephen

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Announcing GWT 2.1

Hi Shawn,

Thanks for the links.

Moving off JDO and Spring MVC (the web framework, not DI) seemed to be
the biggest startup time wins, which is in line with my assertion that
DI itself is not typically the bottleneck.

That being said, the streamhead link:

> http://www.streamhead.com/google-appengine-java-loading-request-analysis/

Was the most interesting because he truly did DI/no-DI comparison
(trusting his approach anyway), and saw base DI adding 1s overhead.

That is more than I would have guessed, but given it's Spring, I guess
I can believe it.

Thanks again,
Stephen

Re: Announcing GWT 2.1

>> That being said, I'm not a Spring (nor Guice) fan, so would actually
>> enjoy seeing numbers that show, say, your stack w/Spring takes x% more
>> time than the same stack w/o Spring.

One more:

http://www.streamhead.com/google-appengine-java-loading-request-analysis/

Shawn

Re: 2.1 linker changes

Should appName.nocache.js be one of the Artifacts obtained via
artifacts.find(EmittedArtifact.class)?

In 2.04 it was emitted in the link method but in 2.1 it isn't!!!!

Is this by design? If so, what is the design?!?

Shawn

>> Later the log reports "Emitting resource projectName.nocache.js"
>
> Just to clarify.
>
> Version 2.0.4 includes appName.nocache.js in the ArtifactSet passed
> into the link method of a class that extends AbstractLinker AND
> reports writing it to disk "Emitting resource appName.nocache.js" and
> writes it to disk
>
> Version 2.1 DOES NOT include appName.nocache.js in the ArtifactSet
> passed into the link method of a class that extends AbstractLinker BUT
> DOES report writing it to disk "Emitting resource appName.nocache.js"
> and writes it to disk
>
> What I can't understand is why artifacts.find(EmittedArtifact.class)
> does not now find appName.nocache.js. EmittedArtifacts are defined in
> the api (both 2.04 and 2.1) as "An artifact that will be emitted into
> the output. All EmittedArtifacts contained in the ArtifactSet at the
> end of the Linking process will be emitted by the compiler into the
> module's output directory."
>
> appName.nocache.js IS emitted into the output so WHY IS IT NO LONGER
> IN THE ARTIFACT SET?????
>
> Shawn
>

Re: Announcing GWT 2.1

> That being said, I'm not a Spring (nor Guice) fan, so would actually
> enjoy seeing numbers that show, say, your stack w/Spring takes x% more
> time than the same stack w/o Spring.

Here's what I read...

"I've been able to reduce my cold start time on AppEngine from an
average of 8.1s to 2.5s, a 69% reduction" ..."by eliminating DI
frameworks and using Objectify for persistence".
http://turbomanage.wordpress.com/2010/03/26/appengine-cold-starts-considered/

"Spring MVC added around 6 seconds to the cold start time"
http://blog.listry.com/2010/03/google-app-engine-cold-start-guide-for.html

Shawn

Re: Announcing GWT 2.1

> As DI requires additional cpu cycles to do its magic

I'd be interested to hear if you have any profiling results specifically
showing DI is responsible for the bad startup perf.

My assertion is that if you startup Hibernate + Wicket + whatever
without DI, just configuring them by hand, it will take 90%+ of the time
it took with DI. E.g. DI should be negligible.

I could very well be wrong, but I do agree with Thomas that, in theory,
DI should be cheap. "Some cycles", yes. But there is no I/O, not a huge
computational task to be done--it should be fast.

Hibernate itself is notoriously slow to startup, so, yeah, any stack
change you make that involves changing Hibernate to Objectify will get a
great startup boost, regardless of whether DI is involved.

That being said, I'm not a Spring (nor Guice) fan, so would actually
enjoy seeing numbers that show, say, your stack w/Spring takes x% more
time than the same stack w/o Spring.

(...it sucks this conversation is happening on the "Announcing GWT 2.1"
thread. Whoever started this tangent, new thread next time.)

- Stephen

Announcing gwt4air 1.0

Hello community,

It s been a long way but i m proud to annouce the release of Gwt4Air 1.0

Gwt4Air will give you the the ability to turn your GWT apps in to desktop apps using adobe air.

You can download the jar here http://code.google.com/p/gwt4air/.

The first release is compatible with gxt 2.2, gwt 2.0 and adobe air 2. It includes the following features:

1) Access to the core AIR APi from GWT, you basically can do anything you would do in actionscript or javascript.

2) An adapter to make GXT(Ext-GWT) works inside the air application sandbox

3) A pdf module to read and write pdf files.

4) A google maps module, so you can produce maps even when your web client is offline

5) An adapter to male RPC and RequestBuilder calls possible with AIR.

6) A sample app with source code that shows some examples. One of the example is how you can export an GXT chart to pdf using gwt4air.

The next releases will add more and more features(check out the roadmap)

To get started you can check out the wiki page.

I hope you guys are going to like this and provide some good feedbacks.

For any question please feel free to contact me.

best regards,

Alain

Re: "client" code from external directory

Put a gwt.xml file in the project.

define the module, then you'll be able to import your library project
into a gwt project.

On Oct 31, 1:59 pm, Alex Shabanov <avshaba...@gmail.com> wrote:
> Guys, can anybody help me, please?
>
> The solution should be pretty simple but I still can't figure out what
> is the problem.
>
> Does someone ever tried the approach given above?
>
> On Oct 26, 8:19 pm, Alex Shabanov <avshaba...@gmail.com> wrote:
>
> > Thank you so much for your advice.
>
> > I've created a small proof-of-concept project (available for svn,
> > revision 291: svn cohttp://webkit-jspf.googlecode.com/svn/trunk/tmp/maven/gwt-external-lib
> > gwt-external-lib)
>
> > Basically it's structure follows the one I described above, there is a
> > generic module that defines Constants class with two public static
> > constants and there is a gwt module "gwtmod" that includes the generic
> > module and uses it's Constants class.
>
> > To make Constants available for gwtmod I've added corresponding
> > compileSourcesArtifacts entry to it's gwt-maven-plugin's configuration
> > section, added Generic.gwt.xml that refers to the sources from generic
> > module's domain and included Generic module in the
> > Application.gwt.xml.
> > GWT compilation fails:
> > [INFO] com.mysite.generic.Generic is up to date. GWT compilation
> > skipped
> > [INFO] Compiling module com.mysite.gwtmod.Application
> > [INFO] Validating newly compiled units
> > [INFO] [ERROR] Errors in 'file:/home/alex/proj/googlecode-webkit-
> > jspf/tmp/maven/gwt-external-lib/gwtmod/src/main/java/com/mysite/gwtmod/
> > client/Application.java'
> > [INFO] [ERROR] Line 16: No source code is available for type
> > com.mysite.generic.Constants; did you forget to inherit a required
> > module?
>
> > - it sees Generic module but omits it's compilation because maven
> > thinks that it is "up to date". And yes, I did mvn clean install.
>
> > Any help greatly appreciated!
>
> > On Oct 25, 10:33 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > > On 25 oct, 13:22, Alex Shabanov <avshaba...@gmail.com> wrote:
> > >>...
>
> > > In other words, general-constants is a library. See:http://mojo.codehaus.org/gwt-maven-plugin/user-guide/library.html
> > > or as an alternative:http://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html

Re: About widgets management

On Thu, Oct 28, 2010 at 6:55 AM, Pablo G.F <blayhck@gmail.com> wrote:

But when I create the menu I have to write the behaviour of each
widget (when hide/show etc), so I have to instance them. I know what
you mean by using Singleton but with that approach I can specify the
behaviour, because they're not created yet.

No, you don't have to instantiate them every time to accomplish what you need to do. Singletons are capable of handling these situations. All that it requires is that you add static methods to your class for what ever behavior you want to exercise on the widget. To show the widget all you would then need to do would be to call YourWidgetClass.getInstance().show() and to hide it YourWidgetClass.getInstance().hide().

In essence you are providing a static api via encapsulation and each static method's implementation does the actual work of manipulating the widget. For example, YourWidgetClass.getInstance().show() would be implemented as follows:

public static void show(){
instance.show();
}

What I want is a way to create a menu with widgets associated to it
and work like a standard web app with html pages, showing the widget
requested in the menu and hiding the other ones. But the problem is
that I´d like not having to instance all widgets at the beggining, but
I don´t see any other way to give them the correct behaviour.

Singleton do not require you instance them when your app starts. They will be instanced when you call their their static factory method .getInstance() and only then. Also, remember that on your client the code running is Javascript which performs garbage collection. At any point you can 'delete' the singletons by calling their api methods to handle deletion from the dom and then follow up with calling the widget's apis that do any further cleaning up. Just remember to set instance to null when you do so that your next call to YourWidgetClass.getInstance() wont fail.

Any other help?

Thx

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

Re: "client" code from external directory

Guys, can anybody help me, please?

The solution should be pretty simple but I still can't figure out what
is the problem.

Does someone ever tried the approach given above?

On Oct 26, 8:19 pm, Alex Shabanov <avshaba...@gmail.com> wrote:
> Thank you so much for your advice.
>
> I've created a small proof-of-concept project (available for svn,
> revision 291: svn cohttp://webkit-jspf.googlecode.com/svn/trunk/tmp/maven/gwt-external-lib
> gwt-external-lib)
>
> Basically it's structure follows the one I described above, there is a
> generic module that defines Constants class with two public static
> constants and there is a gwt module "gwtmod" that includes the generic
> module and uses it's Constants class.
>
> To make Constants available for gwtmod I've added corresponding
> compileSourcesArtifacts entry to it's gwt-maven-plugin's configuration
> section, added Generic.gwt.xml that refers to the sources from generic
> module's domain and included Generic module in the
> Application.gwt.xml.
> GWT compilation fails:
> [INFO] com.mysite.generic.Generic is up to date. GWT compilation
> skipped
> [INFO] Compiling module com.mysite.gwtmod.Application
> [INFO] Validating newly compiled units
> [INFO] [ERROR] Errors in 'file:/home/alex/proj/googlecode-webkit-
> jspf/tmp/maven/gwt-external-lib/gwtmod/src/main/java/com/mysite/gwtmod/
> client/Application.java'
> [INFO] [ERROR] Line 16: No source code is available for type
> com.mysite.generic.Constants; did you forget to inherit a required
> module?
>
> - it sees Generic module but omits it's compilation because maven
> thinks that it is "up to date". And yes, I did mvn clean install.
>
> Any help greatly appreciated!
>
> On Oct 25, 10:33 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > On 25 oct, 13:22, Alex Shabanov <avshaba...@gmail.com> wrote:
> >>...
>
> > In other words, general-constants is a library. See:http://mojo.codehaus.org/gwt-maven-plugin/user-guide/library.html
> > or as an alternative:http://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html

Re: Announcing GWT 2.1

Hi Thomas,

No hard feelings, I assure you, and I think your English is very good so please don't feel insecure. I apologize if I came off with an attitude; I didn't mean to, but it was early in the morning and I didn't have my 1st cup of coffee :)

Roo is a Spring Source technology as is STS & Spring DI. Spring DI uses an application context XML file placed in the war which upon application start up is read. If its contents include declarative class nodes then those classes are instantiated and any additional parameters may also be assigned to their properties to bring them into a usable state. Within the application's code are DI attribute declarations that are used by Spring DI for injecting the objects into the application. Almost all of the Java based DI technologies work in a similar fashion.

The benefits of using DI can vary. It is handy when you want to mock classes for testing, for instance. It is also handy for providing the ability to switch among the numerous implementations of common APIs. These are very worthy capabilities and in the right situations are handy to have. I personally use Spring DI with Wicket and Hibernate. They work together very well.

But with the positive also comes the negative just like with most things in life. For instance, many developers view maintaining an application's context file as burdensome and often complicated. In truth, at least IMO, this is best served by tooling provided in an IDE which understands the XML schemas and which can provide some code completion as well as intelligent feedback. STS, Springs' added value release of Eclipse, does just that but not everyone is using STS. On App Engine, one has 30 seconds to complete an HTML request. While that may seem like a lot of time, it isn't when you consider that on App Engine the time allocated to starting up a new virtual server to service the request is also included in that 20 second quota. Exceed that quota and your request fails with a 500 error. As DI requires additional cpu cycles to do its magic, it may cause an application to exceed the 30 second quota and fail at start up which I am sure you would agree is something to be avoided.

So I am not opposed to DI at all, I just prefer to have the option of using it or not using it such as on App Engine.

In regard to GWT v2.1 MVP, it seems apparent to me that Google is championing Roo as their choice for developers to use when integrating MVP into their GWT applications. From the little I really know about it, Roo is able to generate a lot of the boilerplate code needed to keep the views, models and presenters in sync. This is fine but I would have preferred if Google had also provided options such as extending the code refactoring ability in Eclipse to provide this support. I imagine this wouldn't be a trivial effort but what is when it comes to developing applications? As an example of what I mean, currently when adding a RemoteService using Eclipse all the bindings between the service interface, the service async interface and the service implementation are automatically generated. If I add a method to the service interface and forget to add its implementation it is flagged as an error. This type of 'built in' support is very intuitive as well as productive since the developer is already familiar with their IDE. I can imagine this can also be done with MVP in Eclipse and would eliminate the need for Roo altogether.

Options are a developer's best friend IMO.

Have a great day.

Jeff

On Sun, Oct 31, 2010 at 12:44 PM, Thomas Broyer <t.broyer@gmail.com> wrote:

On 31 oct, 15:26, Duong BaTien <duong.bat...@gmail.com> wrote:
> Hi:
>
> Good to know your experience with Roo and the light weight approach.

I think I already said it: I have zero experience with Roo.

> A best-practiced example of RequestFactory with GIN at GWT side and
> GUICE at server side may be what a mortal developer is looking for.

To really benefit from Guice (or more generally DI) on the server
side, you'd first have to wait for GWT 2.1.1, as in 2.1.0
RequestFactory makes heavy use of static methods.
See http://code.google.com/p/google-web-toolkit/issues/detail?id=5482
(among others)

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

Re: How can I create a CellTree of Anchor nodes?

On Oct 16, 5:50 pm, Tamer Sezgin <tamer.sez...@gmail.com> wrote:
> It's a little complex example, but the left menu of Showcase application is
> implemented using CellTree and contains Hyperlinks..
> http://gwt.google.com/samples/Showcase/Showcase.html
> I assume after figuring out how it works, it should be easy to replace
> Hyperlinks with Anchors (if you really need to link to external URLs).

I'm interested in the same thing, so I found this post and had a look
at the showcase code here:
http://code.google.com/p/google-web-toolkit/source/browse/#svn/trunk/samples/showcase/src/com/google/gwt/sample/showcase/client
As far as I can tell, it does nothing of the kind. It uses a selection
model to fire history change events, not hyperlinks. Were you
referring to an older version?

> On Sat, Oct 16, 2010 at 6:55 AM, Blackberet <ramonjsanti...@gmail.com>wrote:
>
>
>
>
>
>
>
> > I have a CellTree, I would like to add Anchor nodes to it. There is no
> > AnchorCell available. What do I need to use in order to implement this
> > functionality?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-web-toolkit@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubs cribe@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Announcing GWT 2.1

Ur mails r getting wrongly marked to me.
Please avoid
Sent on my BlackBerry® from Vodafone

-----Original Message-----
From: Thomas Broyer <t.broyer@gmail.com>
Sender: google-web-toolkit@googlegroups.com
Date: Sun, 31 Oct 2010 09:39:42
To: Google Web Toolkit<google-web-toolkit@googlegroups.com>
Reply-To: google-web-toolkit@googlegroups.com
Subject: Re: Announcing GWT 2.1

On 31 oct, 13:40, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> Thomas,
>
> It is the 'I' in DI that I reflected on: Injection takes cpu cycles and on
> App Engine server cpu cycles are severely restricted by numerous quotas; the
> penalty for exceeding them cause cascading conditions of failure. If you
> aren't familiar with App Engine hosting and its quotas perhaps you should
> read up on it.

I never used AppEngine so I apologies for not knowing the quotas and
what impact could DI have.

> As for ROO not generating server side DI as part of its tooling in STS when
> used with GWT I will have to check that out for myself; I believe I had read
> that it generates a server side application context configuration file and
> if that is the case then I'd like to know why it would do that if DI wasn't
> employed on the server. If that is the case then DI would certainly cause
> heightened latency causing an increase in 500 errors on App Engine virtual
> server cold starts.

Not having tried Roo, I can only talk about what's visible in the
Expenses sample:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/expenses/src/main/
and what I understand from Roo's addon-gwt source code:
https://fisheye.springsource.org/browse/spring-roo/addon-gwt

And I don't see DI here (on the server-side)

> As for DI being a best practice (that you'd encourage *anyone* to follow)
> well that is your opinion that is not shared by everyone. I encourage a more
> conservative approach to any engineering problem - use the right set of
> tools at the right time.

Sure. I maintain what I said though: DI is a pattern that makes code
easier to test and to maintain. And I really mean DI, as a pattern,
I'm not talking about any tool here; you're free to implement DI
"yourself", it doesn't necessarily means Guice or Spring or JavaEE 6
or whatever (which means you could do it with very low overhead, if
any). I found DI really improved software quality overall.

That being said, let me paraphrase you: "I am open minder. We
developers have to be :) and as such I would very
much like to be proven wrong on all these counts."

> As for Huh!?! That is something best saved for your friends on Facebook.
> This is a technical news group where such antics of conversation are not
> appreciated regardless of difference of opinion.

Sorry, I'm not a native English speaker/writer, so I probably misuse
idioms sometimes.

Re: Announcing GWT 2.1

On 31 oct, 15:26, Duong BaTien <duong.bat...@gmail.com> wrote:
> Hi:
>
> Good to know your experience with Roo and the light weight approach.

I think I already said it: I have zero experience with Roo.

> A best-practiced example of RequestFactory with GIN at GWT side and
> GUICE at server side may be what a mortal developer is looking for.

To really benefit from Guice (or more generally DI) on the server
side, you'd first have to wait for GWT 2.1.1, as in 2.1.0
RequestFactory makes heavy use of static methods.
See http://code.google.com/p/google-web-toolkit/issues/detail?id=5482
(among others)

Re: Announcing GWT 2.1

I never used AppEngine so I apologies for not knowing the quotas and
what impact could DI have.

And I don't see DI here (on the server-side)

That being said, let me paraphrase you: "I am open minder. We
developers have to be :) and as such I would very
much like to be proven wrong on all these counts."

Sorry, I'm not a native English speaker/writer, so I probably misuse
idioms sometimes.

CellTree "reordering" nodes?

This problem is a bit tricky to describe; forgive me. I have a cell
tree where nodes are added programmatically by doing a getList().add()
on a ListDataProvider field. However, I found that using
the .add(Object) method would do strange things to the ordering, i.e.
the node *rendered* as "Item 1" would be passed as *value* "Item 2" to
getNodeInfo(), and thus it looked like Item 1 got Item 2's children.

The really strange thing is that if I do .add(0, Object), then
everything works fine.

The actual code can be found here:
http://bitbucket.org/slide_rule/umd-code-review/src/tip/src/edu/umd/review/gwt/view/impl/CommentTrayViewImpl.java

I just want to have list operations reflected in the tree, is this a
bug or have I just screwed this up somehow?

--
rwsims

Re: Announcing GWT 2.1

Great job, you guys rock!

--
Arthur Kalmenson

On Thu, Oct 28, 2010 at 2:12 PM, David Chandler <drfibonacci@google.com> wrote:
> GWT 2.1 is here!
>
> http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release-of-gwt-21.html
>
> --
> David Chandler
> Developer Programs Engineer, Google Web Toolkit
> http://googlewebtoolkit.blogspot.com/
>
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

Re: JUnit testing GWT

You can still mock out GWT widgets, but you'll need to use the
GWTMockUtilities. You can find more info here:
http://onthejvm.com/mocking-your-gwt-widgets-without-gwttestcase

--
Arthur Kalmenson

On Fri, Oct 29, 2010 at 9:14 AM, chrisr <chris.robert.rowland@gmail.com> wrote:
> Hi Ignat, thank you for the tip. I do remember reading that there is
> a way to write gwt junit tests in a way that were much faster than the
> way I'm doing it now. I wonder if this is it.
>
> Is there some documentation for how to write unit tests of this
> variety? I searched but didn't come across anything that looked like
> what you suggested.
>
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

Re: Announcing GWT 2.1

These mail r been coming to me and I am not a part of this.
Please take a note of this.
Sent on my BlackBerry® from Vodafone

-----Original Message-----
From: Duong BaTien <duong.batien@gmail.com>
Sender: google-web-toolkit@googlegroups.com
Date: Sun, 31 Oct 2010 08:26:38
To: <google-web-toolkit@googlegroups.com>
Reply-To: google-web-toolkit@googlegroups.com
Subject: Re: Announcing GWT 2.1

Hi:

Good to know your experience with Roo and the light weight approach.

A best-practiced example of RequestFactory with GIN at GWT side and
GUICE at server side may be what a mortal developer is looking for. It
is even better with Objectify if Jeff does it.

Thanks
BaTien

On Sun, 2010-10-31 at 02:30 -0700, Thomas Broyer wrote:
>
> On 30 oct, 23:15, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> > Excellent! Thank you for the information. I still however have to wait until
> > support for DAOs & embeded objects is implemented in the MVP framework (I am
> > using Objectify for my ORM as well ass a DAO) before I can cut over.
> >
> > I am also concerned about the apparent reliance on Roo to generate the
> > boilerplate code. It appears that Google is very much behind this combo.
>
> We've been prototyping with RequestFactory for months and haven't ever
> used Roo (our backend is Morphia+MongoDB, not too far from Objectify)
>
> > It
> > isn't that I have anything against Roo, DI or generated code for that matter
> > but I would have preferred a leaner solution.
>
> AFAIK, Roo is only a dev tool to generate and maintain boilerplate
> code. There's nothing related to Roo in the generated code (have a
> look at the Expenses sample, the domain objects and all Scaffold*
> classes are those generated by Roo).
>
> RequestFactory goes against DRY as you have interfaces extending
> EntityProxy on the client-side, and "whatever" on the server-side; but
> it's lighter weight than e.g. GWT-RPC at runtime: lighter payload
> going on the wire (in most cases, and particularly on "upload"), and
> much much lighter and faster on the client-side as parsing the payload
> is just a matter of JSON.parse()
>
> > Applications targeting App
> > Engine already experience enough latency on start-up and I am afraid that DI
> > will just make matters worse;
>
> Huh!?!
>
> Could you explain to me how DI slows things down? It's merely about
> moving the place where you "new" objects, I don't see where there'd be
> overhead re. start-up time.
> Noteworthy: Roo generates GWT apps that use GIN for DI on the client
> side, but there's no DI at all on the server-side. And DI is
> absolutely not a requirement; only a best practice (that I'd encourage
> *anyone* to follow)
>
>

Re: Announcing GWT 2.1

Hi:

Good to know your experience with Roo and the light weight approach.

A best-practiced example of RequestFactory with GIN at GWT side and
GUICE at server side may be what a mortal developer is looking for. It
is even better with Objectify if Jeff does it.

Thanks
BaTien

Re: GWT 2.1 CELL TABLE

Thanks very much bradr!!

I'll try you suggestions!!

Daniele

On 29 Ott, 22:51, bradr <brad.rydzew...@gmail.com> wrote:
> To do this, you have to override the CellTable's default style.
> Because CellTable uses a CssResource, which ultimately gets obfuscated
> when you compile, you have to create your own implementation and pass
> it to the CellTable in the constructor.
>
> Here is how I did it:
>
> Step 1) Create your own implementation of the Resource
>
> import com.google.gwt.core.client.GWT;
> import com.google.gwt.user.cellview.client.CellTable;
> import com.google.gwt.user.cellview.client.CellTable.Resources;
> public interface MyCellTableResources extends Resources {
>
> public MyCellTableResources INSTANCE =
> GWT.create(MyCellTableResources.class);
>
> /**
> * The styles used in this widget.
> */
> @Source("CellTable.css")
> CellTable.Style cellTableStyle();
>
> }
>
> Step 2) Copy the CellTable.css file into your project (from gwt trunk)
> into the same package as your Resource implementation. Customize the
> css until it meets your style needs.
>
> Step 3) When you create an instance of the CellTable, give it your
> your custom CssResource:
>
> myTable = new
> CellTable<Resource>(Integer.MAX_VALUE,CellTableResources.INSTANCE);
>
> Hope that helps!
>
> On Oct 29, 11:55 am, bond <daniele.re...@gmail.com> wrote:
>
> > Hi,
> > is possibile to remove the box around the single cell that appears
> > when I click on a cell?
>
> > Thanks very much
>
> > Best regards

Re: Announcing GWT 2.1

Thomas,

It is the 'I' in DI that I reflected on: Injection takes cpu cycles and on App Engine server cpu cycles are severely restricted by numerous quotas; the penalty for exceeding them cause cascading conditions of failure. If you aren't familiar with App Engine hosting and its quotas perhaps you should read up on it.

As for ROO not generating server side DI as part of its tooling in STS when used with GWT I will have to check that out for myself; I believe I had read that it generates a server side application context configuration file and if that is the case then I'd like to know why it would do that if DI wasn't employed on the server. If that is the case then DI would certainly cause heightened latency causing an increase in 500 errors on App Engine virtual server cold starts.

As for DI being a best practice (that you'd encourage *anyone* to follow) well that is your opinion that is not shared by everyone. I encourage a more conservative approach to any engineering problem - use the right set of tools at the right time.

As for Huh!?! That is something best saved for your friends on Facebook. This is a technical news group where such antics of conversation are not appreciated regardless of difference of opinion.

Jeff

On Sun, Oct 31, 2010 at 5:30 AM, Thomas Broyer <t.broyer@gmail.com> wrote:

On 30 oct, 23:15, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> Excellent! Thank you for the information. I still however have to wait until
> support for DAOs & embeded objects is implemented in the MVP framework (I am
> using Objectify for my ORM as well ass a DAO) before I can cut over.
>
> I am also concerned about the apparent reliance on Roo to generate the
> boilerplate code. It appears that Google is very much behind this combo.

We've been prototyping with RequestFactory for months and haven't ever
used Roo (our backend is Morphia+MongoDB, not too far from Objectify)

> It
> isn't that I have anything against Roo, DI or generated code for that matter
> but I would have preferred a leaner solution.

AFAIK, Roo is only a dev tool to generate and maintain boilerplate
code. There's nothing related to Roo in the generated code (have a
look at the Expenses sample, the domain objects and all Scaffold*
classes are those generated by Roo).

RequestFactory goes against DRY as you have interfaces extending
EntityProxy on the client-side, and "whatever" on the server-side; but
it's lighter weight than e.g. GWT-RPC at runtime: lighter payload
going on the wire (in most cases, and particularly on "upload"), and
much much lighter and faster on the client-side as parsing the payload
is just a matter of JSON.parse()

> Applications targeting App
> Engine already experience enough latency on start-up and I am afraid that DI
> will just make matters worse;

Huh!?!

Could you explain to me how DI slows things down? It's merely about
moving the place where you "new" objects, I don't see where there'd be
overhead re. start-up time.
Noteworthy: Roo generates GWT apps that use GIN for DI on the client
side, but there's no DI at all on the server-side. And DI is
absolutely not a requirement; only a best practice (that I'd encourage
*anyone* to follow)

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

Re: GWT2.1 : sample Data bound views

I see, javax.validation would be sweet. So what is the best approach
to plugin the validation into the existing framework?
I saw that there is a 'hasErrors()' and 'getErrors' method in the
driver but how do I create/record an error, how can I trigger the
'editorDelegate.recordError' being called? In the above mentioned
example I can see that there is a 'ZipPlusFourBox extends ValueBox'
which creates a parser, do I have to create a widget subclass for
every single field that needs validation (would be a bit cumbersome,
also in ValueBoxEditor there is a ' TODO i18n' which to me seems not
very production ready)? Any best practices on this would be great.

thanks,
Den

On Oct 31, 10:33 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> On 31 oct, 01:20, googelybear <googelyb...@gmail.com> wrote:
>
> > I am also trying out the new editor framework. Did anyone already find
> > out how to define constraints on fields? E.g. I have a TextBox and the
> > user needs to type at least n characters in it otherwise an error
> > should be displayed.
>
> Editors are orthogonal to this use case. It's up to your widget or
> "domain model" to do the validation; Editor only makes it easy to
> display errors.
> There's work being done on integration with javax.validation (JSR303),
> being able to have validators run on the client-side as well as the
> server-side; but AFAICT it's not yet ready.

Re: GWT2.1 : sample Data bound views

On 31 oct, 01:20, googelybear <googelyb...@gmail.com> wrote:
> I am also trying out the new editor framework. Did anyone already find
> out how to define constraints on fields? E.g. I have a TextBox and the
> user needs to type at least n characters in it otherwise an error
> should be displayed.

Editors are orthogonal to this use case. It's up to your widget or
"domain model" to do the validation; Editor only makes it easy to
display errors.
There's work being done on integration with javax.validation (JSR303),
being able to have validators run on the client-side as well as the
server-side; but AFAICT it's not yet ready.

Re: Announcing GWT 2.1

On 30 oct, 23:15, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> Excellent! Thank you for the information. I still however have to wait until
> support for DAOs & embeded objects is implemented in the MVP framework (I am
> using Objectify for my ORM as well ass a DAO) before I can cut over.
>
> I am also concerned about the apparent reliance on Roo to generate the
> boilerplate code. It appears that Google is very much behind this combo.

We've been prototyping with RequestFactory for months and haven't ever
used Roo (our backend is Morphia+MongoDB, not too far from Objectify)

> It
> isn't that I have anything against Roo, DI or generated code for that matter
> but I would have preferred a leaner solution.

AFAIK, Roo is only a dev tool to generate and maintain boilerplate
code. There's nothing related to Roo in the generated code (have a
look at the Expenses sample, the domain objects and all Scaffold*
classes are those generated by Roo).

RequestFactory goes against DRY as you have interfaces extending
EntityProxy on the client-side, and "whatever" on the server-side; but
it's lighter weight than e.g. GWT-RPC at runtime: lighter payload
going on the wire (in most cases, and particularly on "upload"), and
much much lighter and faster on the client-side as parsing the payload
is just a matter of JSON.parse()

> Applications targeting App
> Engine already experience enough latency on start-up and I am afraid that DI
> will just make matters worse;

Huh!?!

Could you explain to me how DI slows things down? It's merely about
moving the place where you "new" objects, I don't see where there'd be
overhead re. start-up time.
Noteworthy: Roo generates GWT apps that use GIN for DI on the client
side, but there's no DI at all on the server-side. And DI is
absolutely not a requirement; only a best practice (that I'd encourage
*anyone* to follow)

Saturday, October 30, 2010

newbie: GAE + Oauth + Open Id example

Hi,

I've searched all over the places, what I found is that, I need to
redirect or forward to authenticate to Google account or other
accounts. However I am still puzzled as to how to implement oauth and
open id authentication.

Can anyone enlighten me as to how to implement?
While at it, can you please give me some GWT frontend with RPC code
and GAE server code?

Thank you,
Fendy Tjin

JDBC error when implementing RPC

Hi,

I have an app that connects to MySQL on the server side, and it works
as I have tested it using a separate class. However when I try to
send the data to the client via RPC I get the following error:

java.lang.ClassNotFoundException: com.mysql.jdbc.Driver

when I am running the web app using eclipse (in host mode).
I have made sure that mysql-connector-java-5.1.13-bin.jar is in my
build path.
Can someone please give me some help please?

Re: GWT2.1 : sample Data bound views

I am also trying out the new editor framework. Did anyone already find
out how to define constraints on fields? E.g. I have a TextBox and the
user needs to type at least n characters in it otherwise an error
should be displayed.

regards,
Den

On Oct 30, 2:32 pm, Tobias <thaberm...@gmail.com> wrote:
> On Oct 30, 12:04 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
>
> > On 30 oct, 08:53, "Jean-Francois L." <jeanfrancois.lebe...@gmail.com>
> > wrote:
>
> > > Hello,
>
> > > I just read about Data bound views in GWT 2.1 releasehttp://code.google.com/webtoolkit/doc/latest/ReleaseNotes.html#Editors
>
> > > I'm looking for a sample easy to understand
>
> > Have a look at the DynatableRF sample.
>
> I learned a lot from that sample, but it would be really helpful, if
> it would feature some 1:N or N:N relationships and typical editors,
> like a CellTable where you could add, delete and edit data rows.
>
> Regards,
> Tobias

Re: Announcing GWT 2.1

Excellent! Thank you for the information. I still however have to wait until support for DAOs & embeded objects is implemented in the MVP framework (I am using Objectify for my ORM as well ass a DAO) before I can cut over.

I am also concerned about the apparent reliance on Roo to generate the boilerplate code. It appears that Google is very much behind this combo. It isn't that I have anything against Roo, DI or generated code for that matter but I would have preferred a leaner solution. Applications targeting App Engine already experience enough latency on start-up and I am afraid that DI will just make matters worse; and as I still haven't been able to figure out how to get Roo and Objectify to work together my apprehension is that much more intensified.

But I am open minder. We developers have to be :) and as such I would very much like to be proven wrong on all these counts.

Again, thank you for the information on RequestFactory.

Jeff

This is indeed great news.

On Sat, Oct 30, 2010 at 5:13 PM, Thomas Broyer <t.broyer@gmail.com> wrote:

On 30 oct, 16:44, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> I haven't read up in detail on the new RequestFactory implementation except
> for the information I've read here on the group. I gather from what I've
> read then that RequestFactory is totally data specific and its only
> intention is to persist any data that has been changed on the client back to
> the server. It therefore seems, for example, that if it were required for
> security reasons, for instance, to validate that the request to the server
> is made with a valid session id and the session was still active that
> RequestFactory would not be the api to use and that instead the older
> RemoteService api would be the one to use, correct?

No.

The first thing the RequestFactoryServlet does is to (paraphrasing the
comment in the code) "check that user is logged in before
proceeding" (this is done by "getting" a UserInformation instance,
which has access to the servlet request through
RequestFactoryServlet.getThreadLocalRequest() so you're free to do
whatever checking you want; the actual implementation is given by the
userInfoClass servlet init parameter; see the Expenses sample for an
example using AppEngine's UserService), and return a 401 HTTP response
if it's not the case (which you can trap on the client-side).

On the client-side, RequestFactory uses by default a
DefaultRequestTransport, which you can extend (or even replace, I
think you could use WebSocket or Comet or whatever if you liked) to
send the "session id" in the request payload (for instance); similar
to the RpcRequestBuilder for GWT-RPC.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

Re: Announcing GWT 2.1

On 30 oct, 16:44, Jeff Schwartz <jefftschwa...@gmail.com> wrote:
> I haven't read up in detail on the new RequestFactory implementation except
> for the information I've read here on the group. I gather from what I've
> read then that RequestFactory is totally data specific and its only
> intention is to persist any data that has been changed on the client back to
> the server. It therefore seems, for example, that if it were required for
> security reasons, for instance, to validate that the request to the server
> is made with a valid session id and the session was still active that
> RequestFactory would not be the api to use and that instead the older
> RemoteService api would be the one to use, correct?

No.

The first thing the RequestFactoryServlet does is to (paraphrasing the
comment in the code) "check that user is logged in before
proceeding" (this is done by "getting" a UserInformation instance,
which has access to the servlet request through
RequestFactoryServlet.getThreadLocalRequest() so you're free to do
whatever checking you want; the actual implementation is given by the
userInfoClass servlet init parameter; see the Expenses sample for an
example using AppEngine's UserService), and return a 401 HTTP response
if it's not the case (which you can trap on the client-side).

On the client-side, RequestFactory uses by default a
DefaultRequestTransport, which you can extend (or even replace, I
think you could use WebSocket or Comet or whatever if you liked) to
send the "session id" in the request payload (for instance); similar
to the RpcRequestBuilder for GWT-RPC.

GWT-maps - How to ensure paint-based calls appear in a desired sequence?

Hi - Using GWT 2.0 and GWT-MAPS 1.1.. and am scratching my head
trying to figure how to implement a consistent 'Please wait'
dialog popup to appear *just before* i ask the Map to make many
(hundreds) of markers.setVisible(true). i.e.:

- PopupPanel P defined to say 'Please Wait' and is hidden
- button B onclick() method:
1. invoke P.show();
2. for each marker X in set, call X.setVisible(false) // set is large
3. hide P

Surprisingly in some ways, since steps 1 and 2 are both paint-
based they are interleaving and my popup P is not showing
consistently! Sometimes only after several seconds.. or near the
end of all the .setVisible calls!
How can i ENSURE that the panel (or ANYTHING 'paint-based')
appears before something else that is paint-based happens??

This would seem to be a common issue across Apps (Maps and
otherwise!) (e.g., a "Please Wait" dialog pattern in which the dialog
appears before the 'work' and disappears 'after')

Code snippet below:

WAIT_DIALOG = new DialogBox(false);
WAIT_DIALOG.setStyleName("gwt-PopupPanel");
HTML message4 = new HTML(".. html here ");
WAIT_DIALOG.setPixelSize(280, 100);//w,h
WAIT_DIALOG.setAnimationEnabled(true);
WAIT_DIALOG.setPopupPosition(400,250);
WAIT_DIALOG.setWidget(message4);
WAIT_DIALOG.hide();
...
key_ok_button.addClickListener(new ClickListener() {
public void onClick(Widget sender) {
//show the 'Please wait' dialog
/* THIS SEEMS TO LAG AND THE DIALOG DOES NOT SHOW PROMPTLY! */
WAIT_DIALOG.show();

for(int i=0;i<LS.size();i++){ //THERE ARE MANY MARKERS/POLYLINES IN
THIS SET
((Marker)LS.elementAt(i)).setVisible(true);
}//for
//now hide the dialog after a timeout
/* NO PROBLEMS WITH HIDING IT */
timeoutTimer = new Timer() {
public void run() {
WAIT_DIALOG.hide(); //hide the 'please wait' dialog
timeoutTimer = null;
}//run
};
timeoutTimer.schedule(3 * 1000); // timeout is in milliseconds
return;
}//onclick
}...

lib-gwt-svg 0.5 for GWT 2.1 is available

I am releasing today version 0.5 of lib-gwt-svg for GWT 2.1. The new
version contains many new features.

* The library is now based on the GWT 2.1 final release.
* An SVG validator has been integrated. It is enabled by default and
checks at build-time all the SVG passed as SVGResource,
ExternalSVGResource and inlined in UiBinder templates. The SVG
validator is based on the experimental XML schema provided at W3C with
custom fixes and improvements. It is possible to disable validation
with the proper annotation or UiBinder attribute.
* The API has been migrated to include the latest update from the SVG
specification (SVG 1.1 second edition, W3C Working Draft 22 June
2010). See the release notes for details of the API changes.
* Documentation captured from the SVG specification has been
translated to javadoc and injected everywhere in the API. All the non-
W3C APIs have been documented. Many links pointing to the W3C spec
have been added also.
* Exceptions declared in the specification have been mapped to java
exceptions and the corresponding throws clauses have been added to the
specification. The article on lib-gwt-svg design has been updated to
reflect the design decisions behind these changes.
* Many new helper methods have been introduced (xpath utilities, DOM-
level 2 related methods, graphical methods).

All the details and the library itself can be obtained from the usual
source: http://www.vectomatic.org/lib-gwt-svg or http://code.google.com/p/vectomatic/

Re: GWT as a Desktop App (no browser !)

Without a browser is a bit nebulous ... but I'll tell you what I'm
doing and you can judge for yourself whether it meets your
requirements.

If you create the proper manifest, a web-application can be stored on
the user's hard-drive and run while off-line. I use Mozilla's Prism
as the "non-browser" ... it looks just like the application in a web
browser but has no navigation controls. Once you've got an off-line
application running, you'll also need to store the data locally. This
is only a little bit harder thanks to HTML5. Use the localstorage
calls in the Javascript engine to allow storage to the local hard-
drive. Note that this storage is a map controlled by the browser, so
you can do rudimentary indexing if you're smart about picking your
keys, but you do NOT have complete access to the local hard drive and
the total amount of storage allocated is limited by Prism (but can be
expanded by the user).

Here's a link to get you started with both off-line application
caching and localstorage: http://www.w3.org/TR/offline-webapps/

Hope this helps!

smoyer

On Oct 24, 12:50 pm, Be-noix <benoitscher...@gmail.com> wrote:
> QT is pretty easy to use and has WebKit in it, with the full support
> of javascript.
> You can compile your app for Win, Linux, OSX, ...
>
> Ben
>
> On 23 oct, 10:10, Stefan Bachert <stefanbach...@yahoo.de> wrote:
>
>
>
>
>
>
>
> > Hi matt,
>
> > this requirement are somewhat strange. Anyway,
> > I would rather for a possibility to modify an open source browser in
> > such a way,
> > that he is only allowed to open one URL (an this automatically).
> > Maybe remove URL entry and set the initial url to your site.
>
> > This is in the end no GWT question
>
> > Stefan Bacherthttp://gwtworld.de
>
> > On 22 Okt., 22:52, mattlf <matthieu.lab...@gmail.com> wrote:
>
> > > Hi
>
> > > I need to create a Desktop App. It can not be a browser App as this
> > > App should be the only App available.
> > > Is it possible for a GWT App to run outside the browser (on a
> > > different runtime) as a standalone Desktop App (packaed with a
> > > runtime?)
> > > I came accross GWT running on top of AIR but it seems esoteric
> > > Thank you for your help
> > > matt

No GWT Developer Plugin for Chrome on OSX

See subject.

Why is this - I thought Google was running all Macs now - and this
product is missing the developer plugin for Chrome?

Curious if this is something in progress or should I just continue to
use Safari/Firefox ?

Re: Announcing GWT 2.1

I haven't read up in detail on the new RequestFactory implementation except for the information I've read here on the group. I gather from what I've read then that RequestFactory is totally data specific and its only intention is to persist any data that has been changed on the client back to the server. It therefore seems, for example, that if it were required for security reasons, for instance, to validate that the request to the server is made with a valid session id and the session was still active that RequestFactory would not be the api to use and that instead the older RemoteService api would be the one to use, correct?

If my assumption is true are there any plans to incorporate security into RequestFactory in a future release? Factoring security into RequestFactory for this common use-case would be a good addition IMHO.

Jeff

On Sat, Oct 30, 2010 at 10:34 AM, Subhrajyoti Moitra <subhrajyotim@gmail.com> wrote:

" RequestFactory does not use GWT-RPC and is not intended to replace it. It is designed specifically for implementing a persistence layer on both client and server. "

http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html

On Sat, Oct 30, 2010 at 7:52 PM, gcstang <gcstang@gmail.com> wrote:

Excellent work! Some very nice changes.

Upon reading the documents I see that RPC has been replaced with the
RequestFactory will the old RPC's still work or does this mean that I
have to rebuild my whole project?

On Oct 29, 2:02 pm, "Alejandro D. Garin" <aga...@gmail.com> wrote:
> Hi,
>
> The Cell Widgets documentation at:
>
> http://code.google.com/webtoolkit/doc/latest/DevGuideUiCellWidgets.html
>
> at the bottom say:
>
> *To Update Data Range Changes from a Cell Widget:*
>
> 1. Create a subclass of
> AsyncListViewAdapter<http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...>
> .
> 2. Implement onRangeChanged(HasData
> display)<http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...)>
> .
> 1. Get the current range from the display
> 2. Request the data from the server or data source
> 3. When the data is returned, call updateRowData()
> <http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...)>to
> push the data to the widgets
>
> but AsyncListViewAdapte<http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...>r
> has been renamed to AsyncDataProvider, right?
>
> On Thu, Oct 28, 2010 at 3:12 PM, David Chandler <drfibona...@google.com>wrote:
>
> > GWT 2.1 is here!
>
> >http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release...
>
> > --
> > David Chandler
> > Developer Programs Engineer, Google Web Toolkit
> >http://googlewebtoolkit.blogspot.com/
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-web-toolkit@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubscribe@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Jeff

Re: Announcing GWT 2.1

" RequestFactory does not use GWT-RPC and is not intended to replace it. It is designed specifically for implementing a persistence layer on both client and server. "

http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html

On Sat, Oct 30, 2010 at 7:52 PM, gcstang <gcstang@gmail.com> wrote:

Excellent work! Some very nice changes.

Upon reading the documents I see that RPC has been replaced with the
RequestFactory will the old RPC's still work or does this mean that I
have to rebuild my whole project?

On Oct 29, 2:02 pm, "Alejandro D. Garin" <aga...@gmail.com> wrote:
> Hi,
>
> The Cell Widgets documentation at:
>
> http://code.google.com/webtoolkit/doc/latest/DevGuideUiCellWidgets.html
>
> at the bottom say:
>
> *To Update Data Range Changes from a Cell Widget:*
>
> 1. Create a subclass of
> AsyncListViewAdapter<http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...>
> .
> 2. Implement onRangeChanged(HasData
> display)<http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...)>
> .
> 1. Get the current range from the display
> 2. Request the data from the server or data source
> 3. When the data is returned, call updateRowData()
> <http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...)>to
> push the data to the widgets
>
> but AsyncListViewAdapte<http://google-web-toolkit.googlecode.com/svn/javadoc/2.1/com/google/g...>r
> has been renamed to AsyncDataProvider, right?
>
> On Thu, Oct 28, 2010 at 3:12 PM, David Chandler <drfibona...@google.com>wrote:
>
> > GWT 2.1 is here!
>
> >http://googlewebtoolkit.blogspot.com/2010/10/announcing-final-release...
>
> > --
> > David Chandler
> > Developer Programs Engineer, Google Web Toolkit
> >http://googlewebtoolkit.blogspot.com/
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-web-toolkit@googlegroups.com.
> > To unsubscribe from this group, send email to
> > google-web-toolkit+unsubscribe@googlegroups.com<google-web-toolkit%2Bunsubscribe@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.