subject:"Re\: Best practices\?"

Re: best practices for modular GWT app

2016-10-14 Thread Thomas Broyer

On Friday, October 14, 2016 at 10:20:28 AM UTC+2, Kirill Prazdnikov wrote:
>
> Well, my suggestion was only two modules:
>   1. GWT code - builds the client app
>   2. platform independent code (jar) for some logic shared between, for 
> example, server app
>
> Is it incorrect ?
>

And so you choose to bundle your sources into your JAR and thus deploy them 
in production.
There's nothing wrong with that, but it adds "bloat" to the final 
deliverable only to save you a couple lines in your POMs (btw, as soon as 
you declare a new , the default src/main/resources is ignored, 
and needs to be redeclared explicitly)

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: best practices for modular GWT app

2016-10-14 Thread Kirill Prazdnikov

Well, my suggestion was only two modules:
  1. GWT code - builds the client app
  2. platform independent code (jar) for some logic shared between, for 
example, server app

Is it incorrect ?

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: best practices for modular GWT app

2016-10-13 Thread Jens



> My recommendation, do NOT create a maven module if you don't need it (I 
> think that you do not need it). 
>

+1. Right. I would only split my client side code into multiple maven 
modules if I want to share client side code with a different project. If 
you don't do that, then adding multiple client side maven modules only adds 
complexity without a lot of value. You can still organize your code well 
within a single "client" maven module by creating multiple *.gwt.xml files, 
e.g.

com.example.app.App.gwt.xml
com.example.app.core.Core.gwt.xml
com.example.app.module1.Module1.gwt.xml
com.example.app.module2.Module2.gwt.xml


-- J.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: best practices for modular GWT app

2016-10-13 Thread Ignacio Baca Moreno-Torres

The IT directory in the gwt-maven-plugin includes more ussage examples,
this one includes all possible maven module types
https://github.com/tbroyer/gwt-maven-plugin/tree/master/src/it/e2e as
described here https://tbroyer.github.io/gwt-maven-plugin/. You do not need
to use resources->includes and you should use classifiers for
shared-non-gwt-only modules. Hehe, but this recommendations will make it
work perfect using the command line, I think that Kirill recommendations
will make eclipse more happy, not sure, I always execute GWT using mvn.

My recommendation, do NOT create a maven module if you don't need it (I
think that you do not need it). Client and Server modules are required
because in maven each module should output only one artifact, and also
client and server have independent run classpath. The shared is required to
share code ;).

On Thu, Oct 13, 2016 at 4:38 PM Kirill Prazdnikov  wrote:

> I do not know. We don't use "classifier-sources" in our maven files.
> I never run super-dev-mode from command-line. I run it form within the IDE.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "GWT Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to google-web-toolkit+unsubscr...@googlegroups.com.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> Visit this group at https://groups.google.com/group/google-web-toolkit.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: best practices for modular GWT app

2016-10-13 Thread Kirill Prazdnikov

I do not know. We don't use "classifier-sources" in our maven files.
I never run super-dev-mode from command-line. I run it form within the IDE.
  

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: best practices for modular GWT app

2016-10-13 Thread Luca Morettoni

> On 12 Oct 2016, at 19:38, Kirill Prazdnikov  wrote:
> 
> I do not completely understand which problems do you have, but we dont have 
> any issues working with SDM with modules I described above.

maybe was something wrong in my project layout. Now I made another test, and in 
the submodule I revert the packaging to “jar” and added back this:

src/main/java

**/*.java
**/*.gwt.xml
**/*.ui.xml

and in the main GWT pom.xml file I need to have this to work it correctly:

${project.groupId}
WebMetabase-module-user
${project.version}
sources

otherwise without the classifier-sources I didn’t get a recompile when I 
refresh the browser.
As I posted yesterday the system is also working using the other GWT-Maven 
plugin, but I think is a “clear” way to add extra modules to the project, I’m 
right?

--
Luca Morettoni  | http://www.morettoni.net
http://it.linkedin.com/in/morettoni/   | http://twitter.com/morettoni

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: best practices for modular GWT app

2016-10-12 Thread Kirill Prazdnikov

I do not completely understand which problems do you have, but we dont have any 
issues working with SDM with modules I described above.

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: best practices for modular GWT app

2016-10-12 Thread Luca Morettoni


> On 12 Oct 2016, at 10:29, Luca Morettoni  wrote:
> 
> Hi all, currently my application is using a single module for the GWT code, 
> but I’d like to split it in some submodules to better organize the code.
> Everything is under maven and I organised the main project layout using 
> Thomas Broyer gwt-maven-archetypes [1], so now I have a main maven project 
> and its 3 submodules (client, shared and server): my goal is to have the 
> client submodule that will use the new GWT-submodules, but which is the best 
> approach?
> 
> [1]https://github.com/tbroyer/gwt-maven-archetypes 
> 
I think I found a reasonable solution to my problem adding a maven submodule, 
and in the main pom.xml I just added this:


App-client
App-module-user
App-shared
App-server


in the "App-client” pom.xml (this is the main GWT app) I just added:


${project.groupId}
 App-module-user
${project.version}
gwt-lib


and last this is the pom.xml file for the App-module-user:

http://maven.apache.org/POM/4.0.0; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
4.0.0


net.morettoni.test
App
master


App-module-user
gwt-lib


${mavenVersion}




${project.groupId}
App-shared
${project.version}


${project.groupId}
 App-shared
${project.version}
sources


com.google.gwt
gwt-user




junit
junit






net.ltgt.gwt.maven
gwt-maven-plugin


net.morettoni.test.App.User






Hope this may help others!
A special Thanks to Thomas for the FANTASTIC plugin!!!

--
Luca Morettoni  | http://www.morettoni.net
http://it.linkedin.com/in/morettoni/   | http://twitter.com/morettoni

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: best practices for modular GWT app

2016-10-12 Thread Luca Morettoni


> On 12 Oct 2016, at 19:05, Kirill Prazdnikov  wrote:
> 
> As far as I know you need only one GWT maven module that builds the app. 
> The rest modules are just regular (platform independent) modules 
> (jar) and the gwt-app module depends on it.
> 
> So for the client app u have 2: main GWT module (A) with GWT specific code 
> and GWT dependencies and a plain jar module (B) with shared (with server) 
> logic. 
> And the A depends on B.


Thanks for the hint, but I think the configuration I used don’t allow the SDM 
to recompile the code if I will so some changes in the submodules; that was 
related to the gwt-maven-plugin I used in my project.

--
Luca Morettoni  | http://www.morettoni.net
http://it.linkedin.com/in/morettoni/   | http://twitter.com/morettoni

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: best practices for modular GWT app

2016-10-12 Thread Luca Morettoni


> On 12 Oct 2016, at 10:29, Luca Morettoni  wrote:
> 
> Hi all, currently my application is using a single module for the GWT code, 
> but I’d like to split it in some submodules to better organize the code.
> Everything is under maven and I organised the main project layout using 
> Thomas Broyer gwt-maven-archetypes [1], so now I have a main maven project 
> and its 3 submodules (client, shared and server): my goal is to have the 
> client submodule that will use the new GWT-submodules, but which is the best 
> approach?
> 
> - I will add other maven submodules and I will put there the code?
> - I will continue to use only one maven submodule for the client and there I 
> will split the GWT code in different submodules?
> 
> Thanks for any hints!
> 
> [1]https://github.com/tbroyer/gwt-maven-archetypes 
> 
I think I need to use generate-module [2], but I can’t find any sample or some 
extra details on how to use it, any help?


[2] https://tbroyer.github.io/gwt-maven-plugin/generate-module-mojo.html

--
Luca Morettoni  | http://www.morettoni.net
http://it.linkedin.com/in/morettoni/   | http://twitter.com/morettoni

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Best practices for reducing generated RPC Serialization code?

2014-06-03 Thread David

Hi Jens,

Yes it is true that all commandrequest/response objects will have
serializers generated, but that is exactly what I want. You could implement
some segregation by having multiple request/response base types and
different command processors, but in my case that would be too much work
for little gain.

I cut down on the amount of classes by having a generic response type and I
am grouping handlers in one class when they are of a related business
domain. The grouping happens with a base interface that uses the visitor
pattern. That way I can easily dispatch to the right method in the actual
Handler class. There really is not much friction when adding new commands
to my system, eclipse actually guides you in creating the request, add a
visitor method etc and you don't need to maintain both sync, async
interfaces and a servlet (and potentially web.xml updates).

To forward a request to the right handler I am using an annotation and
Guice on the server side. All I need is one binding in GIN which maps to a
Handler that can handle a group of related functionalities.

I also added lots of useful things like automatic error handling,
authentication with an external Identity Provider ... the business code is
completely oblivious to these things. Instead of using an AsyncCallback I
am using my own implementation of a Promise. This makes writing testing
code even simpler than when faking an AsyncCallback and it will make my
life so much easier when I can use Java 8.

David



On Mon, Jun 2, 2014 at 11:12 PM, Jens jens.nehlme...@gmail.com wrote:

 I'm also using a command pattern iso RPC directly, that makes my exposure
 to GWT specifics minimal and I can bypass the RPC part for automated tests.
 This way I add extra features like bulking, security, caching, etc.


 However if you use command pattern GWT generates serializers for each
 command  command result class. If you would call direct RPC methods
 instead of transferring commands you would save these serializers. I am
 also using command pattern in a larger app and I am still not sure if I
 like it or not. It's cool to have a central place to implement RPC relevant
 features but all these command/result classes are annoying.

 -- J.

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit.
 For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Best practices for reducing generated RPC Serialization code?

2014-06-02 Thread David

The thing that seems to have the biggest impact: be very specific about
concrete classes, otherwise you get an explosion on the number of
serializers that are generated. So don't use List, Collection, Iterable,
Map or even worse Serializable. When using generics also try to have a
specific base type in the generic parameter declaration or the compile size
explodes.

As a Java dev we have been trained to use Collection interfaces or after
Guava even going to Iterable ... not a great idea with RPC.
So I am using a small set of final collection classes in the member
declarations (but not on the setters/getters).

I'm also using a command pattern iso RPC directly, that makes my exposure
to GWT specifics minimal and I can bypass the RPC part for automated tests.
This way I add extra features like bulking, security, caching, etc.

On Mon, Jun 2, 2014 at 10:52 AM, Ed post2edb...@gmail.com wrote:

What are the best practices for reducing generated RPC Serialization code?

Currently I use small Remote backend interfaces such that the
serialization code is only downloaded when used in a split point.
However, reading this SO post,
http://stackoverflow.com/questions/6778664/gwt-how-can-i-reduce-the-size-of-code-serializers-for-rpc-calls
I get the impression it's better to use one big backend remote interface?

--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Best practices for reducing generated RPC Serialization code?

2014-06-02 Thread Juan Pablo Gardella

Agreed with David, FYI for command pattern I'm using gwt-dispatch
https://code.google.com/p/gwt-dispatch/ library.

2014-06-02 16:56 GMT-03:00 David david.no...@gmail.com:

On Mon, Jun 2, 2014 at 10:52 AM, Ed post2edb...@gmail.com wrote:

What are the best practices for reducing generated RPC Serialization code?

--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Best practices for reducing generated RPC Serialization code?

2014-06-02 Thread Jens



 I'm also using a command pattern iso RPC directly, that makes my exposure 
 to GWT specifics minimal and I can bypass the RPC part for automated tests. 
 This way I add extra features like bulking, security, caching, etc.


However if you use command pattern GWT generates serializers for each 
command  command result class. If you would call direct RPC methods 
instead of transferring commands you would save these serializers. I am 
also using command pattern in a larger app and I am still not sure if I 
like it or not. It's cool to have a central place to implement RPC relevant 
features but all these command/result classes are annoying.

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Best practices for reducing generated RPC Serialization code?

2014-06-02 Thread Ed Bras

Thanks for the input.
Could you give me some more insight on how you use the command pattern?
(how it appears in the front/backend interface/classes, and flow)..

I am also using the command pattern in the front-end, not the backend. The
command is handled by a central ServiceHandler that run all commands, and a
command will call a rpc method directly.

I am also using concrete classes, like ArrayList instead of List.
But what about using the issue mentioned in SO (duplicated serialization
code for same class in different method in different Async interfaces)?



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Best practices for reducing generated RPC Serialization code?

2014-06-02 Thread Jens



 Thanks for the input.
 Could you give me some more insight on how you use the command pattern? 
 (how it appears in the front/backend interface/classes, and flow)..


The implementation of the pattern is pretty standard stuff: interfaces 
Command + Result + Handler. Concrete commands have an annotation pointing 
to the handler that executes the command. The handler takes the command as 
input and does all the work.


But what about using the issue mentioned in SO (duplicated serialization 
 code for same class in different method in different Async interfaces)?


All the FieldSerializers are only generated once as they live next to the 
type they serialize. However each RPC service references a TypeSerializer 
which references all required FieldSerializers for that RPC service. If you 
have multiple RPC services and each serializes TypeA then the 
FieldSerializer for TypeA will be referenced by all TypeSerializers (each 
map has an entry for TypeA).

Speaking of command pattern: if you have multiple command services and each 
service has a distinct root command interface (ModACommand, ModBCommand) 
then the only things that might end up in multiple TypeSerializers are 
serializable JRE classes and common DTOs used in multiple command services. 
These might be less than you think. Just take a look at the serialization 
policy files of your services to see how much types are common.

-- J.

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Best Practices for Server-side Authentication in GWT 2.5+

2014-01-10 Thread Adam Browning

If you're just looking for simple authentication then you may want to take 
a look at: http://shiro.apache.org/. I've used it for simple authentication 
all the way up through using an LDAP backing store and it's pretty simple. 
It has some cool things like @RequiresAuthentication annotations that you 
can put on any RPC call you want to make sure the user is logged in for.

On Thursday, December 5, 2013 1:52:14 PM UTC-7, doctra...@gmail.com wrote:

 Hi,

 I'm trying to implement a login service whereby the user submits their 
 username and password to the app server (using RPC or RF, it doesn't really 
 matter).  Then on the server side, once I've verified that the credentials 
 are valid, I need to:

1. Call a loginDAO and record the login to persistence, then
2. Set some sort of session variable and/or cookie that can be used on 
subsequent requests to authenticate the user against
3. On such subsequent requests, check for the existence of the cookie 
and validate it;
4. Then, if they are inactive for a period of time, or they want to 
log out, I need a way to clear the cookie or end the session somehow

 I can handle #1 above all on my own, but I'm struggling with #2 - #4.  In 
 older versions of GWT I read that I could implement my own UserInformation 
 (and then configure the web.xml to accept this impl as a context param) 
 like so:

 public class MyUserInformation implements UserInformation {
 @Override
 public boolean isUserLoggedIn() {
 HttpServletRequest request = 
 RequestFactoryServlet.getThreadLocalRequest();

 // Now query the request for the presence of a cookie or session 
 var, etc. and return true or false accordingly.
 }
 }

 *However*, as of 2.5.1 (the version I'm using) this class has been 
 removed altogether (or so it seems). So I ask, what is the proper way to 
 implement GWT authentication now-a-days?  Is it still session/cookie based? 
 If so, what does it look like, for both the login and the logout? Thanks!


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Best Practices for Server-side Authentication in GWT 2.5+

2014-01-10 Thread Cristiano

Hi,

I'm studying how to use Spring Security to secure GWT web apps (I'll check 
Shiro in the future so I can't compare the two solutions).

I'm working backed by a open source github repo and you can take a look to 
it: https://github.com/cristcost/springsec
however it is a work in progress, where the GWT code is still all missing 
:-) and may require some tricky modification for you to build it (it 
requires the parent of another project of mine which is not updated, it is 
a maven project and also is thought to be deployed in Karaf and so it is 
not a standard web app, but i think that there good hints and I'm available 
to answer questions about it).

The main point to note about my solution for using Spring Security is that 
it has to be a Spring Web Application and used Spring MVC. In the end like 
this approach as I intend to make a light usage of Spring MVC dedicated 
only to generation of baking html pages.

I want to use Spring Security to manage authentication outside of GWT 
(let's say in an old Web 1.0 fashion with old plain html forms) and then 
work on with authorization annotations directly on the service like you can 
see on this example of code: 
https://github.com/cristcost/springsec/blob/master/src/main/java/net/cristcost/study/AnnotatedServiceImpl.java


If you intend to proceed in this direction, the main issue I've solved has 
been to declare a simple HttpServlet and publish it over Spring MVC so it 
can get Secured: this is not well documented (you only find easily how to 
add Spring MVC controllers or the Spring servlets like classes of type 
org.springframework.web.HttpRequestHandler! But a GWT RPC service 
implements an HttpServlet!) but in the end I found a simple solution that 
is registering a SimpleServletHandlerAdapter bean (as in 
https://github.com/cristcost/springsec/blob/master/src/main/webapp/WEB-INF/spring/beans-mvc.xml)
 
and then map it to an URL managed by Spring MVC DispatcherServlet (as you 
can see in 
https://github.com/cristcost/springsec/blob/master/src/main/webapp/WEB-INF/spring/beans.xml
).


The study is not done yet and up to now I've secured only a standard 
HttpServlet (or to be more precise, I've secured an indipendent POJO which 
is used by a standard HttpServlet).
I'm actually preparing a GWT application to add to the project and then 
start testing securing a RPC GWT Service (that is my final goal). For 
simplicity however I will put pre-compiled JavaScript code only in the 
project so I can focus on the server side.

If anyone is interested I'm glad to give free support in exchange for 
feedback :-)

Cristiano




Il giorno giovedì 5 dicembre 2013 21:52:14 UTC+1, doctra...@gmail.com ha 
scritto:

 Hi,

 I'm trying to implement a login service whereby the user submits their 
 username and password to the app server (using RPC or RF, it doesn't really 
 matter).  Then on the server side, once I've verified that the credentials 
 are valid, I need to:

1. Call a loginDAO and record the login to persistence, then
2. Set some sort of session variable and/or cookie that can be used on 
subsequent requests to authenticate the user against
3. On such subsequent requests, check for the existence of the cookie 
and validate it;
4. Then, if they are inactive for a period of time, or they want to 
log out, I need a way to clear the cookie or end the session somehow

 I can handle #1 above all on my own, but I'm struggling with #2 - #4.  In 
 older versions of GWT I read that I could implement my own UserInformation 
 (and then configure the web.xml to accept this impl as a context param) 
 like so:

 public class MyUserInformation implements UserInformation {
 @Override
 public boolean isUserLoggedIn() {
 HttpServletRequest request = 
 RequestFactoryServlet.getThreadLocalRequest();

 // Now query the request for the presence of a cookie or session 
 var, etc. and return true or false accordingly.
 }
 }

 *However*, as of 2.5.1 (the version I'm using) this class has been 
 removed altogether (or so it seems). So I ask, what is the proper way to 
 implement GWT authentication now-a-days?  Is it still session/cookie based? 
 If so, what does it look like, for both the login and the logout? Thanks!


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-14 Thread Joseph Lust

Thanks for sharing. That's what I was using before. A real *chicken and the 
egg *problem while I sounds so simple in principle.

I've also pondered a direct string replacement against the compiles JS 
files (i.e. $$BUILD_NUMBER) with filters in the war building plugin 
as ostensibly strings are still the same string in the compiled JS, but 
that would not be nearly as dependable and could certainly blow up with 
future compiler changes.


Sincerely,
Joseph

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-13 Thread Frank Hossfeld

Hi Honza,

your implementation sounds intresting.
Can you provide more informations about your solution?

Thanks Frank
 
Am Mittwoch, 12. Juni 2013 09:50:41 UTC+2 schrieb Honza Rames:

 I have a XML file that stores various information about my build and is 
 updated by a Linker which increments build number each build I make. And I 
 have a generator that returns an interface that I can use in GWT app which 
 includes the build number, revision, build date etc.

 Regards

 Honza

 On Tuesday, June 11, 2013 7:17:42 PM UTC+2, Joseph Lust wrote:

 For various reasons you need to know the revision of the GWT app code. 
 For example to verify that the server API is not newer than the JS code 
 (i.e. if you deploy GWT JS to a CDN).

 Some common approaches which I find to be rather hackish:

- Use Maven replacer to replace a sequence in a *source* file at the 
validation stage and have that inlined into your GWT file at compile 
(hackish)
- Use Maven replacer or Maven war plugin filters to add the build 
number to the index.html page, or a backend service (JS code still not 
independently versioned, more API calls)
- Hardcode it (don't hardcode things)

 After two years, the best method I've see is to create a *code generator* to 
 allow deferred binding of the build number. This however has always stuck 
 me as massively overkill to add a number to a build artifact.


 So, I was curious how others here have dealt with this common issue. 
 Hopefully there is a simpler way.


 Sincerely,
 Joseph



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

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-13 Thread Honza Rames

Hi Frank,

I have a XML (version.xml) document in my war directory:

?xml version=1.0 encoding=UTF-8?
!DOCTYPE version [!ATTLIST build id ID #IMPLIED]
version
  build id=build76/build
  !-- Another data if you need it --
/version

A linker that increments the build number after the link process has been 
completed:

package my.pkg;

import com.google.gwt.core.ext.LinkerContext;
import com.google.gwt.core.ext.TreeLogger;
import com.google.gwt.core.ext.UnableToCompleteException;
import com.google.gwt.core.ext.linker.AbstractLinker;
import com.google.gwt.core.ext.linker.ArtifactSet;
import com.google.gwt.core.ext.linker.LinkerOrder;
import com.google.gwt.core.ext.linker.LinkerOrder.Order;
import com.google.gwt.core.ext.linker.Shardable;

/**
 * Just a linker that will increment build after compilation is done
 * @author SHadoW
 *
 */
@LinkerOrder(Order.POST)
@Shardable
public class IncBuildLinker extends AbstractLinker
{
  private static boolean incremented = false;

  @Override
  public String getDescription()
  {
return IncBuildLinker;
  }

  @Override
  public ArtifactSet link(TreeLogger logger, LinkerContext context,
  ArtifactSet artifacts, boolean onePermutation) throws 
UnableToCompleteException
  {
//Do this only once after the entire link process has completed
if (onePermutation  (! incremented)) 
{
  BuildHelper.incBuildAndSave(logger); //Do this only after all 
permutations has been compiled
  incremented = true;
}
return super.link(logger, context, artifacts);
  }
}

the BuildHelper class accesses the version.xml and I don't want to post it 
here because it is pretty straight forward but still a lot of code ;-). And 
the generator (it uses some of my classes that ease the code generation) 
which creates an implementation for BuildInfo interface that you 
instantiate with GWT.create(BuildInfo.class) which looks as follows:

package my.pkg;

import java.util.Date;

import com.google.gwt.dev.About;
import my.pkg.generators.BaseGenerator;
import my.pkg.generators.BaseGeneratorClient;

public class BuildGenerator extends BaseGenerator
{
  /* I'm using some helpers in generation process that's why I have the 
Client class here, it defines some functions that make it easier to 
generate java code in hand*/
  @Override
  protected BaseGeneratorClient getClient()
  {
return new Client();
  }
  class Client extends BaseGeneratorClient
  {
/* This gets called by the generator once the class imports and 
declaration is written by the generator */
@Override
protected void doGenerate()
{
  writeBlockIntro(public String getBuildDate());
  writeReturn(STR, (new Date()).toString());
  writeBlockOutro();
  
  writeBlockIntro(public int getBuildNumber());
  writeReturn(BuildHelper.getBuildNumber());
  writeBlockOutro();
  writeBlockIntro(public String getGwtSvnRev());
  writeReturn(STR, About.getGwtSvnRev());  //This is saved during GWT 
build process and can only be accessed in plain java
  writeBlockOutro();
}
  }
}

and of course appropriately set module.gwt.xml that includes:

define-linker name=incbuild class=my.pkg.IncBuildLinker /
add-linker name=incbuild /

generate-with class=my.pkg.BuildGenerator
  when-type-is class=my.pkg.client.BuildInfo/
/generate-with

it is useful to have multiple modules that only one of them includes the 
linker so you only increment the build number after you compile for 
production so that development builds don't increment the build number.

Everybody else not interested in my solution sorry for the longish post, I 
din't see any other way how to do this. 
If anybody else need more explanation I could provide full source codes 
directly if needed, feel free to ask any questions ;-)

Honza

On Thursday, June 13, 2013 9:46:22 AM UTC+2, Frank Hossfeld wrote:

 Hi Honza,

 your implementation sounds intresting.
 Can you provide more informations about your solution?

 Thanks Frank
  
 Am Mittwoch, 12. Juni 2013 09:50:41 UTC+2 schrieb Honza Rames:

 I have a XML file that stores various information about my build and is 
 updated by a Linker which increments build number each build I make. And I 
 have a generator that returns an interface that I can use in GWT app which 
 includes the build number, revision, build date etc.

 Regards

 Honza

 On Tuesday, June 11, 2013 7:17:42 PM UTC+2, Joseph Lust wrote:

 For various reasons you need to know the revision of the GWT app code. 
 For example to verify that the server API is not newer than the JS code 
 (i.e. if you deploy GWT JS to a CDN).

 Some common approaches which I find to be rather hackish:

- Use Maven replacer to replace a sequence in a *source* file at the 
validation stage and have that inlined into your GWT file at compile 
(hackish)
- Use Maven replacer or Maven war plugin filters to add the build 
number to the index.html page, or a backend service (JS code still not 
independently versioned,

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-13 Thread Timothy Spear

Honza,

Nice solution. My old solution using shell scripts and ant was a lot simpler. 
-- A java class object with just static variables, BUILD_DATE, BUILD_NUMBER….
-- In shell scrips I would pull the date and last revision number from 
subversion. Then using a simple echo command I would build a new java class 
file.
-- I have yet to take the time and see how I can integrate the ability to pull 
the information from subversion  into Maven. I even had shell scripts to 
generate release changes, store the RPM in a repository…. At some point I think 
I will have to spend a few weeks converting all my shell scripts, ant build 
scripts to Maven.

Tim

On Jun 13, 2013, at 10:21 AM, Honza Rames rame...@gmail.com wrote:

 Hi Frank,
 
 I have a XML (version.xml) document in my war directory:
 
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE version [!ATTLIST build id ID #IMPLIED]
 version
   build id=build76/build
   !-- Another data if you need it --
 /version
 
 A linker that increments the build number after the link process has been 
 completed:
 
 package my.pkg;
 
 import com.google.gwt.core.ext.LinkerContext;
 import com.google.gwt.core.ext.TreeLogger;
 import com.google.gwt.core.ext.UnableToCompleteException;
 import com.google.gwt.core.ext.linker.AbstractLinker;
 import com.google.gwt.core.ext.linker.ArtifactSet;
 import com.google.gwt.core.ext.linker.LinkerOrder;
 import com.google.gwt.core.ext.linker.LinkerOrder.Order;
 import com.google.gwt.core.ext.linker.Shardable;
 
 /**
  * Just a linker that will increment build after compilation is done
  * @author SHadoW
  *
  */
 @LinkerOrder(Order.POST)
 @Shardable
 public class IncBuildLinker extends AbstractLinker
 {
   private static boolean incremented = false;
 
   @Override
   public String getDescription()
   {
 return IncBuildLinker;
   }
 
   @Override
   public ArtifactSet link(TreeLogger logger, LinkerContext context,
   ArtifactSet artifacts, boolean onePermutation) throws 
 UnableToCompleteException
   {
 //Do this only once after the entire link process has completed
 if (onePermutation  (! incremented)) 
 {
   BuildHelper.incBuildAndSave(logger); //Do this only after all 
 permutations has been compiled
   incremented = true;
 }
 return super.link(logger, context, artifacts);
   }
 }
 
 the BuildHelper class accesses the version.xml and I don't want to post it 
 here because it is pretty straight forward but still a lot of code ;-). And 
 the generator (it uses some of my classes that ease the code generation) 
 which creates an implementation for BuildInfo interface that you instantiate 
 with GWT.create(BuildInfo.class) which looks as follows:
 
 package my.pkg;
 
 import java.util.Date;
 
 import com.google.gwt.dev.About;
 import my.pkg.generators.BaseGenerator;
 import my.pkg.generators.BaseGeneratorClient;
 
 public class BuildGenerator extends BaseGenerator
 {
   /* I'm using some helpers in generation process that's why I have the 
 Client class here, it defines some functions that make it easier to generate 
 java code in hand*/
   @Override
   protected BaseGeneratorClient getClient()
   {
 return new Client();
   }
   
   class Client extends BaseGeneratorClient
   {
 /* This gets called by the generator once the class imports and 
 declaration is written by the generator */
 @Override
 protected void doGenerate()
 {
   writeBlockIntro(public String getBuildDate());
   writeReturn(STR, (new Date()).toString());
   writeBlockOutro();
   
   writeBlockIntro(public int getBuildNumber());
   writeReturn(BuildHelper.getBuildNumber());
   writeBlockOutro();
   
   writeBlockIntro(public String getGwtSvnRev());
   writeReturn(STR, About.getGwtSvnRev());  //This is saved during GWT 
 build process and can only be accessed in plain java
   writeBlockOutro();
 }
   }
 }
 
 and of course appropriately set module.gwt.xml that includes:
 
 define-linker name=incbuild class=my.pkg.IncBuildLinker /
 add-linker name=incbuild /
 
 generate-with class=my.pkg.BuildGenerator
   when-type-is class=my.pkg.client.BuildInfo/
 /generate-with
 
 it is useful to have multiple modules that only one of them includes the 
 linker so you only increment the build number after you compile for 
 production so that development builds don't increment the build number.
 
 Everybody else not interested in my solution sorry for the longish post, I 
 din't see any other way how to do this. 
 If anybody else need more explanation I could provide full source codes 
 directly if needed, feel free to ask any questions ;-)
 
 Honza
 
 On Thursday, June 13, 2013 9:46:22 AM UTC+2, Frank Hossfeld wrote:
 Hi Honza,
 
 your implementation sounds intresting.
 Can you provide more informations about your solution?
 
 Thanks Frank
  
 Am Mittwoch, 12. Juni 2013 09:50:41 UTC+2 schrieb Honza Rames:
 I have a XML file that stores various information about my build and is

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-12 Thread Honza Rames

I have a XML file that stores various information about my build and is 
updated by a Linker which increments build number each build I make. And I 
have a generator that returns an interface that I can use in GWT app which 
includes the build number, revision, build date etc.

Regards

Honza

On Tuesday, June 11, 2013 7:17:42 PM UTC+2, Joseph Lust wrote:

 For various reasons you need to know the revision of the GWT app code. For 
 example to verify that the server API is not newer than the JS code (i.e. 
 if you deploy GWT JS to a CDN).

 Some common approaches which I find to be rather hackish:

- Use Maven replacer to replace a sequence in a *source* file at the 
validation stage and have that inlined into your GWT file at compile 
(hackish)
- Use Maven replacer or Maven war plugin filters to add the build 
number to the index.html page, or a backend service (JS code still not 
independently versioned, more API calls)
- Hardcode it (don't hardcode things)

 After two years, the best method I've see is to create a *code generator* to 
 allow deferred binding of the build number. This however has always stuck 
 me as massively overkill to add a number to a build artifact.


 So, I was curious how others here have dealt with this common issue. 
 Hopefully there is a simpler way.


 Sincerely,
 Joseph


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

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-11 Thread Timothy Spear

I have a version.txt included in the src/java/resources

 NAME=${name}
 VERSION=${version}
 BUILD_DATE=${timestamp}


The values are retrieved from the POM. My current project does not go the next 
step of pushing the completed branch on deploy to a tagged release in 
subversion. I have traditionally done release management via shell scripts and 
have not migrated that aspect to Maven yet.

Tim

On Jun 11, 2013, at 1:17 PM, Joseph Lust lifeofl...@gmail.com wrote:

 For various reasons you need to know the revision of the GWT app code. For 
 example to verify that the server API is not newer than the JS code (i.e. if 
 you deploy GWT JS to a CDN).
 
 Some common approaches which I find to be rather hackish:
 Use Maven replacer to replace a sequence in a source file at the validation 
 stage and have that inlined into your GWT file at compile (hackish)
 Use Maven replacer or Maven war plugin filters to add the build number to the 
 index.html page, or a backend service (JS code still not independently 
 versioned, more API calls)
 Hardcode it (don't hardcode things)
 After two years, the best method I've see is to create a code generator to 
 allow deferred binding of the build number. This however has always stuck me 
 as massively overkill to add a number to a build artifact.
 
 
 So, I was curious how others here have dealt with this common issue. 
 Hopefully there is a simpler way.
 
 
 Sincerely,
 Joseph
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 Google Web Toolkit group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to google-web-toolkit+unsubscr...@googlegroups.com.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.
  
  

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

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-11 Thread Jens

I would either hardcode it into a Gin module and inject the app version 
into any class using an @AppVersion annotation or I would use Maven 
Resource Filtering and let maven replace a placeholder with the project 
version. This replacement is then either done in index.html or in a txt 
file that is then used as a TextResource in a ClientBundle.

-- J.

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

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-11 Thread Thomas Broyer



On Tuesday, June 11, 2013 9:44:51 PM UTC+2, Jens wrote:

 I would either hardcode it into a Gin module and inject the app version 
 into any class using an @AppVersion annotation or I would use Maven 
 Resource Filtering and let maven replace a placeholder with the project 
 version. This replacement is then either done in index.html or in a txt 
 file that is then used as a TextResource in a ClientBundle.


…or a properties file used as a Constants. 

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

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-11 Thread Joseph Lust

Thanks gents,

Your suggestions were helpful. After going the code generator route two 
years ago, but I think this time I'll stick with resource filtering the 
version into the index.html and bootstrapping it into the app via the entry 
point. 

Cheers,
Joseph

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

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-11 Thread Thad Humphries

I'm switching from ant to maven, and recently tried 
http://mojo.codehaus.org/buildnumber-maven-plugin/. I think I will use it 
on my next project.

On Tuesday, June 11, 2013 1:17:42 PM UTC-4, Joseph Lust wrote:

 For various reasons you need to know the revision of the GWT app code. For 
 example to verify that the server API is not newer than the JS code (i.e. 
 if you deploy GWT JS to a CDN).

 Some common approaches which I find to be rather hackish:

- Use Maven replacer to replace a sequence in a *source* file at the 
validation stage and have that inlined into your GWT file at compile 
(hackish)
- Use Maven replacer or Maven war plugin filters to add the build 
number to the index.html page, or a backend service (JS code still not 
independently versioned, more API calls)
- Hardcode it (don't hardcode things)

 After two years, the best method I've see is to create a *code generator* to 
 allow deferred binding of the build number. This however has always stuck 
 me as massively overkill to add a number to a build artifact.


 So, I was curious how others here have dealt with this common issue. 
 Hopefully there is a simpler way.


 Sincerely,
 Joseph


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

Re: Best Practices/Tips to Achieve Great Performance/Memory/etc

2013-05-02 Thread Ashton Thomas

I would like to add some more references here within the context of Memory 
management.

--
http://www.draconianoverlord.com/2010/11/23/gwt-handlers.html

To avoid application-level memory leaks, when adding event handlers, you 
need to think about:

What is the scope of the event source (the widget or the EventBus)?
What is the scope of the event handler (the presenter)?
And then:

AA] - If the scopes are the same: you can ignore the HandlerRegistration 
and trust that GWT/the garbage collection will clean things up for you.
BB] - If the handler scope is longer-lived than the source scope: the 
handler would keep the source in memory, so you need to call 
removeHandler() when appropriate.
CC] - If the source scope is longer-lived than the handler scope: the 
source would keep the handler in memory, so you also need to call 
removeHandler() when appropriate.
=

It seems there are quite a few ways that the average (or, in my case, below 
average) dev can get in trouble:
(In theory, we would never create application-level memory leaks, but)

- Creating handlers (from a disposable Activity which will add new handlers 
on each page/place visit) on widgets in a long-lived, Singleton view
+ Declaring GWT or custom widgets in a UiBinder file (or any long-lived 
view component) where the disposable activity adds handlers
++ I assume this is where we note the GWT standard of MVP and not 
allowing the activity to directly add handlers but have the view contact 
the Activities interface: presenter.onSomeClick();

- Bypassing the Resettable ActivityManager-provided eventBus

- Basically doing anything out of GWT/fundamental standard operation which 
creates situations BB  CC from above.



--

https://code.google.com/p/google-web-toolkit/wiki/UnderstandingMemoryLeaks
https://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks
http://www.draconianoverlord.com/2010/11/23/gwt-handlers.html
https://groups.google.com/forum/#!searchin/google-web-toolkit/Remove$20event$20handlers$20or$20not?/google-web-toolkit/7aHqw-C-Oy0/OOTxO8386BUJ

On Wednesday, May 1, 2013 2:12:37 PM UTC-4, Ashton Thomas wrote:

 Does anyone know of a list of best practices for handling 
 Performance/Memory/etc while using Activities, Widgets, UiBinder, 
 ClickHandlers, etc.?

 Such as:

 - Making sure widgets/components are GC'ed 
 - Patterns for reusing widgets/components instead of rebuilding
 - Widgets to avoid or lean toward
 - Events/Handlers patterns/anti-patterns
 - Using Scheduler.get().scheduleDeffered() to break executions up to 
 achieve 60fps?
 - Non-GWT-specific such as: Write to DOM all at once / avoid layouts 
 (repaint/reflow)
 - Looking for more GWT-specific Best Practices to achieve the best 
 performance and memory usage
 - Use HTMLPanel or DIV when just laying things out (similar examples?)?
 - Other tips BP's for creating high performance apps w/GWT?
 + What are bad things we can do?
 + Most common mistakes that kill performance etc?



 I've tried to include some reference I've come across which seemed to be 
 helpful (GWT or Non-GWT):


 Some Links I've collected:

 http://www.youtube.com/watch?v=0F5zc1UAt2Y

 http://www.youtube.com/watch?v=Oic22dQMRXQlist=PLNYkxOF6rcICCU_UD67Ga0qLvMjnBBwftfeature=player_embedded
 https://developers.google.com/events/io/2012/sessions/gooio2012/207/

 http://addyosmani.com/blog/devtools-visually-re-engineering-css-for-faster-paint-times/
 http://taligarsiel.com/Projects/howbrowserswork1.htm#The_rendering_engine
 http://www.html5rocks.com/en/tutorials/speed/scrolling/
 http://www.igvita.com/
 http://jankfree.org/
 http://paulirish.com/2011/requestanimationframe-for-smart-animating/
 http://kellegous.com/j/2013/01/26/layout-performance/#bindings


 Some Random Notes I've collected:


   - Pointers / Issues / Best Practices
 - CSS Selector (more specific - on right-most side)
 - Reduce DNS Lookup
 - Avoid Redirects - DO NOT REDIRECT
 - Make Fewer HTTP requests
 - Flushing the document early when you have import info (link to 
 resources to start downloading)
 - Use A CDN
 - gzip everything
 - cache headers set correctly on everything
 - optimize images + use correct size
   - Mobile vs Desktop version of images
   - Pick correct format/quality/size
   - Use Transloadit on upload to create options for all images
 - We aren't an image service so this is fine
 - Expires and Etags
 - Stylesheets at top
 - local scripts async when possible
   - sync scripts block document parser
   - place scripts at bottom 
 - Minify, concatenate files
 - 60FPS (16.666ms per execution) - Buttery Smooth
   - check out hardware gpu acceleration 
 - don't update these parts at all
 - Eliminate Memory Leaks / work with GC
   -

Re: Best Practices/Tips to Achieve Great Performance/Memory/etc

2013-05-02 Thread Ümit Seren

Most of your links refer to optimizations for writing pure javascript code. 
GWT actually takes care of many of these issues out of the box . For 
example ClientBundle helps to avoid too many HTTP requests and include CSS 
optimizations.
That doesn't mean that it is impossible to write slow GWT apps. It's just 
that most of these recommendations are really difficult to do in GWT 
because you don't really have control over the compiled code. 
There are some stuff you can do. (i.e. using CSS transitions instead of 
javascript code to do animations, etc)
In the end I would recommend to profile your app and see if there any 
bottlenecks.




On Thursday, May 2, 2013 4:07:29 PM UTC+2, Ashton Thomas wrote:

 I would like to add some more references here within the context of Memory 
 management.

 --
 http://www.draconianoverlord.com/2010/11/23/gwt-handlers.html

 To avoid application-level memory leaks, when adding event handlers, you 
 need to think about:

 What is the scope of the event source (the widget or the EventBus)?
 What is the scope of the event handler (the presenter)?
 And then:

 AA] - If the scopes are the same: you can ignore the HandlerRegistration 
 and trust that GWT/the garbage collection will clean things up for you.
 BB] - If the handler scope is longer-lived than the source scope: the 
 handler would keep the source in memory, so you need to call 
 removeHandler() when appropriate.
 CC] - If the source scope is longer-lived than the handler scope: the 
 source would keep the handler in memory, so you also need to call 
 removeHandler() when appropriate.
 =

 It seems there are quite a few ways that the average (or, in my case, 
 below average) dev can get in trouble:
 (In theory, we would never create application-level memory leaks, but)

 - Creating handlers (from a disposable Activity which will add new 
 handlers on each page/place visit) on widgets in a long-lived, Singleton 
 view
 + Declaring GWT or custom widgets in a UiBinder file (or any long-lived 
 view component) where the disposable activity adds handlers
 ++ I assume this is where we note the GWT standard of MVP and not 
 allowing the activity to directly add handlers but have the view contact 
 the Activities interface: presenter.onSomeClick();

 - Bypassing the Resettable ActivityManager-provided eventBus

 - Basically doing anything out of GWT/fundamental standard operation which 
 creates situations BB  CC from above.



 --

 https://code.google.com/p/google-web-toolkit/wiki/UnderstandingMemoryLeaks
 https://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks
 http://www.draconianoverlord.com/2010/11/23/gwt-handlers.html

 https://groups.google.com/forum/#!searchin/google-web-toolkit/Remove$20event$20handlers$20or$20not?/google-web-toolkit/7aHqw-C-Oy0/OOTxO8386BUJ

 On Wednesday, May 1, 2013 2:12:37 PM UTC-4, Ashton Thomas wrote:

 Does anyone know of a list of best practices for handling 
 Performance/Memory/etc while using Activities, Widgets, UiBinder, 
 ClickHandlers, etc.?

 Such as:

 - Making sure widgets/components are GC'ed 
 - Patterns for reusing widgets/components instead of rebuilding
 - Widgets to avoid or lean toward
 - Events/Handlers patterns/anti-patterns
 - Using Scheduler.get().scheduleDeffered() to break executions up to 
 achieve 60fps?
 - Non-GWT-specific such as: Write to DOM all at once / avoid layouts 
 (repaint/reflow)
 - Looking for more GWT-specific Best Practices to achieve the best 
 performance and memory usage
 - Use HTMLPanel or DIV when just laying things out (similar examples?)?
 - Other tips BP's for creating high performance apps w/GWT?
 + What are bad things we can do?
 + Most common mistakes that kill performance etc?



 I've tried to include some reference I've come across which seemed to be 
 helpful (GWT or Non-GWT):


 Some Links I've collected:

 http://www.youtube.com/watch?v=0F5zc1UAt2Y

 http://www.youtube.com/watch?v=Oic22dQMRXQlist=PLNYkxOF6rcICCU_UD67Ga0qLvMjnBBwftfeature=player_embedded
 https://developers.google.com/events/io/2012/sessions/gooio2012/207/

 http://addyosmani.com/blog/devtools-visually-re-engineering-css-for-faster-paint-times/
 http://taligarsiel.com/Projects/howbrowserswork1.htm#The_rendering_engine
 http://www.html5rocks.com/en/tutorials/speed/scrolling/
 http://www.igvita.com/
 http://jankfree.org/
 http://paulirish.com/2011/requestanimationframe-for-smart-animating/
 http://kellegous.com/j/2013/01/26/layout-performance/#bindings


 Some Random Notes I've collected:


   - Pointers / Issues / Best Practices
 - CSS Selector (more specific - on right-most side)
 - Reduce DNS Lookup
 - Avoid Redirects - DO NOT REDIRECT
 - Make Fewer HTTP requests
 - Flushing the document early when you have import info (link to 
 resources to start downloading)
 - Use A CDN
 - gzip everything
 - cache

Re: Best practices for building UiBinder based widgets: Composition vs Inheritance vs ...

2012-10-25 Thread othman

gwt-platform have a better design for nested Presenters.
That's where nesting presenters becomes handy, because you would create a 
upper layer presenter that has a content slot from every other presenters 
to be shown in and only this one would have the header and the footer in 
it. I always call this presenter : ApplicationPresenter.

You can find an example in here:
http://code.google.com/p/gwt-platform/wiki/GettingStarted?tm=6#Nested_presenters


On Friday, July 22, 2011 3:18:37 PM UTC+1, Alexander Orlov wrote:

 On Fri, Jul 22, 2011 at 1:22 PM, Jens jens.ne...@gmail.com 
 javascript:wrote:

 my:MyPanel
   my:header
  g:LabelHeader/g:Label
   /my:header
 /my:MyPanel

 Your Java implementation of MyPanel would then contain methods:

 @UiChild
 public void addHeader(Widget w) {
  //your add logic
 }

  
 Great, that's basically everything I need!

 -Alex
  

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

Re: Best practices waiting for DOM parsing

2012-08-28 Thread Chris Price

I was under the impression that all DOM manipulation calls are
synchronous, are you sure it's not GWT using the Scheduler under the
hood to run some of your code asynchronously? Can you give some
example code?

On Tue, Aug 28, 2012 at 2:33 PM, Joseph Lust lifeofl...@gmail.com wrote:
 I wanted to ask the community's opinion on the best practice for waiting for
 a DOM resource to become available.

 Use Case:
 You make an elaborate component via UiBinder or injecting some HTML/SVG into
 the DOM and upon executing the following statement trying to access an
 element that was injected, the DOM does not see it (i.e. inject 2MB of SVG)
 due to DOM parsing lag.

 Work Arounds:

 Schedule recurring timer to check if the element is available and then
 continue the program flow (now that the element's accessible in the DOM).
 OR Schedule a deferred timer and then continue (less robust, does not always
 work).

 So, curious what other folks have been using in this case where the GWT code
 must wait to wait for DOM parsing lag time. It seems to me like this is
 something there should be an official GWT function for doing as other
 frameworks do have functions to wait until an object becomes available in
 the DOM.


 Sincerely,
 Joseph

 --
 You received this message because you are subscribed to the Google Groups
 Google Web Toolkit group.
 To view this discussion on the web visit
 https://groups.google.com/d/msg/google-web-toolkit/-/JpBdhNvNWbIJ.
 To post to this group, send email to google-web-toolkit@googlegroups.com.
 To unsubscribe from this group, send email to
 google-web-toolkit+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best practices waiting for DOM parsing

2012-08-28 Thread Alfredo Quiroga-Villamil

Hi Joseph:

Not as familiar with SVG as I am with Canvas, but I am thinking that
you can likely (assuming I interpreted the documentation correctly)
hook into the SVG load event. Do investigate this, as I am not sure,
but below are a couple of sources. Take a look at SVGLoad, perhaps you
can use something like that instead of you doing the checking,
leverage if it's valid the callback that's native there.

http://www.w3.org/TR/SVG/interact.html

Then something like:

http://stackoverflow.com/questions/3883257/loading-svg-into-svgweb-dynamically-with-jquery

svg.addEventListener('SVGLoad', function() {
  svg = this; // this will correctly refer to your SVG root
  alert('loaded!');
}, false);
// also supported:
svg.onsvgload = function() {
  alert('loaded!');
}

Best regards,

Alfredo

On Tue, Aug 28, 2012 at 9:33 AM, Joseph Lust lifeofl...@gmail.com wrote:
 I wanted to ask the community's opinion on the best practice for waiting for
 a DOM resource to become available.

 Use Case:
 You make an elaborate component via UiBinder or injecting some HTML/SVG into
 the DOM and upon executing the following statement trying to access an
 element that was injected, the DOM does not see it (i.e. inject 2MB of SVG)
 due to DOM parsing lag.

 Work Arounds:

 Schedule recurring timer to check if the element is available and then
 continue the program flow (now that the element's accessible in the DOM).
 OR Schedule a deferred timer and then continue (less robust, does not always
 work).

 So, curious what other folks have been using in this case where the GWT code
 must wait to wait for DOM parsing lag time. It seems to me like this is
 something there should be an official GWT function for doing as other
 frameworks do have functions to wait until an object becomes available in
 the DOM.


 Sincerely,
 Joseph

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



-- 
Alfredo Quiroga-Villamil

AOL/Yahoo/Gmail/MSN IM:  lawwton

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best practices waiting for DOM parsing

2012-08-28 Thread Joseph Lust

@Chris Price
Thanks, I'll try to put together a simple demo. The only trouble is that 
this only happens on quite complex UI's, but I'll try to distill it down to 
it's essence.

@Alfredo
The issues I found with SVG is that these events are not well supported. 
For example, in Mozilla, SVG.getElementById is not supported. Why? On the 
but they said that they hadn't bothered to implement the *whole* SVG spec 
since Canvas is the cat's meow. In the Lib-GWT-SVG library which we use, 
there is no support for events on SVG elements. I see that the spec you 
sent is barely a year old. I'll need to check if that is more supported 
than it was last year when I was trying.

Ideally I'd just use addLoadHandler from 
http://www.w3.org/TR/SVG/script.html#EventAttributes, but it's not in the 
aforementioned SVG lib. I'll have to try doing it myself and see how it 
goes.


Sincerely,
Joseph

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

Re: Best practices waiting for DOM parsing

2012-08-28 Thread Joseph Lust

@Chris Price
Thanks, I'll try to put together a simple demo. The only trouble is that 
this only happens on quite complex UI's, but I'll try to distill it down to 
it's essence.

@Alfredo
The issue I found with SVG is that these events are not well supported. For 
example, in Mozilla, SVG.getElementById is not supported. Why? On the bug 
report response they said that they hadn't bothered to implement the whole 
SVG spec since Canvas is the cat's meow. In the Lib-GWT-SVG library which 
we use, there is no support for events on SVG elements. I see that the spec 
you sent is barely a year old. I'll need to check if that is more supported 
than it was last year when I was trying.

Another example is that SVG animation (SMIL) which is awesome, does not 
work very well at all in Chrome while it rocks in Mozilla. It is really 
quite a shame since such declarative animation frameworks make awesome 
animations http://svg-wow.org/ easy, but browser vendors cannot be 
bothered to implement long standing specs.

Ideally I'd just use addLoadHandler from 
http://www.w3.org/TR/SVG/script.html#EventAttributes, but it's not in the 
aforementioned SVG lib. I'll have to try doing it myself and see how it 
goes.


Sincerely,
Joseph

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

Re: Best practices for security with GWT RPC

2011-10-01 Thread brad

First I would just say that it isn't really security on the client side. It 
is a purely aesthetic issue. You have to assume that the client side can see 
anything they want, unless you are conditionally loading UI code from the 
server side. The latter isn't terribly performant.

So what you are really saying is that you want some sort of preferences 
cache on the client side. There are a number of ways to do that, but since 
bit shifting is not very good in javascript, I'd probably skip bit flags and 
use a boolean array.

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

Re: Best practices for security with GWT RPC

2011-09-29 Thread Marius Grama

Some talk about acris is done on this thread :
https://groups.google.com/forum/#!searchin/google-web-toolkit/client$20side$20security/google-web-toolkit/X0CvuHCWv-c/YWXOiT3EBqoJ

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

Re: Best practices for security with GWT RPC

2011-09-29 Thread Jens

Well we don't keep a cache of permissions/roles on the client. In our app we 
always have to load data from the server when a user switches between 
places. So when doing this server request we also ask the server to check 
the permissions that are relevant for the UI of that current place. All 
these permissions are defined as enums (one per place) and placed in the 
shared package so we can use these enums also on server side to secure our 
server methods.

A typical activity thats starts and loads its data would do (using Command 
pattern):

this.server.execute(
  new BatchCommand(
new CheckPermissionsCommand(PlaceAPermissions.CREATE, 
PlaceAPermissions.DELETE),
new LoadDataForThisActivityCommand()
  )
)

and in its onSuccess method we are setting the evaluated permissions to the 
view like:

boolean[] evaluatedPermissions = commandResult.getPermissions();
this.view.secure(evaluatedPermissions[0], ...);

which basically shows/hides all relevant UI elements and also secures view 
methods like setCreateButtonEnabled(boolean isEnabled) to respect the 
permissions.

During the server request everything relevant is disabled by default and the 
actually UI is hidden (a loading overlay will be shown).

So far it works great for us. But of course this does not enforce anything. 
The developer has to implement the UI security on its own.

-- J.

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

Re: Best practices for building UiBinder based widgets: Composition vs Inheritance vs ...

2011-07-22 Thread Thomas Broyer



On Friday, July 22, 2011 1:03:55 PM UTC+2, Alexander Orlov wrote:

 class SuperClass { 
 // .. 
 static class Layout { 
 // ... 
 // put you @UiField, @UiHandler, etc. here 
 @UiField 
 Button test; 
 } 

 final Layout layout; 

 public SuperClass() { 
 this.layout = new Layout(this); 
   
 RootPanel.get(widget).add(BINDER.createAndBindUi(this.layout)); 


D'oh, this is not at all the place to do this kind of thing. You should 
stick with the create something, then put it somewhere pattern (rather 
than a create something, and it'll automatically show at a predefined 
location)
 

 And where can I assign a handler to the test button?


In the Layout inner class, and you can simply defer to your outer class:
abstract class SuperClass { 
...
static class Layout { 
private final SuperClass owner;
...
// put you @UiField, @UiHandler, etc. here 
@UiField 
Button test; 

@UiHandler(test)
void onTestClicked(ClickEvent event) {
  this.owner.onTestClicked();
}

protected abstract void onTestClicked();
...
}

BTW, I'm not saying this is the best way of doing it, but it works, and it 
shows what should be obvious: you're not forced to pass 'this' to 
createAndBindUi (and incidentally to call createAndBindUi from an UiBinder 
owner class instance).
I still believe it's better to make a reusable widget, using @UiChild to 
allow adding children to it and events/delegate to communicate changes to 
the container (or actually anything using it).

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

Re: Best practices for building UiBinder based widgets: Composition vs Inheritance vs ...

2011-07-22 Thread Alexander Orlov

On Fri, Jul 22, 2011 at 1:22 PM, Jens jens.nehlme...@gmail.com wrote:

 my:MyPanel
   my:header
  g:LabelHeader/g:Label
   /my:header
 /my:MyPanel

 Your Java implementation of MyPanel would then contain methods:

 @UiChild
 public void addHeader(Widget w) {
  //your add logic
 }


Great, that's basically everything I need!

-Alex

-- 
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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best practices for security with GWT RPC

2011-03-07 Thread Juan Pablo Gardella

+1

2011/3/5 canis.majoriss canis.major...@hotmail.com

 Hi All,

 We are planning to use GWT RPC as a frontend for a rather large
 project in terms of number of different user profiles, number of
 different logical tabs/windows where user can access only those
 functionalities for which he has permissions. On client side specific,
 let's say, button or window will not be rendered if user does not have
 priviledges, while on the server side services will be declaratively
 secured and even if user somehow managed to call service for which he
 does not have access rights, access will be denied. We are using
 pretty basic security model: permission, role, user, where at UI all
 permissions for given user (via his roles) will be pulled and then
 enforced (UI developer will statically bind specific permission to
 specific UI action).

 Same specific funtionality (button) may be logically present on
 multiple locations on GUI, and client side enforcement would have to
 take that into the account.

 Questions where the help of the community would be appreciated are:

 1) what are the best practice when it comes to client-side RPC
 (declarative?) security enforcement?

 2) should we, say, for every widget (button etc) override isVisible()
 method and then check (assuming here that GWT runtime will call
 JavaScript equivalent of isVisible() Java method at render time from
 within JavaScript runtime) if user has permission to see given
 component?

 3) should we cache user's permissions in some kind of JavaScript
 cache, or caching it on server-side and then make a call from
 JavaScript's to server to see of specific component/button should be
 rendered based on user's priviledges? If server side approach is
 preferred, GWT RPC will not have performance problems?

 Thanks in advance on any tips you may have.

 --
 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best practices for GWT-Eclipse and war deployment

2010-04-06 Thread kozura

You mean just the .svn accounting folders?  Not really a problem if
they're in your deployment, but you can always use the --exclude
option in zip to keep them out.  Otherwise yes, the intent is to zip
and deploy the war directory, which includes a mix of svn source files
and generated files.

On Apr 6, 6:56 am, bradrover brk...@gmail.com wrote:
 Hello, I have a new GWT project, created with the Eclipse plug-in. I'm
 trying to figure out the best way to manage deployment and svn
 together with this project structure. Its difficult because the war
 folder has files in it that need to be under source control, yet I
 need to create a tomcat deployment from this folder. So my deployment
 has all these .svn folders in it. Right now I've resorted to just
 stripping out the .svn files from the war folder hierarchy, and
 zipping it up from there. Seems like there should be a better way.

-- 
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best practices for GWT-Eclipse and war deployment

2010-04-06 Thread Jon Vaughan

It would be better practice not to rely on the IDE; use the plugin to
help you with running in dev mode and getting the project structure
set-up, but then use a build tool like Maven or Ant to build the war.
That way you remove any chance of human error in releasing your code
and you're not tied to a particular IDE / workspace configuration etc.

On Apr 6, 1:56 pm, bradrover brk...@gmail.com wrote:
 Hello, I have a new GWT project, created with the Eclipse plug-in. I'm
 trying to figure out the best way to manage deployment and svn
 together with this project structure. Its difficult because the war
 folder has files in it that need to be under source control, yet I
 need to create a tomcat deployment from this folder. So my deployment
 has all these .svn folders in it. Right now I've resorted to just
 stripping out the .svn files from the war folder hierarchy, and
 zipping it up from there. Seems like there should be a better way.

-- 
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best practices for GWT-Eclipse and war deployment

2010-04-06 Thread bradrover

Jon, yes I would like to eventually use maven for this. I'm not really
sure how to migrate the default project structure to a maven project
structure. I will look into it though.

Brad

On Apr 6, 11:16 am, Jon Vaughan jsvaug...@gmail.com wrote:
 It would be better practice not to rely on the IDE; use the plugin to
 help you with running in dev mode and getting the project structure
 set-up, but then use a build tool like Maven or Ant to build the war.
 That way you remove any chance of human error in releasing your code
 and you're not tied to a particular IDE / workspace configuration etc.

 On Apr 6, 1:56 pm, bradrover brk...@gmail.com wrote:

  Hello, I have a new GWT project, created with the Eclipse plug-in. I'm
  trying to figure out the best way to manage deployment and svn
  together with this project structure. Its difficult because the war
  folder has files in it that need to be under source control, yet I
  need to create a tomcat deployment from this folder. So my deployment
  has all these .svn folders in it. Right now I've resorted to just
  stripping out the .svn files from the war folder hierarchy, and
  zipping it up from there. Seems like there should be a better way.

-- 
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best Practices for Testing?

2010-02-23 Thread خليل بولو

لماذا الحوار بينكم ولم تكن في المقابل لأنني اتلقىرسائلك وانتم تتحاورون
هل من الممكن تفصحو لي الشيفرة التيتتكلمون بها كوني انا المتلقي
وما هية جافا مرض السحايا ؟
ال تكن هية جافاسكريت التي تتحدثنعنة ؟
انني اود ان اشارك في الموضوع
اريد الوضوح
www.abuawad.com

2010/2/22, Trevis trevistho...@gmail.com:
When I started my project I had GWT based testing but befor I got very
far I went to an MVP based archetecture and. At that point I all but
quit using the gwt based tests and just test everything as pure java.

On Feb 22, 3:05 am, Thomas Broyer t.bro...@gmail.com wrote:
On Feb 21, 2:31 pm, FKereki fker...@gmail.com wrote:

I'm trying to work out the consensus as to the best way of structuring
a project for testing.

For client side code, you have two kinds of tests:

* pure unit tests, based on JUnit (and, thanks to MVP, applying to
most of your code)
* integration tests, based on GWTTestCase

What's the optimum project structure? Would you need new gwt.xml
files? How would you configure it?

Have you looked
athttp://groups.google.com/group/google-web-toolkit/t/7a62294ddc615c3f
?
...and the Contacts MVP sample from Google?
...and of course GWT itself?

I'm using a gwt-test for GWTTestCase and a test for pure Java JUnit
tests; this makes it easier (compared to the Contacts sample) to run
only pure-Java tests, as you can use a wildcard and just have to
exclude gwt-test from the classpath.
All test cases are on the same package as the classes under test, so
there's no need for an additional gwt.xml (except when you *need* one:
test-only servlet/, style/ or and/or script/)

--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.

--
www.abuawad.com

Re: Best Practices for Testing?

2010-02-22 Thread Thomas Broyer


On Feb 21, 2:31 pm, FKereki fker...@gmail.com wrote:
 I'm trying to work out the consensus as to the best way of structuring
 a project for testing.

 For client side code, you have two kinds of tests:

 * pure unit tests, based on JUnit (and, thanks to MVP, applying to
 most of your code)
 * integration tests, based on GWTTestCase

 What's the optimum project structure? Would you need new gwt.xml
 files? How would you configure it?

Have you looked at 
http://groups.google.com/group/google-web-toolkit/t/7a62294ddc615c3f
?
...and the Contacts MVP sample from Google?
...and of course GWT itself?

I'm using a gwt-test for GWTTestCase and a test for pure Java JUnit
tests; this makes it easier (compared to the Contacts sample) to run
only pure-Java tests, as you can use a wildcard and just have to
exclude gwt-test from the classpath.
All test cases are on the same package as the classes under test, so
there's no need for an additional gwt.xml (except when you *need* one:
test-only servlet/, style/ or and/or script/)

-- 
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best Practices for Testing?

2010-02-22 Thread Trevis

When I started my project I had GWT based testing but befor I got very
far I went to an MVP based archetecture and. At that point I all but
quit using the gwt based tests and just test everything as pure java.

On Feb 22, 3:05 am, Thomas Broyer t.bro...@gmail.com wrote:
 On Feb 21, 2:31 pm, FKereki fker...@gmail.com wrote:

  I'm trying to work out the consensus as to the best way of structuring
  a project for testing.

  For client side code, you have two kinds of tests:

  * pure unit tests, based on JUnit (and, thanks to MVP, applying to
  most of your code)
  * integration tests, based on GWTTestCase

  What's the optimum project structure? Would you need new gwt.xml
  files? How would you configure it?

 Have you looked 
 athttp://groups.google.com/group/google-web-toolkit/t/7a62294ddc615c3f
 ?
 ...and the Contacts MVP sample from Google?
 ...and of course GWT itself?

 I'm using a gwt-test for GWTTestCase and a test for pure Java JUnit
 tests; this makes it easier (compared to the Contacts sample) to run
 only pure-Java tests, as you can use a wildcard and just have to
 exclude gwt-test from the classpath.
 All test cases are on the same package as the classes under test, so
 there's no need for an additional gwt.xml (except when you *need* one:
 test-only servlet/, style/ or and/or script/)

-- 
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best practices/ideas for GWT with Spring Security (or equivalent)

2010-02-19 Thread Paul S

addendum: my session expired whilst writing this!

On Feb 19, 1:07 pm, Paul S paulsschw...@gmail.com wrote:
 I would like to debate some ideas for how to secure GWT apps in
 different ways and their pros and cons. It is important to remember
 that there will be different needs and so different approaches will be
 more suitable in certain cases, but I just want to be aware of what
 people are doing.

 I am using Spring Security because it is excellent, and whilst I am
 aware that there are many other solutions available this is not the
 focus here, so I'll just call it Security from here on.

 Security offers protection of URLs and also some more fancy AOP style
 protection like protection of specific functions. To keep things
 simple here lets just look at protection of URLs.

 1. Without Ajax - Protecting URLs that relate to pages

 Before the days of Ajax where a URL effectively corresponds to a state
 you can see how the model becomes straight forward. Adam accesses /
 home.html, it loads and Adam gets to read a bunch of content. At this
 point Adam is considered to be a Guest. Adam is curious about a link
 called Administration, when he clicks it he is sending a Request.
 That Request has some header info embedded in it (which the user never
 sees but you can see if with Firebug or whatever). Sadly Adam is not
 signed in so Security redirects him to a login page, but remembers
 everything about that original Request. Adam suddenly remembers he
 does have a user name and password so he logs in. Security processes
 his login and then redirects him to the exact equivalent of what would
 have been the original Request. Adam is happy because his work flow
 continued seamlessly despite being asked to login.

 (Ok, Spring Security can be configured to replay the original Request
 upon successful login (default), or it can be forced to send you to a
 particular default login success page. If you use the latter then
 Adam's work flow will not be seamless because his original request for
 the Administration page has been forgotten. Though sometimes you
 might need a set up like this?)

 Now Ajax comes along, and in particular I'm going to talk about GWT
 here but the principles apply.

 2.a. With Ajax - but still protecting URLs that relate to pages

 If we use Security to protect the URL of container page (in GWT that's
 the page that hosts the bootstrap javascript code for your GWT app)
 then, just like normal if Adam visits /home.html he will be able to
 read the content on that page. The Administration link has been
 modified to take you to /admin.html which is in fact the host page the
 GWT administrator module. Adam clicks Administration which Security
 knows requires the Admin role so he is redirected to the login page.
 Adam logs in and whether Security is configured to play back the exact
 Request or whether you specifically move the browser along to /
 admin.html, at this point doesn't matter. Adam is now looking at a
 fully loaded GWT application. Lets say also that Security is told to
 protect every GWT RPC call. Well Adam is logged in so he is allowed
 access to the server services via GWT RPC and all goes smoothly...
 until Adam leaves his computer for an hour and comes back to continue
 his work. When the next server call that occurs is met by Security who
 says, since your session has expired you are not logged in, so I'm
 going to redirect you to the login page. XmlHttpRequest obeys the 30x
 response code which is telling it to actually load the resource at /
 login.html. In GWT this amounts to an InvocationException where the
 error message content is your /login.html page markup. That's no good!
 The XHR cannot interpret this as your browser would, so what to do?
 The answer is pretty straightforward here. Design your /login.html
 page to contain a text token that you can search for. So for example
 in my /login.html code I have places an html comment right at the top
 like this
 !-- SECURITY-LOGIN-PAGE --
 so when the browser hits the /login.html page it just looks like a
 regular login page. But when the RPC call encounters this
 InvocationTarget exception I have an onFailure handler that looks like
 this:

    public void onFailure(Throwable t) {
       if (t instanceof InvocationException){
          if 
 (t.getMessage().split(!--\\s*SECURITY-LOGIN-PAGE\\s*--).length  1){

             onLoginRequested();
         } else {...}
       } else {...}
    }

 My onLoginRequested() method could be any of a few styles. The most
 obvious is to have it call a native method that looks like this:

    private native void redirectToLogin() /*-{
       $wnd.location.replace(/login.html);
    }-*/;

 Now at this point we have to get clear on the behaviour of Security
 with regard to where it redirects the browser after successful login.
 In this case you would have to specify that it ALWAYS redirects you
 to /admin.html so that when Adam signs in again he is taken back into
 the Administration app. But

Re: Best practices/ideas for GWT with Spring Security (or equivalent)

2010-02-19 Thread Paul S

I got some ideas from Kent 
http://stackoverflow.com/questions/1013032/programmatic-use-of-spring-security
who in turn got some ideas from Spring Security 3 Technical Overview
http://static.springsource.org/spring-security/site/docs/3.0.x/reference/technical-overview.html#d4e689

I now have a set up that resembles Scenario 4.

In my current set up Spring Security is still configured to respond
with a valid html form at /login.html (with my !-- SECURITY-LOGIN-
PAGE -- token hidden in it). So both page requests and XHR Ajax
requests are subject to Spring Security's declarative set up. Whether
I arrive at the host page and am not authenticated, or if I
authenticate and then after my session has timed out I try to call an
RPC service, I will be met with the /login.html contents as the
response. Ok, so the only trick now is that in my GWT app if I get an
InvocationException that equates to Spring Security trying to redirect
me to the /login.html page then I simply show a nice looking GWT popup
that looks like this:

   Sorry, your session seems to have expired
   Username: __
   Password: __
   Login

And when the user clicks Login an RPC call to the server is shot off
that looks a bit like this:

   public interface LoginService extends RemoteService {
  boolean login(String username, String password);
   }

Note that the boolean it returns isn't the real business here. The
real business is that we now have an authenticated session on the
server. The boolean returned just tells our GWT app to hide the popup
(if true) or keep showing it and tell the user to try log in again (if
false). That's all.

On the server I then have a service implementation that performs the
login very similarly to what Kent has done:

@Override
public boolean login(String username, String password) {

log.debug(Authentication attempt:  + username +   + 
password);

try {
Authentication request = new
UsernamePasswordAuthenticationToken(
username, password);
Authentication result =
authenticationManager.authenticate(request);
SecurityContextHolder.getContext().setAuthentication(result);
} catch (AuthenticationException e) {
log.info(Authentication failed:  + e.getMessage());
return false;
}
log.info(Authentication success:  +
SecurityContextHolder.getContext()
.getAuthentication());
return true;
}

... where authenticationManager is injected by Spring. To show you
exactly where I am getting authenticationManager from, here's my
context configuration:

authentication-manager alias=authenticationManager
authentication-provider
password-encoder hash=md5 /
jdbc-user-service data-source-ref=dataSource /
/authentication-provider
/authentication-manager

I am still undecided whether it is right to have two logins,
1. The initial login (traditional web login that moves me from /
home.html -- /login.html --(login success)-- /admin.html)
2. A secondary login that happens over RPC that provides a quick,
convenient login via an Ajax popup, such that it doesn't interrupt
your workflow

The second is exactly what I wanted all along! Is the first redundant?
Or is it just as well to have it. i.e. 1. protects your web app code
(well the host page), 2. protects the good bits (RPC calls!!!)

-- 
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best practices/ideas for GWT with Spring Security (or equivalent)

2010-02-19 Thread Paul S

Oops, forgot to mention, don't protect the URL that corresponds to the
RPC login service!

Like this:
   intercept-url pattern=/**/login.rpc access=permitAll /
   intercept-url pattern=/**/*.rpc access=isAuthenticated() /


On Feb 19, 5:28 pm, Paul S paulsschw...@gmail.com wrote:
 I got some ideas from 
 Kenthttp://stackoverflow.com/questions/1013032/programmatic-use-of-spring...
 who in turn got some ideas from Spring Security 3 Technical 
 Overviewhttp://static.springsource.org/spring-security/site/docs/3.0.x/refere...

 I now have a set up that resembles Scenario 4.

 In my current set up Spring Security is still configured to respond
 with a valid html form at /login.html (with my !-- SECURITY-LOGIN-
 PAGE -- token hidden in it). So both page requests and XHR Ajax
 requests are subject to Spring Security's declarative set up. Whether
 I arrive at the host page and am not authenticated, or if I
 authenticate and then after my session has timed out I try to call an
 RPC service, I will be met with the /login.html contents as the
 response. Ok, so the only trick now is that in my GWT app if I get an
 InvocationException that equates to Spring Security trying to redirect
 me to the /login.html page then I simply show a nice looking GWT popup
 that looks like this:

    Sorry, your session seems to have expired
    Username: __
    Password: __
    Login

 And when the user clicks Login an RPC call to the server is shot off
 that looks a bit like this:

    public interface LoginService extends RemoteService {
       boolean login(String username, String password);
    }

 Note that the boolean it returns isn't the real business here. The
 real business is that we now have an authenticated session on the
 server. The boolean returned just tells our GWT app to hide the popup
 (if true) or keep showing it and tell the user to try log in again (if
 false). That's all.

 On the server I then have a service implementation that performs the
 login very similarly to what Kent has done:

         @Override
         public boolean login(String username, String password) {

                 log.debug(Authentication attempt:  + username +   + 
 password);

             try {
                 Authentication request = new
 UsernamePasswordAuthenticationToken(
                                 username, password);
                 Authentication result =
 authenticationManager.authenticate(request);
                 SecurityContextHolder.getContext().setAuthentication(result);
             } catch (AuthenticationException e) {
                 log.info(Authentication failed:  + e.getMessage());
                 return false;
             }
             log.info(Authentication success:  +
 SecurityContextHolder.getContext()
                         .getAuthentication());
             return true;
         }

 ... where authenticationManager is injected by Spring. To show you
 exactly where I am getting authenticationManager from, here's my
 context configuration:

         authentication-manager alias=authenticationManager
                 authentication-provider
                         password-encoder hash=md5 /
                         jdbc-user-service data-source-ref=dataSource /
                 /authentication-provider
         /authentication-manager

 I am still undecided whether it is right to have two logins,
 1. The initial login (traditional web login that moves me from /
 home.html -- /login.html --(login success)-- /admin.html)
 2. A secondary login that happens over RPC that provides a quick,
 convenient login via an Ajax popup, such that it doesn't interrupt
 your workflow

 The second is exactly what I wanted all along! Is the first redundant?
 Or is it just as well to have it. i.e. 1. protects your web app code
 (well the host page), 2. protects the good bits (RPC calls!!!)

-- 
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best Practices for MVP with Composite Template View ( Header + Content + Nav + Footer) + UiBinder

2010-02-19 Thread digitalsam007

Hi Prashant,

I did try to follow your instructions and added styles to my content
container. I replaced the old view with a g:FlowPanel/. but
unfortunately, I cant see the content update on screen. Only the
Header and footer are displayed.

In the appController class, inside the valueChanged method, I added
the code like this -

@Override
public void onValueChange(ValueChangeEventString event) {

String token = event.getValue();

if (token != null) {
Presenter presenter = null;
HasWidgets outer = this.container;

if (token.equals(main)) {

if (wrapper == null) {
wrapper = new WrapperView();
ContainerSegment.HEADER = 
wrapper.getHeaderContainer();
ContainerSegment.CONTENT = 
wrapper.getContentContainer();
ContainerSegment.FOOTER = 
wrapper.getFooterContainer();

new WrapperPresenter(new 
WrapperView()).go(container);
System.out.println(Initial Screen 
Created!!!);
}

presenter = new SearchPresenter(eventBus, new 
SearchView());
outer = wrapper.getContentContainer();

}

if (presenter != null) {
presenter.go(outer);
System.out
.println(Content Area is going 
to refresh with search Widget);
}
}

}

I verified that the correct go method is being called. Also, the outer
container actually contains the Content panel div and also the
actual SearchView content is getting added to the container.

Any hint why I might not be able to get a refresh?



On Feb 19, 9:39 am, Prashant Hegde prashant.he...@gmail.com wrote:
 I am using a similar strategy and it works just fine. I suspect it may
 be a problem with your DockLayoutPanel sizing. Please check if the sizes
 are 100%, also give the panel a border for debugging to see how your
 layout looks...

 If it helps, I have listed my UiBinder file.

 ui:style
          .layout {
              border-width:1px;
              border-style:solid;
              width: 100%;
              height: 100%;

          }

          .mainlayout {
              width: 100%;
              height: 100%;
              position:relative;
              top:2em;
              left: 2em;
          }
 /ui:style
 g:DockLayoutPanel styleName='{style.mainlayout}' unit='EM'
 g:north size='2' unit=EM
 g:FlowPanel ui:field=header/
 /g:north
 g:center
 g:ScrollPanel styleName='{style.layout}'
 g:FlowPanel ui:field=content/
 /g:ScrollPanel
 /g:center
 g:south size=1 unit=EM
 g:FlowPanel ui:field=footer/
 /g:south
 /g:DockLayoutPanel
 /ui:UiBinder

 -- Prashant

 On 19-02-2010 09:50, digitalsam007 wrote:

  Hello,

  I have been trying to implement the MVP pattern in my new GWT app. I
  have followed the Contacts example app and it seems to be quite
  straightforward. In there, the controller passes the root
  panel(container) to every presenter in its go method. And these
  presenters add the respective view(Display) to the container.

  However, in my case I have to use a template with Header, footer,
  Navigation and Content. Something quite similar to the Mail sample app
  found in the GWT SDK. I tried to create a wrapper view class and its
  corresponding Presenter and included all the 4 diffrent views viz
  header, footer, nav and content in it ( WrapperView.ui.xml).

  I provided extra methods in the WrapperView that can return HasWidgets
  for each of the segments in the page like this -

  HasWidgets getHeaderContainer()
  HasWidgets getContentContainer()
  HasWidgets getFooterContainer()
  HasWidgets getNavContainer()

  In the WrapperView.ui.xml , i added a dockLayoutPanel which inturn
  contains each of these containers ( each container elemensta re in
  turn SimplePanel components which contains the actual widgets for
  Header, footer...etc)

  g:DockLayoutPanel unit='EM'
             g:north size='5'
                     miab:HeaderContainerView ui:field='headerContainer' /
             /g:north
             g:center
                     miab:ContentContainerView ui:field='contentContainer' /
             /g:center
             g:south size=2
                     miab:FooterContainerView ui:field='footerContainer' /
             /g:south
  /g:DockLayoutPanel

  So, the first time when the module loads and the AppController.go
  method is invoked I trigget the history with a new tocket eg Home.
  This invokes the valueChanged method and in that I create the
  WrapperView (if not already created; yes i

Re: Best Practices for MVP with Composite Template View ( Header + Content + Nav + Footer) + UiBinder

2010-02-19 Thread digitalsam007

I forgot to mention that when I try to add the Search View into the
main root container instead of the content container like this -- it
works in that case but my header and footer will now be gone...

  if (presenter != null) {
 presenter.go(this.container); // adding to the Root panel
  }

I guess there's something wrong with retrieving the Contnet Container.
But when I try to print it , it shows the correct Div html stuffs etc.

Can we not update only a part of a widget/panel???


On Feb 19, 7:50 pm, digitalsam007 digitalsam...@gmail.com wrote:
 Hi Prashant,

 I did try to follow your instructions and added styles to my content
 container. I replaced the old view with a g:FlowPanel/. but
 unfortunately, I cant see the content update on screen. Only the
 Header and footer are displayed.

 In the appController class, inside the valueChanged method, I added
 the code like this -

         @Override
         public void onValueChange(ValueChangeEventString event) {

                 String token = event.getValue();

                 if (token != null) {
                         Presenter presenter = null;
                         HasWidgets outer = this.container;

                         if (token.equals(main)) {

                                 if (wrapper == null) {
                                         wrapper = new WrapperView();
                                         ContainerSegment.HEADER = 
 wrapper.getHeaderContainer();
                                         ContainerSegment.CONTENT = 
 wrapper.getContentContainer();
                                         ContainerSegment.FOOTER = 
 wrapper.getFooterContainer();

                                         new WrapperPresenter(new 
 WrapperView()).go(container);
                                         System.out.println(Initial Screen 
 Created!!!);
                                 }

                                 presenter = new SearchPresenter(eventBus, new 
 SearchView());
                                 outer = wrapper.getContentContainer();

                         }

                         if (presenter != null) {
                                 presenter.go(outer);
                                 System.out
                                                 .println(Content Area is 
 going to refresh with search Widget);
                         }
                 }

         }

 I verified that the correct go method is being called. Also, the outer
 container actually contains the Content panel div and also the
 actual SearchView content is getting added to the container.

 Any hint why I might not be able to get a refresh?

 On Feb 19, 9:39 am, Prashant Hegde prashant.he...@gmail.com wrote:

  I am using a similar strategy and it works just fine. I suspect it may
  be a problem with your DockLayoutPanel sizing. Please check if the sizes
  are 100%, also give the panel a border for debugging to see how your
  layout looks...

  If it helps, I have listed my UiBinder file.

  ui:style
           .layout {
               border-width:1px;
               border-style:solid;
               width: 100%;
               height: 100%;

           }

           .mainlayout {
               width: 100%;
               height: 100%;
               position:relative;
               top:2em;
               left: 2em;
           }
  /ui:style
  g:DockLayoutPanel styleName='{style.mainlayout}' unit='EM'
  g:north size='2' unit=EM
  g:FlowPanel ui:field=header/
  /g:north
  g:center
  g:ScrollPanel styleName='{style.layout}'
  g:FlowPanel ui:field=content/
  /g:ScrollPanel
  /g:center
  g:south size=1 unit=EM
  g:FlowPanel ui:field=footer/
  /g:south
  /g:DockLayoutPanel
  /ui:UiBinder

  -- Prashant

  On 19-02-2010 09:50, digitalsam007 wrote:

   Hello,

   I have been trying to implement the MVP pattern in my new GWT app. I
   have followed the Contacts example app and it seems to be quite
   straightforward. In there, the controller passes the root
   panel(container) to every presenter in its go method. And these
   presenters add the respective view(Display) to the container.

   However, in my case I have to use a template with Header, footer,
   Navigation and Content. Something quite similar to the Mail sample app
   found in the GWT SDK. I tried to create a wrapper view class and its
   corresponding Presenter and included all the 4 diffrent views viz
   header, footer, nav and content in it ( WrapperView.ui.xml).

   I provided extra methods in the WrapperView that can return HasWidgets
   for each of the segments in the page like this -

   HasWidgets getHeaderContainer()
   HasWidgets getContentContainer()
   HasWidgets getFooterContainer()
   HasWidgets getNavContainer()

   In the WrapperView.ui.xml , i added a dockLayoutPanel which inturn
   contains each of these containers ( each container elemensta re in
   turn SimplePanel components which contains the actual widgets for
   Header, footer...etc)

Re: Best practices/ideas for GWT with Spring Security (or equivalent)

2010-02-19 Thread Paul S

This is very interesting 
http://seewah.blogspot.com/2009/02/gwt-and-spring-security.html
But comparing See Wah's code, and what I have it looks like mine is
less invasive. In fact I haven't had to do anything to my *ServiceImpl
classes, except to set them up for Spring. I think the key differences
are:
- See Wah uses an Exception to let the client know that you are not
authenticated
- I use a regular page redirect and have to scan for a special token
!-- SECURITY-LOGIN-PAGE --

- See Wah's code allows you to have protection for your RPC calls
- My code allows you to have protection for regular URLs (e.g. /
admin.html), and RPC URLs, and method invocations

- See Wah's code requires you to authenticate yourself via an RPC call
- My code allows you to authenticate yourself via a regular /
login.html page, but then once you're in the GWT app, if your session
expires you are offered an Ajax style login (like See Wah's).

I guess I'm homing in on what I would consider to be my choice of
approach. Keep those thousands of responses coming, folks! ;)




On Feb 19, 5:32 pm, Paul S paulsschw...@gmail.com wrote:
 Oops, forgot to mention, don't protect the URL that corresponds to the
 RPC login service!

 Like this:
    intercept-url pattern=/**/login.rpc access=permitAll /
    intercept-url pattern=/**/*.rpc access=isAuthenticated() /

 On Feb 19, 5:28 pm, Paul S paulsschw...@gmail.com wrote:



  I got some ideas from 
  Kenthttp://stackoverflow.com/questions/1013032/programmatic-use-of-spring...
  who in turn got some ideas from Spring Security 3 Technical 
  Overviewhttp://static.springsource.org/spring-security/site/docs/3.0.x/refere...

  I now have a set up that resembles Scenario 4.

  In my current set up Spring Security is still configured to respond
  with a valid html form at /login.html (with my !-- SECURITY-LOGIN-
  PAGE -- token hidden in it). So both page requests and XHR Ajax
  requests are subject to Spring Security's declarative set up. Whether
  I arrive at the host page and am not authenticated, or if I
  authenticate and then after my session has timed out I try to call an
  RPC service, I will be met with the /login.html contents as the
  response. Ok, so the only trick now is that in my GWT app if I get an
  InvocationException that equates to Spring Security trying to redirect
  me to the /login.html page then I simply show a nice looking GWT popup
  that looks like this:

     Sorry, your session seems to have expired
     Username: __
     Password: __
     Login

  And when the user clicks Login an RPC call to the server is shot off
  that looks a bit like this:

     public interface LoginService extends RemoteService {
        boolean login(String username, String password);
     }

  Note that the boolean it returns isn't the real business here. The
  real business is that we now have an authenticated session on the
  server. The boolean returned just tells our GWT app to hide the popup
  (if true) or keep showing it and tell the user to try log in again (if
  false). That's all.

  On the server I then have a service implementation that performs the
  login very similarly to what Kent has done:

          @Override
          public boolean login(String username, String password) {

                  log.debug(Authentication attempt:  + username +   + 
  password);

              try {
                  Authentication request = new
  UsernamePasswordAuthenticationToken(
                                  username, password);
                  Authentication result =
  authenticationManager.authenticate(request);
                  
  SecurityContextHolder.getContext().setAuthentication(result);
              } catch (AuthenticationException e) {
                  log.info(Authentication failed:  + e.getMessage());
                  return false;
              }
              log.info(Authentication success:  +
  SecurityContextHolder.getContext()
                          .getAuthentication());
              return true;
          }

  ... where authenticationManager is injected by Spring. To show you
  exactly where I am getting authenticationManager from, here's my
  context configuration:

          authentication-manager alias=authenticationManager
                  authentication-provider
                          password-encoder hash=md5 /
                          jdbc-user-service data-source-ref=dataSource /
                  /authentication-provider
          /authentication-manager

  I am still undecided whether it is right to have two logins,
  1. The initial login (traditional web login that moves me from /
  home.html -- /login.html --(login success)-- /admin.html)
  2. A secondary login that happens over RPC that provides a quick,
  convenient login via an Ajax popup, such that it doesn't interrupt
  your workflow

  The second is exactly what I wanted all along! Is the first redundant?
  Or is it just as well to have it. i.e. 1. protects your web app

Re: Best Practices for MVP with Composite Template View ( Header + Content + Nav + Footer) + UiBinder

2010-02-19 Thread digitalsam007

I also tried to add the serach widget into the content container of
the wrapper view and then adding the wrapper view to the rootpanel
container. But it didnt help. See the modified code below -

HasWidgets outer = this.container;

if (token.equals(main)) {

if (wrapper == null) {
wrapper = new WrapperView();
}

presenter = new SearchPresenter(eventBus, new SearchView());
outer = wrapper.getContentContainer();

}

if (presenter != null) {
presenter.go(outer);
new WrapperPresenter(new WrapperView()).go(this.container);

}

On Feb 19, 7:50 pm, digitalsam007 digitalsam...@gmail.com wrote:
 Hi Prashant,

 I did try to follow your instructions and added styles to my content
 container. I replaced the old view with a g:FlowPanel/. but
 unfortunately, I cant see the content update on screen. Only the
 Header and footer are displayed.

 In the appController class, inside the valueChanged method, I added
 the code like this -

         @Override
         public void onValueChange(ValueChangeEventString event) {

                 String token = event.getValue();

                 if (token != null) {
                         Presenter presenter = null;
                         HasWidgets outer = this.container;

                         if (token.equals(main)) {

                                 if (wrapper == null) {
                                         wrapper = new WrapperView();
                                         ContainerSegment.HEADER = 
 wrapper.getHeaderContainer();
                                         ContainerSegment.CONTENT = 
 wrapper.getContentContainer();
                                         ContainerSegment.FOOTER = 
 wrapper.getFooterContainer();

                                         new WrapperPresenter(new 
 WrapperView()).go(container);
                                         System.out.println(Initial Screen 
 Created!!!);
                                 }

                                 presenter = new SearchPresenter(eventBus, new 
 SearchView());
                                 outer = wrapper.getContentContainer();

                         }

                         if (presenter != null) {
                                 presenter.go(outer);
                                 System.out
                                                 .println(Content Area is 
 going to refresh with search Widget);
                         }
                 }

         }

 I verified that the correct go method is being called. Also, the outer
 container actually contains the Content panel div and also the
 actual SearchView content is getting added to the container.

 Any hint why I might not be able to get a refresh?

 On Feb 19, 9:39 am, Prashant Hegde prashant.he...@gmail.com wrote:

  I am using a similar strategy and it works just fine. I suspect it may
  be a problem with your DockLayoutPanel sizing. Please check if the sizes
  are 100%, also give the panel a border for debugging to see how your
  layout looks...

  If it helps, I have listed my UiBinder file.

  ui:style
           .layout {
               border-width:1px;
               border-style:solid;
               width: 100%;
               height: 100%;

           }

           .mainlayout {
               width: 100%;
               height: 100%;
               position:relative;
               top:2em;
               left: 2em;
           }
  /ui:style
  g:DockLayoutPanel styleName='{style.mainlayout}' unit='EM'
  g:north size='2' unit=EM
  g:FlowPanel ui:field=header/
  /g:north
  g:center
  g:ScrollPanel styleName='{style.layout}'
  g:FlowPanel ui:field=content/
  /g:ScrollPanel
  /g:center
  g:south size=1 unit=EM
  g:FlowPanel ui:field=footer/
  /g:south
  /g:DockLayoutPanel
  /ui:UiBinder

  -- Prashant

  On 19-02-2010 09:50, digitalsam007 wrote:

   Hello,

   I have been trying to implement the MVP pattern in my new GWT app. I
   have followed the Contacts example app and it seems to be quite
   straightforward. In there, the controller passes the root
   panel(container) to every presenter in its go method. And these
   presenters add the respective view(Display) to the container.

   However, in my case I have to use a template with Header, footer,
   Navigation and Content. Something quite similar to the Mail sample app
   found in the GWT SDK. I tried to create a wrapper view class and its
   corresponding Presenter and included all the 4 diffrent views viz
   header, footer, nav and content in it ( WrapperView.ui.xml).

   I provided extra methods in the WrapperView that can return HasWidgets
   for each of the segments in the page like this -

   HasWidgets getHeaderContainer()
   HasWidgets getContentContainer()
   HasWidgets getFooterContainer()
   HasWidgets getNavContainer()

   In the WrapperView.ui.xml , i added a dockLayoutPanel which inturn
   contains each of these containers ( each container elemensta re in
   turn

Re: Best Practices for MVP with Composite Template View ( Header + Content + Nav + Footer) + UiBinder

2010-02-18 Thread Prashant Hegde

I am using a similar strategy and it works just fine. I suspect it may 
be a problem with your DockLayoutPanel sizing. Please check if the sizes 
are 100%, also give the panel a border for debugging to see how your 
layout looks...


If it helps, I have listed my UiBinder file.

ui:style
.layout {
border-width:1px;
border-style:solid;
width: 100%;
height: 100%;

}

.mainlayout {
width: 100%;
height: 100%;
position:relative;
top:2em;
left: 2em;
}
/ui:style
g:DockLayoutPanel styleName='{style.mainlayout}' unit='EM'
g:north size='2' unit=EM
g:FlowPanel ui:field=header/
/g:north
g:center
g:ScrollPanel styleName='{style.layout}'
g:FlowPanel ui:field=content/
/g:ScrollPanel
/g:center
g:south size=1 unit=EM
g:FlowPanel ui:field=footer/
/g:south
/g:DockLayoutPanel
/ui:UiBinder

-- Prashant

On 19-02-2010 09:50, digitalsam007 wrote:

Hello,

I have been trying to implement the MVP pattern in my new GWT app. I
have followed the Contacts example app and it seems to be quite
straightforward. In there, the controller passes the root
panel(container) to every presenter in its go method. And these
presenters add the respective view(Display) to the container.

However, in my case I have to use a template with Header, footer,
Navigation and Content. Something quite similar to the Mail sample app
found in the GWT SDK. I tried to create a wrapper view class and its
corresponding Presenter and included all the 4 diffrent views viz
header, footer, nav and content in it ( WrapperView.ui.xml).

I provided extra methods in the WrapperView that can return HasWidgets
for each of the segments in the page like this -

HasWidgets getHeaderContainer()
HasWidgets getContentContainer()
HasWidgets getFooterContainer()
HasWidgets getNavContainer()

In the WrapperView.ui.xml , i added a dockLayoutPanel which inturn
contains each of these containers ( each container elemensta re in
turn SimplePanel components which contains the actual widgets for
Header, footer...etc)

g:DockLayoutPanel unit='EM'
g:north size='5'
miab:HeaderContainerView ui:field='headerContainer' /
/g:north
g:center
miab:ContentContainerView ui:field='contentContainer' 
/
/g:center
g:south size=2
miab:FooterContainerView ui:field='footerContainer' /
/g:south
/g:DockLayoutPanel

So, the first time when the module loads and the AppController.go
method is invoked I trigget the history with a new tocket eg Home.
This invokes the valueChanged method and in that I create the
WrapperView (if not already created; yes i maintain a reference to
this object in AppController) and present it on screen. Then, I call
the views getContentContainer method and try to add the content
directly to that in another presenter. I do not pass the topmost
container this time.

Logically it should work and the content area must be refreshed with
the respective Views when diffrent presenter presents it. But
unfortunately I cannot achieve what I want to yet. So, could anyone of
you provide me with some ideas or may share with me the best way of
achieving this usecase?

Any help in this regard will be highly appreciated

Regards

Sam

   


--
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-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Best practices for screen layout in GWT

2009-08-12 Thread flyingb...@gmail.com


I did my layout by coding but better way is to use css but I suck in
using css .

On Aug 11, 9:47 am, Sean slough...@gmail.com wrote:
 I personally did the layout all in code. I originally used a DockPanel
 and realized that I was only using WEST, NORTH, and CENTER. And being
 in a DockPanel limited me. So I ended up swapping out (Fairly easily)
 for a VerticalPanel with either Widgets or a HorizontalPanel in it.
 While the widgets were all set in code, I still have a lot of
 flexibility to change things with CSS. This also allows the widgets to
 all speak to each other if you so choose.

 On Aug 11, 6:48 am, Oskar Hannesson osk...@centrum.is wrote:

  Hello.
  Can anyone give me a hint what layout technique is best suitable for
  GWT.
  Should I use tables , iframe, div or even construct the page in
  code by using DockPanel.
  I tried the iframe but I had trouble directing the response message to
  a different iframe.
  I also got DockPanel to work but i'm not sure if it is a good idea to
  do the layout in code entirely.

  Thanks
  Oskar H.
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices for screen layout in GWT

2009-08-12 Thread Ian Bambury

My view is that it all rather depends on your situation and your skill
strengths. Not much help, I know.
If you are in a situation where you have savvy designers, you might like to
give them control of the html host page and let them stick divs in wherever
they want stuff to be, giving them ids so you as the programmer can pick
them up and add widgets to them and style them as they wish in css.

On the other hand, at the other end of the spectrum, if you are a
one-man-band and control everything - functionality, layout etc - then it
doesn't really matter what you do. In that situation, I tend to go for
nested flowpanels where I can, and float them where I want them.

Simple is better, so avoid FlexTables and DockPanels (and any other
table-based widgets like HP, VP etc). There are endless examples on this
list of people saying that GWT is broken because they haven't understood the
css implications of using HPs and VPs.

If you don't need to control a particular level of layout in code, then I'd
say lay it out in HTML in the host page. After that, use the simplest
widgets you can.

Ian

http://examples.roughian.com


2009/8/11 Oskar Hannesson osk...@centrum.is


 Hello.
 Can anyone give me a hint what layout technique is best suitable for
 GWT.
 Should I use tables , iframe, div or even construct the page in
 code by using DockPanel.
 I tried the iframe but I had trouble directing the response message to
 a different iframe.
 I also got DockPanel to work but i'm not sure if it is a good idea to
 do the layout in code entirely.

 Thanks
 Oskar H.

 


--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices for screen layout in GWT

2009-08-11 Thread Sean


I personally did the layout all in code. I originally used a DockPanel
and realized that I was only using WEST, NORTH, and CENTER. And being
in a DockPanel limited me. So I ended up swapping out (Fairly easily)
for a VerticalPanel with either Widgets or a HorizontalPanel in it.
While the widgets were all set in code, I still have a lot of
flexibility to change things with CSS. This also allows the widgets to
all speak to each other if you so choose.

On Aug 11, 6:48 am, Oskar Hannesson osk...@centrum.is wrote:
 Hello.
 Can anyone give me a hint what layout technique is best suitable for
 GWT.
 Should I use tables , iframe, div or even construct the page in
 code by using DockPanel.
 I tried the iframe but I had trouble directing the response message to
 a different iframe.
 I also got DockPanel to work but i'm not sure if it is a good idea to
 do the layout in code entirely.

 Thanks
 Oskar H.
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices with typical LAMP backend and GWT frontend

2009-06-28 Thread Morpheu5


Hello everybody,
I already started coding some small applications using backends on
LAMP and creating the frontend UI with GWT, I already know how to
overcome the same origin issue while testing locally, and of course I
have some working knowledge of Java, but now I need some advices about
some unclear points -- or maybe they're clear and I am blind :)

Suppose I have my backend application -- e.g. a web site rendering
engine, not exactly what you'd call a backend but we'll make it work
for this example by supposing it also has an engine to take data from
a client application and store them in a database that will be used
for rendering -- residing at localhost/mywebsite/. Now, suppose I want
to write the administration panel, so I set up a GWT project called
mywebsiteAdmin with the appropriate assumptions and configurations,
and start coding. Everything works, I'm ready to compile the project
and deploy it to my remote webserver. Now suppose that I already have
the backend installed atwww.mywebsite.comand I want the admin
interface to be available atwww.mywebsite.com/admin/. First of all, I
take all the relevant files from mywebsiteAdmin/war/ and put them into
localhost/mywebsite/admin/. Then I upload this directory to my remote
server and launch it. Oops, I hardcoded the url to which to make
remote requests, which is localhost/mywebsite/remotelistener.php.
Let's go and change it, but how? If I locally run the application from
the project's url, I get something 
likehttp://localhost/mywebsiteAdmin/war/MywebsiteAdmin.html,
but if I try to locally run it from the backend's url I get something
likehttp://localhost/mywebsite/admin/MywebsiteAdmin.html(which is
also quite ugly, but of course I can rename that file to index.html
and ignore it) and finally when I go remote, I getwww.mywebsite.com/
admin/MywebsiteAdmin.html(of course I can still
rename it to index.html) and here comes the point. My remote listener
is both at localhost/mywebsite/remotelistener.php and atwww.mywebsite/
remotelistener.phpand my admin application can be at a
large variety of different urls.
Solution: have the location to be discovered automatically by the GWT
frontend. Wait. I hope you see the difficulty by yourselves, because
I've already seen it for an entire day now trying to make some regexp/
conditions to do the job. No success.
Solution 2: have a config file that tells me where the remote listener
is. No, wait. How can I retrieve a remote file if I can't make
requests? Beside this, I'd rather not have my users have to edit two
separate files, because the only way I see this working (not too
hopeful, though) is having the file put together with the admin
application. Of course I can have these two files created via some
sort of install procedure, but I'd rather keep this as a last resort.

Other ideas?
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best Practices For Translating Strings To Be Used In An Internationalized Application

2009-06-23 Thread Arthur Kalmenson


If you want an accurate translation, you're going to have to hire
someone. While Google Translate is good enough to understand the
general flow, it's not going to look very professional in your
application.

--
Arthur Kalmenson



On Mon, Jun 22, 2009 at 6:12 PM,
nellyvilledavid.jonathan.nel...@gmail.com wrote:

 Hi,

 I'm building an app I'd like to internationalize.  What is the best
 practice for doing the string translation?

 Do I have to hire, for instance, someone who speaks english and french
 and have them translate all the strings in my properties file?  Can I
 use the google language tools to do this myself (would it be accurate
 enough)?

 I'd like to know how others have tackled this problem.

 Many Thanks!
 David

 


--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best Practices For Translating Strings To Be Used In An Internationalized Application

2009-06-23 Thread Dean S. Jones


One of my previous enterprise apps was I18N for 22 languages,
including proper display of R-L languages like Hebrew and Arabic.

We used properties files, all text on the screen was indirectly drawn
by looking up it's key in the property file. GWT I18N can help here,
but it creates ALOT
of compile permutations.

Besides that point, on languages, you find that a simple word like
Submit, or Apply, is different in foreign languages based on
context, on a button, in a table, or a dialog message - that context
may change the word used based on tense, gender, or other
grammatical rules. You really need a native speaker to do it properly.

GWT I18N also does little to help you with data generated Server side.


--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: best practices for gwt + jee

2009-05-06 Thread Vályi Péter

Thanks for your input. Although by drag'n'drop style designer I meant a
WYSIWYG editor.
I know about the Instantiations GWT designer plugin for eclipse, is it any
good? Can it work with the GWT eclipse plugin?
Are there any alternatives?



On Tue, May 5, 2009 at 9:52 PM, Jim jim.p...@gmail.com wrote:


 You can use 1. Eclipse (3.4.2), 2. Tomcat 6, 3. Google GWT Eclipse
 Plugin and 4. http://code.google.com/p/gwt-dnd/.


 Jim
 http://www.gwtorm.com/mail/Mail.html for GWT Mail Example.
 http://code.google.com/p/dreamsource-orm/downloads/list

 On May 5, 3:07 pm, Pecc valyi.p...@gmail.com wrote:
  Hello everyone,
 
  I'm quite new to GWT and JEE, so I'm looking for some general help.
  What are the best softwares and methods for developing a jee
  application with GWT?
  What should i choose as IDE, app server, plugins so that they work
  together well, and are easy to use? Are there any drag'n'drop style
  designers for making the GUI? What else do i need?
 
  Thx for any advice.
  Best Regards
  Peter Valyi
 



-- 

-Pecc

--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: best practices for gwt + jee

2009-05-05 Thread Jim


You can use 1. Eclipse (3.4.2), 2. Tomcat 6, 3. Google GWT Eclipse
Plugin and 4. http://code.google.com/p/gwt-dnd/.


Jim
http://www.gwtorm.com/mail/Mail.html for GWT Mail Example.
http://code.google.com/p/dreamsource-orm/downloads/list

On May 5, 3:07 pm, Pecc valyi.p...@gmail.com wrote:
 Hello everyone,

 I'm quite new to GWT and JEE, so I'm looking for some general help.
 What are the best softwares and methods for developing a jee
 application with GWT?
 What should i choose as IDE, app server, plugins so that they work
 together well, and are easy to use? Are there any drag'n'drop style
 designers for making the GUI? What else do i need?

 Thx for any advice.
 Best Regards
 Peter Valyi
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices?

2009-04-27 Thread Laird Nelson


On Apr 23, 8:32 pm, Ben FS ben.su...@gmail.com wrote:
 Let's try a concrete example. Feel free to specify something closer to
 what you want. I think you want to have a bunch of applications, each
 of which could run on its own, but you also want a housing
 application that provides navigation, etc. and decides which sub-
 applications to include in the UI. Yes?

Yes.

 One way to do this:
 1. Make a core GWT module. It defines an Application abstract class
 that inherits from GWT's Composite class.
 2. Make the housing GWT module. It provides the high-level UI with
 navigation, etc. and placeholders for one or more Application
 instances.
 3. Make additional GWT modules, each containing a concrete sub-class
 of Application. These are your sub-applications. They each define an
 EntryPoint, useful for testing them on their own, but mainly you will
 instantiate each Application as a UI component in the housing
 application.

Yes, that's exactly the model I want from a where-is-the-code-
developed-and-how-is-it-organized perspective.

The dilemma I'm still facing is: do I go with loading option 1 or 2,
where the options are described in the page you referenced in your
last post (http://code.google.com/webtoolkit/doc/1.6/
DevGuideOrganizingProjects.html#DevGuideModules):

   1. Compile each module separately and include each module with a
separate script tag in your HTML host page.
   2. Create a top level module XML definition that includes all the
modules you want to include. Compile the top level module to create a
single set of JavaScript output.

That page strongly recommends #2, but that implies that I would be
sucking down what would amount to an entire ERP application into my
browser, right?  I mean, the Javascript to define what the finance
application is would be downloaded by the browser in option 2, along
with the Javascript for the housing application, and the Javascript
for the order application, and the Javascript for the kitchen sink
application and so on, even if the customer spent all his time in the
finance application.

To make it more concrete, option 2 would have me do this in
Housing.gwt.xml:

?xml version=1.0 encoding=UTF-8?
!DOCTYPE module PUBLIC -//Google Inc.//DTD Google Web Toolkit 1.6.4//
EN http://google-web-toolkit.googlecode.com/svn/tags/1.6.4/distro-
source/core/src/gwt-module.dtd
module rename-to='housing'
  inherits name='com.google.gwt.user.User'/
  inherits name='com.google.gwt.user.theme.standard.Standard'/
  inherits name='org.superbiz.modules.Finance'/
  inherits name='org.superbiz.modules.Order'/
  inherits name='org.superbiz.modules.KitchenSink'/
  !-- and so on --
  entry-point class='org.superbiz.modules.housing.Housing'/
/module

...and I'd invoke the GWT compiler to assemble one great big hairball
of Javascript, which would be included, once, in the housing's HTML:

!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
  head
meta http-equiv=content-type content=text/html;
charset=UTF-8
link type=text/css rel=stylesheet href=Housing.css
titleHousing Application/title

!-- let's go get all 37 sub applications...go brew a pot of
coffee! --
script type=text/javascript language=javascript src=housing/
housing.nocache.js/script

  /head
  body
iframe src=javascript:'' id=__gwt_historyFrame tabIndex='-1'
style=position:absolute;width:0;height:0;border:0/iframe
  /body
/html

I appreciate the efficiency of this from a DRY standpoint--the GWT
internals are downloaded once--but I don't appreciate the
*in*efficiency of this from a load-the-whole-world perspective.  That
is, I don't particularly want 27 sub-apps living in my browser unless
they are absolutely needed; I'd rather only reference an HTML page
that does a script src= import when that portion of the overall
app is needed.

So if I'm doing my homework properly, it looks like option #1, despite
not being recommended, is nevertheless my best option, even though, in
the words of the GWT developers, each module will contain redundant
copies of GWT library code and could possibly conflict with each other
during event handling.

(Lastly, it looks like option #2 could become a valid choice for me
again once http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting
goes in to an official release.  That is, it looks like code splitting
will allow me to compile a giant GWT module--consisting of the finance
app, the order app, the housing app, the kitchen sink app--but
deferring much of the loading of hunks of the Javascript until they're
actually needed.  Should I begin designing assuming that code
splitting will appear soon, or is that a mechanism that is not
designed to be used in such ordinary business-application ways?)

Thanks again for your time.

Best,
Laird
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To post to this group, send email to

Re: Best practices?

2009-04-27 Thread Ben FS


Hi Laird, see below.

 I appreciate the efficiency of this from a DRY standpoint--the GWT
 internals are downloaded once--but I don't appreciate the
 *in*efficiency of this from a load-the-whole-world perspective.  That
 is, I don't particularly want 27 sub-apps living in my browser unless
 they are absolutely needed; I'd rather only reference an HTML page
 that does a script src= import when that portion of the overall
 app is needed.

Above you said 37, here you say 27 sub-apps, I assume neither number
is real. But I think a more important estimate is how many different
configurations of these sub-apps do you envision? You mentioned two
options, but I think there is a third option, and I think it might
work better for you. But it depends on how many different
configurations of your sub-apps are to be expected.

Option #3:
You have many (ca. 30?) sub-apps. These will be combined in various
ways depending on user needs. How many such configurations are there?
Let's assume there are five. I suggest you take your option 2
approach but apply it to each of these five configurations, rather
than the single monolithic approach.

a. So if you had 30 sub-apps, you'd have 30 sub-app modules (each
inherits from Application).
b. You'd still have the housing module, to maintain a common feel
(it houses multiple Application instances).
c. If you had 5 required configurations, you'd have 5 more modules.
Each of these modules instantiates a Housing instance, instantiates
the necessary Application instances, and adds these to the Housing.
You'd probably define a Configuration class.

I think this will give you the benefit of delivering to your users
only just what they need, without duplication and without extraneous
sub-apps.


 (Lastly, it looks like option #2 could become a valid choice for me
 again oncehttp://code.google.com/p/google-web-toolkit/wiki/CodeSplitting
 goes in to an official release.  That is, it looks like code splitting
 will allow me to compile a giant GWT module--consisting of the finance
 app, the order app, the housing app, the kitchen sink app--but
 deferring much of the loading of hunks of the Javascript until they're
 actually needed.  Should I begin designing assuming that code
 splitting will appear soon, or is that a mechanism that is not
 designed to be used in such ordinary business-application ways?)
No idea on the timing. My suggestion would be to go with my option 3
for now and, as dynamic code slurping becomes available I think you
should have a pretty smooth transition. This announcement says it will
be post-1.6 but that's all I've seen:
http://googlewebtoolkit.blogspot.com/2008/12/whats-ahead-for-google-web-toolkit_10.html


 Thanks again for your time.

 Best,
 Laird
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices?

2009-04-23 Thread Jeff Chimene


On 04/23/2009 09:36 AM, Laird Nelson wrote:
 I'm looking for some recommendations from the hard-core GWT users out
 there.  I'm sure my requirements are not unique.

 What is the best way to set up a modular web application that features
 GWT?


You're asking two questions:
o How do I develop in a GWT environment
 You've already said you don't want to ... have one giant .war file 
that represents my whole application In GWT, I'd use multiple 
applications, each with its own entry point. Apply generous amounts of 
JUnit. GWT gives you the ability to use Java source code management and 
testing technology while generating Javascript. I'd leverage that going 
forward. You haven't mentioned the server-side code. That may affect 
this discussion.

o How to crush multiple legacy apps together, still keep them unique, 
while leveraging HTML
 Frames.




--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices?

2009-04-23 Thread Laird Nelson


On Apr 23, 1:04 pm, Jeff Chimene jchim...@gmail.com wrote:
 You're asking two questions:

At least.  :-D

      You've already said you don't want to ... have one giant .war file
 that represents my whole application In GWT, I'd use multiple
 applications, each with its own entry point. Apply generous amounts of
 JUnit.

So--just so I'm clear--five .war files, five Eclipse projects, etc.?
Each of which would feature at least one entry point?  How are you
suggesting I should pull these entry points together under the
housing?  That's where I'm conceptually stuck.  Or, conversely,
given a housing .war, how should it pull content from other .wars?

Now, I'm thick and slow at this stuff so far (early days!) but my
understanding is that an entry point is Java-to-Javascript code that
is executed when a host HTML page makes reference to the entry point.
So if I have an HTML page that refers to 127 entry points, then it's
like running 127 main() (onModuleLoad()) methods.  So if I want the
housing app to pull in the, say, finance application, then somewhere
under the control of the housing app there will be an HTML page
sucking in the housing module/entry point, and sucking in the finance
module/entry point.

Now in a perfect world I wouldn't want the housing app to know that
it's pulling in the finance app.  I come from a rich client
development background, primarily, doing stuff on the NetBeans
platform.  There you can drop your NetBeans modules (.jar files) in
The Right Place, and the housing (the NetBeans platform) picks them
up dynamically and runs them.  I'm looking for the GWT analog here.

Perhaps another way to ask (one of) my questions is like this:

I want one .war to have the HTML files that are in charge of deciding
what entry points--from various other .war files--to load.  There are
two problems with this, which is partly why I feel like I'm groping in
the dark, and am reaching out to the GWT group here:

1. War files don't know about other war files.  So war file 1 can't go
rummaging around in war file 2 to find a GWT module.  That's
nevertheless sort of what I want to happen.

2. Since that really isn't an option, what's left is the housing
referring to something like a list of URLs, each of which talks to a
servlet or what-have-you hosted by the housed war files.  That is,
let the Housing GWT app load up in the browser and then kick off a
bunch of async requests to go hit various URLs for the sub-
applications.  Something here just smells fishy to me; I am not
articulate enough at the moment to be able to state clearly what my
problem is with this approach.  Perhaps you or someone else can
educate me here.  One ancillary thing that occurs to me is that
security and authentication is a pain going this route unless there's
an SSO server back there somewhere.

 GWT gives you the ability to use Java source code management and
 testing technology while generating Javascript. I'd leverage that going
 forward. You haven't mentioned the server-side code. That may affect
 this discussion.

True; good point.  For now, assume it's pure JEE 5 stuff (.war files,
servlets, EJB3 on the back end).  We haven't made a final decision on
whether to use GWT RPC stuff or go pure web services for our
communication with the back end.

 o How to crush multiple legacy apps together, still keep them unique,
 while leveraging HTML
      Frames.

Seriously?  Yikes.  These aren't legacy applications, BTW; they're
being developed right now.

Best,
Laird
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices?

2009-04-23 Thread Jeff Chimene


On 04/23/2009 10:39 AM, Laird Nelson wrote:
 On Apr 23, 1:04�pm, Jeff Chimenejchim...@gmail.com  wrote:

 You're asking two questions:
  

 At least.  :-D


Replies inline
(sound of rolling up sleeves)

 � � �You've already said you don't want to ... have one giant .war file
 that represents my whole application In GWT, I'd use multiple
 applications, each with its own entry point. Apply generous amounts of
 JUnit.
  

 So--just so I'm clear--five .war files, five Eclipse projects, etc.?
 Each of which would feature at least one entry point?  How are you
 suggesting I should pull these entry points together under the
 housing?  That's where I'm conceptually stuck.  Or, conversely,
 given a housing .war, how should it pull content from other .wars?


If you don't want a monolithic .war, you'll have (WAR count)  1, no?

Forget Eclipse projects for the moment. It's a question I didn't ask 
(what IDE are you considering?), and deliberately so.
.war files are IDE independent. Using Maven, you can construct .wars in 
whatever way suits your deployment strategy.
Remember, .war files are a Java construct shoe-horned into a Javascript 
world. They solve a large-ish problem while (perhaps) creating others. 
On a server, one doesn't pull content from other .wars. The content 
will be served via your httpd from a directory containing Javascript, 
HTML, images, c. My apologies if you already know this.

Perhaps NetBeans is appropriate here? Please read on for further 
questions on that point.

The bigger question, independent of the implementation details, is: how 
would you like the client/server interaction to work? Set the thorny 
implementation details aside for a moment. What does the user see? What 
actions should the user take to initiate changes to the application 
state? Perhaps a simple storyboard? Or maybe a UI mockup using an 
WYSIWYG HTML editor? Perhaps you've already answered this question. If 
so, my apologies.

 Now, I'm thick and slow at this stuff so far (early days!) but my
 understanding is that an entry point is Java-to-Javascript code that
 is executed when a host HTML page makes reference to the entry point.
 So if I have an HTML page that refers to 127 entry points, then it's
 like running 127 main() (onModuleLoad()) methods.

Definitely not that many entry points (although you /could/ ;-) )
 So if I want the
 housing app to pull in the, say, finance application, then somewhere
 under the control of the housing app there will be an HTML page
 sucking in the housing module/entry point, and sucking in the finance
 module/entry point.


Entry points are one thing. Libraries of application-specific code are 
also possible (implemented via Java classes).

 Now in a perfect world I wouldn't want the housing app to know that
 it's pulling in the finance app.  I come from a rich client
 development background, primarily, doing stuff on the NetBeans
 platform.  There you can drop your NetBeans modules (.jar files) in
 The Right Place, and the housing (the NetBeans platform) picks them
 up dynamically and runs them.  I'm looking for the GWT analog here.


I'm probably not a good reference for NetBeans. NetBeans is an 
architecture that embraces Javascript and HTML, no? Therefore, how does 
one deploy HTML and Javascript in a NetBeans environment? That would be 
the direction to follow when incorporating GWT.

I think the GWT analog is:
o The client makes AJAX requests of the server;
o The server, running in a NetBeans framework, decides which of several 
resources can respond to the request;
o Those resources, in the form of raw data, Javascript, HTML, images, c 
are sent to the client;
o The response is transformed using the GWT classes into (D)HTML and 
other UI shiny stuff

It's not clear to me how much client-side Javascript you'll need. From 
the outside, it seems that most business logic will be on the server, 
the only use for the client is to manage the UI.

I think that your client side code will be quite thin; 
authenticate/authorize the user, then dispatch to appropriate entry 
point. You'll probably be using RPC to retrieve data and DHTML to manage 
it. The server will probably also send static HTML as fundamental 
components of the UI change. The client code will tear down the current 
UI view, and replace it with this static HTML, thus updating the UI view.

As an aside: have you watched this presentation? 
http://www.scribd.com/doc/44602/Google-Web-Toolkit

 Perhaps another way to ask (one of) my questions is like this:

 I want one .war to have the HTML files that are in charge of deciding
 what entry points--from various other .war files--to load.  There are
 two problems with this, which is partly why I feel like I'm groping in
 the dark, and am reaching out to the GWT group here:

 1. War files don't know about other war files.  So war file 1 can't go
 rummaging around in war file 2 to find a GWT module.  That's
 nevertheless sort of what I want to

Re: Best practices?

2009-04-23 Thread Ben FS


 1. War files don't know about other war files.  So war file 1 can't go
 rummaging around in war file 2 to find a GWT module.  That's
 nevertheless sort of what I want to happen.
Don't think so much in terms of WAR files and EntryPoints, and rather
think in terms of existing HTTP and HTML capabilities (though maybe
not frames ;)).

Any HTML page can include any number of GWT modules, and for each one
the EntryPoint will be called. Each GWT module can include both client-
side and server-side components, or only client-side components, or
only server-side components. Additionally, you can have server-side
stuff that is not part of a GWT module. You can have a GWT module that
includes all your core or common elements, and another GWT module that
implements the account management UI and back-end, and another GWT
module that provides a latest news feature, and so on for each sub-
application.

For the housing: You can write a simple HTML page that includes each
of these modules directly (link to the .js file for the module and
provide a DIV slot for the module). Or you can have such HTML
generated dynamically server-side. Or you can have one GWT module that
itself includes and arranges other GWT modules (the sub-applications).

How you organize this in Eclipse, well, that's flexible and I suspect
there are numerous pros and cons to different strategies. I can only
tell you what I do. I have a small, simple GWT app consisting of only
three modules. One has the core/common functionality. I also have some
non-GWT servlets. I have these all in one Eclipse project. I have
multiple launch configurations to run each module EntryPoint
separately, and also to launch the combined app. Right now, all of
these get compiled into a single .war file. That works for me.

Sounds like your application is bigger, there are multiple people
working on it, etc. I'd suggest maintaining a single source tree, with
separate packages for the different modules, and then just let each
developer check out the parts they modify directly into their project.
To make this work well, you should set up each module to be packaged
into its own JAR file (which is how GWT library modules are
distributed), which then can be included by the developer. I'm not
sure if this is right, but it seems like a decent start. Other
thoughts?

--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices?

2009-04-23 Thread Laird Nelson

On Thu, Apr 23, 2009 at 3:49 PM, Jeff Chimene jchim...@gmail.com wrote:

 On 04/23/2009 10:39 AM, Laird Nelson wrote:
  On Apr 23, 1:04�pm, Jeff Chimenejchim...@gmail.com  wrote:
  � � �You've already said you don't want to ... have one giant .war file
  that represents my whole application In GWT, I'd use multiple
  applications, each with its own entry point. Apply generous amounts of
  JUnit.
 
  So--just so I'm clear--five .war files, five Eclipse projects, etc.?

 If you don't want a monolithic .war, you'll have (WAR count)  1, no?


That's certainly what I thought, but I wasn't sure if it was possible to,
for example, split out the housed applications into jar files and then
glom them all into a war file at war file construction time.


 Forget Eclipse projects for the moment. It's a question I didn't ask
 (what IDE are you considering?), and deliberately so.
 .war files are IDE independent. Using Maven, you can construct .wars in
 whatever way suits your deployment strategy.


Yes, and that's actually what we're using.  Well, or looking to use anyhow.


 Remember, .war files are a Java construct shoe-horned into a Javascript
 world. They solve a large-ish problem while (perhaps) creating others.
 On a server, one doesn't pull content from other .wars. The content
 will be served via your httpd from a directory containing Javascript,
 HTML, images, c. My apologies if you already know this.


I do, but no need to apologize.


 Perhaps NetBeans is appropriate here? Please read on for further
 questions on that point.


NetBeans is a Swing-based rich client framework; I think perhaps you have it
confused with something else?


  So if I want the
  housing app to pull in the, say, finance application, then somewhere
  under the control of the housing app there will be an HTML page
  sucking in the housing module/entry point, and sucking in the finance
  module/entry point.

 Entry points are one thing. Libraries of application-specific code are
 also possible (implemented via Java classes).


Right.


  Now in a perfect world I wouldn't want the housing app to know that
  it's pulling in the finance app.  I come from a rich client
  development background, primarily, doing stuff on the NetBeans
  platform.  There you can drop your NetBeans modules (.jar files) in
  The Right Place, and the housing (the NetBeans platform) picks them
  up dynamically and runs them.  I'm looking for the GWT analog here.

 I'm probably not a good reference for NetBeans. NetBeans is an
 architecture that embraces Javascript and HTML, no?


No.  :-)  No problem.


 I think the GWT analog is:
 o The client makes AJAX requests of the server;
 o The server, running in a NetBeans framework, decides which of several
 resources can respond to the request;
 o Those resources, in the form of raw data, Javascript, HTML, images, c
 are sent to the client;
 o The response is transformed using the GWT classes into (D)HTML and
 other UI shiny stuff


The reason I'm hung up on the implementation is not because I haven't
thought about how the application should behave.  If anything, I've thought
TOO hard about that, as well as how the applications, plural, should be
maintained, developed, versioned, upgraded, customized, and finally
aggregated together into different wholes for different clients.  One
client, for example, may want the finance application only.  Another may
want the order application and the finance application.  Both clients will
of necessity need the housing, since that governs how you navigate around
this sick little world.  ;-)

So it's really more of a packaging question I'm asking than a Help Me To
Understand GWT question--the only reason GWT comes into play that I can see
is that it appears that GWT is not capable of modularly and dynamically
sucking in *code* at runtime that didn't exist before.  See, for example,
this excellent thread: http://tinyurl.com/cveeft.

(Returning briefly to NetBeans for a moment, the whole architecture is built
on the fact that it sucks in code dynamically at run time.  So the NetBeans
housing fires up empty, initially, and then scans the classpath or other
area to discover the various little-m modules it needs to pull in, and does
so.  In GWT's case you have to specify those modules up front, i.e. in your
HTML host page.  If the HTML host page is being served out of a location or
package or .war file or other kind of web application hairball that is
supposed to be self-contained, by definition it can't know about other .war
files or packages or locations or web application hairballs that contain the
code that should be dynamically loaded.)


 It's not clear to me how much client-side Javascript you'll need. From
 the outside, it seems that most business logic will be on the server,
 the only use for the client is to manage the UI.


Yes; that is very much true.


 I think that your client side code will be quite thin;
 authenticate/authorize the user, then dispatch to appropriate

Re: Best practices?

2009-04-23 Thread Laird Nelson

On Thu, Apr 23, 2009 at 3:55 PM, Ben FS ben.su...@gmail.com wrote:

 Any HTML page can include any number of GWT modules, and for each one
 the EntryPoint will be called.


And I could have a module without an EntryPoint, as I understand it.


 Each GWT module can include both client-
 side and server-side components, or only client-side components, or
 only server-side components. Additionally, you can have server-side
 stuff that is not part of a GWT module. You can have a GWT module that
 includes all your core or common elements, and another GWT module that
 implements the account management UI and back-end, and another GWT
 module that provides a latest news feature, and so on for each sub-
 application.


Right.


 For the housing: You can write a simple HTML page that includes each
 of these modules directly (link to the .js file for the module and
 provide a DIV slot for the module). Or you can have such HTML
 generated dynamically server-side.


OK.


 Or you can have one GWT module that
 itself includes and arranges other GWT modules (the sub-applications).


Perhaps a *really* stupid question, but how do I do that?  I didn't realize
a GWT module could load another one itself.

Sounds like your application is bigger, there are multiple people
 working on it, etc.


Oh yes.  Would that it were smaller.  :-)


 I'd suggest maintaining a single source tree, with
 separate packages for the different modules, and then just let each
 developer check out the parts they modify directly into their project.


Well, I'd just as soon not have one big .war file that everyone is whacking
away on.  For one thing, I'd like to use Maven to version the various
artifacts.  In my dumb example, assume the presence of some sort of housing
artifact (.war, probably), the finance app artifact (another .war? something
else?), the order app artifact (another .war? something else?) that get
pulled together and aggregated into some sort of distribution unit that gets
sent off to clients.  Each client may get a different distribution unit made
up of these building blocks.


 To make this work well, you should set up each module to be packaged
 into its own JAR file (which is how GWT library modules are
 distributed), which then can be included by the developer.


Ah, OK.  I need to do some more reading; I did not realize that GWT library
modules could be distributed as jar files.  If I can do that--as in, work in
isolation in a corner somewhere, set up a stupid little hosted war
environment to test things out with, but then only distribute my end product
as a jar file--to be combined together with my other teams' jar files and
aggregated together into the final war file--that would probably work well.

I'm sure it's in front of me somewhere, but do you have a pointer to get me
started on this packaging method?

Thanks very much for your time and help; it is greatly appreciated.

Best,
Laird

--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices?

2009-04-23 Thread Jeff Chimene


On 04/23/2009 01:22 PM, Laird Nelson wrote:
 On Thu, Apr 23, 2009 at 3:49 PM, Jeff Chimene jchim...@gmail.com 
 mailto:jchim...@gmail.com wrote:

 On 04/23/2009 10:39 AM, Laird Nelson wrote:
  On Apr 23, 1:04�pm, Jeff Chimenejchim...@gmail.com
 mailto:jchim...@gmail.com  wrote:
  � � �You've already said you don't want to ... have one giant
 .war file
  that represents my whole application In GWT, I'd use multiple
  applications, each with its own entry point. Apply generous
 amounts of
  JUnit.
 
  So--just so I'm clear--five .war files, five Eclipse projects, etc.?

 If you don't want a monolithic .war, you'll have (WAR count)  1, no?


 That's certainly what I thought, but I wasn't sure if it was possible 
 to, for example, split out the housed applications into jar files 
 and then glom them all into a war file at war file construction time.

 Forget Eclipse projects for the moment. It's a question I didn't ask
 (what IDE are you considering?), and deliberately so.
 .war files are IDE independent. Using Maven, you can construct
 .wars in
 whatever way suits your deployment strategy.


 Yes, and that's actually what we're using.  Well, or looking to use 
 anyhow.

 Remember, .war files are a Java construct shoe-horned into a
 Javascript
 world. They solve a large-ish problem while (perhaps) creating others.
 On a server, one doesn't pull content from other .wars. The content
 will be served via your httpd from a directory containing Javascript,
 HTML, images, c. My apologies if you already know this.


 I do, but no need to apologize.

 Perhaps NetBeans is appropriate here? Please read on for further
 questions on that point.


 NetBeans is a Swing-based rich client framework; I think perhaps you 
 have it confused with something else?

  So if I want the
  housing app to pull in the, say, finance application, then somewhere
  under the control of the housing app there will be an HTML page
  sucking in the housing module/entry point, and sucking in the
 finance
  module/entry point.

 Entry points are one thing. Libraries of application-specific code are
 also possible (implemented via Java classes).


 Right.

  Now in a perfect world I wouldn't want the housing app to know that
  it's pulling in the finance app.  I come from a rich client
  development background, primarily, doing stuff on the NetBeans
  platform.  There you can drop your NetBeans modules (.jar files) in
  The Right Place, and the housing (the NetBeans platform) picks
 them
  up dynamically and runs them.  I'm looking for the GWT analog here.

 I'm probably not a good reference for NetBeans. NetBeans is an
 architecture that embraces Javascript and HTML, no?


 No.  :-)  No problem.

I was thinking of the NetBeans IDE Bundle for Web  Java EE. If one 
can send HTML to the client, one can send Javascript. GWT is designed to 
fit nicely into such environments.

 I think the GWT analog is:
 o The client makes AJAX requests of the server;
 o The server, running in a NetBeans framework, decides which of
 several
 resources can respond to the request;
 o Those resources, in the form of raw data, Javascript, HTML,
 images, c
 are sent to the client;
 o The response is transformed using the GWT classes into (D)HTML and
 other UI shiny stuff


 The reason I'm hung up on the implementation is not because I haven't 
 thought about how the application should behave.  If anything, I've 
 thought TOO hard about that, as well as how the applications, plural, 
 should be maintained, developed, versioned, upgraded, customized, and 
 finally aggregated together into different wholes for different 
 clients.  One client, for example, may want the finance application 
 only.  Another may want the order application and the finance 
 application.  Both clients will of necessity need the housing, since 
 that governs how you navigate around this sick little world.  ;-)

It sounds like you have a /lot/ of Java coding/maintenance/deployment 
experience. Don't be throwin' that away. Did you check out the scribd 
link? One of GWT's design goals is to provide you the leverage you need 
to make use of those Java/team management skills.

 So it's really more of a packaging question I'm asking than a Help Me 
 To Understand GWT question--the only reason GWT comes into play that I 
 can see is that it appears that GWT is not capable of modularly and 
 dynamically sucking in *code* at runtime that didn't exist before.  
 See, for example, this excellent thread: http://tinyurl.com/cveeft.

Yes, but (/me wields a thread): 
http://code.google.com/p/google-web-toolkit/wiki/CodeSplitting
 (Returning briefly to NetBeans for a moment, the whole architecture is 
 built on the fact that it sucks in code dynamically at run time.  So 
 the NetBeans housing fires up

Re: Best practices?

2009-04-23 Thread Ben FS


 And I could have a module without an EntryPoint, as I understand it.
Yes. Useful for common utility classes, UI components, authentication
framework, etc.

  Or you can have one GWT module that
  itself includes and arranges other GWT modules (the sub-applications).

 Perhaps a *really* stupid question, but how do I do that?
Let's try a concrete example. Feel free to specify something closer to
what you want. I think you want to have a bunch of applications, each
of which could run on its own, but you also want a housing
application that provides navigation, etc. and decides which sub-
applications to include in the UI. Yes?

One way to do this:
1. Make a core GWT module. It defines an Application abstract class
that inherits from GWT's Composite class.
2. Make the housing GWT module. It provides the high-level UI with
navigation, etc. and placeholders for one or more Application
instances.
3. Make additional GWT modules, each containing a concrete sub-class
of Application. These are your sub-applications. They each define an
EntryPoint, useful for testing them on their own, but mainly you will
instantiate each Application as a UI component in the housing
application.

Your Application base class will probably define methods like getTitle
(), getPreferredSize(), which your housing app might find useful.

Depending on how you determine which sub-applications should be
included, you could for example have a Servlet which generates the
appropriate HTML depending on some parameters.

 I didn't realize a GWT module could load another one itself.
In your GWT module definition (XML), you specify all other modules
upon which this module depends. The GWT compiler uses this
information. But this is likely not the loading to which you refer.

 Well, I'd just as soon not have one big .war file that everyone is whacking
 away on.  For one thing, I'd like to use Maven to version the various
 artifacts.  In my dumb example, assume the presence of some sort of housing
 artifact (.war, probably), the finance app artifact (another .war? something
 else?), the order app artifact (another .war? something else?) that get
 pulled together and aggregated into some sort of distribution unit that gets
 sent off to clients.  Each client may get a different distribution unit made
 up of these building blocks.
Yup, should be doable (see above for a simplified example). How do you
determine which client gets which building blocks?

I think you are free to decide how you wish to package these sub-
applications, i.e. modules. You can put them all in one WAR, or you
can put them in separate WAR's. Once a WAR is in a J2EE container,
the .js files etc. that make up the module are all accessible by
URL's ...

That said, you should pay attention to where you define your server-
side code, aka servlets. Will each module have its own? Will there be
a separate module that contains all the server-side code? Will they be
servlets that are not part of a module? Depending on how you work this
out, it will be easier or more difficult to resolve the appropriate
back-end URL's to be called from your asynchronous data access methods
in the client-side code.

  To make this work well, you should set up each module to be packaged
  into its own JAR file (which is how GWT library modules are
  distributed), which then can be included by the developer.

 Ah, OK.  I need to do some more reading; I did not realize that GWT library
 modules could be distributed as jar files.  If I can do that--as in, work in
 isolation in a corner somewhere, set up a stupid little hosted war
 environment to test things out with, but then only distribute my end product
 as a jar file--to be combined together with my other teams' jar files and
 aggregated together into the final war file--that would probably work well.

 I'm sure it's in front of me somewhere, but do you have a pointer to get me
 started on this packaging method?
Hmm, best I can come up with now is to read the Loading Modules
section on the following page, where it indicates that they are loaded
from the usual classpath. Also read the section titled Loading
multiple modules in an HTML host page:
http://code.google.com/webtoolkit/doc/1.6/DevGuideOrganizingProjects.html#DevGuideModules

Note how GWT's core classes are packaged, as a .jar file. Also, look
at 3rd party GWT modules, and some from Google, such as what is here:
http://code.google.com/p/gwt-google-apis/

 Thanks very much for your time and help; it is greatly appreciated.
You're welcome, good luck!


 Best,
 Laird
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en

Re: Best Practices for managing GWT 1.6 based Applications, Projects and Modules?

2009-03-23 Thread Thomas Broyer




On 23 mar, 02:50, ni...@stsoftware.com.au ni...@stsoftware.com.au
wrote:
 does anyone know if we can have more than one gwt module per page in
 1.6 ?

AFAICT, you already can with 1.5. It's just that the hosted mode makes
it a bit harder to debug (you have to tweak your HTML page wrt the
path of the nocache.js for the other modules).

From what I've read, it should be easier (read: straightforward,
supported out-of-the-box) in 1.6 with the new HostedMode: just pass it
your modules names as arguments and it just works.
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best Practices for managing GWT 1.6 based Applications, Projects and Modules?

2009-03-23 Thread Kevin Telford


We've been developing a multi-module application and I think the 1
project 1 entry point multiple module approach is the best (of course
there are always exceptions).

One good reason is that in your main modules' gwt.xml you can inherit
everything and then all of the subordinate modules will inherit
everything from the main module that inherited them.  Other than
unique rpc callback servlets, all of our modules' gwt.xml files are an
empty set of module/module tags.

Another thing is if you have some common 'methods' or 'utilities' you
can make a module for them, inherit that in your main module and they
will be available for all the other modules.

One thing to be careful about though is keep your module naming
conventions the same.  We do a lot of reflection for multiple
instances of given modules and are only able to do so by adhearing to
naming conventions.

Another thing is try to keep all the 'work' out of your gwt code and
keep it in your /server folder or in another designated server side
package.  You never know when the client will get all hot and heavy
and you may have to swap out the presentation layer.

On Mar 20, 9:47 pm, Lance Weber weber.la...@gmail.com wrote:
 With the arrival of the new project structure in 1.6 I'm looking for
 recommendations/experiences on organizing complex applications
 containing several major functional areas.

 For purposes of this discussion, I'm envisioning
 -Application A
 --Functional Area A1
 --Functional Area A2
 --Functional Area A3

 Assuming each functional area shares  50% common entities, business
 logic and gui components, it isn't clear to me what approaches to
 organizing the codebase will scale with the eventual size of the
 application. Here are some of the options as I understand them:

 1) Monolith Option. One project with one module, possibly supporting
 multple entry points.

 2) One project, multiple modules. Maintain one project, but create
 multiple modules to organize common classes and functional areas. (How
 do you accomplish this in 1.6? It's not clear to me)

 3) Multiple projects, one module per project. Create one project for
 each module, resulting in a commons project and a project for each
 functional area.

 Any thoughts/comments on this would be welcome...
 Advantages/Disadvantages?
 Options I'm missing?
 Good/Bad experiences with these approaches?

--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best Practices for managing GWT 1.6 based Applications, Projects and Modules?

2009-03-22 Thread Thomas Broyer




On 21 mar, 02:47, Lance Weber weber.la...@gmail.com wrote:
 With the arrival of the new project structure in 1.6 I'm looking for
 recommendations/experiences on organizing complex applications
 containing several major functional areas.

 For purposes of this discussion, I'm envisioning
 -Application A
 --Functional Area A1
 --Functional Area A2
 --Functional Area A3

 Assuming each functional area shares  50% common entities, business
 logic and gui components, it isn't clear to me what approaches to
 organizing the codebase will scale with the eventual size of the
 application.

1.6 isn't different from 1.5 with this respect. 1.6 is just about
where you put your HTML host page.

 Here are some of the options as I understand them:

 1) Monolith Option. One project with one module, possibly supporting
 multple entry points.

 2) One project, multiple modules. Maintain one project, but create
 multiple modules to organize common classes and functional areas. (How
 do you accomplish this in 1.6? It's not clear to me)

 3) Multiple projects, one module per project. Create one project for
 each module, resulting in a commons project and a project for each
 functional area.

As jgrimm, I'd recommend option 2. I'd only use a distinct project for
modules that can be reused in other applications.

 Any thoughts/comments on this would be welcome...
 Advantages/Disadvantages?
 Options I'm missing?
 Good/Bad experiences with these approaches?

GWT itself has many modules yet a single project (as far as client,
translatable code is concerned)

--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best Practices for managing GWT 1.6 based Applications, Projects and Modules?

2009-03-22 Thread branflake2267


Hi,

I like what I see with the improvements of 1.6! I am building a
enterprise application at a major telecom company which is getting
used, in which I am fully utilizing gwt. I also have built
GoneVertical.com application.

This is a great question. I have been experimenting with including my
modules like this. Although I haven't had all the items come together
like I want I have gotten close. I haven't been able to build included
projects with my current war builder. I really like the new system,
but haven't got Ant figured out to include other modules, and then get
the other module classes included into the war.

This is my goal for my project builds. I have successfully testing
including modules in 1.6 like this, but building them I have not.
 Navigational Core Module - entry point resides here, directs the applications 
 rendering
   Login Module - login widgets and class
   Common Module - common widgets and classes
   Options for more included modules
   Project Module - current working project

I am a GWT promoter!
Brandon


On Mar 20, 6:47 pm, Lance Weber weber.la...@gmail.com wrote:
 With the arrival of the new project structure in 1.6 I'm looking for
 recommendations/experiences on organizing complex applications
 containing several major functional areas.

 For purposes of this discussion, I'm envisioning
 -Application A
 --Functional Area A1
 --Functional Area A2
 --Functional Area A3

 Assuming each functional area shares  50% common entities, business
 logic and gui components, it isn't clear to me what approaches to
 organizing the codebase will scale with the eventual size of the
 application. Here are some of the options as I understand them:

 1) Monolith Option. One project with one module, possibly supporting
 multple entry points.

 2) One project, multiple modules. Maintain one project, but create
 multiple modules to organize common classes and functional areas. (How
 do you accomplish this in 1.6? It's not clear to me)

 3) Multiple projects, one module per project. Create one project for
 each module, resulting in a commons project and a project for each
 functional area.

 Any thoughts/comments on this would be welcome...
 Advantages/Disadvantages?
 Options I'm missing?
 Good/Bad experiences with these approaches?
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best Practices for managing GWT 1.6 based Applications, Projects and Modules?

2009-03-22 Thread ni...@stsoftware.com.au


does anyone know if we can have more than one gwt module per page in
1.6 ? This was a limitation in IE using GWT 1.4
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best Practices for managing GWT 1.6 based Applications, Projects and Modules?

2009-03-21 Thread jgr...@gmail.com


Hi Lance,

I suggest you build one module for each functional area, plus some
modules common across the application, with each module *not* having
an entry point.  The functional area module would inherit from the
common modules, in essence treating them as libraries.  Eventually,
you will have one module, inheriting from each of the functional area
modules, that will define the one entry point for the entire
application.  (You might also consider having this module that
represents the application also not have an entry point, and then have
two modules that inherit from it that just have entry points.  One of
these two modules would act as the runtime module; the other would
have extra bits for testing.)


Cheers,
James


On Mar 20, 6:47 pm, Lance Weber weber.la...@gmail.com wrote:
 With the arrival of the new project structure in 1.6 I'm looking for
 recommendations/experiences on organizing complex applications
 containing several major functional areas.

 For purposes of this discussion, I'm envisioning
 -Application A
 --Functional Area A1
 --Functional Area A2
 --Functional Area A3

 Assuming each functional area shares  50% common entities, business
 logic and gui components, it isn't clear to me what approaches to
 organizing the codebase will scale with the eventual size of the
 application. Here are some of the options as I understand them:

 1) Monolith Option. One project with one module, possibly supporting
 multple entry points.

 2) One project, multiple modules. Maintain one project, but create
 multiple modules to organize common classes and functional areas. (How
 do you accomplish this in 1.6? It's not clear to me)

 3) Multiple projects, one module per project. Create one project for
 each module, resulting in a commons project and a project for each
 functional area.

 Any thoughts/comments on this would be welcome...
 Advantages/Disadvantages?
 Options I'm missing?
 Good/Bad experiences with these approaches?
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best Practices for managing GWT 1.6 based Applications, Projects and Modules?

2009-03-21 Thread Lance Weber


Hi James,

Thanks for the thoughtful reply, it helps me to just talk this
through. I really like the idea of having a topmost runtime module and
a topmost test scaffold module. Quick question: would you recommend 1
project per module so you end up with multiple projects? Is there an
easy way to manage multiple modules inside a single project?

On Mar 21, 11:29 am, jgr...@gmail.com jgr...@gmail.com wrote:
 Hi Lance,

 I suggest you build one module for each functional area, plus some
 modules common across the application, with each module *not* having
 an entry point.  The functional area module would inherit from the
 common modules, in essence treating them as libraries.  Eventually,
 you will have one module, inheriting from each of the functional area
 modules, that will define the one entry point for the entire
 application.  (You might also consider having this module that
 represents the application also not have an entry point, and then have
 two modules that inherit from it that just have entry points.  One of
 these two modules would act as the runtime module; the other would
 have extra bits for testing.)

 Cheers,
 James

 On Mar 20, 6:47 pm, Lance Weber weber.la...@gmail.com wrote:

  With the arrival of the new project structure in 1.6 I'm looking for
  recommendations/experiences on organizing complex applications
  containing several major functional areas.

  For purposes of this discussion, I'm envisioning
  -Application A
  --Functional Area A1
  --Functional Area A2
  --Functional Area A3

  Assuming each functional area shares  50% common entities, business
  logic and gui components, it isn't clear to me what approaches to
  organizing the codebase will scale with the eventual size of the
  application. Here are some of the options as I understand them:

  1) Monolith Option. One project with one module, possibly supporting
  multple entry points.

  2) One project, multiple modules. Maintain one project, but create
  multiple modules to organize common classes and functional areas. (How
  do you accomplish this in 1.6? It's not clear to me)

  3) Multiple projects, one module per project. Create one project for
  each module, resulting in a commons project and a project for each
  functional area.

  Any thoughts/comments on this would be welcome...
  Advantages/Disadvantages?
  Options I'm missing?
  Good/Bad experiences with these approaches?
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: best practices for gwt caching

2009-02-18 Thread Shawn Pearce

On Tue, Feb 17, 2009 at 22:41, batosai tariq.albabt...@gmail.com wrote:


 I am working on optimizing my gwt app performance and I was looking at
 caching among other things. But I noticed that there are only a few
 posts that address the best practice of caching for GWT apps. (e.g.
 etags , mod_expires)

  I wanted to start a discussion on the matter and I would appreciate
 if anybody there could shre his ideas and experience in this matter.


I can't speak for anyone else, but I'm using this filter to enforce caching
of the non-changing files, e.g. the $hash.cache.html files produced by the
GWT compiler:


http://android.git.kernel.org/?p=tools/gerrit.git;a=blob;f=src/main/java/com/google/gerrit/server/CacheControlFilter.java;hb=HEAD

http://android.git.kernel.org/?p=tools/gerrit.git;a=blob;f=src/main/webapp/WEB-INF/web.xml;hb=HEAD

Using the web.xml I send all requests through the cache control filter, but
only cache those that end in *.cache.html, or *.cache.png (ImageBundles).
The others are marked as uncached as they are typically RPCs.

I also run the application container behind an Apache2 reverse proxy, with
caching enabled in Apache:

  http://gerrit.googlecode.com/svn/documentation/2.0/install.html#apache2

In practice, the container only receives RPC requests, everything else is
served out of the disk cache by the Apache children.  And clients and edge
proxies are able to quite aggressively cache content, reducing the number of
hits Apache sees.

--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: best practices for gwt caching

2009-02-18 Thread batosai


Thanks shawn for the feedback. I know that there are files like the
*.cache.* files produced by the compiler with hash values that are
unique for every build. So we can cache them for a long time using
http server (apache in my case ) by setting the cache-control header
for a max age for a year or more on those files :)

But I have been reading the apache caching guide
http://httpd.apache.org/docs/trunk/caching.html and I feel that I
should do more than just enable the cache  Anyone there also care
to share his ideas.


--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices

2008-09-29 Thread gregor


Hi Stefan,

Maybe because there are so many different kinds af application you can
build with GWT that it's hard to say if there is any one best
practice -  perhaps there there are number of good blueprints
suitable for particular types of application. But for me there are a
few guiding principles I adhere to:

1) GWT, based on Java, is fully object oriented, so all OO principles
apply - they are well known.

2) Use the GWT event model for sending messages between widgets, do
not hold any direct internal references to peer widgets to call peer
methods directly. In the face of complexity this simplifies code and
makes it more robust. It also means that pieces can be easily swapped
in and out of the application and it makes testing and maintenance a
lot easier. This is the Observer pattern, it has stood the test of
time and it avoids tight coupling between components. In practice this
means that a parent widget typically  instantiates and lays out its
child widgets and then hooks up their event listeners etc for them,
but the children have no idea who their parent is or who their peers
are - they just broadcast events which other widgets might listen out
for.

3) The exception to this rule is where you have a group of widgets
that work very closely together for exactly one purpose - in OO
parlance are highly cohesive - so that to all intents and purposes
they have little or no relevance to anything outside that purpose. In
this case it can be not only acceptable but probably desirable to use
direct method calls between them. I'm not sure that there is an
accepted name for this pattern - I've seen things like goal-oriented
windows etc - and in GWT it is tempting to call it a Composite, but
although related, GWT's Composite isn't exactly the same thing, nor is
the GoF definition of it. Two examples of what I mean by this are a) a
form with a number of input fields, list boxes etc, where you might
want to do validation/auto-suggest work on the fields, and b) a
navigation structure, e.g. a Tree, where you also have a button bar
with a range of tool buttons driving functions off the tree's selected
item and might need to turn themselves on/off depending on the item
selected. It can be more efficient and basically easier to put
everything in one class and have the individual field/buttons etc call
each other directly via private access in this situation. You would
typically use a GWT Composite to implement this pattern.

4) However you need to be careful with this exception and use the
concept of granularity - a component should be neither too big nor
too small, but just right. What right is is matter of judgment.
When I was learning C++ in college I was taught that the right size
of a function was usually between 5 and 12 meaningful lines of code.
My own rules of thumb on this are that I do not like GWT classes to
have more than about 100-150 LoC max. If they go over this and the
class qualifies as a single purpose unit then I tend to break it up
using private internal classes. If it looks like it's going over
about 500 LoC, then I break it up into separate public classes if I
can and go back to using the Observer pattern and the event system.
But this a judgement call, a matter of craft IMO rather than science
and situation vary widely.

5) Decide early on whether you are after an application that looks and
feels like a web page or like a desktop application. Outside of
aesthetic considerations, it is technically more difficult to get a
GWT UI to work perfectly completely contained within the browser's
window area, resizing itself perfectly etc and it will cost you some
to do so. The browsers think of everything as a document so their
natural tendency is to extend the height of the document, invoking
scrolling, and not to contain within the available visible client area
height. if you want a desktop style app, then it's probably a good
idea to do extra work up front on the overall layout mechanisms until
you get it working properly. If you are used to windows style GUI
programming, maybe Swing or SWT, or you are writing a business
application, it can be difficult to choose on this one. At the end of
the day customer perception is all, but I think that if your users
will be happy with a more web style layout then it's probably best
to go that way. I would recommend you trial some prototypes early on
to find out. Ask yourself whether Google tried to copy Outlook when
they made GMail.

6)  Plan your asynchronous RPC calls out in the large up front and
plan for them to change as you find out if your initial decisions
where good - in most non-trivial apps I think some changes in approach
will become necessary as real performance figures start coming in. RPC
is a trade off between keeping the number of calls to a minimum whilst
at the same time keeping the size the packets to a reasonable level,
and no two situations will be identical. Aim for a response time of
1s except for situations where that is clearly not

Re: Best practices

2008-09-29 Thread Thomas Broyer



On 25 sep, 10:44, Stefan [EMAIL PROTECTED] wrote:
 Hi,

 Does anyone know any good resources for Best practices when writing
 GWT apps? Questions I would like to have answered:

 * How to I write high-performing apps? I know that the compiler helps
 out, but how do I write code that helps the compiler to minify/
 optimize my app?

Google for high performance ajax and the like. Application and code
organisation and design, independently of being pure or GWT-
generated JavaScript, highly impacts performance.

The main rule: the fastest code is the one that doesn't run (or, as
would say Julien Lecomte [1]: less is more: don't do anything
unnecessary / don't do anything until it becomes absolutely necessary)

[1] http://www.slideshare.net/julien.lecomte/high-performance-ajax-applications/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices

2008-09-29 Thread Carlos Rafael Ramirez

Hello Gregor,

Have you thought in put your answer in a BLOG? For me your message is an GWT
optimization article.

Thanks,
Regards,
Carlos

On Tue, Sep 30, 2008 at 12:04 PM, Thomas Broyer [EMAIL PROTECTED] wrote:



 On 25 sep, 10:44, Stefan [EMAIL PROTECTED] wrote:
  Hi,
 
  Does anyone know any good resources for Best practices when writing
  GWT apps? Questions I would like to have answered:
 
  * How to I write high-performing apps? I know that the compiler helps
  out, but how do I write code that helps the compiler to minify/
  optimize my app?

 Google for high performance ajax and the like. Application and code
 organisation and design, independently of being pure or GWT-
 generated JavaScript, highly impacts performance.

 The main rule: the fastest code is the one that doesn't run (or, as
 would say Julien Lecomte [1]: less is more: don't do anything
 unnecessary / don't do anything until it becomes absolutely necessary)

 [1]
 http://www.slideshare.net/julien.lecomte/high-performance-ajax-applications/
 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices

2008-09-28 Thread tyler


Hi,

I would also be interested in seeing a set of best practices for
writing the client-side portion of GWT apps.  In the mean time, try
the -style PRETTY parameter to your compiler.   Looking at the
generated JavaScript might give you some insight into how you might
improve your java code.

Tyler


On Sep 25, 3:44 am, Stefan [EMAIL PROTECTED] wrote:
 Hi,

 Does anyone know any good resources for Best practices when writing
 GWT apps? Questions I would like to have answered:

 * How to I write high-performing apps? I know that the compiler helps
 out, but how do I write code that helps the compiler to minify/
 optimize my app?
 * How does static and final assignments affect the performance of
 apps?

 Thanks in advance!
 Stefan

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

Re: Best practices

2008-09-25 Thread Lothar Kimmeringer


Stefan schrieb:

 Does anyone know any good resources for Best practices when writing
 GWT apps? Questions I would like to have answered:
 
 * How to I write high-performing apps? I know that the compiler helps
 out, but how do I write code that helps the compiler to minify/
 optimize my app?
 * How does static and final assignments affect the performance of
 apps?

A GWT-app consists of the client- and server-side part. For
the server-side you can use the rules for Java, on the
client-side others might be able to say more.


Regards, Lothar

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---

87 matches

Mail list logo