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.
agreed.
>>> - Straightforward and dead simple to use for dummies like me
>>> persistency.
>>>> Should be separate project as well.
yes
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.