Question regarding Template.jsp

[Rick F.]

John..

In briefly looking thru the fish-n-chips club sample, I noticed it has various roles along with different Template.jsp files that reside in various directories.. In my example code derived from the electric company tutorial code, that one has the Template.jsp in the root directory..

My question is whether there's any rhyme or reason as to where these various Template.jsp's get places or is it completely arbitrary?  Also, in a particular role how to you tell web4j to use a particular version of that file?  I didn't really notice anything in the electric tutorial that specified that directly..

In my case I'm working an app that will have 3 different roles (1 user, 2 different admin types) and a not-logged in user that would have yet another set of options available.. I'd like to use the Template.jsp to tailor role specific jquery UI menus that are tailored for each user as that appears to be the best approach..

Please correct me if any of my assumptions are wrong.

Thx!

[Rick F.]

In the fish-n-chips reference above I think the comment about roles is really supposed to be modules..but I think the same applies regardless.. I still need to study more on roles & authentication..

[Rick F.]

Ok.. Found a nice write-up done by John at this link -- perhaps it will help someone else with the whole login/role angle..  In the meantime I think I will build my various modules w/o the need for authentication/roles for now and plug that in later.

[John O'Hanley]

That's a good question. The templating mechanism works fine when you have a working example to use, but the mechanism isn't very clear, unless you dig down deep.

You can think of it this way:
1 app ... N modules (a module is just a set of related features, all under a given base URL  '.../admin/', for example)
1 module .. N features
1 feature .. 1 java package (roughly, a single screen and its related data)
1 java package .. N classes, .sql file, and a 'body' jsp.

(It's not 100% necessary to use the above scheme, but it likely is useful for many apps to be broken down like this.)

The N features in a module can share an overall Template.jsp. Each feature has its own 'body' jsp. At run time, the Template and the body are combined together to make the final result.

Where does the Template.jsp live? Well, it should live somewhere where it can be readily referenced by all of its related features. There's no real restriction on where it lives, per se, but the example apps make use of a convention, whereby the N features in a module are all under the same 'base' url, and the Template.jsp is placed under the web app root, under that same base url. This makes it easier to wire together a body and a template, since the Action and the Template share the same base url. That's all.

The only real restriction is that your Actions need to return a ResponsePage object. If you look at the javadoc for ResponsePage, you can see that its various constructors allow for various policies. You can also see that ResponsePage is a wrapper for a URL.

It's up to you which constructor you use; the example apps provide one reasonable way of doing things. One weird thing about the example apps is that the Templates are defined 'elsewhere', in a sense, and are placed under the root of the web app itself, and are distant from the features (the code) that use it. That's a bit confusing and not very modular, but its not too bad (I hope).

[Rick F.]

Thanks John.. Very informative.. I will try playing around with this tonight and see how it fares..