updateRoot: Weirdness

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

This is totally INSANE!!! No matter what I do, I can’t get stylesheets to work in Seaside.

I even went back to the bare basics...

• I took a fresh copy of Squeak 3.9
• I put a fresh copy of Damien’s Seaside 2.7 image into the Squeak directory
• I put the CSS files colour.css and styles.css into the same directory (putting it in the root for simplicity)
• I subclass WAComponent to create GSTemplate
• I create class method #canBeRoot: for GSTemplate
• I create #updateRoot:
  

super updateRoot: aRoot.
aRoot linkToStyle: ‘/colour.css’.
aRoot linkToStyle: ‘/styles.css’

• I create some HTML in #renderContentOn:
• In Seaside config, I create application “NewApp” using GSTemplate
  

I ought to see the HTML rendered according to the specified stylesheets. What could be simpler?

But it doesn’t work!

And it worked in my original development image! For the life of me, I can’t see ANY difference between the original image and this one. What the hell is going on???

Richard


On 7/17/07 6:15 PM, "Richard K Eng" <[hidden email]> wrote:

Okay, in my Seaside 2.7 development image, I used updateRoot: to get my app to use CSS files in a particular location (using linkToStyle:). This works fine.
 
But now I'm trying to create a fresh image and the updateRoot: method is no longer having the intended effect--the CSS files are ignored. I must've "accidentally" got it working in the original image.
 
So the question is: How do I correctly apply updateRoot: to get my app to use CSS files?
 
Thanks,
Richard

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi All,

There's addToStartUpList:after: in SeasidePlatformSupport so that this
method can perform different on different dialects. I've noticed that
WAKom and WAListener call this method directly on Smalltalk while the
rest of the code uses SeasidePlatformSupport.

As well as that, addToShutDownList: doesn't exist on
SeasidePlatformSupport yet and so it is also called on Smalltalk.

Could this be changed so that SeasidePlatformSupport is used
consistently and addToShutDownList: is added to SeasidePlatformSupport ?

Cheers,
Michael
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/18, Michael Lucas-Smith <[hidden email]>:
> Hi All,
>
> There's addToStartUpList:after: in SeasidePlatformSupport so that this
> method can perform different on different dialects. I've noticed that
> WAKom and WAListener call this method directly on Smalltalk while the
> rest of the code uses SeasidePlatformSupport.

WAKom and WAListener are platform specific because they depend on Kom.
This is why they are located in Seaside-Platform.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 18 Jul 2007, at 08:01 , Michael Lucas-Smith wrote:

Hi Michael,

Some portions of the Seaside package are excluded from the port to  
VisualWorks. This includes WAKom and WAListener. Those things that  
are excluded from the port do not need the extra effort of using  
SeasidePlatformSupport, that's why they send their messages directly  
to Smalltalk. As far as I know, none of the ported portions of  
Seaside sends #addToShutDownList:, that's why this doesn't need an  
implementation in SeasidePlatformSupport.

Method #addToStartUpList:after: is no longer sent in the ported  
portions of Seaside. This method has now been removed from Squeak but  
not yet in Seaside. This is dead wood.

The rules for deciding what gets ported to VisualWorks and what  
doesn't are implemented by SeasideVWInfo and its superclasses.  
Basically, all classes from class category Seaside-Platform are  
excluded, all **extension** methods that include "-squeak" in their  
method category are excluded.

HTH,
Michel.
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Thanks for the tip.

Michel Bany wrote:
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Wednesday, July 18, 2007 3:59 AM

Subject: RE: [Seaside] updateRoot: Weirdness

Hi.

You probably need to enable file serve. You may have enabled it in your old image.

I’ve got this snippet of code from somewhere, possibly Ramon’ blog... can’t remember right now...

 

"Kill all existing Kom HTTP servers"

"Start a new server servering both static content and seaside apps"

| ma seaside |

HttpService allInstancesDo: [:each | each stop. each unregister].

seaside := WAKom default.

ma := ModuleAssembly core.

ma serverRoot: (FileDirectory default directoryNamed: 'FileRoot') fullName.

ma alias: '/seaside' to: [ma addPlug: [:request | seaside process: request]].

ma documentRoot: (FileDirectory default directoryNamed: 'FileRoot') fullName.

ma directoryIndex: 'index.html index.htm'.

ma serveFiles.

(HttpService startOn: 8080 named: 'httpd') plug: ma rootModule.

 

Hope it works

Liliana

 

 

From: Richard Eng [mailto:[hidden email]]
Sent: 18 July 2007 06:44 AM
To: Seaside - general discussion
Subject: Re: [Seaside] updateRoot: Weirdness

 

This is totally INSANE!!! No matter what I do, I can’t get stylesheets to work in Seaside.

I even went back to the bare basics...

• I took a fresh copy of Squeak 3.9
• I put a fresh copy of Damien’s Seaside 2.7 image into the Squeak directory
• I put the CSS files colour.css and styles.css into the same directory (putting it in the root for simplicity)
• I subclass WAComponent to create GSTemplate
• I create class method #canBeRoot: for GSTemplate
• I create #updateRoot:

super updateRoot: aRoot.
aRoot linkToStyle: ‘/colour.css’.
aRoot linkToStyle: ‘/styles.css’

• I create some HTML in #renderContentOn:
• In Seaside config, I create application “NewApp” using GSTemplate

I ought to see the HTML rendered according to the specified stylesheets. What could be simpler?

But it doesn’t work!

And it worked in my original development image! For the life of me, I can’t see ANY difference between the original image and this one. What the hell is going on???

Richard


On 7/17/07 6:15 PM, "Richard K Eng" <[hidden email]> wrote:

Okay, in my Seaside 2.7 development image, I used updateRoot: to get my app to use CSS files in a particular location (using linkToStyle:). This works fine.
 
But now I'm trying to create a fresh image and the updateRoot: method is no longer having the intended effect--the CSS files are ignored. I must've "accidentally" got it working in the original image.
 
So the question is: How do I correctly apply updateRoot: to get my app to use CSS files?
 
Thanks,
Richard

---

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Wednesday, July 18, 2007 3:59 AM

Subject: RE: [Seaside] updateRoot: Weirdness

Hi.

You probably need to enable file serve. You may have enabled it in your old image.

I’ve got this snippet of code from somewhere, possibly Ramon’ blog... can’t remember right now...

 

"Kill all existing Kom HTTP servers"

"Start a new server servering both static content and seaside apps"

| ma seaside |

HttpService allInstancesDo: [:each | each stop. each unregister].

seaside := WAKom default.

ma := ModuleAssembly core.

ma serverRoot: (FileDirectory default directoryNamed: 'FileRoot') fullName.

ma alias: '/seaside' to: [ma addPlug: [:request | seaside process: request]].

ma documentRoot: (FileDirectory default directoryNamed: 'FileRoot') fullName.

ma directoryIndex: 'index.html index.htm'.

ma serveFiles.

(HttpService startOn: 8080 named: 'httpd') plug: ma rootModule.

 

Hope it works

Liliana

 

 

From: Richard Eng [mailto:[hidden email]]
Sent: 18 July 2007 06:44 AM
To: Seaside - general discussion
Subject: Re: [Seaside] updateRoot: Weirdness

 

This is totally INSANE!!! No matter what I do, I can’t get stylesheets to work in Seaside.

I even went back to the bare basics...

• I took a fresh copy of Squeak 3.9
• I put a fresh copy of Damien’s Seaside 2.7 image into the Squeak directory
• I put the CSS files colour.css and styles.css into the same directory (putting it in the root for simplicity)
• I subclass WAComponent to create GSTemplate
• I create class method #canBeRoot: for GSTemplate
• I create #updateRoot:

super updateRoot: aRoot.
aRoot linkToStyle: ‘/colour.css’.
aRoot linkToStyle: ‘/styles.css’

• I create some HTML in #renderContentOn:
• In Seaside config, I create application “NewApp” using GSTemplate

I ought to see the HTML rendered according to the specified stylesheets. What could be simpler?

But it doesn’t work!

And it worked in my original development image! For the life of me, I can’t see ANY difference between the original image and this one. What the hell is going on???

Richard


On 7/17/07 6:15 PM, "Richard K Eng" <[hidden email]> wrote:

Okay, in my Seaside 2.7 development image, I used updateRoot: to get my app to use CSS files in a particular location (using linkToStyle:). This works fine.
 
But now I'm trying to create a fresh image and the updateRoot: method is no longer having the intended effect--the CSS files are ignored. I must've "accidentally" got it working in the original image.
 
So the question is: How do I correctly apply updateRoot: to get my app to use CSS files?
 
Thanks,
Richard

---

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Wednesday, July 18, 2007 8:44 AM

Subject: Re: [Seaside] updateRoot: Weirdness

Okay, here's a further hint as to what's going on...

 

If I run the code snippet below in my original development image, the stylesheets STOP WORKING! So I think it *is* related somehow to the configuration of the web server. But I don't know how or what's missing. Any ideas?

 

Thanks.

 

Regards,

Richard

 

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Wednesday, July 18, 2007 3:59 AM

Subject: RE: [Seaside] updateRoot: Weirdness

Hi.

You probably need to enable file serve. You may have enabled it in your old image.

I’ve got this snippet of code from somewhere, possibly Ramon’ blog... can’t remember right now...

 

"Kill all existing Kom HTTP servers"

"Start a new server servering both static content and seaside apps"

| ma seaside |

HttpService allInstancesDo: [:each | each stop. each unregister].

seaside := WAKom default.

ma := ModuleAssembly core.

ma serverRoot: (FileDirectory default directoryNamed: 'FileRoot') fullName.

ma alias: '/seaside' to: [ma addPlug: [:request | seaside process: request]].

ma documentRoot: (FileDirectory default directoryNamed: 'FileRoot') fullName.

ma directoryIndex: 'index.html index.htm'.

ma serveFiles.

(HttpService startOn: 8080 named: 'httpd') plug: ma rootModule.

 

Hope it works

Liliana

 

 

From: Richard Eng [mailto:[hidden email]]
Sent: 18 July 2007 06:44 AM
To: Seaside - general discussion
Subject: Re: [Seaside] updateRoot: Weirdness

 

This is totally INSANE!!! No matter what I do, I can’t get stylesheets to work in Seaside.

I even went back to the bare basics...

• I took a fresh copy of Squeak 3.9
• I put a fresh copy of Damien’s Seaside 2.7 image into the Squeak directory
• I put the CSS files colour.css and styles.css into the same directory (putting it in the root for simplicity)
• I subclass WAComponent to create GSTemplate
• I create class method #canBeRoot: for GSTemplate
• I create #updateRoot:

super updateRoot: aRoot.
aRoot linkToStyle: ‘/colour.css’.
aRoot linkToStyle: ‘/styles.css’

• I create some HTML in #renderContentOn:
• In Seaside config, I create application “NewApp” using GSTemplate

I ought to see the HTML rendered according to the specified stylesheets. What could be simpler?

But it doesn’t work!

And it worked in my original development image! For the life of me, I can’t see ANY difference between the original image and this one. What the hell is going on???

Richard


On 7/17/07 6:15 PM, "Richard K Eng" <[hidden email]> wrote:

Okay, in my Seaside 2.7 development image, I used updateRoot: to get my app to use CSS files in a particular location (using linkToStyle:). This works fine.
 
But now I'm trying to create a fresh image and the updateRoot: method is no longer having the intended effect--the CSS files are ignored. I must've "accidentally" got it working in the original image.
 
So the question is: How do I correctly apply updateRoot: to get my app to use CSS files?
 
Thanks,
Richard

---

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

---

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Richard,

Why not use Apache as web server for static files?
At least for production, I highly recommend doing so, especially if  
you also serve large files.

Adrian

On Jul 18, 2007, at 15:37 , Richard K Eng wrote:

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Richard K Eng wrote:
>  
>  
> Seems like the configuring of the web server is very arcane and
> touchy! I'm going to have the above emblazoned on my forehead...  :-)
>  
> Regards,
> Richard

Yes, the Comanche web server is a pain.  After having spent the time to
figure it out I like it and hate it at the same time ;-)  BTW, all of
those examples refer directly to WAKom.  You probably want
WAKomEncoded39 if you're working in a Squeak3.9 image.

Most Seaside beginners who've had web experience like the idea of having
static resources on their file system but many seasoned Seasiders seem
to use WAFileLibrary to serve static resources during development.  
There are examples in the image...probably wouldn't take you long to
figure it out.  This avoids having to know anything about Comanche and
has the advantage(?) of having all of your "static" resources in your
Smalltalk image.  That way your static resources get versioned in
Monticello along with your Smalltalk code.

For deployment most people use a front end web server to serve static
files.  There was a blog post somewhere which showed a pretty nifty
apache hack which automatically "cached" (for lack of a better word)
file library resources.  In any case using file library makes deployment
a bit more complicated.  I've used the "static resources on the file
system" for all of my projects sans one and I think I still prefer it
simply for the ease of deployment.  Maybe this can be solved?

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I've seen a couple of blog posts about running Seaside with Apache. I'm a
little confused, though. Are you supposed to stop WAKom and have Seaside use
Apache instead? I'm not sure how to do this. The instructions don't make it
clear.

Thanks,
Richard


On 7/18/07 10:31 AM, "David Shaffer" <[hidden email]> wrote:


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Richard Eng wrote:
> I've seen a couple of blog posts about running Seaside with Apache. I'm a
> little confused, though. Are you supposed to stop WAKom and have Seaside use
> Apache instead? I'm not sure how to do this. The instructions don't make it
> clear.
>
> Thanks,
> Richard
>
>  
Not typically.  You have both apache and Comanche (Squeak) web servers
running.  You configure apache to proxy requests, usually based on the
path or host name, to seaside as needed.  There are lots of examples of
this out there:

http://onsmalltalk.com/programming/smalltalk/running-seaside-apache-and-iis-on-windowsxp/

http://tekkie.wordpress.com/2006/10/24/configuring-and-managing-seaside/

http://liststest.squeakfoundation.org/pipermail/seaside/2006-February/006841.html

http://www.motionobj.com/seasidefaq/ServeStaticFilesWithApache

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Also,

http://leftshore.wordpress.com/2006/10/27/hint-setting-up-apache-proxy-f
or-your-seaside-host/

Short,

http://tinyurl.com/yyc8oz

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of David Shaffer
> Sent: Wednesday, July 18, 2007 9:58 AM
> To: Seaside - general discussion
> Subject: Re: [Seaside] updateRoot: Weirdness
>
> Richard Eng wrote:
> > I've seen a couple of blog posts about running Seaside with Apache.
I'm
> a
> > little confused, though. Are you supposed to stop WAKom and have
Seaside
> use
> > Apache instead? I'm not sure how to do this. The instructions don't
make of
> this out there:
>
>
http://onsmalltalk.com/programming/smalltalk/running-seaside-apache-and-
> iis-on-windowsxp/
>
>
http://tekkie.wordpress.com/2006/10/24/configuring-and-managing-seaside/_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Does this offer performace benefits as such, or is that Apache provides the infrastructure for a scalable configuration?



_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Marcin Tustin wrote:
> Does this offer performace benefits as such, or is that Apache
> provides the infrastructure for a scalable configuration?
>
Both.

First, Squeak is fairly bad at serving static content (whether using
File Libraries or Comanche directly) so having a front-end web server
(apache, lighthttpd etc) can often times improve the user's perception
of the responsiveness of your application.  See
http://wiki.squeak.org/squeak/539

Second, Seaside can be fairly memory and CPU intensive so having a means
to load balance across multiple images or machines is useful.  Apache,
lighthttpd, HAProxy just a few of the long list of possible
load-balancing solutions.  I've used apache quite a bit so I tend to
refer to it more than the alternatives.  Normally I like a single static
file server/proxy/load balancer but I've seen people use various
combinations.  For example:

http://onsmalltalk.com/programming/smalltalk/scaling-seaside-redux-enter-the-penguin/

uses apache and HAProxy.

David

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I don't think that  everyone is interested in being an expert at
configuring wierdo linux technologies. I myself have no intention of
ever having to write apache rewrite rules. If I ever have to then I
figure something is wrong.

Why do I think this way you might ask. It is simple, I am a mac user!

Not that I cant do the "hard" stuff, I used to program my PC's in C back
in '85 and mc code before that.

The fact is that I don't want to.

I don't know why everything is so hard. When you collect your images
together, when you edit your images where are they? On disk, so where
should you be able to serve them from by default. Yes thats right ON DISK.

If you are fine tuning your site, editing you images what don't you want
the browser to do? Thats right you don't want it to cache the images!
Can seaside do this out of the box no it can't! Never mind accessing
databases, seaside cant even serve files.

Moving the file in-image is an optimization, and its quite nice for
distributing a pre-configured image without lots of supporting files,
but its not the simplest thing to configure or use. Throwing your files
into a directory or a directory hierarchy is. And seaside cant handle
that, despite, as I was told recently trying to embody the 80-20 rule,
that is supporting the majority of what users want to achieve.

So in terms of lowering the bar for newbies some things are basically
obvious, but seaside has acquired an "elitist" approach. It appears that
some things (like serving files) are beneath it, and "best left to
apache". So it turns out that due to this elitism, seaside cant even do
the basics out of the box. The purist mentality doesnt allow for the
"seaside does what it does, and does it well" to be poluted by
compromise positions which would make things more flexible and therefore
perhaps more broadly usable. Serving files is but one example, using
cookies for day to day site things is another, this facility almost
disappeared from 2.8a unnoticed.

Now I would like to be able to rectify this situation, but I have a
distinct disadvantage, I don't write perfect code, I throw something
together which does the job, I need others with different skills to
refine and hone the result to perfection.

So as it happens I have on numerous occasions attempted to submit code
which addresses some of these (imho) shortfalls. And time and time again
the purists reject much of what I have offered out of hand. For various
reasons, some of them good reasons. Nevertheless I got tired of the
continuous negative attitude that comes out in this "protecting the
purity" of seaside.

This has resulted in me making a complete ass of myself by loosing my
rag (fortunately in private) at the maintainers. I have apologized, and
if you have noticed that the seaside repository is now read only, thats
probably all my fault that I pissed off the maintainers and I apologize
to them and also to the community for that.

But lets examine this a little bit, one example.

Seaside configuration attributes are organized into groups. So the
function "tell me if this application has the configuration group named
x" (so I can add a dispatcher plugin to it). This function is an
accessor into private information encapsulated within the seaside kernel
so to speak. So in order to make this useful as a feature, whose
responsibility would it be to provide an accessor? I would say the
package that implements the feature should expose enough of that feature
in a public api so as to be useful to users who want to use it. So I
suggest #hasGroupNamed: accessor  to match its existing counterpart
#hasAttributeNamed:

The objection I am given is: "This is dangerous". Why? Because it has no
users within the seaside core package, and having no users it is fragile
and might break or be removed without anyone noticing. Well hang on,
isnt that obvious! It isnt in the base package 'yet' so of course it
hasn't got any users, its whole purpose is to be a public API so that
clients and extensions to the base package can use it. Its reason for
being that is to support users external to the core, not internal to the
core, the internals probably dont need it since they can access the
value directly etc. So somehow we have this statement of law which says
"No public api shall be exposed which is not used inside the grey-box of
the core, which incidentally doesnt need a public api anyway".

So what if it does break? Well if it doesnt have any users inside the
core seaside package, then who cares. Its not dangerous at all, if it
breaks its not going to ruin anyones day. Ok so I, with three users of
this api might miss it and flag if it becomes broken. But dangerous it
is NOT.

This really got my goat I am afraid, I attempted to put this accessor
into the seaside repository 6 times or more. And it still hasnt made it
past the idealistic police. Now I am not writing code or uploading to
monticello for my health. Can you wonder why I got a little peeved.

So if you are wondering why seaside doesnt make progress in attracting
broader appeal, one possible answer is that the maintainers have a very
narrow and purist perspective. Which is worthwhile, and serves a purpose
to make seaside better in a certain focussed way, just not in the way
that will broaden seaside's appeal (imnsho).

So lets turn to the question at hand, serving files. What would it take
to add this to seaside.

1 Method thats all! Where is it? Not there? Why not? because I guess
serving files must be in the 20 of the 80/20 mentioned earlier. Who
decides this? Well someone who likes configuring apache I guess.

So in a three method varient a) subclass FileLibrary add an instVar
fileNames and load it up with any resources you want to serve in-image
as defaults which the files can then override.

the methods:

WAFileBasedLibrary-initialize

    fileNames := self libraryDirectory fileNames

WAFileBasedLibrary-libraryDirectory

^FileDirectory default directoryNamed: 'resources'

WAFileBasedLibrary-documentAt: aFilename ifAbsent: aBlock
   
    | doc |
 
    (fileNames includes: aFilename)
        ifFalse: [ ^ super documentAt: aFilename ifAbsent: aBlock ].
 
    doc := (WACachedDocument
            fileName:  (self libraryDirectory pathName, FileDirectory
slash , aFilename)) asMIMEDocument.

     ^  WAResponse
            document: doc
            mimeType: doc mimeType

Bingo, now that wasn't hard was it, throw any files you want to serve
into 'resources' directory and you are away.

best regards

Keith


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside