GWT Design Problem

[ping2ravi]

Hi All,
I am trying to create a website and stuck with confusion over whether
to use GWT for presentation or JSP based framework like Spring MVC. I
want UI to be very user friendly,faster etc and this is possible with
GWT. But following problem comes with GWT

1) Book marking of any page. As GWT is suppose to be one url
application and everything should come under it. But how i will solve
the problem if i have a site like Facebook, where url can be for User
profile(/profile/1), My Home(/home), community(/cpmm),video(/video)
etc. I can solve it by using one html and keeping everything as
params(i.e. /myapp.htm?type=profile&id=1) but then i feel its not how
GWT should be used or is this the only way i will be able to use it.

2) Not searchable by Search Engines. Search engine can not see what
the content is as it always comes through RPC calls.

3) Implementing History is Overhead, if i fix the issue 1

4) Its not possibkle to mix jsps and GWT. I tried but GWT css start
interfaring with my CSS, first starting with changing background
color.



But i still like GWT but not sure how i will solve these problems.

Any suggestions/comments most welcome.

Thanks,
Ravi

[mikeds...@gmail.com]

Just a quick response...sorry I don't have time at this second for a
more thorough one...

Items 1, 2 & 3 are hardly unique to GWT...you've described the
standing challenges that DHTML/AJAX clients have dealt with for
literally the last 10 years. GWT does have some advantages,
especially in history because of the way that the GWT team engineered
the whole History subsystem.

Item 4 sounds like more of a setup issue for your GWT app as you can
use or not use as much standard CSS as you want. We currently have a
number of mixed apps consisting of GWT & JSP's, using the corporate
standard CSS stuff with no issues at all.

If I survive this impending 3 hour meeting I might be able to respond
with more detail.

Later,

Shaffer

[Sripathi Krishnan]

There is a big difference between a website and a webapp, and deciding which is more suitable for use case is more important than choosing the technology.

Website is old-school. There are multiple pages, and moving from one page to another is done via hyperlinks. Websites aren't interactive, and are largely content driven. A website has information to share, and hence SEO becomes important. Blogs, newspapers and forums, corporate websites are great examples. 

Webapps are the new trend. They typically have just a single page. Multiple views are simulated using javascript and DOM manipulation. History and backbutton support are achieved by tricking the browser via fragment identifiers. Webapps are usually interactive; user performs actions and site responds quickly. Webapps are typically personalized for a user, and hence SEO doesn't matter much. Gmail, Wave, Facebook are great examples of webapps. 

You have to decide whether you need a Content-driven Website or an interactive, personalized Webapp. Nobody can help you there.

Once you have made the decision, it becomes very simple. If your requirements tend towards a Website, use server-side technologies like JSP/Spring Webflow. Then use a js library like JQuery or YUI (or whatever) and progressively enhance it to get a richer experience. DO NOT attempt to build such a website using GWT; you are going to be dissatisfied with the outcome. Although GWT has support for history, backbutton and SEO, its a lot easier to get it right using traditional technologies.

But if what you want is more like a webapp, welcome to GWT! URLs can still be bookmarkable - only they will end in #profile, #community and #videos. History management comes automatically if you have bookmarkable urls. To make it seo friendly, read the Ajax Crawling article. Mixing JSP's and GWT is possible but in general a bad idea, because multiple jsps are an indication that you want a website. More importantly, loading a GWT module is expensive, and you only want to do that once per user session. 

There are ways to overcome the problems you mention using both technologies. The decision to use a particular technology should be based on your requirements (website v/s app), and not on the specific problems you have enumerated.

--Sri

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

[ping2ravi]

Thanks Shaffer/Sri,
I think i will go with GWT, the only thing is that i will have to
implement History which usually i dont do while writing the
websites(jsp/html page based). May be thats the reason i thought
writing history is overhead but i guess this over head will give me
good webapp/website.
now with GWT also i have few question like.
e.g. i am on a user profile (some other user) screen i created a
panel(grand parent of every widget inside it) say the url is
myapp.html#type=profile&id=100
then i go to another user's profile and url is now
myapp.html#type=profile&id=234.

Question, what is the best approach here. Shall i create a brand new
that grand panel and fill the data from server or shall i reuse the
exisitng panel, clean it and then refill the data from server.
Option 1) If i create always new panel, can i trust GWT that it will
never go out of memeory or after some time user;s browser wont feel
that something heavy has been loaded? By using this approach i can
make sure that if user come to link myapp.html#type=profile&id=100
again, i wont go to server and will just display the existing Panel.
It will be quickest thing on the earth and user may feel better to see
a page faster then anything.

My Server calls will be like

myapp.html#type=profile&id=100 call server and get data
myapp.html#type=profile&id=234 call server and get data
myapp.html#type=profile&id=100 ======No need to call
server as one panel already exists which can show profile for user 100
myapp.html#type=profile&id=234 ======No need to call
server as one panel already exists which can show profile for user 234

Probelm which i see in this approach:
1) Memory can be a problem in this approach. Exp GWT developer may be
able to give me some insight here.
2) Client view might be bit older then server, but panels can be
removed from history cache using timers say 1 minute etc. But still
older.


Option 2) Reruse the existing Panel again and again. Basically create
all main panels which need to have history as singleton(although its
javascript, but in java write code like that) and reuse the panel and
whenevr history changes reset all panels/widgets inside it and reload
the data from Server
myapp.html#type=profile&id=100 call server and get data
myapp.html#type=profile&id=234 call server and get data
myapp.html#type=profile&id=100 call server and get data
myapp.html#type=profile&id=234 call server and get data

In this approach i guesss i will have less problem with memory and
data will always be latest. But Server calls will be increased.That
means extra load on server and user's every click(Back and forward)
will go to server

Is there any ther option available here?. If not then out of these
which one of you think will be better. SOmehow i am inclined to option
1 but need to know if memory will be a problem.
Thanks,
Ravi.






On Jun 1, 6:42 pm, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:

> There is a big difference between a website and a webapp, and deciding which
> is more suitable for use case is more important than choosing the
> technology.
>

> *Website* is old-school. There are multiple pages, and moving from one page

> to another is done via hyperlinks. Websites aren't interactive, and are
> largely content driven. A website has information to share, and hence SEO
> becomes important. Blogs, newspapers and forums, corporate websites are
> great examples.
>

> *Webapps* are the new trend. They typically have just a single page.

> Multiple views are simulated using javascript and DOM manipulation. History
> and backbutton support are achieved by tricking the browser via fragment
> identifiers. Webapps are usually interactive; user performs actions and site
> responds quickly. Webapps are typically personalized for a user, and hence
> SEO doesn't matter much. Gmail, Wave, Facebook are great examples of
> webapps.
>
> You have to decide whether you need a Content-driven Website or an
> interactive, personalized Webapp. Nobody can help you there.
>
> Once you have made the decision, it becomes very simple. If your
> requirements tend towards a Website, use server-side technologies like
> JSP/Spring Webflow. Then use a js library like JQuery or YUI (or whatever)
> and progressively enhance it to get a richer experience. DO NOT attempt to
> build such a website using GWT; you are going to be dissatisfied with the
> outcome. Although GWT has support for history, backbutton and SEO, its a lot
> easier to get it right using traditional technologies.
>
> But if what you want is more like a webapp, welcome to GWT! URLs can still
> be bookmarkable - only they will end in #profile, #community and #videos.
> History management comes automatically if you have bookmarkable urls. To
> make it seo friendly, read the Ajax Crawling

> article<http://code.google.com/web/ajaxcrawling/>.

> Mixing JSP's and GWT is possible but in general a bad idea, because multiple
> jsps are an indication that you want a website. More importantly, loading a
> GWT module is expensive, and you only want to do that once per user
> session.
>
> There are ways to overcome the problems you mention using both technologies.
> The decision to use a particular technology should be based on your
> requirements (website v/s app), and not on the specific problems you have
> enumerated.
>
> --Sri
>

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsu...@googlegroups.com>
> > .

[kozura]

I recommend you use a single widget with a method to change the data
showing in it (user profile, whatever). You have to be able to
populate it anyway, so that's no extra code. Caching panels is
generally a bad idea and a lot of overhead.

As for limiting server calls, you can cache the data returned to avoid
having to recall the server. Easiest way is a simple map id->data;
check it when you need an id, if you have it then call the async
callback immediately, otherwise make the RPC call and be sure to stick
the result into the cache map when it gets returned. Of course if the
data is dynamic you probably want some mechanism to know when a
particular piece of data gets changed and needs re-sent..

Also you might look at one of the models built on top of GWT which do
this for you in various ways.

[ping2ravi]

Ya this approach looks good, thanks kozura.
Now my app will look like this.

myapp.html#type=profile&id=100 call server and get data
myapp.html#type=profile&id=234 call server and get data

myapp.html#type=profile&id=100 get data from cache and
refresh panel with this data
myapp.html#type=profile&id=234 get data from cache and
refresh panel with this data

Thanks all, i guess now i can start writing a basic framework around
this approach.

[Tristan]

check this out to give you some ideas about the history service..

http://code.google.com/p/handlebars/wiki/PlaceServiceOverview

[Frederic Conrotte]

I advise you to take a look at this book:
http://apress.com/book/view/9781590599853

and the related website:
http://code.google.com/p/tocollege-net/

The books explains how you can nicely split your web application
between HTML/JSP pages and GWT modules

Fred

[Frederic Conrotte]

Hello

You should check this book:
http://apress.com/book/view/9781590599853

And the associated website:
http://code.google.com/p/tocollege-net/

It mix both HTML/Freemarker templates with GWT modules.

Fred

[ping2ravi]

This post i am not asking a problem but suggesting a feature request
for GWT.
========================================================

Now history stuff is working well, except few things(Basic GWT issue/
feature, because of its nature of converting java into javascript at
the time of compilation and the classes it supports in .client
packages).

I have declared the ValueChangeHandler but then in that code i need to
check one or more particular param, lets say page and then i write
5-10 if then else statement to call my proper handlers.

say if page=main, then call com.my.MainPanel.loadFromHistory(params)
say if page=editData1, then call
com.my.EditData1Panel.loadFromHistory(params)
say if page=editData2, then call
com.my.EditData2Panel.loadFromHistory(params)
say if page=showData1, then call
com.my.ShowData1Panel.loadFromHistory(params)
say if page=showData2, then call
com.my.ShowData2Panel.loadFromHistory(params)
etc etc


In Spring/MVC architect we have seen that we don't need to write such
ifs as DispatchServlet can read our xml and call our handlers
depending on xml content(url-handler mappings). In Spring it was
implemented using Reflection which cant be used in GWT as there are no
JAVA classes at run time, its all javascript. Understandable.No
argument over it but its still solvable.

We should not forget the javascript is loosely coupled language and
implementing such things(Reflection) should not be a big
hassle.Reflection makes Java loosely coupled at compile time(ofcourse
wrong types will create problem at runtime)

Solution :

We already have UIBinders where GWT compiler reads the xml and
generate proper java script. Why cant we have something like for
History(say HistoryBinder.xml) and i should be able to define some xml
like
<HistoryMapping>
<HandlerMapping>
<param name="page" value="main">
<handler value="com.my.MainPanel" />
</HandlerMapping>
</HistoryMapping>

And all handlers can implement a Interface like
public interface HistoryHandler{
public handleHsitory(Map<String,String> params, any other param which
is required)
}

and at compile time, compiler will check each class mentioned in this
xml and generate error if anything wrong with class else generate the
proper code behind the scene as lots of If then else(Compiler writers
cant use Reflection for generated scriptts too :) )

and then GWT can call our proper handler whenever history event occurs
and we will never have to implement ValueChangeHandler.And GWT will
also take care of converting our history tokens into proper hashmap
like structure or any other key-value pair structure.

This will make code writing much easier, more understandable, makes
Developer's life bit easier. And i am sure it will add value to GWT.

Thanks,
Ravi




On Jun 2, 8:13 pm, Frederic Conrotte <frederic.conro...@gmail.com>
wrote:

[Nathan Wells]

I would suggest watching Ray Ryan's videos on architecture from Google
I/O 2009 and 2010. That couple of hours will help you understand how
to solve a lot of your architecture/design problems.

[Tristan Slominski]

I for one don't want to write any more xml in my life than I have to. I prefer my history service written in Java with auto completion, etc... that's why I use Guice over other DI frameworks. I think your argument is for declarative history service, which I could get behind. But the particular xml implementation of it, yuck.

--
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-we...@googlegroups.com.

To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Sorinel C]

Nice GWT books you can find here ...

http://gwt-books.blogspot.com/

Cheers!