Re: Separate modules for separate views?
Instead of using multiple modules you can also used a single module. For your views you create an implementation for each role that your application requires. For example: CatalogView CatalogViewAdminImpl CatalogViewEnduserImpl The you use deferred binding to pick the right implementation. This will have the added benefit that the module will be split by the compiler. Each permutation will only contain the controls that are used by its implementations. So, if you have alot of extra control for the Admin role they won't bleed into the Enduser role. Downside is that the compile time scales linear with each role that you add. With 2 roles you will already compile 10 permutations with the standard settings. I guess, it's the same for multiple modules though. You also have to make sure, to recheck the user's roles on the server since it's rather trivial to trick the UI to display the admin role. On Sep 3, 11:52 am, Thomas Broyer t.bro...@gmail.com wrote: On Sep 3, 2:33 am, Riley rileyl...@gmail.com wrote: Naturally, though I'd been looking for these answers for an hour before I posted here, I discovered that if I used the google plugin to create a new HTML page, it automatically configured whatever it needs to configure to support two separate HTML pages with different modules different entry points. It seems to be working. My only remaining question, then, is whether I'm right about how the compiler works. To rephrase: I have two modules, side by side in the same directory. They both have the client and shared directories as source. If module B hardly references any of the code in these folders, will the final module B compiled JS omit the unused code? Yes (just like it won't output code for, say, TabLayoutPanel, if you don't use it, but still use other widgets in the same package). I would however, for clearer/cleaner separation, make a Shared module and have A and B both inherit Shared, and put A's EntryPoint (and some or all other A-specific code) in a separate package from B's EntryPoint (which would live in a separator package than the Shared code). -- 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-tool...@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.
Re: Fewer compile permutations using ant: Can user.agent be passed in via command-line?
Hi Anders,
We use seperate modules for each compile mode. Then we pass a
parameter into the build file to make it pick up the different
modules.
For example:
TachyonField.gwt.xml - Contains all common settings but no
entrypoint
TachyonField_dev.gwt.xml - Inherits the base module and adds
entrypoint definition and development settings
TachyonField_prod.gwt.xml - Inherits base + production settings
This is handy for defining different log levels, supported user agents
and obfuscation settings. It would look something like this:
TachyonField.gwt.xml
module
inherits name='com.google.gwt.user.User'/
inherits name=com.google.gwt.inject.Inject/
/module
TachyonField_dev.gwt.xml
module rename-to=tachyonfield
inherits name='com.enterprise.TachyonField'/
inherits name=com.allen_sauer.gwt.log.gwt-log /
extend-property name=log_level values=TRACE /
set-property name=log_level value=TRACE /
set-property name=user.agent value=gecko1_8 /
set-configuration-property name=CssResource.style
value=pretty /
entry-point class='com.enterprise.TachyonField'/
/module
TachyonField_prod.gwt.xml
module rename-to=tachyonfield
inherits name='com.enterprise.TachyonField'/
inherits name=com.allen_sauer.gwt.log.gwt-log /
extend-property name=log_level values=ERROR /
set-property name=log_level value=ERROR /
entry-point class='com.enterprise.TachyonField'/
/module
Then in the build file you can init your settings depending on the
passed in parameter ${build.gwt.options.isproduction}. For this
example I also pass in the name of the module as ${build.gwt.module}.
In real life we use a small groovy script to find all modules with
entrypoints in them:
build.xml
...
target name=init depends=init-builds, init-production, init-
development /
target name=init-builds
condition property=production.build
equals arg1=${build.gwt.options.isproduction} arg2=true /
/condition
condition property=development.build
not
isset property=production.build/
/not
/condition
/target
target name=init-production if=production.build
echo message=Using production settings/
property name=gwt.module value=${build.gwt.module}
_prod.gwt.xml/
property name=gwt.logLevel value=TRACE/
property name=gwt.style value=OBFUSCATED/
property name=gwt.additionalArgs value=/
property name=gwt.localWorkers value=4/
/target
target name=init-development if=development.build
echo message=Using development settings/
property name=gwt.module value=${build.gwt.module}
_dev.gwt.xml/
property name=gwt.logLevel value=TRACE/
property name=gwt.style value=PRETTY/
property name=gwt.localWorkers value=2/
property name=gwt.additionalArgs value=-draftCompile/
/target
target name=compile depends=init
java classname=com.google.gwt.dev.Compiler fork=true
failonerror=true
jvmarg value=-Xms256m /
jvmarg value=-Xmx512m /
arg value=-war /
arg value=${build.gwt} /
arg value=-gen /
arg value=${build.gen} /
arg value=-extra /
arg value=${build.extra} /
arg value=-logLevel /
arg value=${gwt.logLevel} /
arg value=-style /
arg value=${gwt.style} /
arg value=${gwt.additionalArgs} /
arg value=-localWorkers /
arg value=${gwt.localWorkers} /
arg value=@{gwt.module} /
/java
/target
...
This way we can build different versions for local development and
production environment. This makes local builds very fast and you get
all the convenience from the debugging and logging settings. On
production the code is minimized and logging is reduced to a minimum.
Hope this helps,
Michael
--
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-tool...@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.
