Aye aye;

To add to Ian's response, the module definition files do three things:

A) When you inherit any module.gwt.xml {say, com.example.util.A}, you
add access to all the source in that modules package, as if you used:
import com.example.util.*;  Note, this causes ALL static code calls in
the package to be executed.  Your app only NEEDS one entry point: The
one you tell the compiler to execute, like a main() function; after
that, EntryPoints are only needed when you want GWT to create a non-
static object of the EntryPoint class, and execute it's main
onModuleLoad method.  This is very useful if you want to make
Singletons, or "a single global object with private constructors and
non-static methods".  Sometimes, we build widgets that might break an
app if two were to be created {RootPanel, for example, must be
singular}, so we create a single instance {via onModuleLoad or
GWT.create}, store a static reference to that object, and call
RootPanel.get() to retrieve it.  This means we don't have to make
EVERYTHING static, just one object, and one method to retrieve that
object.

B) If the module has a defined EntryPoint, the app will add the code
in said EntryPoint's onModuleLoad to the bootstrap process.  THIS IS
VERY HANDY, as it is LIKE executing static code, because it gets
called when the script is added to the document, BUT IT IS NOT STATIC,
so it will get executed If and only if you choose a gwt.xml that says
<entry-point class="com.example.util.A"/>.  If you have some classes
that perform utility work regardless of whether you call onModuleLoad,
you can have gwt.xml without an EntryPoint to give you access to the
utilities, and multiple other gwt.xmls with EntryPoints that do a
specific set of non-required tasks, depending on how you want to
implement them. Say you have a package that does all your gui work,
and you want two versions: one for users, and one for developers.  By
having two gwt.xml module defs, you can compile the fastest, cleanest
code for user-production, and another one with debugging info and
extra tools for developers.  By changing with gwt.xml you inherit, you
can select branches of code to execute at compile time.  VERY nice!

finally,
c) Project Structure.  If you're building a single gwt project, go
ahead and put it all into a single module and do all your work in a
massive blob of code {please don't actually do that}, but if you want
modules that perform specific tasks that can be manually overridden,
tweaked or replaced, later on, you'll want to organize them into
groups.  For example, gwt puts all the ui code in a ui package and all
the event code in an event package; this way, if you don't want to use
it, just don't inherit from it.  In your own projects, you may need
some common widgets, like pop ups or decorated links, so feel free to
put them in a common package and inherit them everywhere.  BUT, if you
make a very special Widget, say...  A media player with a bunch of
images for buttons in an ImageBundle, gwt has to compile and recompile
those images on every build, whether you use them or not.  Putting
such widgets in their own package with their own module means when you
don't use them, the compiler doesn't have to look at them, and you
save time! {File size also benefits from this}.


With your first taste of gwt, don't worry too much about package
structure until you get used to deferred binding {replacing one class
with another}.  GWT is more powerful than java alone, because it lets
you break rules.  Like, a protected constructor, can't be made with
new MyObject(), but CAN be made with GWT.<MyObject>create
(MyObject.class);  It's a very powerful tool, and I wish you an
amazing journey of learning as you explore the depth and breadth of
its power.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to