On Wed, Mar 5, 2008 at 10:38 AM, Sergiu Dumitriu <[email protected]> wrote:
No, we didn't quite disagree. I was not talking about the implementation, but about the design of the implementation. If we would write some restlets, then they would do what?
Let's say we have the URL http://server/Space/Page/ and do a: - GET: duplicate some of the code in ViewAction - PUT: duplicate some of the code in SaveAction - DELETE: duplicate some of the code in DeleteAction - POST: duplicate some other code in SaveAction - HEAD: write some new code, as this is not done yet
So I was saying that when designing the URLs, we should redesign the application logiC (and this is something you implied, too), but put it not in the restlets, but in another layer, so that it can be reused by other protocols. You do agree that we can't just design new URLs (or should we say IRIs?), without designing the logic behind them.
Currently the logic is spread around all the platform. There is code in the Struts actions, in the XWiki giant, in the data model, in templates, in documents, in plugins (FileUpload, for example), so writing restlets that reuse this spread logic will be very inefficient: - search all around the code to see how to do something - duplicate code - copy the bugs along with the code - increase even more the mess
And we can't just completely replace the servlets (and their URLs) with the new REST approach, as all the bookmarks and knowledge about the URLs would be broken, so people will not upgrade. So we either reimplement them using the new app logic layer, or write an URL rewrite engine that forwards to the new IRIs.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
I completely agree with this, and think that consolidating the logic so it isn't spread across so many places would also simplify life for those of us that want to put a completely new face on things (so to speak). I have also been bitten by the crawler bug: Some of the delete actions are/were regular URLs relying on Javascript for confirm/deny... I've seen a bot with read access start deleting things.. (in the absence of javascript, the URL is effectively "clicked", causing the action to happen.. ). That's a little tangential to the discussion, but consolidating where the logic is for managing deletes, etc. would be good.. It might also make the path length a little shorter, if you do it right.. -- 'Waste of a good apple' -Samwise Gamgee