----- Original Message -----
From: Rafal Krzewski <[EMAIL PROTECTED]>
To: Turbine list <[EMAIL PROTECTED]>
Sent: Thursday, August 10, 2000 8:38 AM
Subject: WebMacroSiteLayout
> Hello!
>
> There is something I don't like about WebMacroSiteLayout. It uses ECS to
generate
> <head> part of the page.
I see this as a strength.
> There is WebMacroPageAttributes that allows manipulation
> of it's content, but I think it may not be the best solution possible.
> The disvantage of this approach is that layout template is not valid html
because
> is't obviously missing the <head> part.
It's missing the <html> and <body> tags as well.
>This forces the web developer that is
> perparing the template to use WM 'incatations' to set such basic things as
body
> bgcolor attribute and disallows him to test his layout right away in the
browser.
>
> I'd much better like to have a layout template like that
>
> <html>
> <head>
> <titile>$data.getTitle()</title>
> <link rel="/_style/style.css" type="text/css">
> #foreach $item in $meta #begin
> <meta name="$item.name" content="$item.content">
> #end
> <script lanuage="JavaScript">
> function whatever() {
> }
> </script>
> </head>
> <body bgcolor="#41A382">
> $screen_holder
> </body>
> </html>
>
> where 'meta' is a vector of hashtables contiaing keys 'name' and 'content'
> that allows your screen to generate meta information dynamically and
> allows your html author to manipulate styles and other stuff he cares
about
> wiht minimal hassle.
I like Screens to be able to add javascipt to the head, but I guess this is
not absolutely necessary. Is data.setTitle(x) called at this point, (I am
just making a lazy question, not too important)? And what if my screen
would like to implement an onLoad event handler?
>
> To make this work, layout class should use the same WebContext instance as
> the Screen and Action (currently WebMacroSiteLayout creates a fresh
instance,
> for some reason)
The original thinking was to limit the available information in the layout
context, so that it is used appropriately and did not contain a lot of
dynamic content. That said I think it might be beneficial to have one
context for the Page, as it might facilitate flattening out the content (for
designer tools). This would apply to Navigations as well, I'm not sure it
needs to apply to the Layout but you would be writing an alternate one
anyway.
> and use data.getOut() instead data.getPage() to write
> template rendering result to the browser.
>
> I'm not sure if this is "the right thing" - maybe the current approach has
> some advantages I'm not aware of, still I think that such calss should be
> available as an alternative. I'm not sure how should this class be called,
> WebMacroSitePureLayout, WebMacroSiteNoECSLayout?
>
I think you should write a Layout that you see as a better alternative and
if others feel that it has more benefits than limitations, it will become
the one used more often. I would recommend against using the Site word. I
have been reworking the template framework and one of the things I have done
is get back to essentially one Page which contains the build method (I hope,
I have not tested things, yet) where child WebMacroSitePage and other
template Pages override a method to supply the context. Since there is no
WebMacroPage that is different than a WebMacroSitePage I would prefer to
lose the term. I have not done so, since I am making a big change and I
want to avoid breaking things for people where they have to run down some
unrelated errors.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
