Re: Leather and global variables

[Ross Gardler <rg...@apache.org>]

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

Re: Leather and global variables

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> On Wed, 2005-03-16 at 08:34 +0000, Ross Gardler wrote:
> 
> 
>>I'm guessing you mean something like:
>>
>><map:generate src="{project:conf-dir}/default.fv"/>
>>
>>If so, my original reply was spot on: Do you mean where do we define 
>>*new* global variables that can be set in forrest.properties?
>>
>>You now need to set the value you want in forrest.properties:
>>
>>project.conf-dir=${project.content-dir}/conf
>>
>>Everything else happens automatically.
>>
> 
> 
> hmm, I actually thought so, but no. 
> 
> I did it like this from the beginning and because it was not working
> like this I asked about defining new variables.
> 
> 
>>If this isn't what you are trying to do then it really would help my 
>>fuzzy early morning brain if you provided a code snippet of what you 
>>want to do - I wouldn't have to think before my morning brew ;-) (my 
>>head hurts this morning - sorry)
> 
> 

...

> <map:when test="{project:conf-dir}/default.fv">
>           <map:generate src="{project:conf-dir}/default.fv"/>
>         </map:when>

Hmmm, so my guesses about what you were doing were right. I'm not sure 
why this isn't working - it should. We are clearly missing something 
(maybe someone will jump in here).

Just a shot in the dark. Have you tried building forrest. I don't see 
that this will make any difference, but then I don't understand the 
magic about how stuff gets from cocoon.xconf into the sitemap. It can't 
do any harm.

What happens when you have the above pipeline instead of your hack. You 
should get an error message in the logs that will indicate what value is 
being assgned to {project:conf-dir} (or not as the case may be).

Ross

Re: Leather and global variables

[Thorsten Scherler <th...@apache.org>]

On Wed, 2005-03-16 at 08:34 +0000, Ross Gardler wrote:

> I'm guessing you mean something like:
> 
> <map:generate src="{project:conf-dir}/default.fv"/>
> 
> If so, my original reply was spot on: Do you mean where do we define 
> *new* global variables that can be set in forrest.properties?
> 
> You now need to set the value you want in forrest.properties:
> 
> project.conf-dir=${project.content-dir}/conf
> 
> Everything else happens automatically.
> 

hmm, I actually thought so, but no. 

I did it like this from the beginning and because it was not working
like this I asked about defining new variables.

> If this isn't what you are trying to do then it really would help my 
> fuzzy early morning brain if you provided a code snippet of what you 
> want to do - I wouldn't have to think before my morning brew ;-) (my 
> head hurts this morning - sorry)

The pipe looks like the following right now:

<map:pipeline>
    <map:match pattern="prepare.view.*">
      <map:select type="exists">
        <!--here we will have to test, whether the requested page needs
a specific view.
          This will be assumed as soon there is a .ft 
          e.g. index.xml + index.fv-->
        <map:when test="{project:content.xdocs}{1}.fv">
          <map:generate src="{project:content.xdocs}{1}.fv"/>
        </map:when>
<!--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 ;-)-->
        <map:when test="{project:content.xdocs}/default.fv">
          <map:generate src="{project:content.xdocs}/default.fv"/>
        </map:when>
        <!--If the above not matches then get the default view of the
skin-->
        <map:otherwise>
          <map:generate
src="{forrest:skins-dir}{forrest:skin}/templates/default.fv"/>
        </map:otherwise>
      </map:select>
     <map:serialize type="xml"/>
    </map:match>
  </map:pipeline>

But it should be like this:
<map:when test="{project:conf-dir}/default.fv">
          <map:generate src="{project:conf-dir}/default.fv"/>
        </map:when>

TIA for your time (again)

salu2
thorsten

> 
> Ross
> 
> 
> 
> 
> 
> 
> 
> 
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)

Re: Leather and global variables

[Ross Gardler <rg...@apache.org>]

Thorsten Scherler wrote:
> On Tue, 2005-03-15 at 10:08 +0000, Ross Gardler wrote:
> 
>>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.
>>
> 
> 
> hmm, ok, I tried:
> Index: main/webapp/WEB-INF/xconf/forrest-core.xconf
> ===================================================================
> --- main/webapp/WEB-INF/xconf/forrest-core.xconf        (revision
> 157530)
> +++ main/webapp/WEB-INF/xconf/forrest-core.xconf        (working copy)
> @@ -139,6 +139,7 @@
>          <doc>@project.home@/@project.content-dir@/</doc>
>          <content>@project.home@/@project.raw-content-dir@/</content>
> 
> <content.xdocs>@project.home@/@project.xdocs-dir@/</content.xdocs>
> +        <conf-dir>@project.conf-dir@</conf-dir>
> 
> <translations>@project.home@/@project.translations-dir@</translations>
> <resources.stylesheets>@project.home@/@project.stylesheets-dir@/</resources.stylesheets>
> 
> <resources.images>@project.home@/@project.images-dir@/</resources.images>
> 
> ...but I could not find any target that would do e.g.
> <replacetoken>@project.home@</replacetoken>
> 
> Can you please give me another hint how to use {project:conf-dir} within
> my output.xmap

I'm guessing you mean something like:

<map:generate src="{project:conf-dir}/default.fv"/>

If so, my original reply was spot on: Do you mean where do we define 
*new* global variables that can be set in forrest.properties?

You now need to set the value you want in forrest.properties:

project.conf-dir=${project.content-dir}/conf

Everything else happens automatically.

If this isn't what you are trying to do then it really would help my 
fuzzy early morning brain if you provided a code snippet of what you 
want to do - I wouldn't have to think before my morning brew ;-) (my 
head hurts this morning - sorry)

Ross

Re: Leather and global variables

[Thorsten Scherler <th...@apache.org>]

On Tue, 2005-03-15 at 10:08 +0000, Ross Gardler wrote:
> 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.
> 

hmm, ok, I tried:
Index: main/webapp/WEB-INF/xconf/forrest-core.xconf
===================================================================
--- main/webapp/WEB-INF/xconf/forrest-core.xconf        (revision
157530)
+++ main/webapp/WEB-INF/xconf/forrest-core.xconf        (working copy)
@@ -139,6 +139,7 @@
         <doc>@project.home@/@project.content-dir@/</doc>
         <content>@project.home@/@project.raw-content-dir@/</content>

<content.xdocs>@project.home@/@project.xdocs-dir@/</content.xdocs>
+        <conf-dir>@project.conf-dir@</conf-dir>

<translations>@project.home@/@project.translations-dir@</translations>
<resources.stylesheets>@project.home@/@project.stylesheets-dir@/</resources.stylesheets>

<resources.images>@project.home@/@project.images-dir@/</resources.images>

...but I could not find any target that would do e.g.
<replacetoken>@project.home@</replacetoken>

Can you please give me another hint how to use {project:conf-dir} within
my output.xmap


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

That is why I said if I will touch the core I will prepare a patch or
will create a new branch. ;-)

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

Yeah, I will try that.

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

ok, I will try the internal plugin ASAP.

salu2
-- 
thorsten

"Together we stand, divided we fall!" 
Hey you (Pink Floyd)