Nice to see it catch on. I thought it was a pretty decent design, though it
did not seem to generate much interest. One thing:
I had hoped earlier to generate some discussion on whether it might be
better to dump the layouts directory in the template directory structure.
Layouts are generally associated with a directory, but to give maximum
flexibility they can be assigned to a specific screen. I think it is more
intuitive to have something like:
all searching is done in the screens directory
template = /about_us/directions/driving.wm
the search follows:
/about_us/directions/driving_layout.wm
/about_us/directions/default_layout.wm
/about_us/default_layout.wm
/default_layout.wm
It might not seem that much better, being used to the module structure in
Turbine. But it will probably always be the case that an application/site
will have a few layouts and 10's to 100's of templates. It is also easier
to look in the screen directory tree and determine the layout assigned to a
screen as a opposed to tracking a parallel directory tree. I did not
implement it this way in FM, as I was hoping for discussion first and it
would require some more string manipulation code, I did not feel like
implementing at the time. But I do feel it is a better design.
Comments?
John
----- Original Message -----
From: dave bryson <[EMAIL PROTECTED]>
To: Turbine <[EMAIL PROTECTED]>
Sent: Tuesday, April 18, 2000 5:58 PM
Subject: Re: basewebmacroscreen
> 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]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
