Ferdinand Soethe wrote:
Brian M Dube wrote:
Absolute references in the final output should also help with caching at
the proxy and browser level. As I understand it, caching proxies will
Thanks Brian. I was not aware of that behavior. That is indeed a very
good reason not to use them. Coul
El jue, 20-04-2006 a las 10:12 +0100, Ross Gardler escribió:
> Thorsten Scherler wrote:
> > El jue, 20-04-2006 a las 10:40 +0200, Ferdinand Soethe escribió:
> >
> >>Ross Gardler wrote:
> >>
> >>
> >>>Am I helping or confusing?
> >>
> >>Helping (me), thanks.
> >>
> >>
> >>Still, I'm looking at this
Thorsten Scherler wrote:
El jue, 20-04-2006 a las 10:40 +0200, Ferdinand Soethe escribió:
Ross Gardler wrote:
Am I helping or confusing?
Helping (me), thanks.
Still, I'm looking at this and wonder.
It seems to me like these cascades create a behavior that is very hard to
predict by the
El jue, 20-04-2006 a las 10:40 +0200, Ferdinand Soethe escribió:
> Ross Gardler wrote:
>
> > Am I helping or confusing?
> Helping (me), thanks.
>
>
> Still, I'm looking at this and wonder.
>
> It seems to me like these cascades create a behavior that is very hard to
> predict by the user. And p
Ross Gardler wrote:
> Am I helping or confusing?
Helping (me), thanks.
Still, I'm looking at this and wonder.
It seems to me like these cascades create a behavior that is very hard to
predict by the user. And probably - unless you really study that
sitemap - for many developers as well.
Shoul
Ferdinand Soethe wrote:
Looking at 0.7 resources.xmap I'm trying to understand the cascade:
1 and 3 are clear. Check
Looking at 0.7 resources.xmap I'm trying to understand the cascade:
1 and 3 are clear. Check for image file in images
Brian M Dube wrote:
> Absolute references in the final output should also help with caching at
> the proxy and browser level. As I understand it, caching proxies will
Thanks Brian. I was not aware of that behavior. That is indeed a very
good reason not to use them. Could you refer me to any mor
Brian M Dube wrote:
> David Crossley wrote:
> >Using references like /images/icon.png is the way to go.
> >I just tried it with 0.8-dev in 'forrest seed site' and
> >it correctly finds image sources in either resources/images/
> >or in xdocs/images/ directories. Sub-directories also works.
> >There
David Crossley wrote:
Using references like /images/icon.png is the way to go.
I just tried it with 0.8-dev in 'forrest seed site' and
it correctly finds image sources in either resources/images/
or in xdocs/images/ directories. Sub-directories also works.
There is no need for any special sitemap
Ferdinand Soethe wrote:
> Ross Gardler wrote:
>
> > Don't use relative paths would be my first thought. Forrest is designed
> > to not need them since relative paths break easily when a file is moved.
>
> > However, I'm guessing that this is legacy content being imported and so
> > you don't have
Ferdinand Soethe wrote:
Ross Gardler wrote:
Don't use relative paths would be my first thought. Forrest is designed
to not need them since relative paths break easily when a file is moved.
However, I'm guessing that this is legacy content being imported and so
you don't have such control.
Ross Gardler wrote:
> Don't use relative paths would be my first thought. Forrest is designed
> to not need them since relative paths break easily when a file is moved.
> However, I'm guessing that this is legacy content being imported and so
> you don't have such control.
Thanks.
It is actua
Ferdinand Soethe wrote:
I found that Forrest 0.7x will generate content above (in the parent
dirs of) the build/site directory if documents in xdocs contain
relative links to images with too many ../'s.
Example:
A document in (1) references an embedded image file located in
with (2) as "../../i
I found that Forrest 0.7x will generate content above (in the parent
dirs of) the build/site directory if documents in xdocs contain
relative links to images with too many ../'s.
Example:
A document in (1) references an embedded image file located in
with (2) as "../../images/dozenten/imagexyz.g
15 matches
Mail list logo