forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: xhtml2 tonights update & questions
Date Thu, 08 Sep 2005 21:45:28 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.

Great work Tim.

[WARING] I have *not* looked at your work in detail, so my comments may 
be way off. If they are just say "check the code and then get back to 
me", don't waste time explaining things in detail unless you see the need.

The reason I'm jumping in now is I am really busy for a week or so and 
may not be able to look at your code in detail, I just have a *major* 
concern that I want to air early in order to avoid too much effort in 
the wrong direction.

> Here's what I've done:
> o) Changed *.page to use a new pipeline **xhtmlbody-*.fhtml instead of
> the old **body-*.html

Views should not use aggregation of body, site, tabs etc. Each of these 
parts are just nuggets of data that should be pulled together as and 
when they are required.

That is if I want navigation I should have a nav contract that knows 
where to find the content. Look at the content-include-html contract [1] 
as an example of how to do this.

For further discussion see "Step 3: Filtering" in our TR [2]

Why do it this way. Well one reason is that it solves the problems you 
highlight below. The other is that it removes an inneficiency in the 
current system. That is, if I request a document that does not have 
navigation (e.g. a PDF rendering of a page) then the whole aggregation 
step is a waste of time. Striping this one step from the PDF output 
alone will improve Forrest performance a great deal.

Another reason is that it makes a much tidier sitemap and it separates 
the concerns of content aggregation (structurer) and content processing 

> 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.)

That problem will go away with the above approach ;-)

> 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.

That need will go away with the above approach ;-)

> 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. 

Yes it will ;-)

> 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.

I'm all for a fresh start, but lets explore the above first. I believe 
it will greatly simplify the overall forrest pipeline and, more 
importantly, bring us into line with out TR since the filtering of 
content will be contained in the structurer only, rather than split 
across core and views.

>  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 we discussed on IRC, there are things in the current XHTML2 plugin 
that should be in a theme plugin, so I agree there is a need. But not 
for the reason you highlight above.

> 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.  

Interestingly enough *.page is the only matcher I have not added to 
structurer.xmap, for the reasons above. My commit messages did not 
highligh this, sorry.




View raw message