forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Williams <>
Subject Re: xhtml2 tonights update & questions
Date Thu, 08 Sep 2005 22:24:13 GMT
I'll read the rest of this later but really quickly I don't see how
moving the navi stuff out to a contract (which I agree with btw) is
going to solve my problem.  It's not going to change that the internal
plugin xmap has match precedence over the menu.xmap.

I've been thinking we were taking baby steps here.  I don't know that
I want to tackle both "xhtml2 to core" and "views refinement" at the
same time.  My goal has just been to get the former done with current
views, then tackle views refinement armed with what was learned in the
first step.  I think it'll take going through the pain of the first
step in order for everyone to be able to speak intelligently about
views and what the implications of suggestioning certain conceptual
refinements might be technically.

For example, in this process so far, I've been notetaking my own ideas
of how we might improve views but I don't want that to slow down the
xhtml2 to core progress -- as it will require lots of
non-code-but-thinking discussion.

On 9/8/05, Ross Gardler <> wrote:
> 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.
> [1]
> [2]

View raw message