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