[Seaside] About Seaside 3.0
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
> #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
> There's no reason you shouldn't have a choice between any of the
> competing component libraries which should all be separate projects.
>>> - Straightforward and dead simple to use for dummies like me
>> Should be separate project as well.
What I meant was more good integration of the proposed solutions.
> 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
> Seaside is. ActiveRecord is the persistence framework used by the
> 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
> 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.
> 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
> Rails. Convention over configuration, tight integration, simple to
> 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
What I would like to learn from them is not technical. It is about
integration and working solution.
More information about the seaside