[Seaside] state of the aubergine

Nevin Pratt nevin@smalltalkpro.com
Mon, 22 Apr 2002 19:40:17 -0600


Avi Bryant wrote:

>
>Ok, if you have relative urls for those images, they're not going to work
>*quite* that simply - obviously if your url is
>http://www.test.com/seaside/pastword/some/other/stuff, and you have
><img src="foo.gif">, that's not going to come out as
>http://test.com/foo.gif the way you want it to.
>
>You need to let Seaside modify that url, which means putting an @ sign in
>there, like this: <img src="@foo.gif">.  Hopefully that's an acceptable
>change to make.
>
>You'll also need to tell the Seaside app where your images are stored (eg,
>http://test.com/), so go into the configuration page for your pastwork app
>and set the document root to that url (or just '/' should work here).
>Programmtically, that's
>  (IAApplication at: 'pastwork') documentRoot: '/'.
>
>This make sense?
>
>Avi
>


Well, nobody dumps ALL of their images in just one directory.  They will 
always be scattered among a number of subordinate directories-- not just 
one.  Therefore, the mechanism used needs to be able to follow a path 
down from the docRoot.  And that doesn't seem to be supported (i.e., 
<img src="@path/image.jpg"> won't work).

I'm still inclined to change the "IAKom" code (actually, I've called it 
"IAComancheInterface" as to not touch the original IAKom) to hack out 
the seaside portion of the URL it sees when the end of the URL is ".jpg" 
or ".gif".  After all, I can't think of anytime such a URL should *not* 
be statically served.  Can you?

For example, wouldn't you *always* want <img src="foo.gif"> statically 
served?  If you wanted it dynamically served, wouldn't you instead write 
<img src="@foo">, and not have the ".gif" extension?

Likewise, wouldn't you *always* want <img src="images/foo.gif"> 
statically served?  Again, if you wanted seaside to dynamically serve 
it, wouldn't you *always* write something like <img src="@foo"> instead? 
(thus ommitting not only the trailing ".gif", but also the leading 
"images/" portion)

In other words, when using Comanche with Seaside, I would think that 
static images should be handled entirely by Comanche and not involve 
Seaside at all.  But there doesn't seem to be any way to do that while 
simultaneously driving the html from the #html method of the seaside 
app, unless the Comanche/Seaside interface detects the ".jpg" or ".gif" 
extension and hacks out the seaside portion of the URL so that Comanche 
can handle it.

I see the same issues if you instead use Apache with Seaside.  The 
problem is that Seaside doesn't integrate static content very well with 
its way of doing things (although for purely dynamic content, Seaside 
seems top notch).

Or at least, that's how it is all appearing to me.  I'd love to be 
corrected, though :-)

Nevin