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.) > > >>>> 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. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
