Reinhard Poetz said:
>
> I agree with you but let me give you some reasoning that has lead to this
> misture:
>
> The problem is that developing really RESTful applications isn't entirely
> possible with current web browsers, e.g. you can't use other methods than
> POST
> and GET in your forms. Additionally, you will have a hard life if you want
> to
> compete with full-blown web app frameworks like JSF, Wicket, Tapestry or
> our own
> cForms because all of them introduce some kind of abstraction layer (=
> server-side forms) on top.
> On the one side this is handy, on the other side you fight against the
> nature of
> the web (HTTP) to some extend. The better a framework, the less problems
> you
> will face as web application developer.
Isn't this pretty much what I said in an earlier post?
>
> One could argue now that if you use a framework that hides all those
> alleged
> limitations of HTTP fits your needs it doesn't matter whether you follow
> RESTful
> principles or not. However, IMO you lose a lot because if your web
> applications
> are implemented in a RESTful way, they are not only available for human
> users
> but also become useable by machines.
I don't buy this. A machine wants a service, a human wants an interface it
can interact with. The UI for the human may use that service, but in an
MVC sense the service is providing access to the model, not the view.
>
> My second argument was that most of today's web applications are developed
> across two layers: One (bigger) part at the server's web-tier and one
> (smaller)
> part at the browser in the form of Javascript.
Gee, that is a bit user-centric. Classic design also calls for a business
tier and a data tier.
>
> If you decide to go the RESTful way and want to develop web applications
> that
> can compete with those developed based on one of those full-blown web
> frameworks, you will also need Javascript (event-handling, editing of
> several
> resources on one page, etc.). Probably, in comparison that's a bit more,
> but
> still manageable. In addition I expect that RESTful applications will be
> less
> complex.
Why? Because all the complication is in the Javascript library? I still
want to know how you are going to handle data that cannot or should not be
stored in the user's browser? The argument that there isn't any (which you
haven't made) just isn't the case.
>
> For me those are the reasons why I said that I have changed the camp and
> think
> that Stefano was right with his opinion that traditional web frameworks
> would
> become obsolete. But, in contrast to him, I think that Cocoon, which in
> some
> respect isn't 'traditional' at all, can become the ideal server-side
> counterpart
> for such RESTful web applications.
No offense to Stefano, but I don't think he has ever worked at a bank.
But yes, Cocoon should easily be able to handle this.
Ralph
