[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