Re: About Seaside 3.0
>>>> - 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.
>
Yes we really need to be more explicit about what seaside do (is good
for) and provide guidelines like integration patterns (provide
presistence solutions, apache setup (+load balance) and also swazoo as
an alternative, etc...).
I'd like to know about one in particular that I find has not been
discussed much. It's about how-to mix web sites and seaside apps
I find one common mistake is that people try at first to build a 100%
seaside site. It's possible but for most common web tasks, it's
overkill. Look at the main dabbledb page, it's a pure classic html
site... It's the same for auctomatic, again the same with
reservetravel where you can't see at first glance this is using
seaside (there are aspx pages), For reservtravel, "only" the booking
engine is done in seaside (entry point is after validating a search at
http://www.reservetravel.com/v6).
So, I think often people are looking forward a full solution that will
also manage static html pages (with seaside engine included). Maybe
the stack solution should give answers on how to integrate/manage the
classic html development. I actually have no idea how people deal with
that. Do they write pure xhtml in a text editor ? Do they use a tool
for that (even nvu for instance)? is it possible in smalltalk (I
would like that) ?
As a sumup, how can we cleanly separate html pages and app processing
components ? How do others do ?
Cédrick
_______________________________________________
seaside mailing list
seaside <at> lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
