[Seaside] updateRoot: Weirdness

Richard Eng richard.eng at rogers.com
Thu Jul 19 04:06:04 UTC 2007

I share your sentiments. While the "purity" of Seaside is a noble objective,
it should be more a guideline than a strict edict. Seaside should be more
flexible in meeting the diverse needs of web development, because we all
know that the *real* world of the web is not neat and tidy. It is messy and
terribly makeshift. And it is NOT the job of Seaside to bring order to the
world of web development. So, yes, let's have *easy* and *convenient*
support for file serving. If you don't make allowance for developer
convenience, you will unfairly limit Seaside's appeal.

Note that this isn't the same thing as "dumbing down" Seaside. I'm saying we
have to recognize the pragmatic realities of the web environment and
infrastructure, and not cocoon ourselves within an artificially pure,
enclosed world.


On 7/18/07 5:13 PM, "Keith Hodges" <keith_hodges at yahoo.co.uk> wrote:

> 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
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the Seaside mailing list