On 10/11/07, Jerome Louvel <[EMAIL PROTECTED]> wrote: > > Hi Sean, > > > I think *Representation is problematic: headRepresentation()? > > I understand your > > concerns with get(Variant), getVariant(). A colleague of mine > > pointed out that > > conceptually, merely using post(), get(), etc., is like > > encroaching on a global > > name space. He suggested (and I'm comfortable with), > > doPost(), doGet(), doHead(), > > doDelete(), doPut(), and doOptions(). The 'do' has the effect > > of taking > > the names out of the global name space...conceptually. > > I agree, but what do you think about the fact that we already have the > handleGet, handlePost, handleHead or handleOptions right in the Resource > class? > > Do you think that handleHead() should call a doHead() method? What would be > the added value? > > In case of handleGet() we provide a default implementation based on the > getVariants() and getRepresentation(Variant) methods in order to provide a > default support for content negotiation. Same for handleHead() which in 99% > of the case is just a GET with no entity sent back on the wire. > > The handleOptions() also has a default implementation which is based on the > "alloww*" methods available that return true. > > If you don't want to use content negotiation, you could directly override > the handleGet(), handleHead() methods. Doesn't it cover your needs? >
allowPut(), allowPost(), allowDelete(), allowGet() handlePut(), handlePost(), handleDelete(), handleGet() put(), post(), delete(), getRepresentation() - eh? what? The lack of symmetry there is jarring - it leads people to go looking for the get() method and when they cant find it, they're confused. I think two things need to happen. First, the documentation for handlePut(), handlePost(), handleDelete() and handleGet() needs a whole lot more detail making it plain what exactly they do. As the documentation stands right now (1.0), it's not even clear that handleGet() will ultimately call getRepresentation(). And handlePut, handlePost and handleDelete appear to do nothing more than call put,post or delete respectively - even though the code shows that there's a lot more going on. And second, yes, I think put(), post() and delete() and getRepresentation() need to be renamed. While doPut(), doPost(), doDelete() and doGet() are OK, I think I'd prefer processPut(), processPost(), processDelete() and processGet() - but anything that makes it clear that they are at the same level of processing is fine. I've puposely avoided head and options because they're less well-known, but the do*() and process*() patterns seem to cover them just fine. And if you don't want handleHead() being a one-liner with a call to doHead(), make it clear in the docs that handleHead() actually calls doGet(). Besides, I think the number of people who will be looking for a head() or doHead() method will be significantly smaller than the number of people looking for get() or doGet(). (And just how many cases are there where you'd want to override the default behavior of head anyway?) --Chuck
