forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bert Van Kets <b...@vankets.com>
Subject RE: build path variable
Date Fri, 21 Jun 2002 16:19:41 GMT
At 19:12 21/06/2002 +0400, you wrote:
> > From: Bert Van Kets [mailto:bert@vankets.com]
> > At 12:34 20/06/2002 +0400, you wrote:
> > > > From: Bert Van Kets [mailto:bert@vankets.com]
> > > >
> > > > This is a call to an Ant expert.
> > > > I was thinking of solving the hard coded path in the tabs.
> > > > To my opinion
> > > > the best solution is to get the path from Ant and use it in the
> > > > stylesheet.  I have been looking at the project.xtarget but
> > > > can't find the
> > > > parameter I can use in the stylesheet (something like
> > > > @build.path@).  I
> > > > have tried to use some variables with no succes.  This is why
> > > > I hard coded
> > > > it in the first place.
> > >
> > >I don't think that specifying the path info as a build
> > parameter is a good
> > >idea, but currently I have no idea how to solve it better. What about
> > >relative links? I know that this requires calculation of
> > relativeness for
> > >every nested level, but I don't think that it's impossible.
> > Will think about
> > >it ASAP.
> >
> > Relative links require a recalculation of the link on the tab
> > on every page.
> > Assuming that we use specified URI space for every TAB, is't
> > just a matter
> > of a "starts-with" to know the selected tab (works this way now).
> > The calculation of the link on the active (non selected) tabs
> > can be done
> > as following:
> >
> > Suppose we have
> > a download Tab with the URL
> > http://xml.apache.org/xml-forrest/downloads/index.html
> > and a page with the URL
> > http://xml.apache.org/xml-forrest/docs/howto/forms.html
> >
> > The link on the tab needs to go from the page to the tab's
> > main page (of
> > course).
> > The following steps need to be taken:
> > 1. drop the common part (here http://xml.apache.org/xml-forrest/)
>
>No need. You can get only the path part of the URL.

Right, I have to check out how though.  Haven't done this yet in Cocoon.


> > 2. calculate the difference in levels (number of "/"
> > characters), convert
> > to n times ../ to go up to the common level
>
>Yup
>
> > 3. add the target URL minus the common part (here
> > downloads/index.html)
> >
> > This results in ../../downloads/index.html, the correct relative path.
>
>Exactly
>
> >
> > I don't see how we can do this string parsing in XSLT, at
> > least without
> > knowing the host and the project directory (and this is why
> > we would use
> > the relative path, because we don't want to use them).  Is a
> > logicsheet in
> > order here, or has anyone a better solution?
>
>What about a stylesheet parameter passed from the sitemap? We can use a
>special matcher or an action for this.

Stefano was going on about actions this week.  He'd even like to kill them 
entirely.  I'll check out the matchers then ;-)


>The main advantage of using relative links is that one can simply generate a
>single version of the site then upload it to multiple servers, while with
>the build parameter you'll have to regenerate the site for all the servers.
>(This is not an issue if we have a single site location at
>xml.apache.org/forrest).

Exactly.  We'd also be able to test the generated docs from the filesytem 
instead of a web server.


>But after thinking a while I still see don't see a good way of generating
>correct content links except using relative paths, until Forrest will go
>dynamic (then we can use application context path, topic maps, etc.).
>
>[...]

Agree, relative paths is the only way to go.


> >
> > Wouldn't it be great if all the XML.apache projects would use
> > the same URI
> > structure.  No matter what project you are interested in, you
> > would be able
> > to go to the docs by typing xml.apache.org/[project]/docs.
>
>I think that this is one of the tasks that Forrest is going to solve (isn't
>the 'URI Namespace Management' from the Primer document about it too?)

Yes, it is.  I just want to keep it fresh in mind ;-)


> > Uniformity
> > amongst the projects will help usability a great deal and make the
> > xml.apache site as a whole a lot more popular.  Isn't this
> > what we are
> > aiming for?
>
>Don't know about popularity - it will be popular anyway, cause people need
>all that XML stuff, but having a better usability is definitely needed.
>
>One important thing that I miss much is a printable documentation for Cocoon
>(not the print_skinned pages, but a PDF document). Btw, why we don't have an
>downloadable archive with the docs?

Working on it.  I'm trying to get an xml:fo stylesheet running to convert 
xhtml to xsl:fo and then to PDF for my current project.
Once I'm up to speed with xsl:fo I'll check out the document2fo.xsl file 
and update it if necessary.  Adding it to the bert skin will be trivial.

Bert


>Konstantin
>
> >
> >
> > >I think that we should take a closer look at the libre and its
> > >possibilities.
> >
> > Will do.
> >
> > Bert
> >
> >
> > >Konstantin
> > >
> > > >
> > > > Bert
> > > >
> > > > --------------------------------------------------------------
> > > > -------------------------------
> > > > Please notify me if you did not receive this mail.
> > > >
> >


Mime
View raw message