forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: [PATCH] customizable skins, greater configurability, image di r fixes, miscellanea
Date Fri, 13 Sep 2002 13:38:35 GMT
> From: Jeff Turner [mailto:jefft@apache.org] 
> 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.

Ok. I'll take a look at it and try to understand better when your patch is
applied. 

> 
> > 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).

We can have "early access task" from 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.

This was the main reason for 'global-parameter' proposal at Cocoon. I've
been also thinking about setting those params externally, e.g. as command
line arguments (in case of static version generation) and as a request
parameter, e.g. 'cocoon-param', though, I was absolutely out of time to
implement it.

Next week I am on vacation and will try to optimize (simplify) the sitemap
using input modules and parameters.

> 
> > > ?? 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:

I mean, that we don't need JavaScript at all to generate those links. Is
there any hidden meaning in that JS that I have missed or is it just for
generating the 'global-path' that we can see at the top of every page?

> 
> <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..

Let's not go this way. 
Though, generally, the idea of filtering/transforming a JavaScript is quite
interesting and can be used in other webapps, e.g. for generating
personalized validation rules. But this is a little OT for Forrest.

> 
> > > 
> > > 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

;)

--
  Konstantin

> 
> --Jeff
> 
> > Konstantin
> > 
> 

Mime
View raw message