[Seaside] About Seaside 3.0

stephane ducasse stephane.ducasse at free.fr
Sun Jul 13 19:32:44 UTC 2008


lukas I meant 3.0 without the idea of rewriting but with the idea that  
after 2.9, 2.10 is a boring number :)

Stef


On Jul 13, 2008, at 12:22 AM, Lukas Renggli wrote:

> 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.
>
> Cheers,
> Lukas
>
> 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
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>



More information about the seaside mailing list