[Seaside] About Seaside 3.0

stephane ducasse stephane.ducasse at free.fr
Sun Jul 13 19:31:52 UTC 2008

On Jul 12, 2008, at 11:42 PM, Ramon Leon 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.

What I meant was more good integration of the proposed solutions.

>> 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.

Indeed this was not what I meant.
> 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.

What I would like to learn from them is not technical. It is about
integration and working solution.

More information about the seaside mailing list