forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <d...@brondsema.net>
Subject Re: [RT] plugin infrastructure
Date Mon, 08 Nov 2004 19:05:14 GMT
On Mon, 8 Nov 2004, Ross Gardler wrote:

> Nicola Ken Barozzi wrote:
> > Ross Gardler wrote:
> >
> >> Nicola Ken Barozzi wrote:
> >
>
> <snip what="we don't need plugin dependencies (yet?)"/>
>
> >>>
> >>> faq should start using the content aware pipelines, and this is solved.
> >>
> >>
> >> +1 this can be done when the faq stuff is moved to a plugin.
> >
> > ...
> >
> >>> For other special *internal* parts we should probably not use name for
> >>> matching but maybe a parameter.
> >>>
> >>>   *?forrest-part=site.xml
> >>
> >>
> >> +1, this could facilitate the generation of different Forrest parts
> >> for different pages. There is no forrest-part at present that needs
> >> this, but some time ago there was an RT about have Forrest provide
> >> additional parts, for example, a news panel. These parts can be
> >> provided by infrastructure plugins and using the above match we can
> >> customise on a per page basis. For example,
> >> "index.html?forrest-part=news.xml" would return news about project
> >> releases whilst "developers/index.html?forrest-part=news.xml" would
> >> provide recent changes.
> >
> >
> > Hand on a second, let's go deeper in this.
> >
> > I see three issues:
> >
> > 1 - the page is the context, the part is the data:
> >     forrest-part should show some extra data as it has to be shown
> >     on the page being rendered.
> >
> >     forrest-part=tabs.xml would show the tabs with the selected one
> >                           specified
> >     forrest-part=site.xml would show the site with the selected one
> >                           specified
> >     ...etc
> >
> > 2 - the page is the data, and we specify a view
> >     for each page we may have different representations of it:
> >
> >       MyClass.java
> >          -> MyClass.html  javadocs
> >          -> MyClass.html  UML graph
> >          -> MyClass.html  highlighted source code
> >          -> MyClass.html  checkstyle result
> >
> >     How do we differentiate them? Not with parameters, as it has to
> >     remain in a name.
> >
> >     Proposal:
> >
> >       MyClass.java
> >          -> MyClass-javadocs.html   javadocs
> >          -> MyClass-uml.html        UML graph
> >          -> MyClass-source.html     highlighted source code
> >          -> MyClass-checkstyle.html checkstyle result
>
> I already came across this very issue in the s5 (slides) plugin and the
> (soon to be announced) WYSIWYG editor plugin.
>
> My current solution has been to encode it in the URL, i.e.
> slides/index.html gives the slides, index.html gives the default HTML
> output. The problem with this solution, is that it causes some
> complications with relative linking from one type of document to the
> other (i.e. slides to normal HTML) and it reserves some patterns in the
> URL space.


I would suggests MyClass.javadocs.html, MyClass.source.html, etc.  This
would be in alignment with the filename format used in content negotiation
by Apache HTTPD.  We've discussed this already in terms of i18n.

http://httpd.apache.org/docs-2.0/content-negotiation.html

-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
http://csx.calvin.edu : student org

Mime
View raw message