Can I define two 'entry point' in a single MyPage.gwt.xml file

[Ren]

Is it legal to define morn than one 'entry point' in a single
MyPage.gwt.xml file?

If that's not the case, then I shall have MyPage1.gwt.xml ,
MyPage2.gwt.xml right?
However, in the GWT compiler, you only supply one module (such as
com.mycompany.MyPage1) as the argument, how do I compile every module
into javascript?

[oli]

Hi Ren,

you can create one module which inherits another (all of them could
have entry points). So you have for example: "layout " module which is
inherited by "main" module. When you compile main module, the layout
module will be compiled too. And of course all entry points will be
executed. Only thing you must do is to add this line to your main
module gwt.xml file:

<inherits name="my.package.Layout" />

Regards
Jacek Olszak
http://rubynetwork.svnrepository.com/ajaxdevelopersuite/trac.cgi

[Ren]

Hi oli,
Thanks for replying, and thanks for letting me know about the module
inheritance. However, I'm still not quite sure what to do yet.

I have two pages, view_order.html and order_form.html, at the
momenet, they are in two modules, com.mycompany.ViewOrder and
com.mycompany.OrderForm.

If I get OrderForm to inherits ViewOrder, that will probably work but
is that nice and clear?
Also, what if I want to add another page called
'edit_personal_detail.html', should this inherit OrderForm?

[oli]

Hi Ren,

I have misunderstood you. I though that you want to have a page with
multiple entry points. But as you said in last message, you only need a
way to compile all files at once. I think that it is only possible to
compile every module singly (but always you can create a batch file
which run compiler couple of times)

Regards
Jacek

[bjorn]

Hi Ren

I we've just decided to go for GWT for a similar app, with entry
"screens" for similar things (view order, edit order, edit user prefs
etc.) I think there are good reasons to use only one entry point for
the whole application, and use one of the following ways (or
combinations thereof -- we're still prototyping) to switch between the
view/edit/userprefs "screens":

1. replacing all widgets in the Root:
The widgets in the Root panel (see the Root class) can be added and
removed dynamically while running the application. By replacing all
widgets in the Root panel, you give the user the impression that the
whole application "changed screen". This without having to do a full
page reload in the browser, thus retaining the local state of the
application (data which you might have brought in via RPC to the
server, the utterly useful History stack, plus your UI widgets
themselves)

2. Use tabs in the Root
Another possibility is to use tabs in the Root panel (just like the
KitchenSink example). This way, the user can immediately access the
"screens" available and the user will very easily see which screen
he/she is currently viewing (as indicated by the selected tab).
Switching between screens is very fast (the tabs can even have keyboard
shortcuts me thinks). While being elegant, there are some things to
think about though:
- keeping any data common to more than one "screen" in sync (if the
user changes the font size in the preferences tab, is this then
refreshed in the other screens? Guess this can be solved by using
listeners on changes to the "preferences" data model objects, or
refreshing the data in the other screen when the user selects that tab
(using a TabListener)).
- uses more space in the browser window, certainly something that we
will have to think about since our app is going to live inside of a
frameset... :-)

3. Dynamically change the state of the entry widgets
Switching between view and edit mode could probably also be done by
changing the "enabled" property of all of the entry widgets (text entry
fields, drop down lists etc) This would mean traversing the Widget tree
and calling #setEnabled() on each instanceof FocusWidget. This is
typically what you would do in a thick client (Swing app), haven't
tried this in GWT though but my guess is that it will work as expected.

Happy GWT:ing, many thanks Google for sharing this stuff and specially
for the quick responses in the forum cheers Björn

[Ren]

Firstly, thank for oli's help.

Secondly, thanks for bjorn's detailed discussion. Because all samples
shipped with GWT SDK have only one entry point, I think GWT developers
probably want us to only have only one entry point and change the page
content inside the root panel, rather than going to a different URL.

I actually thought about replacing all widgets in the Root, but
there're a couple of issues with this.

1. We will have to create the whole page with Swing-style Java code,
(something like panel.add(button), table.add(label, 1, 2), etc) This
isn't quite efficient (That's why IDEs enable you to drag and drop to
design Swing GUIs.) I think my manager (not me) would prefer to design
the web page in Dreamweaver and put place holders, I will then populate
widgets in GWT.

2. We need some kind of template mechanisms. One of our existing
application was built on Spring MVC and Tiles, Tiles makes it so easy
to have a unique look and feel throughout the website. but if we
replace Root panel for each page, we probably need to design some kind
of our own root panel which defines the look and feel of the website,
and other subpanels might extend that panel, this could cause some
extra coding as well.

Have you decide your strategy yet bjon?

[Ren]

I actually realised another issue with GWT and single entry point for
all pages, it's about security.

So if I have some pages for client user and some functions for admin
users, how do I make sure the client user cannot access admin
functions?

What I did with my current Spring MVC app is giving URL prefix, so a
client action might have URL http://mycompany/client/view_order.do and
an admin action will have URL http://mycompany/admin/disable_user.do, I
can easily setup a filter which blocks any request to /admin/xxxx.do
from a client user.

In a GWT application, I think I cannot put client actions and admin
actions into a single entry point, because even I can hide the admin
panel for a client user, but it will still be in the javascript, IT IS
POSSIBLE THAT SOMEONE HACKS the javascript and get access to the admin
panel, although it should be hard to understand those generated
javascripts, but it is possible I think, the core GWT developers in
Google are probably able to hack those javascripts.

So, we will have to have different entry points for different user
roles, they will go to different URLs and we can filter unauthorised
access. I'm not saying it's not possible to do security in GWT, we
could design logics inside GWT app which stop admin panel from showing
for a client, but it must be a bit complicated comparing to URL filters

I'm looking forward to see the support for multiple entry points in GWT.

[scott....@gmail.com]

You should really have the final authorization code on the server. This
means that, even if the client side is hacked, updates to the
underlying data will not be able to be committed unless the user's
session is authorized to do the commit.

[bjorn]

About DreamWeavin':

Glad you mention this Ren, I was just discussing this with my colleague
about the possibilities to have DreamWeaver help us in any way. I hope
we can do some really simple HTML in DreamWeaver and then use CSS (also
in DreamWeaver, if the tool has good support, oppinions anyone?)
extensively for the looks and also layout (padding, alignment, etc.) If
we can do this, we only have to re-implement the very simple HTML in
GWT, the CSS goes in unchanged. Will try this during the week, and will
post any results in this thread.

Cheers, Björn

[Ren]

Thanks guys