[Seaside] rails niceties equivalents?

[Philippe Marschall]

2009/5/17 Julian Fitzell <jfitzell at gmail.com>:
> On Sat, May 16, 2009 at 10:06 AM, Philippe Marschall
> <philippe.marschall at gmail.com> wrote:
>> 2009/5/15 Eagle Offshore <eagleoffshore at mac.com>:
>>> The one thing that is consistently requested (and I definitely need) is ways
>>> to do RESTful dispatching.
>>
>> Seaside is not a RESTful framework. If you need that look somewhere
>> else. There are certain ways to emulate certain things but that's
>> about it.
>>
>>> The usual reply is that it is done in Pier and I
>>> could download Pier and look at that.  I've done this and browsed code for a
>>> few hours, and still come up empty about how to do this in generic Seaside.
>>>  I think the core maintainers have to do this - only they have the
>>> knowledge.
>>
>> The usual reply is look at #initialRequest: #updateUrl: and
>> #addToPath: they actually have comments. Look at WABrowser for
>> concrete example.
>
> I don't think it's that simple and I don't think we should discourage
> people who want to work on this.

Well it is a lot of work doing it and then maintaining it.

> 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.

Right, because we had no need for it.

> 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
> people.

Right, but there are at least two problems:
1. It has to be driven by a one or several application development
projects, otherwise nothing good will emerge from it. I seriously
question this will ever happen.
2. Database access, there's no portable way of doing it. So either we
write our own database abstraction layer (yay) or we accept that
database access again is not part of it (I can see people being
totally happy with that) and that each and every tutorial will do
database access in a different way (yay again).


Cheers
Philippe