Tobias Schlitt a écrit :
On 07/01/2008 11:06 AM Derick Rethans wrote:
On Mon, 30 Jun 2008, Tobias Schlitt wrote:
On 06/30/2008 12:02 PM Derick Rethans wrote:
On Mon, 30 Jun 2008, Tobias Schlitt wrote:
On 06/30/2008 09:24 AM Derick Rethans wrote:
On Sun, 29 Jun 2008, Tobias Schlitt wrote:
ezcMvcRequest
-------------
The class defines a $content and a $variables attribute. Where is the
difference here?
In case of GET/POST requests, there are only variables, files, etc. So
not content. In case of PUT requests, there might be content, but no
variables. Shouldn't this be unified? In case of a SOAP request, there
are only variables, too, but no content.
It's a struct, so I don't see what you're trying to say here.
The point is, that $variables and $content is redundant.
No, they are not. For PUT you have both content and variables (a la
GET).
I did not see PUT requests like this, yet. However, then it makes sense
to keep both. We need to define how non-HTTP requests then fill these
attributes to keep consistency.
Well, for the mail request builder, the content could be the message
body, where as the variables could be things *parsed* from the body,
like bugzilla does with:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=200641#15
(the retitle part f.e.)
The body would be available through $request->raw->body already. ;)
Nopes.
Email body is, most of the time, THE payload of the request. So it has
to be present in the abstract part of the request to be of any use
(remember, the whole point of having abstract requests is that actions
"most of the time" do not need to worry about the protocol that carried
the info).
As a side note, you could also have parameters for POST, not only PUT
requests. I am thinking especially to POSTs that carry a request body
which is not form-multipart and some parameters in their http headers or
a query string.
Maybe the best way to organize the request struct is to define in detail
how common requests could be parsed into a req. object:
- GET request (query string parsed into a key/val array, cookies present
in raw part)
- plain http POST request (query string ?, cookies present in raw part,
body parsed into a key/val array)
- xmlrpc POST request (query string ?, cookies present in raw part, body
parsed into a method name and list of params)
- xml POST request (query string ?, cookies present in raw part, body
parsed into simplexml object or php obj?)
- jsonrpc POST request (query string ?, cookies present in raw part,
body parsed into a method name and list of params)
- json POST request (query string ?, cookies present in raw part, body
parsed into a key/val array or a php object)
- soap POST request (query string ?, cookies present in raw part, http
header for soap action, body parsed into simplexml object or php obj?)
- PUT request
- HEAD request
- email request
- webdav request (not in the design docs so far?)
- ftp command request (not in the design docs so far?)
etc...
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
