forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: xhtml2 tonights update & questions
Date Thu, 08 Sep 2005 15:30:00 GMT
Tim Williams wrote:
> When you start reading these issues, it's not as bad as it sounds,
> I've got an xhtml page "viewed" at this point, although it's really
> ugly.
> Here's what I've done:
> o) Changed *.page to use a new pipeline **xhtmlbody-*.fhtml instead of
> the old **body-*.html
> o) Changed the stylesheet we got to deliver a div id="content" wrapped
> html chunk instead of a complete html document.
> o) Added the **xhtmlbody-* pipeline mentioned above.  It essentially
> just applies the stylesheet.
> o) Changed the **.html back to using *.page as it's generator src.
> o) Changed structurer.xmap to be pass-through.
> o) Tested each view-related pipeline with success.
> Here's why I haven't yet checked everything in (i.e. our problem)
> o) Having an internal plugin that matches **.html is really bad -- it
> breaks lots of stuff (e.g. menu-*.html, tab-*.html, etc.)
> o) As a workaround I changed the relevant bits to match and find
> *.fhtml instead of *.html.  I did that because I wanted to see
> something working and it does.
> Bottom line (ok Thorsten get's one and only one "i told you so"';)
> appears to be that these won't work properly as an internal plugin. 
> So, at this point I'm thinking the following course of action:
> 1) Create two brand new plugins
> o.a.f.p.internal.newCore
> o.a.f.p.output.defaultTheme
> don't worry so much about the names.  The point is that we've (i've at
> least) learned tons by having this xhtml2 plugin but I think it's time
> already for a fresh start.  We should make these new plugins with
> view/viewHelper as the model. What I'm calling "newCore" will
> obviously get rolled into the core forrest when we're done and the
> plugin removed.  What I'm calling output.defaultTheme will likely go
> through name changes, may or may not be a part of core/stay in a
> plugin/etc.

As i said in another thread, we might need to
develop and throw away a few times, as we explore
what is needed.

> Then we can get back up and running quicker so that we're not fighting
> with taking over core sitemap things like tab-*.html, etc, letting us
> focus on the real xhtml2 issue.  There are other smaller problems too
> but this is the real showstopper at the moment.
> Thoughts?

That sounds like a good approach to me. Even doing
that *.fhtml thing is not such a workaround. The
Cocoon sitemap gives us the power to do such internal


View raw message