[Seaside] updateRoot: Weirdness

Keith Hodges keith_hodges at yahoo.co.uk
Wed Jul 18 21:13:56 UTC 2007


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




More information about the Seaside mailing list