[Seaside] Naming URLs - three questions

[Avi Bryant]

On Wed, 26 Jan 2005 13:45:40 -0800, Roger Whitney <whitney at cs.sdsu.edu> wrote:

> However in VW Seaside version 2.5b5.9.0,mbany from the Cincom
> repository it needs to be
> 
>         (WARenderLoop new root: aComponent) run
> 
> Is this difference just a lag between the VW version and the Squeak
> version of Seaside?

No, it appears to be lag between the documentation and the code.  Thanks.

> Q2. The point of creating the subclass of WAMain seems to be to allow a
> way pass request information to a session, allowing for bookmarkable
> pages. So one might be able to have a url like
> http://universe.com/seasideApp?product='spaceship' work with a seaside
> app. Now I have to create new class, a subclass of WAMain, and usually
> add just one method start: and modify the application settings. This
> start: method just creates a new component and passes it information.
> Why not just add a hook method to WAComponent that is called when
> WAMain creates the component? It would make it easier on the
> application developer.

Excellent question.  I think there will still be some cases where a
subclass of Main is needed - if, for example, you wish to return a
static response for certain URLs (like the RSS feed in SmallBlog). 
However, if it's just initialization data, you're right that the
component can probably handle it.  Do you have a suggestion for an
interface for this?  Perhaps #initializeFromRequest: on Component?  Or
#takeValuesFromInitialRequest:?  Should that just be sent to the top
level component, or should we walk the tree (that seems better, since
you could then have an embedded component that wanted info from the
request and the root component would be oblivious to this).

To step back a little: in Seaside 2.3, I tried to impose a fairly
strict layering, so that (for example), the base Session class has no
knowledge of Component, but only deals with requests and responses. 
In 2.5, I tried to separate things out further, so that we didn't need
a subclass of Session at all, but only a subclass of Main - in this
way it's possible to combine any session class with any type of
application (for example, one that didn't use components at all). 
However, I'm getting a distinct sense of YAGNI here: more and more
Seaside apps are getting written and none of them seem to be making
use of  Session without Component, or Main without RenderLoop, etc. 
So it may be time to start collapsing some of these mechanisms back
into something less general but easier to use - I think your
suggestion is a good one along those lines.

> Q3. If wanted to provide some more documentation to the new seaside web
> site who should I contact?

You can contact me.

Avi