forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piroumian Konstantin <KPiroum...@protek.com>
Subject RE: build path variable
Date Fri, 21 Jun 2002 15:12:33 GMT
> 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.

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

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

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

[...]

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

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

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