General question about project architecture.
162 views
Skip to first unread message
David C. Hicks
Nov 12, 2009, 5:26:38 PM11/12/09
to GWT Users
Specifically, I'm curious about the use of GWT Modules in a project.
Each time we have a new "screen" to create, we have been adding a new
module to our project. Of course, with each new module, there is an
additional build cycle to generate the Javascript for that module. What
I'm wondering is if this is normal, or does it make more sense to try to
build up whole applications in a single module and perhaps keep the
build time down? Each new module we add appears to increase our build
time by about 1.5 minutes. It won't be long and this will be way beyond
painful.
Any thoughts?
Thanks,
Dave
Each time we have a new "screen" to create, we have been adding a new
module to our project. Of course, with each new module, there is an
additional build cycle to generate the Javascript for that module. What
I'm wondering is if this is normal, or does it make more sense to try to
build up whole applications in a single module and perhaps keep the
build time down? Each new module we add appears to increase our build
time by about 1.5 minutes. It won't be long and this will be way beyond
painful.
Any thoughts?
Thanks,
Dave
Sripathi Krishnan
Nov 14, 2009, 6:50:22 AM11/14/09
to google-we...@googlegroups.com
Multiple modules is the wrong way to use GWT.
GWT highly recommends using a single module. Most of the performance optimizations GWT does relies on the fact that you have a single, monolithic module. Plus, as you observed, the time to build your application keeps growing as you add more modules, so it doesn't scale well.
Part of the problem is deciding whether you are building a "Web App" or a "Web Site". Lots of discussions can be found on this topic.
GWT is great if you want to build a Web App. Typically, there is only a single HTML page, and different "screens" are manipulated on the client side using DOM. But if you are building a traditional, multi-page Web Site (nothing wrong with that), then GWT is not for you. You are better off using one of the many javascript libraries.
So, lets assume you decide you want to build a web-app, and want to use GWT to do so. To get started, stick to a single HTML page with a single GWT Module/Entry Point. Adding multiple "screens" is adding a new FlowPanel or Composite with your content. Or perhaps, you have all "screens" built into the original HTML page, and you just hide/unhide the divs based on user action.
The above approach works well if you have a few (say less than 10) screens. If your application grows bigger and more complex, you would want to start following some established patterns. The MVP pattern has been touted as the "way to build web-apps". Just do a google search, there are a lot of articles on that subject. Also, catch Ray Ryan's talk on GWT Architecture and best practices.
--Sri
GWT highly recommends using a single module. Most of the performance optimizations GWT does relies on the fact that you have a single, monolithic module. Plus, as you observed, the time to build your application keeps growing as you add more modules, so it doesn't scale well.
Part of the problem is deciding whether you are building a "Web App" or a "Web Site". Lots of discussions can be found on this topic.
GWT is great if you want to build a Web App. Typically, there is only a single HTML page, and different "screens" are manipulated on the client side using DOM. But if you are building a traditional, multi-page Web Site (nothing wrong with that), then GWT is not for you. You are better off using one of the many javascript libraries.
So, lets assume you decide you want to build a web-app, and want to use GWT to do so. To get started, stick to a single HTML page with a single GWT Module/Entry Point. Adding multiple "screens" is adding a new FlowPanel or Composite with your content. Or perhaps, you have all "screens" built into the original HTML page, and you just hide/unhide the divs based on user action.
The above approach works well if you have a few (say less than 10) screens. If your application grows bigger and more complex, you would want to start following some established patterns. The MVP pattern has been touted as the "way to build web-apps". Just do a google search, there are a lot of articles on that subject. Also, catch Ray Ryan's talk on GWT Architecture and best practices.
--Sri
2009/11/13 David C. Hicks <dhi...@i-hicks.org>
--
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=.
rjcarr
Nov 14, 2009, 4:03:22 PM11/14/09
to Google Web Toolkit
Great explanation Sri, I just wanted to add that you could also do
both.
In my project, I have two GWT entry points (and about 5 GWT modules
for sharing / reuse), but I also have another 4-5 "regular" web pages
with static content.
You need to decide the portions of your site that require the
dynanicism of GWT and the portions that will suffice with plain old
HTML. Mostly likely, only a small portion of your site will require
GWT.
On Nov 14, 3:50 am, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:
> > .
both.
In my project, I have two GWT entry points (and about 5 GWT modules
for sharing / reuse), but I also have another 4-5 "regular" web pages
with static content.
You need to decide the portions of your site that require the
dynanicism of GWT and the portions that will suffice with plain old
HTML. Mostly likely, only a small portion of your site will require
GWT.
On Nov 14, 3:50 am, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:
> Multiple modules is the wrong way to use GWT.
>
> GWT highly recommends using a single module. Most of the performance
> optimizations GWT does relies on the fact that you have a single, monolithic
> module. Plus, as you observed, the time to build your application keeps
> growing as you add more modules, so it doesn't scale well.
>
> Part of the problem is deciding whether you are building a "Web App" or a
> "Web Site". Lots of
> discussions<http://www.clyral.com/za/pages/web/website_vs_webapplication.html>can
>
> GWT highly recommends using a single module. Most of the performance
> optimizations GWT does relies on the fact that you have a single, monolithic
> module. Plus, as you observed, the time to build your application keeps
> growing as you add more modules, so it doesn't scale well.
>
> Part of the problem is deciding whether you are building a "Web App" or a
> "Web Site". Lots of
> be found on this topic.
>
> GWT is great if you want to build a Web App. Typically, there is only a
> single HTML page, and different "screens" are manipulated on the client side
> using DOM. But if you are building a traditional, multi-page Web Site
> (nothing wrong with that), then GWT is not for you. You are better off using
> one of the many javascript libraries.
>
> So, lets assume you decide you want to build a web-app, and want to use GWT
> to do so. To get started, stick to a single HTML page with a single GWT
> Module/Entry Point. Adding multiple "screens" is adding a new FlowPanel or
> Composite with your content. Or perhaps, you have all "screens" built into
> the original HTML page, and you just hide/unhide the divs based on user
> action.
>
> The above approach works well if you have a few (say less than 10) screens.
> If your application grows bigger and more complex, you would want to start
> following some established patterns. The MVP pattern has been touted as the
> "way to build web-apps". Just do a google search, there are a lot of
> articles on that subject. Also, catch Ray Ryan's talk on GWT Architecture
> and best practices<http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPr...>.
>
> GWT is great if you want to build a Web App. Typically, there is only a
> single HTML page, and different "screens" are manipulated on the client side
> using DOM. But if you are building a traditional, multi-page Web Site
> (nothing wrong with that), then GWT is not for you. You are better off using
> one of the many javascript libraries.
>
> So, lets assume you decide you want to build a web-app, and want to use GWT
> to do so. To get started, stick to a single HTML page with a single GWT
> Module/Entry Point. Adding multiple "screens" is adding a new FlowPanel or
> Composite with your content. Or perhaps, you have all "screens" built into
> the original HTML page, and you just hide/unhide the divs based on user
> action.
>
> The above approach works well if you have a few (say less than 10) screens.
> If your application grows bigger and more complex, you would want to start
> following some established patterns. The MVP pattern has been touted as the
> "way to build web-apps". Just do a google search, there are a lot of
> articles on that subject. Also, catch Ray Ryan's talk on GWT Architecture
>
> --Sri
>
> 2009/11/13 David C. Hicks <dhi...@i-hicks.org>
>
>
>
> > Specifically, I'm curious about the use of GWT Modules in a project.
>
> > Each time we have a new "screen" to create, we have been adding a new
> > module to our project. Of course, with each new module, there is an
> > additional build cycle to generate the Javascript for that module. What
> > I'm wondering is if this is normal, or does it make more sense to try to
> > build up whole applications in a single module and perhaps keep the
> > build time down? Each new module we add appears to increase our build
> > time by about 1.5 minutes. It won't be long and this will be way beyond
> > painful.
>
> > Any thoughts?
> > Thanks,
> > Dave
>
> > --
>
> > 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<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> --Sri
>
> 2009/11/13 David C. Hicks <dhi...@i-hicks.org>
>
>
>
> > Specifically, I'm curious about the use of GWT Modules in a project.
>
> > Each time we have a new "screen" to create, we have been adding a new
> > module to our project. Of course, with each new module, there is an
> > additional build cycle to generate the Javascript for that module. What
> > I'm wondering is if this is normal, or does it make more sense to try to
> > build up whole applications in a single module and perhaps keep the
> > build time down? Each new module we add appears to increase our build
> > time by about 1.5 minutes. It won't be long and this will be way beyond
> > painful.
>
> > Any thoughts?
> > Thanks,
> > Dave
>
> > --
>
> > 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
> > .
David C. Hicks
Nov 15, 2009, 11:21:58 AM11/15/09
to google-we...@googlegroups.com
Thanks for the replies, guys, and yes that's a great explanation!
We're very new to GWT. So, clearly we're learning these ins and outs.
Unfortunately, we started with a Struts2-based application, and we're only adding new "screens" in GWT as they come up. I'll have to think about it, but it's kind of hard to see, right now, how I can consolidate those into a single module. I definitely can see the benefits, now that you've explained it, though.
Thanks again,
Dave
rjcarr wrote:
Unfortunately, we started with a Struts2-based application, and we're only adding new "screens" in GWT as they come up. I'll have to think about it, but it's kind of hard to see, right now, how I can consolidate those into a single module. I definitely can see the benefits, now that you've explained it, though.
Thanks again,
Dave
rjcarr wrote:
. 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=.
rolf
Nov 14, 2009, 8:24:22 AM11/14/09
to Google Web Toolkit
What's the best way to create a web app with multiple entry points but
a lot of common code (eg. common widgets and dialogs) shared between
them, as well as a common server back end? Currently I'm creating
multiple modules and multiple HTML pages within a single web app but
I'm also worried about scalability. The different entry points
correspond to different workflows depending on what the user is trying
to do, or perhaps customised versions of the interface for particular
customers.
I guess I should probably have a single module and top level entry
point and then switch between interfaces from there but that will
involve a lot of code refactoring.
-Rolf
On Nov 14, 11:50 am, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:
> > .
a lot of common code (eg. common widgets and dialogs) shared between
them, as well as a common server back end? Currently I'm creating
multiple modules and multiple HTML pages within a single web app but
I'm also worried about scalability. The different entry points
correspond to different workflows depending on what the user is trying
to do, or perhaps customised versions of the interface for particular
customers.
I guess I should probably have a single module and top level entry
point and then switch between interfaces from there but that will
involve a lot of code refactoring.
-Rolf
On Nov 14, 11:50 am, Sripathi Krishnan <sripathi.krish...@gmail.com>
wrote:
> Multiple modules is the wrong way to use GWT.
>
> GWT highly recommends using a single module. Most of the performance
> optimizations GWT does relies on the fact that you have a single, monolithic
> module. Plus, as you observed, the time to build your application keeps
> growing as you add more modules, so it doesn't scale well.
>
> Part of the problem is deciding whether you are building a "Web App" or a
> "Web Site". Lots of
> discussions<http://www.clyral.com/za/pages/web/website_vs_webapplication.html>can
>
> GWT highly recommends using a single module. Most of the performance
> optimizations GWT does relies on the fact that you have a single, monolithic
> module. Plus, as you observed, the time to build your application keeps
> growing as you add more modules, so it doesn't scale well.
>
> Part of the problem is deciding whether you are building a "Web App" or a
> "Web Site". Lots of
> be found on this topic.
>
> GWT is great if you want to build a Web App. Typically, there is only a
> single HTML page, and different "screens" are manipulated on the client side
> using DOM. But if you are building a traditional, multi-page Web Site
> (nothing wrong with that), then GWT is not for you. You are better off using
> one of the many javascript libraries.
>
> So, lets assume you decide you want to build a web-app, and want to use GWT
> to do so. To get started, stick to a single HTML page with a single GWT
> Module/Entry Point. Adding multiple "screens" is adding a new FlowPanel or
> Composite with your content. Or perhaps, you have all "screens" built into
> the original HTML page, and you just hide/unhide the divs based on user
> action.
>
> The above approach works well if you have a few (say less than 10) screens.
> If your application grows bigger and more complex, you would want to start
> following some established patterns. The MVP pattern has been touted as the
> "way to build web-apps". Just do a google search, there are a lot of
> articles on that subject. Also, catch Ray Ryan's talk on GWT Architecture
> and best practices<http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPr...>.
>
> GWT is great if you want to build a Web App. Typically, there is only a
> single HTML page, and different "screens" are manipulated on the client side
> using DOM. But if you are building a traditional, multi-page Web Site
> (nothing wrong with that), then GWT is not for you. You are better off using
> one of the many javascript libraries.
>
> So, lets assume you decide you want to build a web-app, and want to use GWT
> to do so. To get started, stick to a single HTML page with a single GWT
> Module/Entry Point. Adding multiple "screens" is adding a new FlowPanel or
> Composite with your content. Or perhaps, you have all "screens" built into
> the original HTML page, and you just hide/unhide the divs based on user
> action.
>
> The above approach works well if you have a few (say less than 10) screens.
> If your application grows bigger and more complex, you would want to start
> following some established patterns. The MVP pattern has been touted as the
> "way to build web-apps". Just do a google search, there are a lot of
> articles on that subject. Also, catch Ray Ryan's talk on GWT Architecture
>
> --Sri
>
> 2009/11/13 David C. Hicks <dhi...@i-hicks.org>
>
>
>
> > Specifically, I'm curious about the use of GWT Modules in a project.
>
> > Each time we have a new "screen" to create, we have been adding a new
> > module to our project. Of course, with each new module, there is an
> > additional build cycle to generate the Javascript for that module. What
> > I'm wondering is if this is normal, or does it make more sense to try to
> > build up whole applications in a single module and perhaps keep the
> > build time down? Each new module we add appears to increase our build
> > time by about 1.5 minutes. It won't be long and this will be way beyond
> > painful.
>
> > Any thoughts?
> > Thanks,
> > Dave
>
> > --
>
> > 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<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> --Sri
>
> 2009/11/13 David C. Hicks <dhi...@i-hicks.org>
>
>
>
> > Specifically, I'm curious about the use of GWT Modules in a project.
>
> > Each time we have a new "screen" to create, we have been adding a new
> > module to our project. Of course, with each new module, there is an
> > additional build cycle to generate the Javascript for that module. What
> > I'm wondering is if this is normal, or does it make more sense to try to
> > build up whole applications in a single module and perhaps keep the
> > build time down? Each new module we add appears to increase our build
> > time by about 1.5 minutes. It won't be long and this will be way beyond
> > painful.
>
> > Any thoughts?
> > Thanks,
> > Dave
>
> > --
>
> > 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
> > .
Sripathi Krishnan
Nov 15, 2009, 11:40:26 PM11/15/09
to google-we...@googlegroups.com
I guess I should probably have a single module and top level entry
point and then switch between interfaces from there but that will
involve a lot of code refactoring.
I am assuming have 3 entry point classes corresponding to 3 modules, each of which is included in a separate HTML host page. Each module is a separate workflow. [The exact number doesn't matter].
- Get rid of all the modules(workflow A, through C), but keep the java classes implementing EntryPoint as-is.
- Next, create a new module, say we call it parent-workflow.
- In the onModuleLoad() of parent-workflow, figure out which workflow (A, B or C) to load, and then just delegate to the onModuleLoad() of the appropriate child workflow. [Of course, it doesn't have to be onModuleLoad() - but we are reusing it because of the high refactoring cost].
How do you figure out which child workflow to load? Append a fragment identifier to the URLs (#workflowA), and use History.getToken() to make the decision in the onModuleLoad() method of the new
If your original urls were like this -
http://mydomain.com/workflowA.html, http://mydomain.com/workflowB.html, http://mydomain.com/workflowC.html
they will now become -
http://mydomain.com/parent-workflow.html#workflowA, http://mydomain.com/parent-workflow.html#workflowB, http://mydomain.com/parent-workflow.html#workflowC
This way, control will always go to the single, top-level module, and from there you decide which workflow to load. Plus, it gives you history management and back button support.
Notice that you have got rid of 3 HTML files, 3 *.gwt.xml files, and in due course - 3 EntryPoint classes. And since there is only one entry point, your compilation is a lot faster, it is easier to share common widgets, and you get more optimized javascript code.
This is the least intrusive way to get to a single module. With time, you can figure out different strategies to map the history token to the appropriate workflow. You can also refactor your code to get rid of the additional EntryPoint classes, and come up with your own interface to define a workflow (or screen or page or whatever you want to call it).
Once you get a hang of the basic idea, read the MVP pattern. Go through Ray Ryans presentation. That will give you more ammunition to better design your application.
--Sri
2009/11/14 rolf <ro...@squarebox.co.uk>
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
Davis Ford
Nov 16, 2009, 8:36:49 AM11/16/09
to google-we...@googlegroups.com
I'm doing this now. I set the project up this way several months ago and it works great for me. The only real con is double compile-time, but I don't care about that. I even have a feature where I can show a view of one application inside another, which is very cool.
--
Zeno Consulting, Inc.
home: http://www.zenoconsulting.biz
blog: http://zenoconsulting.wikidot.com
p: 248.894.4922
f: 313.884.2977
Here's how I set it up -- http://zenoconsulting.wikidot.com/blog:16
Davis
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
--
Zeno Consulting, Inc.
home: http://www.zenoconsulting.biz
blog: http://zenoconsulting.wikidot.com
p: 248.894.4922
f: 313.884.2977
Carl
Dec 23, 2009, 10:16:00 AM12/23/09
to Google Web Toolkit
You might want to look at this article:
http://claudiushauptmann.com/a-framework-for-gwt-multipage-applications.html
http://claudiushauptmann.com/a-framework-for-gwt-multipage-applications.html
> > > > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com><google-web-toolkit%2Bunsubs
> > cr...@googlegroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/google-web-toolkit?hl=.
>
> > --
>
> > 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<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=.
>
> --
Reply all
Reply to author
Forward
0 new messages