GWT project with multiple pages
290 views
Skip to first unread message
zep
Mar 12, 2009, 4:47:34 AM3/12/09
to Google Web Toolkit
Hello!
My question is perhaps not so relevant for Ajax applications, but for
various reasons (including CMS), I would like to have a GWT
application with multiple pages. What is the best way to do this? I
have thought to have a GWT module for each page, but wonder if it is
practical? Grateful for your answers!
My question is perhaps not so relevant for Ajax applications, but for
various reasons (including CMS), I would like to have a GWT
application with multiple pages. What is the best way to do this? I
have thought to have a GWT module for each page, but wonder if it is
practical? Grateful for your answers!
Magius
Mar 13, 2009, 6:12:47 AM3/13/09
to Google Web Toolkit
I had this problem some months ago.
I had several pages in the same project (GWT 1.4), sharing services,
code and images.
The first approach was to create several modules, but each module had
to be compiled separately.
The problem was that the whole compilation took num-modules times more
than a single compilation.
And the static contents (/public folder) were repeated num-modules
times.
Finally I moved to a single module approach with several EntryPoints.
Each EntryPoint had a 'name' (Java constant): "Module1",
"Module2", ....
And each HTML page had a corresponding title: "Module1",
"Module2", ...
When opening an HTML page, all the EntryPoints are fired and each of
them checks the HTML title against its name, and only the EntryPoint
associated with the page begins to generate its panels.
With a bit of OOP it's easy to implement.
This was the only solution I found in case of:
- several HTMLs, each for one specific form
- almost all the code and images shared between forms
And the benefits:
- Only 1 compilation (4 minutes).
- Only 1 copy of static contents (images, etc).
I had several pages in the same project (GWT 1.4), sharing services,
code and images.
The first approach was to create several modules, but each module had
to be compiled separately.
The problem was that the whole compilation took num-modules times more
than a single compilation.
And the static contents (/public folder) were repeated num-modules
times.
Finally I moved to a single module approach with several EntryPoints.
Each EntryPoint had a 'name' (Java constant): "Module1",
"Module2", ....
And each HTML page had a corresponding title: "Module1",
"Module2", ...
When opening an HTML page, all the EntryPoints are fired and each of
them checks the HTML title against its name, and only the EntryPoint
associated with the page begins to generate its panels.
With a bit of OOP it's easy to implement.
This was the only solution I found in case of:
- several HTMLs, each for one specific form
- almost all the code and images shared between forms
And the benefits:
- Only 1 compilation (4 minutes).
- Only 1 copy of static contents (images, etc).
Vitali Lovich
Mar 13, 2009, 6:56:50 AM3/13/09
to Google-We...@googlegroups.com
Why have multiple entry points? Why not just the one that decides which code to run?
Magius
Mar 13, 2009, 7:14:23 AM3/13/09
to Google Web Toolkit
One Abstract EntryPoint with a child EntryPoint for each form was OOP-
nicer,
but only one EntryPoint with a 'switch-case' will do the job.
On Mar 13, 11:56 am, Vitali Lovich <vlov...@gmail.com> wrote:
> Why have multiple entry points? Why not just the one that decides which
> code to run?
>
nicer,
but only one EntryPoint with a 'switch-case' will do the job.
On Mar 13, 11:56 am, Vitali Lovich <vlov...@gmail.com> wrote:
> Why have multiple entry points? Why not just the one that decides which
> code to run?
>
Vitali Lovich
Mar 13, 2009, 1:00:38 PM3/13/09
to Google-We...@googlegroups.com
It seems like deferred binding would be a better approach from a whole number of perspectives (although I'm not sure if you can define a custom pivot point that's not based on user-agent or localization).
If you can figure out a way, you'll get performance benefits (compilation-time determination of which module to use) & cleaner code (modules don't have to filter - it'll be done by GWT.create at compile-time). The trick is that the title on the HTML page isn't available to the GWT compiler.
On the other hand, it will slow down your compilation by num pivot points again.
Trade-offs, trade-offs.
If you can figure out a way, you'll get performance benefits (compilation-time determination of which module to use) & cleaner code (modules don't have to filter - it'll be done by GWT.create at compile-time). The trick is that the title on the HTML page isn't available to the GWT compiler.
On the other hand, it will slow down your compilation by num pivot points again.
Trade-offs, trade-offs.
Reply all
Reply to author
Forward
0 new messages