>Here's how I'm thinking about it - If someone wants to use
>WebMacro, they'd want to use it's features. It seems to me it'd
>be more complicated and counter productive to have to break up
screens/Layouts/Navigations when I can just let >the page authors assemble
them via #parse. After all this is just an optional Service
>it doesn't break anything.
WM has many good features and #parse might be one of them if you have not
already come up with the idea to separate layout from content (navigations
and screen). The header/footer with some content thrown in might be easy
enough, but layouts can get more complicated. And even with a simple
header/footer layout, if you build the layout into the screen, you may end
up with certain components that vary slightly from one section to another,
so if you make a change you have to touch several files.
>
> The goal is to allow page designers the freedom over the entire UI while
> still allowing the developers to come in with dynamic content. If you keep
> some of the UI within the Layout/Navigation modules, then you are going to
> end up with a partial UI abstraction instead of a complete one.
>
Layouts and Navigations should be written as WM templates as well, so they
are handled by the UI developers. So I guess what I am saying, if done
simply by using #parse, that the screens should not contain #parse
statements. There should be a layout associated with the screen that
contains #parse statements for the navigations and the screen.
When looking at content management systems, let's take Dynabase. In
dynabase you would set up navigations and screens which are primarily html
with some variables for dynamic content. You then
glue the navigations and screen together with some VB script. When someone
requests the screen the VB script is run to generate the whole page. Other
than the VB script this is a good design.
And with WM it is possible to write the glue as a WM template as well (so
this is even better than the dynabase method), which following the Turbine
terminology I would call it a layout. .
How to associate layouts with screens:
Since WM templates resemble html files, it is best to assume a
directory/file analogy for templates as opposed to a package/object
structure. UI developers should find this a very easy way of visualizing
things. It can be assumed that most the templates in a given directory
should have the same layout. In the event that it makes sense for a
template to be located in a given directory even though it does not follow
the same layout, there should be a way to override this behavior.
I have done all this wrt FreeMarker/Turbine integration. I would like to
see it used with WebMacro as well. I guess I would say it should be
possible to accommodate both ways of doing things. A simple property like
use.layouts=true/false would work. Of course then one would have to do
things the same way throughout the application/site which would make the
most sense anyway.
Please look at my FreeMarker example templates. the FreeMarkerSitePage has
a pretty lengthy description of the process. There is a document in the
docs directory as well. Please make comments. I thought it was a pretty
good solution, but I guess there is not much interest. Please at least try
to accommodate my way of looking at it or talk me out of it.
Thank you,
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
