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:
>
> >> ezcMvcRequestFilter
> >> -------------------
> >>
> >> The filters are described to be used in a method named
> >> ezcMvcController->runRequestFilters(), while this method should be
> >> called by ezcMvcController->run(). It does make little sense to me to
> >> mention that a method ezcMvcController->runRequestFilters() should be
> >> implemented at all, if the controller calls the filter itself.
> >>
> >> Instead I would suggest to design it in either of the following ways:
> >>
> >> a) Remove the ezcMvcController->runRequestFilters() part and just
> >> mention that filters should be run by the controller.
> >> b) Require the method ezcMvcController->runRequestFilters() in the
> >> interface and make it be run by the request builder.
>
> > The reason for not calling the interface methods just run() is so that
> > you can implement all the three filter interfaces in one class:
>
> > ezcMvcAuthenticationFilter implements ezcRequestFilter, ezcResultFilter,
> > ezcResponseFilter.
>
> > The filters should indeed just be run by the controller from the run()
> > method in some way. I think you're right that we can just remove it.
> > (your point a). As for b, that would be a bad idea, as the request
> > builder doesn't actually run the controller, but just returns the
> > request object. The dispatcher calls the controller with this request
> > object. How the controller runs the filter, should not really matter -
> > however, I think it would be good to standardize it, and thus leave it
> > in the interface like we've currently designed.
>
> If we go for standardizing it, then why not simply make the dispatcher
> run that stuff? This avoids having all controllers run this methods.
See my reply to your other mail.
> >> 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).
> >> 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.
> >> ezcMvcViewHandler
> >> -----------------
> >>
> >> The design states, that this class should implement createResponse() and
> >> handleResponse(). Both methods are just called in a chain. Is there much
> >> sense in defining both, then?
>
> > Yes, easier testability.
>
> >> It would only make sense, if createResponse() is defined in a
> >> different class than handleResponse(). Shouldn't this be different
> >> classes anyway? I imagine:
> >>
> >> ezcMvcProductHtmlViewHandler extends ezcMvcViewHandler
> >> {
> >> public function createResponse( ezcMvcResult $result )
> >> {
> >> // Prepare the product result for HTML output...
> >> // ... return a HTML response object
> >> }
> >> }
>
> > The preparring is done by the controller, I don't see why you should
> > prepare the result from the controller in the view again...
>
> >> ezcMvcHtmlViewSomething extends ezcMvcViewSomething
> >> {
> >> public function handleResponse( ezcMvcHtmlResponse $response )
> >> {
> >> // Process a template and print the result...
> >> }
> >> }
>
> > The handleResponse method should just send the output and set the
> > correct HTTP headers.
>
> The point is, that the controller just returns an abstract result
> object, that could potentially be send as any kind of response (HTML
> over HTTP, HTML stored to a file, SOAP response, Email). The view
> handler is then up to transform the result in such a way that it can be
> send as the protocol specific response (a template object - aka
> ezcMvcHtmlResponse for HTML output, an ezcMail object, a SOAP
> response,...). This view handler is somewhat dependant on the controller.
Yes, so you have a view handler for each specific protocol. The
ViewManager uses protocol data to find out which view handler to create,
just like a router selects a controller.
> Maybe one view handler can process the result of different controllers,
> but commonly you'd have multiple view handlers to process different
> result objects. The final serialization and outputing should be equal
> for all responses of a certain type (e.g. sending headers for HTTP
> response and printing the HTML code, opening a file handler and storing
> the HTML output, creating an MTA connection and sending the email,...).
>
> Therefore I'd devide these functionalities into different classes. One
> class to process the result to a certain output format, another one to
> handle the real sending of the response.
No, this does not make sense. One view handler handles abstract results
from a controller, in a protocol dependent way. You do not have to split
up this into two classes. The view handlers that you use can just be
inherited classes, so the myFirstViewHandler can easily extend the
ezcMvcHtmlViewHandler which implements the handleResponse() method,
whereas your myFirstViewHandler runs the correct templates.
regards,
Derick
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
