[Seaside] rails niceties equivalents?
philippe.marschall at gmail.com
Sun May 17 19:15:20 UTC 2009
2009/5/17 Ash Wilson <smashwilson at gmail.com>:
> On Sat, May 16, 2009 at 9:49 PM, Julian Fitzell <jfitzell at gmail.com> wrote:
>> I don't think it's that simple and I don't think we should discourage
>> people who want to work on this. It is true that nobody has come up
>> with a good paradigm for doing non-Session REST stuff in Seaside and
>> also true that we haven't even come close to figuring out a good way
>> to blend the two but I would suggest that in a huge number of cases
>> you don't need both within the same "application" anyway.
>> Seaside has always been capable of supporting other paradigms, though
>> this should be more obvious again with the reorganization in 2.9. At
>> its core, Seaside is a request and response dispatching engine. So
>> while you are right that Seaside is not *currently* a RESTful
>> framework, it wouldn't take much effort to make it support both a
>> Rails-type model and the existing Session model if only someone knew
>> what they wanted a request handler for the former to look like. And I
>> think being able to easily develop stateless rails-style apps with
>> full REST URLs but using the Canvas API would be a huge win for many
> I for one like this idea a lot. Generating HTML and XML with the
> Canvas is one of the big draws of Seaside for me, as well as the
> support for Prototype / Scriptaculous and the like. I also like the
> idea of having RESTful and non-RESTful applications coexisting on the
> same Seaside server.
> Philippe: having active projects supporting the framework is a
> chicken-and-egg problem. If it's difficult to do REST in Seaside,
> then users seeking to do REST projects will use Rails instead; if
> there's an option to do so, however primitive, some of them may stay
> and support the development. I would think that the intersection of
> web developers interested in REST and those interested in Seaside is
Not anymore, instead of writing an awful lot of mails that don't get
anything done I sat for an hour and hacked something together:
(requires Seaside 2.9)
Now prove me wrong:
Use, test it, document it, develop it, deploy it, extend it, hire
Lukas or Julian or write your own. Do nothing and you prove me right.
> I definitely agree that lack of a coherent persistence strategy is a
> big problem, though (one that I've run into myself).
Out of the scope of Seaside, sorry.
More information about the seaside