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. ;) However, fine with me, keep both. :) >>>>>> ezcMvcRequestAuthentication >>>>>> --------------------------- >>>>>> >>>>>> This class defines an $identifier and $password field. These fields only >>>>>> make sense for authentications as Basic-Auth. However, in case of e.g. >>>>>> OpenID, they are not available. Such differences should be abstracted in >>>>>> the class. >>>>> That's why this is just part of the stuct as a property of >>>>> ezcMvcRequest. It can be absent of course. >>>> The point is not the absense, but the different needs for authentication >>>> mechanisms. Is this struct meant to be extended for different >>>> authentication methods? As I said, OpenID is an example where you don't >>>> have username and password. Token based authentication is another >>>> example. Maybe someone wants to realize GPG key based authentication? >>> Sure, but all the other things that you mention, is not request data. So >>> it's not important. >> A token submitted via GET or POST is indeed request data. :) However, if >> my described inheritence is the plan, it's fine for me. Shall I update >> the design in this direction? > We'd like to play with how this looks like for OpenID first. Hopefully > today. Sounds like a plan! Cheers! Toby -- Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer [EMAIL PROTECTED] | eZ Systems AS | ez.no -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
