[Seaside] About Seaside 3.0

Lukas Renggli renggli at gmail.com
Sat Jul 12 22:22:58 UTC 2008

Ramon, I coulden't agree more.

To justify a major version jump from 2.x to 3.0 we need something
radically better. Seaside 2.0 was a complete rewrite over Seaside
0.98. The manpower (and interest?) to start such an endavour seems to
be missing currently.


On 7/12/08, Ramon Leon <ramon.leon at allresnet.com> wrote:
>> >        - 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
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lukas Renggli

More information about the seaside mailing list