Friday, September 3, 2010

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-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

No comments:

Post a Comment