GWT Module inheritance and entry point class
528 views
Skip to first unread message
sim123
May 12, 2009, 7:53:08 PM5/12/09
to Google Web Toolkit
I have two GWT modules A and B and where B is inheriting A. When I run
B application, GWT tries to load B.java and then A.java. I don't want
to load A.java. B uses A but it has it's own API, is there any way to
prevent loading of A via B, as I can not make any changes in A.
Thanks for all the help and support.
B application, GWT tries to load B.java and then A.java. I don't want
to load A.java. B uses A but it has it's own API, is there any way to
prevent loading of A via B, as I can not make any changes in A.
Thanks for all the help and support.
Ian Bambury
May 12, 2009, 8:24:06 PM5/12/09
to Google-We...@googlegroups.com
Have a module (*.gwt.xml) file for A that doesn't define an entry point and inherit that in the module file for B
Magius
May 13, 2009, 5:45:56 AM5/13/09
to Google Web Toolkit
If you want to use the module A separatly you can create a C module
with the EntryPoint from A.
On May 13, 2:24 am, Ian Bambury <ianbamb...@gmail.com> wrote:
> Have a module (*.gwt.xml) file for A that doesn't define an entry point and
> inherit that in the module file for B
> Ian
>
> http://examples.roughian.com
>
> 2009/5/13 sim123 <sim3...@gmail.com>
with the EntryPoint from A.
On May 13, 2:24 am, Ian Bambury <ianbamb...@gmail.com> wrote:
> Have a module (*.gwt.xml) file for A that doesn't define an entry point and
> inherit that in the module file for B
> Ian
>
> http://examples.roughian.com
>
Alyxandor
May 13, 2009, 7:22:10 AM5/13/09
to Google Web Toolkit
Aye, use deferred binding to override any direct references to the
code you want to include.
<replace-with class="B.newEntryPoint">
<when-type-is class="A.oldEntryPoint"/>
</replace-with>
Be careful of static fields that are auto initialized, and static code
blocks, as you CANNOT override these. Even if you never access the
static object, GWT must include all calls to static code, and will
only erase the notNeeded field.
static WastefulBlob notNeeded = someHugeBuilderMethod();
OR
static WastefulBlob notNeeded;
static{
notNeeded=someHugeBuilderMethod();
}
NOTE:
MONOLITHIC MODULES ARE Baaaaaad! All those "nice" static imports turn
into cl_init() functions, and any code referenced in those static
functions that AREN'T called in an overridable EntryPoint will become
unerasable and bloat your codebase forever... ...Trust me, I've
started over twice now, and I've got over 50 small modules that
FINALLY play nice with each other and the compiler.
Also, if you can, USE INTERFACES AS MUCH AS POSSIBLE. I know it's off
topic, but putting all your interfaces in a single module that is
inherited by all will reduce bloat tremendously, reduce the footprint
by reusing prototypes AND gives you the freedom to connect and
disconnect modules by simply changing how you implement your
interfaces. Plus, you will always have a central module to toggle <!--
set-property name="user.agent" value="gecko1_8"/--> to target your
builds to a specific browser whilst debugging and cut compile time in
half.
code you want to include.
<replace-with class="B.newEntryPoint">
<when-type-is class="A.oldEntryPoint"/>
</replace-with>
Be careful of static fields that are auto initialized, and static code
blocks, as you CANNOT override these. Even if you never access the
static object, GWT must include all calls to static code, and will
only erase the notNeeded field.
static WastefulBlob notNeeded = someHugeBuilderMethod();
OR
static WastefulBlob notNeeded;
static{
notNeeded=someHugeBuilderMethod();
}
NOTE:
MONOLITHIC MODULES ARE Baaaaaad! All those "nice" static imports turn
into cl_init() functions, and any code referenced in those static
functions that AREN'T called in an overridable EntryPoint will become
unerasable and bloat your codebase forever... ...Trust me, I've
started over twice now, and I've got over 50 small modules that
FINALLY play nice with each other and the compiler.
Also, if you can, USE INTERFACES AS MUCH AS POSSIBLE. I know it's off
topic, but putting all your interfaces in a single module that is
inherited by all will reduce bloat tremendously, reduce the footprint
by reusing prototypes AND gives you the freedom to connect and
disconnect modules by simply changing how you implement your
interfaces. Plus, you will always have a central module to toggle <!--
set-property name="user.agent" value="gecko1_8"/--> to target your
builds to a specific browser whilst debugging and cut compile time in
half.
sim123
May 13, 2009, 1:20:45 PM5/13/09
to Google Web Toolkit
Thanks for reply, it worked. I could call service layer of module A
without loading the entry point class. I would appreciate if you could
help me understand how does it works, for example my application name
is "Test" so I have Test.gwt.xml in com.user.sim.test package. I
create another file exactly same as Test.gwt.xml and rename it to
A.gwt.xml. This A.gwt.xml does not have an entry-point class. I
inherit A.gwt.xml in another GWT application B. So how does the
compiler figure out what is A and A.gwt.xml is associated with
Test.html ?
Thanks for the help.
On May 12, 5:24 pm, Ian Bambury <ianbamb...@gmail.com> wrote:
> Have a module (*.gwt.xml) file for A that doesn't define an entry point and
> inherit that in the module file for B
> Ian
>
> http://examples.roughian.com
>
> 2009/5/13 sim123 <sim3...@gmail.com>
without loading the entry point class. I would appreciate if you could
help me understand how does it works, for example my application name
is "Test" so I have Test.gwt.xml in com.user.sim.test package. I
create another file exactly same as Test.gwt.xml and rename it to
A.gwt.xml. This A.gwt.xml does not have an entry-point class. I
inherit A.gwt.xml in another GWT application B. So how does the
compiler figure out what is A and A.gwt.xml is associated with
Test.html ?
Thanks for the help.
On May 12, 5:24 pm, Ian Bambury <ianbamb...@gmail.com> wrote:
> Have a module (*.gwt.xml) file for A that doesn't define an entry point and
> inherit that in the module file for B
> Ian
>
> http://examples.roughian.com
>
Ian Bambury
May 13, 2009, 2:33:20 PM5/13/09
to Google-We...@googlegroups.com
Hi,
It does what it is told! (The big advantage and the big disadvantage of computers :-))
One of the big disadvantages of the application creators so far is that they call everything the same and you can't work out some of the stranger relationships.
If the GWT named things better, a lot of confusion would be avoided, e.g. the project could be called MyProject (or whatever the programmer puts in) and the module file could be called MyProjectModuleFile.gwt.xml plus MyProjectEntryPointFile etc. It would be *so* much simpler for people starting out.
Anyway, to answer the question - the module file (*.gwt.xml) can be called anything.gwt.xml. Nothing tries to guess what it is by concatenating the project name and '.gwt.xml'
So you can have any number of them, all valid. Not that you'd ever need many.
The compiler starts off with the top-level *.gwt.xml file and just cascades down into other module files if it is told to (via an 'inherits' tag).
Just to repeat: there is no requirement to name the module file after the project name (or anything else).
In your case, it uses A.gwt.xml because you have a line in B.gwt.xml telling it to.
HTH, if not, just say.
Alyxandor
May 13, 2009, 10:39:48 PM5/13/09
to Google Web Toolkit
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.
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.
Reply all
Reply to author
Forward
0 new messages