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
(sitemap).
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.
WDYT?
[1]
http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.viewHelper.xhtml/resources/templates/content-include-html.ft
[2]
http://svn.apache.org/viewcvs.cgi/*checkout*/forrest/trunk/site-author/content/xdocs/TR/2004/WD-forrest10.html
