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 13:43:30 GMT
On Fri, Sep 13, 2002 at 03:38:35PM +0400, Piroumian Konstantin wrote:
> > 
> > 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.
> 
> Ok. I got the idea and it sounds good. So any project deciding to use
> Forrest can simply put all the project-specific files inside of a folder
> (e.g. 'documentation'), point Forrest to that folder and get all processed,
> right? This is what Forrest was missing long time.

Well not quite.. with the new build.build.xml you CAN point Forrest at
any project, say "build this" and have docs generated. That's how I built
aft.sf.net. The location of the jars was for lack of better alternatives,
and I'm not too worried what the default is.

> The good thing is that Nicola is the author of the xmlproperty task. Nicola,
> is it possible to specify some XPath expression for the task?

The bad thing is that Ant committers don't believe in "release early and
often". which is severely discouraging to all but the most far-sighted
developers (kudos to Nicola).

> > <map:transform src="skins/@skin@/xslt/html/{type}.xsl">
> >   ...
> >   <map:parameter name="config-file" value="../../../../skinconf.xml"/>
> > 
> > So it is quite flexible.
> 
> This snippet reminded me about another thing that can be fixed using input
> modules and global parameters of Cocoon. I'll have a look at it next week.
> How would you like the above rewritten like this:
> 
>  <map:global-parameter name="config-file" value="../../../../skinconf.xml"/>
> 
>  <map:transform src="skins/skin:name/xslt/html/{type}.xsl">
>    ...
>    <map:parameter name="config-file" value="{/config-file}"/>
> 
> Find differences ;)
> The 'skin' input module can read the skinconf.xml at the initialization and
> provide all the data for use in sitemap.

Oooooooo.. yes please! Getting rid of all those @skin@ tokens in the
sitemap would be excellent.

As I said in that mini-RT, my dream is that users be able to edit their
docs and sitemap inside src/documentation/, without any intermediate
<copy>, and then work with a live Cocoon instead of a static crawler.
These global params and input filters help eliminate the need for
filtered copies.

> > ?? Yes, tokens are needed.. how else do you customize a .js file?
> 
> Yes, you are right. 
> 
> Btw, is it now really needed? We can get all the needed data from the
> skinconf.xml and generate the needed 'breadcrumbs'. Are there any problems
> with it?

How do you generate breadcrumbs.js? XSLT would be yucky. Perhaps leave
the @tokens@ in, and have:

<map:match pattern="breadcrumbs.js">
  <map:read src="skins/.../breadcrumbs.js"/>
  <map:transform type="filter">
    <map:parameter name="filtersfile" value="filters.properties"/>
  </map:transform>
</map:match>

if that's possible..

> > 
> > I don't know. Isn't it more fun when users have to figure stuff out
> > themselves?
> > Brings some excitement to their dull pointless little lives..
> 
> Usually, they don't like this kind of entertainment, otherwise they become
> developers

Bah, the wimps ;P

--Jeff

> Konstantin
> 

Mime
View raw message