forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
Subject Re: images, images and more images
Date Thu, 10 Jul 2003 13:19:25 GMT
On Thu, Jul 10, 2003 at 08:34:51AM -0400, Robert P. J. Day wrote:
> On Thu, 10 Jul 2003, Jeff Turner wrote:
> 
> > On Wed, Jul 09, 2003 at 09:40:40PM -0400, Robert P. J. Day wrote:
> 
> > >   ok, first point.  i found it initially confusing that the file
> > > "forrest.properties" defines an explicit project.images-dir directory,
> > > whose name is conveniently "images/", yet the references to images
> > > in skinconf.xml must (apparently) be listed relative to the parent
> > > "resources" directory.  this is not at all intuitive.
> > 
> > What should it be relative to?  If it helps, in 0.6 we're planning to
> > make it relative to content/.
> 
> one would think that, if the "forrest.properties" file defines an
> explicit directory called the images directory, why wouldn't it
> be relative to that?  what is the function of that option in the
> forrest.properties file, if not to identify where images are to be
> found?
...
> > Currently, project.images-dir locates the images directory in the
> > _source_.  Forrest then builds a webapp in the standardized format the
> > the sitemap expects.  In this standardized format, the directory is
> > always called 'images'.
> > 
> > The easiest way to see how things work is to build a webapp ('forrest
> > webapp'), and then look at the sitemaps. 
> 
> sorry, i'm not sure what you're saying here.  i'll go back and read
> the docs more carefully, but from my perspective as a newbie, i look
> at it as that my images *are* in the "source".  i just think this 
> distinction needs to be explained more carefully somehow.  as a newbie,
> if i see something identifying an images directory, i naturally assume
> that's where i should put my images and that's where the app will look
> for them.

And you'd be right.  The only thing is, within your XML, the
${project.images-dir} files are accessed with an 'images/' prefix.  Why?
Because in XML, you refer to other files by their _URL_, not their
filesystem location.  The Forrest sitemap maps from filesystem
(${project.images-dir}) to URL ('images/').  Thus, no matter where your
images appear on the filesystem, they will always be accessible with
'images/*' URLs.

Another example may help.  You mentioned the skin images/ directory.
Which skin is currently in use is determined by the ${project.skins-dir}
and ${project.skin} variables.  However, within the sitemap, skin images
are always available through the URL 'skin/images/...'.

Graphically:

    [ FILESYSTEM ]                                         [ URI SPACE ]

${project.images-dir}/...                -->  Forrest  --> 'images/...'
${project.skins-dir}/${project.skin}...  -->  Forrest  --> 'skins/images/...'

So in effect, Forrest sites are built on a virtual filesystem (the URL
space), not the _actual_ filesystem.  Every link (image or href) must be
to a URL, not a filesystem file.

...
> believe me, i flogged this for most of yesterday evening.

Ah, fun..

> if i replaced the reference to linuxpower.jpeg with a PNG file, it
> rendered nicely.  when i switched it back, the generated HTML *did*
> refer to the linuxpower file, but that file was never copied into the
> build/site hierarchy, thus no image.  so the generated HTML was, in
> fact, correct.  it was just the file that was never copied over.

As I'm sure you've noticed by now, Forrest's command-line rendering
sucks.  It is painfully slow business making a change, rerendering, then
checking the output.  For any sort of debugging work, I find its best to
launch a webapp ('forrest run'), then check the output on
http://localhost:8888/.  A temporary copy of the files can then be edited
in realtime in $PROJECT/build/webapp/

In your case, I think you would have found that the image was broken on
localhost:8888.  Cocoon never saw the image, so never spidered it, so
never copied it to build/site/.

> is there any possible way that this spidering fails to copy the .jpeg
> file, while successfully copying, say, a .png file?  i'll test it some
> more later today.

Btw, in the webapp, you can see exactly what links a page has by
requesting (say):

http://localhost:8888/index.html?cocoon-view=links

That should include all the images in the page.


--Jeff

> rday
> 
> --
> 
> Robert P. J. Day
> Eno River Technologies
> Unix, Linux and Open Source training
> Waterloo, Ontario
> 
> www.enoriver.com
> 

Mime
View raw message