forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Leather and global variables
Date Tue, 15 Mar 2005 10:08:08 GMT
Thorsten Scherler wrote:
> On Mon, 2005-03-14 at 12:12 +0000, thorsten@apache.org wrote:
> 
> I need some input on the following:
> 
> 
>>+<!--This should be match to the conf dir but I do not know ┬┐how?
>>+          {project:conf-dir} does not work -> ask on ml!
>>+          For now that matches the default.fv in the xdocs dir.
>>+          The problem with this solution is that the a default.xml will be always
render with the default view.
>>+          Not too bad of a problem after all ;-)-->
> 
> 
> Where do we define this global variables? 

Do you mean where do we define *new* global variables that can be set in 
forrest.properties? If so the answer is cocoon.xconf.

> Now to the changes of the fbits-plugin in regards to leather.

I'll have a look at that as soon as I can, should be in a day or two.

> 
> The missing steps are just a matter of implementing (change the default
> "skinit" pipe and capsuled all code of the site2xhtml.xsl). I am working
> on that (including document2xhtml and css) right now but I am "scared"
> to commit it (because I do not have the time to test it appropriately
> and it will alter the default behavior of forrest), so I will prepare a
> patch or open a new branch (what do you prefer?) for the upcoming
> changes.

We definitely *don't* want to go messing with core before the 0.7 release.

Have you considered using an internal plugin? You can (theoretically) 
override anything in the core sitemaps using an internal plugin. This 
sounds like a brilliant use case for complete testing of internal 
plugins (only the IMSManifest plugin exists so far).

Working with it as an Internal plugin will prevent any branch merge 
conflicts at a later date. Of course we will still be able to move it 
into core if and when necessary.

> ...but saying this an old question in my head raises. IMO skins are not
> flexible enough to met user needs. Their should become deprecated when
> the forrest:views are finally working in the way the old skins did. 

Lets see what we think when forrest:views are done. My view is that if 
they can do everything skins can *and* they add flexibility then we 
should deprecate skins for them. What I see so far indicates this to be 
the case, but not yet.

> Now I am facing a mayor clean up of the fbits plugin because 90% of the
> stuff is not needed anymore. I kept it simple and stupid (regards 2
> Ross) and ended up with a couple of pipes and stylesheets.

Glad to hear much of it is not needed, I've been trying to follow your 
work and am afraid to admit I am still confused. Now I know why.

> I further think that the fbits plugin should be either called
> forrest.contracts or forrest.view plugin because actually it is a
> producing factory which will deliver contracts (fbits or nuggets) for a
> forrest:view. 

forrest.view seems more descriptive.

> Wrapping up here my upcoming steps:
> 1) implement css
> 2) implement requested document parsing
> 3) cleanup and rename fbits.plugin

When I have the time I will see if I can do what I need to do and 
provide some feedback (and hopefully assistance).

Looks like great work.

> ATM I am working on a client project away from home and have limited
> internet access, please be patient waiting for my answer. 

pesky clients!

Ross



Mime
View raw message