[Seaside] About Seaside 3.0

[Ramon Leon]

> >        - Better and more ready to use components.
> 
> Should not be part of Seaside, should be separate project.

+1, there's no such thing as a ready to use UI component, one size does not
fit all and UI components don't belong in Seaside.  I'd even like to see
#request: and #inform: removed because it plants such ideas in peoples
heads.  Seaside can be used to build many UI frameworks, like wrapping
MooTools, YUI, XUL, or the myriad of other current and future UI components.
There's no reason you shouldn't have a choice between any of the various
competing component libraries which should all be separate projects.

> 
> >        - Straightforward and dead simple to use for dummies like me
> > persistency.
> 
> Should be separate project as well.
> 
> Cheers
> Philippe

Also +1, persistence is not a web framework's job, it's a persistence
framework's job and you should be able to use any one of the various
competing persistence frameworks with Seaside.  Ruby on Rails is not
technically a web framework, it's a collection of frameworks in an
application stack; that it's called a framework is more marketing than
truth.  The web framework within Rails is called ActionPack, that's what
Seaside is.  ActiveRecord is the persistence framework used by the Rails
stack, for Seaside that's Gemstone, Glorp, GOODS, Magma, OmniBase, Roe or
the Image itself depending on what you need.

If there's anything to learn from Rails, it's that the stack can benefit
from being very well integrated from an outside point of view so that it
appears all the parts were made to fit together.  That doesn't mean we need
to dump everything into Seaside, and it's too late for that anyway.  Rails
came out of the gate with just ActiveRecord and everyone uses it, but you
won't get the Seaside community to do that, we already have more than one
persistence option and you aren't going to be able to pick any one bless it
as *the* one.

There may be things Seaside can learn from Rails, but it shouldn't copy
Rails.  Convention over configuration, tight integration, simple to use,
easy to setup, all good things; on the other hand html templates, url
hacking with regex and manual marshaling of state, integrated code
generators/scaffolding, focus on statelessness, all IMHO, bad things and a
direction I'd hate to see Seaside go.  Even the Rails guys spent a lot of
time on 2.0 trying to push things out of the core and into plugins or
separate gems because they realized it was a mistake including them in the
core.

Ramon Leon
http://onsmalltalk.com