forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: [PATCH] customizable skins, greater configurability, image di r fixes, miscellanea
Date Fri, 13 Sep 2002 14:37:18 GMT
On Fri, Sep 13, 2002 at 02:20:13PM +0200, Nicola Ken Barozzi wrote:
> 
> Jeff Turner wrote:
> >On Fri, Sep 13, 2002 at 01:35:36PM +0400, Piroumian Konstantin wrote:
> >
> >>>From: Jeff Turner [mailto:jefft@apache.org] 
> >>
> >...
> >
> >>>These changes were made while producing the site at
> >>>http://aft.sourceforge.net/
> >>
> >>Seems that Forrest's skin is the favourite one. We already have at least 3
> >>sites with the same skin.
> >
> >I like the Krysalis one (avalon-site) though. I think this patch would
> >allow the krysalis skin mods to be rolled back into avalon-site.
> 
> Cool :-)
> Well, we have changed the skin at Avalon, as you can see
> http://jakarta.apache.org/avalon/ , and I've done some minor
> enhancements for the text of the krysalis one.

Hey yes, I'm also an Avalon committer.. ;)

So if I want to fix up the avalon-site skin so Avalon can use it, which
would be the one to use?

jeff@expresso:~/apache/jakarta/jakarta-avalon/src/documentation/skins$ ls
alt-avalon-site  avalon-site  avalon-tigris  basic  CVS  krysalis-site


> Many people have asked me to decouple the skin repository from Forrest 
> itself, do you have any ideas on how this can be done well?

Sounds odd.. what use is a skin on it's own? Perhaps the style.tigris.org
people have something going.

> >>>The patch does the following:
> >>>
> >>>- Allows users to have a custom sitemap, overriding the
> >>>forrest-provided one. Default location is
> >>>src/documentation/sitemap.xmap, though it is configurable.
> >>
> >>Why not the src/resources/conf?
> >
> >That's where it lives in Forrest's CVS module, where it is indeed a
> >"resource". But inside a live Forrest-using project, it's not a static
> >"resource", but the active controller. It specifies how resources
> >(images, xdocs) are mapped to URIs, so it's not a resource itself. Thus I
> >followed the Cocoon example of putting it at
> >src/documentation/sitemap.xmap. It's configurable of course.
> 
> I have been thinking about the dir layout we ask our users to have...
> Since we have decided that we put all in the same dir, with the 
> possibility of having also them in indipendent dirs, what about this 
> default layout:
> 
>  */documentation/fdocs (forrest docs)

ie, xdocs live here?

>  */documentation/fdocs/images

.. and images linked to from ../*.xml live here?

If so, big +1. I'm greatly in favour of anything that allows simpler doc
layouts for simpler projects.

> >Putting them in lib/ might interfere with other jars there, and might
> >cause unforseen interactions with either Cocoon or the user's app.
> >lib/optional and lib/endorsed are Centipede specific. How about lib/doc/?
> >Hmm.. if your project doesn't have a lib/ directory anyway, it would look
> >a bit silly. The intention with src/documentation/lib is that all doc
> >stuff (xdocs, stylesheets, images, jars) are in one directory.
> 
> We should decouple the doc dir from the doc-generation enhancements dir.
> 
> What about
> 
>  */documentation/fdocs (forrest docs)
>  */documentation/fdocs/images
>  ...
>  */documentation/resources/images
>  ...
>  */ext/sitemap.xmap
>  */ext/lib/
>  ...
> 
> ?
> 
> In this way it can be easier to decuple the exts later on and make a 
> specific forrst enhancement plugin. (mayby plugin instead of ext?)

forrest enhancement plugin.. hmm, like, a "user feedback" plugin, or a
wiki plugin, or a CMS plugin.. is that what you mean? Sounds cool.

...
> >Yes it would be nice. However the 'processor' is the <xmlproperty> task,
> >and unfortunately it provides no way for accessing the n'th link.
> 
> We can get round this quite easily with two ways:
>  1) I patched the xmlproperty task (@see Ant Bugzilla) to make multiple 
> entries result in a comma-separated list on which the for-each task can 
> iterate

Wohoo:)

>  2) We update to the latest Ant embed proposal and use JXPath
>     http://www.krysalis.org/cgi-bin/krywiki.pl?AntJXPath

Even better.

Would be nice if we could keep Ant 1.5 compat though. Let's say a typical
Forrest-using project invokes Forrest with:

<target name="webapp" description="Build the website webapp">
  <ant antfile="${forrest.home}/forrest.build.xml" target="webapp"/>
</target>

Seems a bit much for a doc system to force a version of Ant on users.

But then maybe Marc is right and users will all use a 'forrest' script
instead. And we can always <exec> Forrest.


--Jeff


Mime
View raw message