No, that's not enough. You want to handle the error, you want the ability to return an HTTP forward to a show function if the update is successful OR to a newly generated "success" page.
These are pretty standard HTTP form semantics and they can't be handled with a single function in a nice way. Also, your proposal doesn't have a good way to propagate the update error back to the error page which is essential. This is the kind of thing most modern web framework provide a simple high level abstraction for. We don't need the high level thing but we do need a good API that binds a particular "update" to all the HTTP and related database calls it needs to make. Without that nobody can even build the high level thing. -Mikeal On Sun, Aug 1, 2010 at 11:48 AM, J Chris Anderson <[email protected]> wrote: > > On Aug 1, 2010, at 11:46 AM, Mikeal Rogers wrote: > > > I've been thinking about this a lot lately and I'm starting to think > > that continuing to build on the update function isn't the best idea. > > > > The update function just wasn't designed with this in mind. > > > > I don't get it, this seems a perfectly sensible enhancement to the current > API. All that is missing is the ability to not spew garbage to the user on > failure conditions. > > > Any way I can think of to add support for this use case to the update > > function ends with a API I wouldn't actually want to use. Meanwhile, for > > simpler cases the update function is still one of my favorite APIs and I > > don't like the idea of complicating it. > > > > Maybe it's best here to design a new API called "form" or something > similar. > > We could build in the standard redirect system and failure cases and make > > the API really nice to use and just leave update alone. > > > > Thoughts? > > > > -Mikeal > > > > On Sun, Aug 1, 2010 at 11:38 AM, J Chris Anderson <[email protected]> > wrote: > > > >> > >> On Aug 1, 2010, at 11:34 AM, Jason Smith wrote: > >> > >>> On Sun, Aug 1, 2010 at 02:21, J Chris Anderson <[email protected]> > wrote: > >>> > >>>> I'm totally +1 on getting rid of these rough edges. I seriously doubt > >> I'll > >>>> have time to do anything but cheerlead, so if this is gonna happen, > >> someone > >>>> is gonna have to take up the charge. > >>>> > >>> > >>> Do you mind a little discussion about how that might work? > >>> > >>> It seems to me there is no avoiding round trips between the _update > >> function > >>> and couchdb. > >>> > >>> Is it allowed for the update function to query couchdb about whether id > X > >> is > >>> available? > >>> > >>> Is it allowed (or preferred) for the update function to have an > >> additional > >>> flag similar to rereduce, indicating it is being called again due to a > >> bad > >>> _id? What about two bad _ids in a row? Is the function called > >> indefinitely > >>> with a growing list of previously-bad _ids until it returns an > >> already-seen > >>> bad _id, in which case you get a 409? None of this strikes me as clean. > >>> > >>> Another thing to consider is perhaps the _update function can just > >> specify > >>> what to render in the case of conflict and let the client handle it. I > >> think > >>> that would be sufficient to at least allow a basic HTML form workflow > >> again. > >>> > >> > >> I like this the best. It could return: > >> > >> { > >> "success": "<p>it worked</p>", > >> "conflict" : "<p>sorry, out of date rev made an update conflict, please > >> reload and retry</p>", > >> "error" : "<p>yikes, I don't know what went wrong</p>" > >> } > >> > >> and if any are missing you get the CouchDB json response instead > >> > >>> -- > >>> Jason Smith > >>> Couchio Hosting > >> > >> > >
