On Tue, 18 Apr 2000, you wrote:
> Also, lets build some layout guidelines. For instance...lets define a
> standard for where the .wm files should go not only for this new stuff, but
> for the rest of the stuff. ie: should they be right next to the .class
> files? Should they have similar names? etc...
The layout guideline is not an option, this new WebMacroSitePage
depends on a particular layout. HTML authors lay out their
pages the same as the programmers. So, they start with a directory
structure like this:
/layouts
/navigations
/screens
What's cool about what John M has designed here is that Page authors
can define layout and navigations with templates. More on that later.
Screens follow this rule. If there's a one-to-one relationship
between a screen and a template then they should both have the same
name. It a template does not match a particular screen, then it will
be picked up and executed by the WebMacroSiteScreen. John's doc has a
good explanation of how it works:
The templates can be grouped in directories with common layouts.
Screen modules are then expected to be placed in packages
corresponding with the templates' directories and follow a specific
naming scheme.
The template parameter is parsed and a Screen whose package
matches the templates path and shares the same name minus any
extension and beginning with a capital letter is search for. If
not found a Screen in a package matching the template's path with
name Default is searched for. If still not found, a Screen with
name Default is looked for in packages corresponding to parent
directories in the template's path until a match is found.
For example if data.getParameters().getString("template") returns
/about_us/directions/driving.wm, the search follows
about_us.directions.Driving
about_us.directions.Default
about_us.Default
Default
WebMacroSiteScreen
Note: When one-to-one template to screen relationships are needed,
developers can extend the WebMacroSiteScreen and override the
doBuildtemplate() with the particular logic or data. In most cases
that's all they should need to do.
Only one Layout module (see WebMacroSiteLayout) is used, since it is
expected that any dynamic content will be placed in navigations and
screens. The layout template to be used is found in a similar way to
the Screen. For example the following paths will be searched in the
layouts subdirectory:
/about_us/directions/driving.wm
/about_us/directions/default.wm
/about_us/default.wm
/default.wm
Here's an example layout, defined by a page author:
<table width="100%">
<tr>
<td>$navigation.setPage("/default_top.wm")</td>
</tr>
<tr>
<td>$screen_placeholder</td>
</tr>
<tr>
<td>$navigation.setPage("/default_bottom.wm")</td>
</tr>
</table>
The content for the screen_holder variable above is created on the
WebMacroSiteLayout.
As for navigations, I'm creating a $navigation.setPage() tag so the page
author can use it as above.
I'm also creating the $link.setPage().setQS().setPI(). tag it allows
authors to link WM pages together. The Link tag sets the
template variable that's used to look up a screen.
Here's a couple things to remember. To use this, the default page must
be set to the WebMacroSitePage. This gets back to the thing I brought up
earlier about merging these all into one page. However, I don't see
this as a really big deal right now, because you can still execute a
plain ole' screen if you need to.
I hope this clears things up a little.
Overall, this "new way" should:
* Be easy to use for HTML author. Page authors can make changes to
the site without a progammer.
* Template can have a one-to-many relationship with screens.
* No external mapping file needed.
Are we on track???
--
dave
[EMAIL PROTECTED]
-----------------------
"I find it the same with all pleasures within my reach; unless
they cost me nothing, I find them insipid."
Rousseau
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
