on 6/18/03 2:12 AM Ugo Cei wrote: > Stefano Mazzocchi wrote: > >>No, no need for that. It took me half an hour to figure that problem out >>myself and it's an indication of how generally badly designed is >>cocoon's handling of multipart-encoded POST requests. > > > Could it be useful to document this "feature" along with the usage > instructions?
It is written clearly in the samples note that you need to enable file upload to make it running. > Anyway, I'm wondering why the multipart request. Is it because of > images? yep. > If it weren't for images, wouldn't it be better to POST a > text/xml body with all the necessary information, putting the "verb" > (save, delete, etc.) in the URI, in the style of REST? Tell you what (Mr. lazy ass speaking): 1) I just wanted to get it done 2) I'm a URI purist 3) I'm already posting all the necessary information, yet using normal POST parameters so that I don't have to parse them again to get what I want (can you say "golden hammer"?) I think the current solution is the simplest thing that can possibly work. And I love it that way because it's so simple it hurts, expecially if you think on how much more complex it can be done to achieve the exact some thing in the name of some design purism that, IMO, has yet to show its value in real life. I didn't use a database: I didn't need one. I didn't encode all my posted data into one XML document, but submitted different parameters, some of them are XML fragments (and are parsed as such by the RequestGenerator). I needed access to those parameters from the flow and cocoon.request.getParameter() was much easier than resorting to a DOM and look for something using XPath (or worse, crawl the DOM myself). But, as usual, patches are welcome. -- Stefano.
