You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@apache.org> on 2005/09/06 07:04:25 UTC
Validation transformer RELAX NG with Jing
Yesterday Pier added a "validation" block to Cocoon to do
RELAX NG processing at any part of the pipelines.
So far it is only in Cocoon-2.1 and he is in the process
of adding it to the Cocoon trunk.
Today i added it to my Forrest and it works nicely,
so i added this preview of it to our Forrest trunk.
Will replace it later.
Here are Pier's notes about it:
http://marc.theaimsgroup.com/?t=112541971900003
http://cocoon.zones.apache.org/daisy/documentation/blocks/
validation.html
http://cocoon.zones.apache.org/daisy/documentation/components/
transformers/jingtransformer.html
----oOo----
To test it in Forrest, we have a basic grammar
called any.rng which just makes sure that docs are
well-formed. Later we will have full grammars.
So for now, add this to your project sitemap:
<map:match pattern="xhtml2.xml">
<map:generate src="{project:content}/plan/xhtml2.xml"/>
<map:transform type="jing" src="{forrest:context}/resources/schema/relaxng/unstable/any.rng"/>
<map:serialize type="xml"/>
</map:match>
Add Gav's xhtml2.xml to the xdocs/plan/ directory
I also removed the document type declaration and
exposed the <html> element and namespace.
Make a deliberate error, e.g. remove an end tag.
Now request http://localhost:8888/plan/xhtml2.xml
So it will help us with testing of our various
internal xhtml2 pipelines, and of course have
other uses.
-David
Re: New user of views.
Posted by Kevin <fo...@kegcl.demon.co.uk>.
On Fri, 2005-09-09 at 09:17 +1000, David Crossley wrote:
> Kevin wrote:
> > Thorsten Scherler wrote:
> >
> > > Have a look on the beautiful mail of Diwaker and the log of cheche from
> > > FT. I (tscherler or target{something}) talked with cheche what we have
> > > to do to enable that.
> >
> > Sorry didn't understand that. Could you point me to the "homework" or an
> > outline here. Diwaker's mail - I probably missed it and the log?
>
> The summary of last ForrestTuesday on IRC and the log
> http://marc.theaimsgroup.com/?t=112607812800006
>
> -David
Thanks, I'll have a look.
Kevin.
Re: New user of views.
Posted by David Crossley <cr...@apache.org>.
Kevin wrote:
> Thorsten Scherler wrote:
>
> > Have a look on the beautiful mail of Diwaker and the log of cheche from
> > FT. I (tscherler or target{something}) talked with cheche what we have
> > to do to enable that.
>
> Sorry didn't understand that. Could you point me to the "homework" or an
> outline here. Diwaker's mail - I probably missed it and the log?
The summary of last ForrestTuesday on IRC and the log
http://marc.theaimsgroup.com/?t=112607812800006
-David
Re: New user of views.
Posted by Kevin <fo...@kegcl.demon.co.uk>.
On Thu, 2005-09-08 at 01:25 +0200, Thorsten Scherler wrote:
...snip...
> > > > 2) Next I wanted to use my own css in that fv using <forrest:css> so
> > > > in my xdocs/default.fv
> > > >
> > > > <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0" >
> > > > <forrest:view type="xhtml">
> > > > <forrest:css url="default.css"/>
> > > > <forrest:css url="nav-main-hook.css"/>
> > > > ...
> > > >
> > > > (I had successfuly implemented my own nav-main contract implementation)
> > > >
> > > > forrest site
> > > >
> > > > Will produce *.html with stylesheets with different titled <link>
> > > > elements:
> > > >
> > > > <link href="skin/default.css" title="default.css" rel="stylesheet"
> > > > type="text/css" />
> > > > <link href="skin/nav-main-hook.css" title="nav-main-hook.css" rel="stylesheet" type="text/css" />
> > > >
> > > > So my nav-main-hook.css won't cascade.
> > >
> > > What do you mean?
> >
> > #nav-main-hook defined in nav-main-hook.css should override
> > #nav-main-hook defined in default.css
> >
>
> Wait. css is working the way that what you define last it got matched.
> Like you have it in your example it *should* get override! Try
> commenting out default.fv. See what happens. I imagine you will see the
> css for your nav. If that is the case then just copy the parts you need
> of the default.css and create your own theme. That should work. ;-)
I've found another way to fix it:
<forrest:css url="default.css" media="screen" title="Custom"/>
<forrest:css url="nav-main-hook.css" media="screen" title="Custom"/>
Define "Custom" titles in default.fv
> > > > I've used @title before with
> > > > alternative stylesheets. So to get it to work I removed the @title. Or
> > > > ensure they have the same name.
> > >
> > > Actually I reckon that is a bug, I am not sure, that part is new.
> >
> > I think it is a bug. Though I can rewrite default.css and add my
> > nav-main-hook.css changes. Then put default.css in my skin/css as a
> > work around. Then remove <forrest:css url="nav-main-hook.css"/> from
> > the default.fv as it doesn't work.
> >
>
> Hmm, it should work, but I think it is a typical css behavior that you
> are running into. The thing on css is that if you want to override
> styles defined before you will need to reset them and define them
> again.
Not had to do that before. But I'll try that if I have css override
problems.
> Best is to do what you describe. You can name it BTW like you want, it
> do not have to be called default.fv.
>
> > > > I noticed the new pelt view uses
> > > > alternative stylesheets (which will look good with some javascript to
> > > > switch between :)
> > >
> > > :) Yeah should be simple to write a contract for that. ;-)
> > >
> > > > Though I haven't tried adding a <forrest:css> to
> > > > a fv and check what happens.
> > >
> > > ¿? Your example above has forrest:css in the default.fv.
> >
> > Yes but I didn't try it in the new pelt view.
> >
>
> Views are all the same. They only define structure and the theme (*.css)
> to use. BTW make sure the <forrest:css/> are direct children of
> <forrest:view/> otherwise it will not work!
Yes it is. Needed to rename default.fv to pelt.fv to see my view.
> > > >
> > > > 3) How I see contracts at the moment are an override method of hooking
> > > > into leather-dev xslt. A well defined interface but to what resolution
> > > > can you go without knowing the internals? To explain what I mean, below
> > > > is the addition to my custom nav-main.ft. If I wanted to get to the <a>
> > > > element and define class="my-base-selected" it looks as if I'd have to
> > > > borrow more from the leather-dev skin to get calculate-tab-href?
> > > >
> > >
> > > The menu part is created from the book2menu.xsl of leather-dev, the tab
> > > part of tab2menu.xsl. We are in the middle of refactoring that as well.
> > > Anyway you will have to pick up what comes out of this transformation
> > > and apply your custom transformation to it.
> > >
...snip...
> > <xsl:template match="li[not(@class)]">
> > <xsl:apply-templates/>
> > </xsl:template>
> >
> > leather-dev is before view to pass me <li> which I get rid of but
> > <xsl:apply-templates/> will transform the <a> back in a leather-dev
> > template somewhere.
>
> No and yes. No, it applies all templates after that
> match="li[not(@class)]". Yes because applying all templates mean that
> you go back to the *.page. What you should try is <xsl:apply-templates
> select="*"/>
It will take me a long time to understand Tim's trip through view
pipelines and understand about *.page best stop while I'm ahead.
> > Unless I try as above and would I have to use
> > tabutils to get calculate-tab-href? Or is $path resolved correctly.
> >
>
> Actually I have to look in the code for that. If you do not get an
> error, than yes it resolves correctly. ;-)
>
> > > try localhost:8888/index.page
> >
> > thanks for the tip
> >
>
> What do you get?
Well my browser didn't render the xml but a view source showed what
looked like a concat of
skinconf
info
nav-main content
views
> > >
> > > > Thinking about it I'd just need to override class="base-selected" etc.
> > > > in css.
> > > >
> > > > Well that was more than a toe in the water as I first thought :) Let me
> > > > know if there are any valid points to raise a jira [1 & 2] above. 3 is
> > > > just a workshop for me as a beginner in views and xsl too.
> > > >
> > >
> > > :)
> > >
> > > Welcome to views.
> >
> > Thanks I'll have a go at the leftbar nav menus next?
> >
>
> If you keen to use views and willing to help, than I would give you some
> "homework". The benefit is that you will help forrest, yourself and can
> have a custom menu that is partly independent of the site.xml.
Well I'll try, what had you in mind? Forrest is just an interest hobby
in my spare time in the evening to learn new skills, on a slow dial up
connection too :(
> Have a look on the beautiful mail of Diwaker and the log of cheche from
> FT. I (tscherler or target{something}) talked with cheche what we have
> to do to enable that.
Sorry didn't understand that. Could you point me to the "homework" or an
outline here. Diwaker's mail - I probably missed it and the log?
Kevin
> Still interested? ;-)
> salu2
> > Kevin
> >
> > > salu2
> >
Re: New user of views.
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-09-07 at 22:09 +0100, Kevin wrote:
> On Wed, 2005-09-07 at 20:24 +0200, Thorsten Scherler wrote:
> > On Wed, 2005-09-07 at 18:12 +0100, Kevin wrote:
> > > Hi,
> > >
> > > I've dipped my toe in the water using views and thought I'd ask
> > > here before raising a jira. Also this is my first thread on dev
> > > as a user so please bear with me.
> > >
> > > 1) Following instructions:
> > >
> > > forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.view/build/site/howItWork.html
> > > RESUME part b)
> > > ...
> > > copy the default.fv
> > > from the viewHelper implementation to your ${project.conf-dir}
> > >
> > > I found it should go in
> > > src/documentation/content/xdocs
> > >
> >
> > That documentation is not actual anymore. We changed it a while ago.
> > Sorry for that confusion instruction, we are in the middle of
> > refactoring the view prototype.
> >
> > You will need to place it in your xdocs-dir.
> >
> > Please follow
> > http://forrest.apache.org/docs_0_80/howto/howto-view-dsl.html
> > instead.
>
> I did for following the index.fv example. Didn't see default.fv
> I'll do a fresh site-author.
>
No, it is not there. I will have to extend that how-to. It is on my todo
list but there are many thing on there. :/
> > > 2) Next I wanted to use my own css in that fv using <forrest:css> so
> > > in my xdocs/default.fv
> > >
> > > <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0" >
> > > <forrest:view type="xhtml">
> > > <forrest:css url="default.css"/>
> > > <forrest:css url="nav-main-hook.css"/>
> > > ...
> > >
> > > (I had successfuly implemented my own nav-main contract implementation)
> > >
> > > forrest site
> > >
> > > Will produce *.html with stylesheets with different titled <link>
> > > elements:
> > >
> > > <link href="skin/default.css" title="default.css" rel="stylesheet"
> > > type="text/css" />
> > > <link href="skin/nav-main-hook.css" title="nav-main-hook.css" rel="stylesheet" type="text/css" />
> > >
> > > So my nav-main-hook.css won't cascade.
> >
> > What do you mean?
>
> #nav-main-hook defined in nav-main-hook.css should override
> #nav-main-hook defined in default.css
>
Wait. css is working the way that what you define last it got matched.
Like you have it in your example it *should* get override! Try
commenting out default.fv. See what happens. I imagine you will see the
css for your nav. If that is the case then just copy the parts you need
of the default.css and create your own theme. That should work. ;-)
> > > I've used @title before with
> > > alternative stylesheets. So to get it to work I removed the @title. Or
> > > ensure they have the same name.
> >
> > Actually I reckon that is a bug, I am not sure, that part is new.
>
> I think it is a bug. Though I can rewrite default.css and add my
> nav-main-hook.css changes. Then put default.css in my skin/css as a
> work around. Then remove <forrest:css url="nav-main-hook.css"/> from
> the default.fv as it doesn't work.
>
Hmm, it should work, but I think it is a typical css behavior that you
are running into. The thing on css is that if you want to override
styles defined before you will need to reset them and define them
again.
Best is to do what you describe. You can name it BTW like you want, it
do not have to be called default.fv.
> > > I noticed the new pelt view uses
> > > alternative stylesheets (which will look good with some javascript to
> > > switch between :)
> >
> > :) Yeah should be simple to write a contract for that. ;-)
> >
> > > Though I haven't tried adding a <forrest:css> to
> > > a fv and check what happens.
> >
> > ¿? Your example above has forrest:css in the default.fv.
>
> Yes but I didn't try it in the new pelt view.
>
Views are all the same. They only define structure and the theme (*.css)
to use. BTW make sure the <forrest:css/> are direct children of
<forrest:view/> otherwise it will not work!
> > >
> > > 3) How I see contracts at the moment are an override method of hooking
> > > into leather-dev xslt. A well defined interface but to what resolution
> > > can you go without knowing the internals? To explain what I mean, below
> > > is the addition to my custom nav-main.ft. If I wanted to get to the <a>
> > > element and define class="my-base-selected" it looks as if I'd have to
> > > borrow more from the leather-dev skin to get calculate-tab-href?
> > >
> >
> > The menu part is created from the book2menu.xsl of leather-dev, the tab
> > part of tab2menu.xsl. We are in the middle of refactoring that as well.
> > Anyway you will have to pick up what comes out of this transformation
> > and apply your custom transformation to it.
> >
> > > <!--
> > > Get rid of <ul> and <li> inline children and just leave <a> to style.
> > > HTML output like:
> > >
> > > <div id="tabs">
> > > <div id="nav-main">
> > > <a class="base-not-selected" href="tab1.html">Tab 1</a>
> > > <a class="base-selected" href="tab2.html">Tab 2</a>
> > > </div>
> > > </div>
> > > -->
> > > <xsl:template match="ul[@id='nav-main']">
> > > <div id="nav-main">
> > > <xsl:apply-templates select="li"/>
> > > </div>
> > > </xsl:template>
> > >
> > > <xsl:template match="li[@class='current']">
> > > <a class="base-selected">
> > > <xsl:attribute name="href">
> > > <!--
> > > Need calculate-tab-href? How did param $path get here?
> > > <xsl:call-template name="calculate-tab-href">
> > > <xsl:with-param name="tab" select="."/>
> > > <xsl:with-param name="path" select="$path"/>
> > > </xsl:call-template>
> > > -->
> > > <xsl:value-of select="$path"/>
> > > </xsl:attribute>
> > > <xsl:value-of select="."/>
> > > </a>
> > > </xsl:template>
> > >
> > > <xsl:template match="li[not(@class)]">
> > > <xsl:apply-templates/>
> > > </xsl:template>
> >
> > Looks good. Yes, views are still heavily borrow stuff from the skins.
> > $path is in one of the imports that happens in the background.
> >
> > >
> > > At the moment the first match="li[@class='current']" works but probably
> > > by luck as I have no subdirs. I'd be interested in the correct way or
> > > am I off track. Anyway I don't need to do this it is just an exercise.
> > >
> > > I just do <xsl:apply-templates/> as in the second match and let the
> > > leather-dev xsl work it out.
> > >
> >
> > Hmm, actually leather-dev is before view comes into place. Views is
> > simply overriding the stuff from leather. You can see the page that is
> > coming in as input by using the *.page extension. That is plain xml and
> > actually the document that then get transformed by views.
>
> <xsl:template match="li[not(@class)]">
> <xsl:apply-templates/>
> </xsl:template>
>
> leather-dev is before view to pass me <li> which I get rid of but
> <xsl:apply-templates/> will transform the <a> back in a leather-dev
> template somewhere.
No and yes. No, it applies all templates after that
match="li[not(@class)]". Yes because applying all templates mean that
you go back to the *.page. What you should try is <xsl:apply-templates
select="*"/>
> Unless I try as above and would I have to use
> tabutils to get calculate-tab-href? Or is $path resolved correctly.
>
Actually I have to look in the code for that. If you do not get an
error, than yes it resolves correctly. ;-)
> > try localhost:8888/index.page
>
> thanks for the tip
>
What do you get?
> >
> > > Thinking about it I'd just need to override class="base-selected" etc.
> > > in css.
> > >
> > > Well that was more than a toe in the water as I first thought :) Let me
> > > know if there are any valid points to raise a jira [1 & 2] above. 3 is
> > > just a workshop for me as a beginner in views and xsl too.
> > >
> >
> > :)
> >
> > Welcome to views.
>
> Thanks I'll have a go at the leftbar nav menus next?
>
If you keen to use views and willing to help, than I would give you some
"homework". The benefit is that you will help forrest, yourself and can
have a custom menu that is partly independent of the site.xml.
Have a look on the beautiful mail of Diwaker and the log of cheche from
FT. I (tscherler or target{something}) talked with cheche what we have
to do to enable that.
Still interested? ;-)
salu2
> Kevin
>
> > salu2
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: New user of views.
Posted by Kevin <fo...@kegcl.demon.co.uk>.
On Wed, 2005-09-07 at 20:24 +0200, Thorsten Scherler wrote:
> On Wed, 2005-09-07 at 18:12 +0100, Kevin wrote:
> > Hi,
> >
> > I've dipped my toe in the water using views and thought I'd ask
> > here before raising a jira. Also this is my first thread on dev
> > as a user so please bear with me.
> >
> > 1) Following instructions:
> >
> > forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.view/build/site/howItWork.html
> > RESUME part b)
> > ...
> > copy the default.fv
> > from the viewHelper implementation to your ${project.conf-dir}
> >
> > I found it should go in
> > src/documentation/content/xdocs
> >
>
> That documentation is not actual anymore. We changed it a while ago.
> Sorry for that confusion instruction, we are in the middle of
> refactoring the view prototype.
>
> You will need to place it in your xdocs-dir.
>
> Please follow
> http://forrest.apache.org/docs_0_80/howto/howto-view-dsl.html
> instead.
I did for following the index.fv example. Didn't see default.fv
I'll do a fresh site-author.
> > 2) Next I wanted to use my own css in that fv using <forrest:css> so
> > in my xdocs/default.fv
> >
> > <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0" >
> > <forrest:view type="xhtml">
> > <forrest:css url="default.css"/>
> > <forrest:css url="nav-main-hook.css"/>
> > ...
> >
> > (I had successfuly implemented my own nav-main contract implementation)
> >
> > forrest site
> >
> > Will produce *.html with stylesheets with different titled <link>
> > elements:
> >
> > <link href="skin/default.css" title="default.css" rel="stylesheet"
> > type="text/css" />
> > <link href="skin/nav-main-hook.css" title="nav-main-hook.css" rel="stylesheet" type="text/css" />
> >
> > So my nav-main-hook.css won't cascade.
>
> What do you mean?
#nav-main-hook defined in nav-main-hook.css should override
#nav-main-hook defined in default.css
> > I've used @title before with
> > alternative stylesheets. So to get it to work I removed the @title. Or
> > ensure they have the same name.
>
> Actually I reckon that is a bug, I am not sure, that part is new.
I think it is a bug. Though I can rewrite default.css and add my
nav-main-hook.css changes. Then put default.css in my skin/css as a
work around. Then remove <forrest:css url="nav-main-hook.css"/> from
the default.fv as it doesn't work.
> > I noticed the new pelt view uses
> > alternative stylesheets (which will look good with some javascript to
> > switch between :)
>
> :) Yeah should be simple to write a contract for that. ;-)
>
> > Though I haven't tried adding a <forrest:css> to
> > a fv and check what happens.
>
> ¿? Your example above has forrest:css in the default.fv.
Yes but I didn't try it in the new pelt view.
> >
> > 3) How I see contracts at the moment are an override method of hooking
> > into leather-dev xslt. A well defined interface but to what resolution
> > can you go without knowing the internals? To explain what I mean, below
> > is the addition to my custom nav-main.ft. If I wanted to get to the <a>
> > element and define class="my-base-selected" it looks as if I'd have to
> > borrow more from the leather-dev skin to get calculate-tab-href?
> >
>
> The menu part is created from the book2menu.xsl of leather-dev, the tab
> part of tab2menu.xsl. We are in the middle of refactoring that as well.
> Anyway you will have to pick up what comes out of this transformation
> and apply your custom transformation to it.
>
> > <!--
> > Get rid of <ul> and <li> inline children and just leave <a> to style.
> > HTML output like:
> >
> > <div id="tabs">
> > <div id="nav-main">
> > <a class="base-not-selected" href="tab1.html">Tab 1</a>
> > <a class="base-selected" href="tab2.html">Tab 2</a>
> > </div>
> > </div>
> > -->
> > <xsl:template match="ul[@id='nav-main']">
> > <div id="nav-main">
> > <xsl:apply-templates select="li"/>
> > </div>
> > </xsl:template>
> >
> > <xsl:template match="li[@class='current']">
> > <a class="base-selected">
> > <xsl:attribute name="href">
> > <!--
> > Need calculate-tab-href? How did param $path get here?
> > <xsl:call-template name="calculate-tab-href">
> > <xsl:with-param name="tab" select="."/>
> > <xsl:with-param name="path" select="$path"/>
> > </xsl:call-template>
> > -->
> > <xsl:value-of select="$path"/>
> > </xsl:attribute>
> > <xsl:value-of select="."/>
> > </a>
> > </xsl:template>
> >
> > <xsl:template match="li[not(@class)]">
> > <xsl:apply-templates/>
> > </xsl:template>
>
> Looks good. Yes, views are still heavily borrow stuff from the skins.
> $path is in one of the imports that happens in the background.
>
> >
> > At the moment the first match="li[@class='current']" works but probably
> > by luck as I have no subdirs. I'd be interested in the correct way or
> > am I off track. Anyway I don't need to do this it is just an exercise.
> >
> > I just do <xsl:apply-templates/> as in the second match and let the
> > leather-dev xsl work it out.
> >
>
> Hmm, actually leather-dev is before view comes into place. Views is
> simply overriding the stuff from leather. You can see the page that is
> coming in as input by using the *.page extension. That is plain xml and
> actually the document that then get transformed by views.
<xsl:template match="li[not(@class)]">
<xsl:apply-templates/>
</xsl:template>
leather-dev is before view to pass me <li> which I get rid of but
<xsl:apply-templates/> will transform the <a> back in a leather-dev
template somewhere. Unless I try as above and would I have to use
tabutils to get calculate-tab-href? Or is $path resolved correctly.
> try localhost:8888/index.page
thanks for the tip
>
> > Thinking about it I'd just need to override class="base-selected" etc.
> > in css.
> >
> > Well that was more than a toe in the water as I first thought :) Let me
> > know if there are any valid points to raise a jira [1 & 2] above. 3 is
> > just a workshop for me as a beginner in views and xsl too.
> >
>
> :)
>
> Welcome to views.
Thanks I'll have a go at the leftbar nav menus next?
Kevin
> salu2
Re: New user of views.
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-09-07 at 18:12 +0100, Kevin wrote:
> Hi,
>
> I've dipped my toe in the water using views and thought I'd ask
> here before raising a jira. Also this is my first thread on dev
> as a user so please bear with me.
>
> 1) Following instructions:
>
> forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.view/build/site/howItWork.html
> RESUME part b)
> ...
> copy the default.fv
> from the viewHelper implementation to your ${project.conf-dir}
>
> I found it should go in
> src/documentation/content/xdocs
>
That documentation is not actual anymore. We changed it a while ago.
Sorry for that confusion instruction, we are in the middle of
refactoring the view prototype.
You will need to place it in your xdocs-dir.
Please follow
http://forrest.apache.org/docs_0_80/howto/howto-view-dsl.html
instead.
> 2) Next I wanted to use my own css in that fv using <forrest:css> so
> in my xdocs/default.fv
>
> <forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0" >
> <forrest:view type="xhtml">
> <forrest:css url="default.css"/>
> <forrest:css url="nav-main-hook.css"/>
> ...
>
> (I had successfuly implemented my own nav-main contract implementation)
>
> forrest site
>
> Will produce *.html with stylesheets with different titled <link>
> elements:
>
> <link href="skin/default.css" title="default.css" rel="stylesheet"
> type="text/css" />
> <link href="skin/nav-main-hook.css" title="nav-main-hook.css" rel="stylesheet" type="text/css" />
>
> So my nav-main-hook.css won't cascade.
What do you mean?
> I've used @title before with
> alternative stylesheets. So to get it to work I removed the @title. Or
> ensure they have the same name.
Actually I reckon that is a bug, I am not sure, that part is new.
> I noticed the new pelt view uses
> alternative stylesheets (which will look good with some javascript to
> switch between :)
:) Yeah should be simple to write a contract for that. ;-)
> Though I haven't tried adding a <forrest:css> to
> a fv and check what happens.
¿? Your example above has forrest:css in the default.fv.
>
> 3) How I see contracts at the moment are an override method of hooking
> into leather-dev xslt. A well defined interface but to what resolution
> can you go without knowing the internals? To explain what I mean, below
> is the addition to my custom nav-main.ft. If I wanted to get to the <a>
> element and define class="my-base-selected" it looks as if I'd have to
> borrow more from the leather-dev skin to get calculate-tab-href?
>
The menu part is created from the book2menu.xsl of leather-dev, the tab
part of tab2menu.xsl. We are in the middle of refactoring that as well.
Anyway you will have to pick up what comes out of this transformation
and apply your custom transformation to it.
> <!--
> Get rid of <ul> and <li> inline children and just leave <a> to style.
> HTML output like:
>
> <div id="tabs">
> <div id="nav-main">
> <a class="base-not-selected" href="tab1.html">Tab 1</a>
> <a class="base-selected" href="tab2.html">Tab 2</a>
> </div>
> </div>
> -->
> <xsl:template match="ul[@id='nav-main']">
> <div id="nav-main">
> <xsl:apply-templates select="li"/>
> </div>
> </xsl:template>
>
> <xsl:template match="li[@class='current']">
> <a class="base-selected">
> <xsl:attribute name="href">
> <!--
> Need calculate-tab-href? How did param $path get here?
> <xsl:call-template name="calculate-tab-href">
> <xsl:with-param name="tab" select="."/>
> <xsl:with-param name="path" select="$path"/>
> </xsl:call-template>
> -->
> <xsl:value-of select="$path"/>
> </xsl:attribute>
> <xsl:value-of select="."/>
> </a>
> </xsl:template>
>
> <xsl:template match="li[not(@class)]">
> <xsl:apply-templates/>
> </xsl:template>
Looks good. Yes, views are still heavily borrow stuff from the skins.
$path is in one of the imports that happens in the background.
>
> At the moment the first match="li[@class='current']" works but probably
> by luck as I have no subdirs. I'd be interested in the correct way or
> am I off track. Anyway I don't need to do this it is just an exercise.
>
> I just do <xsl:apply-templates/> as in the second match and let the
> leather-dev xsl work it out.
>
Hmm, actually leather-dev is before view comes into place. Views is
simply overriding the stuff from leather. You can see the page that is
coming in as input by using the *.page extension. That is plain xml and
actually the document that then get transformed by views.
try localhost:8888/index.page
> Thinking about it I'd just need to override class="base-selected" etc.
> in css.
>
> Well that was more than a toe in the water as I first thought :) Let me
> know if there are any valid points to raise a jira [1 & 2] above. 3 is
> just a workshop for me as a beginner in views and xsl too.
>
:)
Welcome to views.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
New user of views.
Posted by Kevin <fo...@kegcl.demon.co.uk>.
Hi,
I've dipped my toe in the water using views and thought I'd ask
here before raising a jira. Also this is my first thread on dev
as a user so please bear with me.
1) Following instructions:
forrest/whiteboard/plugins/org.apache.forrest.plugin.internal.view/build/site/howItWork.html
RESUME part b)
...
copy the default.fv
from the viewHelper implementation to your ${project.conf-dir}
I found it should go in
src/documentation/content/xdocs
2) Next I wanted to use my own css in that fv using <forrest:css> so
in my xdocs/default.fv
<forrest:views xmlns:forrest="http://apache.org/forrest/templates/1.0" >
<forrest:view type="xhtml">
<forrest:css url="default.css"/>
<forrest:css url="nav-main-hook.css"/>
...
(I had successfuly implemented my own nav-main contract implementation)
forrest site
Will produce *.html with stylesheets with different titled <link>
elements:
<link href="skin/default.css" title="default.css" rel="stylesheet"
type="text/css" />
<link href="skin/nav-main-hook.css" title="nav-main-hook.css" rel="stylesheet" type="text/css" />
So my nav-main-hook.css won't cascade. I've used @title before with
alternative stylesheets. So to get it to work I removed the @title. Or
ensure they have the same name. I noticed the new pelt view uses
alternative stylesheets (which will look good with some javascript to
switch between :) Though I haven't tried adding a <forrest:css> to
a fv and check what happens.
3) How I see contracts at the moment are an override method of hooking
into leather-dev xslt. A well defined interface but to what resolution
can you go without knowing the internals? To explain what I mean, below
is the addition to my custom nav-main.ft. If I wanted to get to the <a>
element and define class="my-base-selected" it looks as if I'd have to
borrow more from the leather-dev skin to get calculate-tab-href?
<!--
Get rid of <ul> and <li> inline children and just leave <a> to style.
HTML output like:
<div id="tabs">
<div id="nav-main">
<a class="base-not-selected" href="tab1.html">Tab 1</a>
<a class="base-selected" href="tab2.html">Tab 2</a>
</div>
</div>
-->
<xsl:template match="ul[@id='nav-main']">
<div id="nav-main">
<xsl:apply-templates select="li"/>
</div>
</xsl:template>
<xsl:template match="li[@class='current']">
<a class="base-selected">
<xsl:attribute name="href">
<!--
Need calculate-tab-href? How did param $path get here?
<xsl:call-template name="calculate-tab-href">
<xsl:with-param name="tab" select="."/>
<xsl:with-param name="path" select="$path"/>
</xsl:call-template>
-->
<xsl:value-of select="$path"/>
</xsl:attribute>
<xsl:value-of select="."/>
</a>
</xsl:template>
<xsl:template match="li[not(@class)]">
<xsl:apply-templates/>
</xsl:template>
At the moment the first match="li[@class='current']" works but probably
by luck as I have no subdirs. I'd be interested in the correct way or
am I off track. Anyway I don't need to do this it is just an exercise.
I just do <xsl:apply-templates/> as in the second match and let the
leather-dev xsl work it out.
Thinking about it I'd just need to override class="base-selected" etc.
in css.
Well that was more than a toe in the water as I first thought :) Let me
know if there are any valid points to raise a jira [1 & 2] above. 3 is
just a workshop for me as a beginner in views and xsl too.
Kevin