Using multiple HTML files for GWT
Learn2FlyGWT
I am new to GWT and i love it. I wrote my first little app (login
screen) Yay!!
My idea is to extend my app on a piece by piece basis. The next thing
i would do is write my "Inbox" app, then "Filters" app, then
"Contacts" app...and so on, but all under a part of this BIG gwt app,
the entry point of which is the Login screen i just created.
This is where i am not being able to move forward. I want the rest of
the screens as separate HTML files (rather than doing 'hide/show' in
the same HTML), and each HTML file will have its own 'client UI logic'
in GWT - which means separate Java file and HTML files refering to
these files in <head> .. <meta name='gwt:module'
content='org.act.gwt.XXXX> ..</head>
I dont want to create another directory structure, another app and
another servlet.
So what i tried to do was list multiple <entry-point> tags in the main
app.gwt.xml. However, when i redirect to the next page, it fails
I read this suggestion from Bruce Johnson himself:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/1106bc10356e9880/#03c3d13a29f31273
But it went over my head.
Could anyone please illustrate how he is suggesting to do it?
Thanks
Learn2FlyGWT
I integrate two GWT sub apps
(its a little too verbose - the illustration below - but i hope it
helps someone who gets as stuck as me)
Solution is: (multiple HTML files + GWT) (multiple files GWT)
Project Structure:
main/pgk1.pkg2.client.app1.java
main/pgk1.pkg2.client.app2.java
main/pgk1.pkg2.public/FirstApp.Html
main/pgk1.pkg2.public/SecondApp.Html
main/pgk1.pkg2/app1.gwt.xml
main/pgk1.pkg2/app2.gwt.xml
file: app1.gwt.xml
<
<module>
<!-- Inherit the core Web Toolkit stuff. -->
<inherits name='com.google.gwt.user.User'/>
<!-- Specify the app entry point class. -->
<entry-point class='org.act.gwt.client.app1'/>
</module>
file: app2.gwt.xml
<
<module>
<!-- Inherit the core Web Toolkit stuff. -->
<inherits name='com.google.gwt.user.User'/>
<!-- Specify the app entry point class. -->
<entry-point class='org.act.gwt.client.app2'/>
</module>
EOF>
File: main/pgk1.pkg2.public/FirstApp.Html
<
... <meta name='gwt:module' content='org.act.gwt.app1'> ...
EOF>
File: main/pgk1.pkg2.public/SecondApp.Html
<
... <meta name='gwt:module' content='org.act.gwt.app2'> ...
EOF>
================================================
Well that works
Now i am wondering about - what should be the design of this front end
in relation to the backend in Spring, Hibernate. Deployment issues.
How many servlets do we need?
On Mar 29, 6:28 pm, "Learn2FlyGWT" <skiddy.pou...@gmail.com> wrote:
> Hi,
>
> I am new to GWT and i love it. I wrote my first little app (login
> screen) Yay!!
>
> My idea is to extend my app on a piece by piece basis. The next thing
> i would do is write my "Inbox" app, then "Filters" app, then
> "Contacts" app...and so on, but all under a part of this BIG gwt app,
> the entry point of which is the Login screen i just created.
>
> This is where i am not being able to move forward. I want the rest of
> the screens as separate HTML files (rather than doing 'hide/show' in
> the same HTML), and each HTML file will have its own 'client UI logic'
> in GWT - which means separate Java file and HTML files refering to
> these files in <head> .. <meta name='gwt:module'
> content='org.act.gwt.XXXX> ..</head>
>
> I dont want to create another directory structure, another app and
> another servlet.
>
> So what i tried to do was list multiple <entry-point> tags in the main
> app.gwt.xml. However, when i redirect to the next page, it fails
>
> I read this suggestion from Bruce Johnson himself:http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
Reinier Zwitserloot
Create new pages as Composites (public class Inbox extends
Composite)....
then remove the LoginScreen composite, and add the Inbox composite, to
e.g. RootPanel directly, or some child of root.
Multiple files, yes, please. Multiple packages and multiple projects,
even.
But only one entry point. Cuts down, MASSIVELY, on the bandwidth and
latency.
On Mar 30, 1:28 am, "Learn2FlyGWT" <skiddy.pou...@gmail.com> wrote:
> Hi,
>
> I am new to GWT and i love it. I wrote my first little app (login
> screen) Yay!!
>
> My idea is to extend my app on a piece by piece basis. The next thing
> i would do is write my "Inbox" app, then "Filters" app, then
> "Contacts" app...and so on, but all under a part of this BIG gwt app,
> the entry point of which is the Login screen i just created.
>
> This is where i am not being able to move forward. I want the rest of
> the screens as separate HTML files (rather than doing 'hide/show' in
> the same HTML), and each HTML file will have its own 'client UI logic'
> in GWT - which means separate Java file and HTML files refering to
> these files in <head> .. <meta name='gwt:module'
> content='org.act.gwt.XXXX> ..</head>
>
> I dont want to create another directory structure, another app and
> another servlet.
>
> So what i tried to do was list multiple <entry-point> tags in the main
> app.gwt.xml. However, when i redirect to the next page, it fails
>
> I read this suggestion from Bruce Johnson himself:http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
Learn2FlyGWT
Thanks for your reply.
Creating composites and replacing them still loads the composite on
the same HTML page. I understand how it can cut down on the bandwidth,
but speaking from a project management and software engineering
perspective combined for a VERY large project (i could be wrong), i
would still like to have the flexibility of:
(Point # 4 below is the focus part of my objectives)
1. Assigning designers to come up with highly appealing professional
web pages with "slots" for gwt apps (project management). Each page
thus designed has a separate look and feel (maybe the headers and logo
are same - but lets be open about the possibility of changes in the
way other parts are arranged)
2. Develop GWT components independently (which are composites as you
mentioned) to be inserted into the "slots". Think of this as "Gadgets"
in your personalized google home page (like server aware ActiveX
objects in windows). Team A develops component "Role Based Menu", Team
B writes ("Rich Text composer") etc. all of them server-aware
3. As usual, another team develops the core backend in Spring,
Hibernate, EJB etc - supposed to be independent of presentation tier
4. Then some one sews them up as required. This is the most important
part of my logic: Conditional branching/redirection to a given page
from a servlet. For example, lets say when you first launched your
app, you gave some features. But then later you extended the
application (with more composite and more HTMLs) and decided to show
these only to those users who decide to Pay for the services. Now you
dont want to touch your already working code (the old features), but
just want to integrate the new features (bundled in new HTMLs and new
composites). Or it could be as simple as these new features require
you to HTTPS to a different page....lots of different situations.
The idea is to introduce manageable component based development for
the web when things get really huge and you dont want to make huge
changes to your pre-existing app.
I apologize for having such a huge post. :-)
Wanted to illustrate my concept without communication mismatch.
Your comments would be very much appreciated..
Thanks
> > Thanks- Hide quoted text -
>
> - Show quoted text -
Reinier Zwitserloot
It's called lazy loading. The KitchenSink does it. The moment you need
a composite, you create one, which renders it, and then you display
it. It doesn't all get rendered the moment the app were to load.
The code to create it IS loaded immediately, but this is a good thing:
It means the code gets properly cached and your app is extremely
responsive. In practice even large GWT apps don't amount to much more
than about 300k for just the script file. For a modem connection (and
how many web users still have that? Less than 20%?) this will be about
40 seconds to download, but it's a one-off, after that it's in the
cache, and the app is instant-speed responsive).
> 1. Assigning designers to come up with highly appealing professional
> web pages with "slots" for gwt apps (project management). Each page
> thus designed has a separate look and feel (maybe the headers and logo
> are same - but lets be open about the possibility of changes in the
> way other parts are arranged)
>
Most designers I know of work in illustrator and not HTML. WHich means
someone has to translate the thing to HTML and CSS, and there's
nothing stopping you from translating it to a GWT composite with CSS
instead. That said, some sort of templating solution would be nice.
> 2. Develop GWT components independently (which are composites as you
> mentioned) to be inserted into the "slots". Think of this as "Gadgets"
> in your personalized google home page (like server aware ActiveX
> objects in windows). Team A develops component "Role Based Menu", Team
> B writes ("Rich Text composer") etc. all of them server-aware
>
Nothing's stopping you from doing this, without separate compiled GWT
files.
You seem to misunderstand; you can use multiple separate MODULES just
fine; as long as there is only one entry point, the compilation
process produces one app, with one download. If your beef is that you
want to just insert the generated code straight into your web server's
file directory and skipping compilation, you have a point, but that
point isn't very convincing.
> 3. As usual, another team develops the core backend in Spring,
> Hibernate, EJB etc - supposed to be independent of presentation tier
>
Now you really misunderstand.
GWT is client side technology. It is fundamentally incompatible with
Hibernate, EJB, Spring, and all that jazz, as those are all server
side technologies. However, JAVASCRIPT can only communicate with 1
server at a time (namely, the server that fielded the page, this is
called 'domain restriction'. Thus you can't access apps from both a
Spring server and some other server unless they are running on the
same apache or you use server-side proxying. Either way, this is 100%
unrelated to GWT.
> 4. Then some one sews them up as required. This is the most important
> part of my logic: Conditional branching/redirection to a given page
> from a servlet.
An app is an app. Period. What, exactly, are you building here? An OS?
If there are a bunch of different, completely seperate things going
on, then, well, they are separate; and should have separate pages.
Either things go together, and thus probably share lots of development
ground, or they don't. The type ofapps that go together from a
presentation viewpoint but are utterly separate from a development
viewpoint are extremely rare, and if they do exist, GWT can facilitate
this easily; use one entry point with a number of separate modules
compiled into one, or, for interoperating with non-GWT stuff, use
setInnerHTML.
I get the distinct feeling you're dreaming up vast infrastructures for
something that is in essence much simpler. Get some experience first
before spending 6 months building loads of frameworks to make sure
you're flexible. In practice that leads to madness, INflexibility, and
maintainaince headaches.
Learn2FlyGWT
I understand your point: Create an application with composites. I
think that is the way to go. My argument is to integrate it with other
subsystems of that app (it can be a huge OS? what's wrong with
that :-) - if GWT can help realize that more easily than other
frameworks)
let me try to illustrate that with some use cases:
System: OS
SubSystems: Spreadsheets, Email, Online filemanagement,
What you have here is one big app called "OS". You write your
subsystems (each subsystem is somewhat like the kitchensink - with
lots of composites)
So you have SpreadSheet, Email and FileManagement separate GWT
applications.
So a user logs on writes spread sheet, and thinks (oh wow, let me mail
Sandy to feed my cat), so moves to Email subsystem to write a mail and
hits back button to his spread sheet.
(Note: Each subsystem - email, spreadsheet,filemgmt - opens up in a
separate url in the same domain)
I think GWT already supports this. And as you can see, we can create
disparate apps, sew them up into one big OS. That is my target.
The infrastructure is GWT. And i think building up something as large
as an OS might be possible with it.
Comments?
Thanks
Brill
Interesting, thats exactly what I'm doing as well,.. and the patch I
sent for the maven2 plugin handles generating the entrypoints.
- Brill
Brill
at one?
I don't know thats teh case, but it seems to me that if there is the
*potential* for referencing something that you don't need yet, then
you must have the code loaded.
So, for a 6 page app, for each page you have all 6 loaded.
When I started wondering about this, I noticed that Google itself uses
separate site for each of its tools... which is a good thing IMO for a
number of reasons not least of which is maintainability.
- Brill Pappin
On Mar 30, 12:04 am, "Reinier Zwitserloot" <reini...@gmail.com> wrote:
Brill
input on the lazy loading... it makes me feel better about the large
apps I'm working with... however I think your absolutely correct in
your assessment in terms project management and maintainability (which
I think is under valued in most shops).
Obviously whats needed is an in between solution that takes both
issues into account.
It might be possible to create multiple "sub sites" then call them
from a master site (being a maven user, this sounds very good to
me) .I don't see any problem doing that with the actual code, but
because the "public" portion of each app works the way it does, most
tools just don't take that kind of issue into account.
Interesting subject... it'll be interesting to see how things shake
out in my ow work.
- Brill Pappin
On Mar 30, 11:26 am, "Learn2FlyGWT" <skiddy.pou...@gmail.com> wrote:
> Reinier,
> Thanks for your reply.
>
> Creating composites and replacing them still loads the composite on
> the same HTML page. I understand how it can cut down on the bandwidth,
> but speaking from a project management and software engineering
> perspective combined for a VERY large project (i could be wrong), i
> would still like to have the flexibility of:
ext -
Brill
That's a good idea... we (or at least I) have overlooked the module
breakup of the different parts and gone with separate entrypoints
instead (time to reorganize things).
I took a quick look around and although there is fairly good
documentation on the modules, there seems to be a lot missing on what
thing *mean*.
Is there a good reference out there on the module files?
- Brill Pappin
Reinier Zwitserloot
Basically, you include another .gwt.xml file, and its <public>,
<stylesheet>, <source> and other tags get 'added' to the entry-
point .gwt.xml file (don't be fooled; even bare bones .gwt.xml files
have them, it's just that <source path="."> and <public path="public">
are automatically presumed; check the documentation on the gwt site
for the (by the way incomplete, but complete enough to figure this
stuff out) format of the .gwt.xml files.
Another caveat is that the GWT compiler needs to have SOURCE
DIRECTORIES in the classpath. This is very unjava; normally source is
irrelevant, only class files are. This may require you to do some
magic on i.e. your IDE's classpath settings.
including a.b.c.Foo will look for a/b/c/Foo.gwt.xml on the CLASSPATH,
and go from there.
I've done this multiple times now, and it's really an excellent GWT
strategy in general, because any unused code in a given module never
even makes it into the compiled result; GWT compilation strips out
unused bits very effectively. Thus, abstracting away just about
anything that seems nice to abstract away into a separate module is
always a good idea.
Learn2FlyGWT
for shifting our HUGE (i mean very HUGE) application to use GWT esp
due to the hurdles in keeping up the presentation logic (yes JSF is
nice but when demands are high for extreme client side interaction,
having to write cross-browser javascript manually sucks) with dynamic
client requirement changes (we follow agile).
>Brill said:
>When I started wondering about this, I noticed that Google itself uses
> separate site for each of its tools... which is a good thing IMO for a
> number of reasons not least of which is maintainability.
About that: Google points out that referencing a different domain from
one app may not accurately work (because browsers are trying to
prevent that for security reasons)
And thanks to Reinier for pointing out that GWT does efficiently strip
out unused bits. It is giving me more reasons to move forward.
I wonder what Bruce has to say about this. Since we are injecting a
relatively new technology in big apps, an assessment by someone who
more deeply understands the intricacies can save a lot of wasted
manhours and make/break commitment towards GWT.
Guys,
thanks for you input
>Reinier said:
> including a.b.c.Foo will look for a/b/c/Foo.gwt.xml on the CLASSPATH,
> and go from there.
I tested for:
a/Foo.gwt.xml
and
a/b/c/Foo.java
then in Foo.gwt.xml i over-rode the source path <source path=' .. (sub
folder)'/>. That worked. Which means, there is some (not the most
flexible i have to admit) of arranging the paths of the project
So you can have a pool of configs (gwt.xml) in one location and the
rest of the source of subapps pacakged in their sub folders.
Brill I am glad you like the idea of having sub-apps. I really do
think that part is mostly overlooked (maintainability and flexibility
of VERY big apps).
> > > point isn't very convincing.- Hide quoted text -