Hi!
On 06/30/2008 12:42 AM James Pic wrote:
> 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.
> Don't you mean that the request maker should run the filters?
> Should the selection of filters depend on the controller or the request
> builder?
The object running the controller should do it. :)
>> 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.
> Sounds like a good idea, do you mean that a property like $request->data would
> either be an array of variables, either a main content? What is your exact
> proposal?
I'm not sure here, it's quite hard to design unless we have a good
overview which are the potential formats of incoming content. Maybe you
could create a little list for this in the requirements document, so we
get an overview what we can expect here?
>> 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.
> Or add property $request->auth->location?
In the end we should create an abstract base struct for this, which does
not contain anything (but ensure proper instanceof checks). An
ezcMvcRequestPasswordAuthentication struct can extend this class and
provide username and password. ezcMvcRequestTokenAuthentication would
provide a differnt set of attributes, same with
ezcMvcRequestOpenIdAuthentication. For example.
>> 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? 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
>> }
>> }
>>
>> ezcMvcHtmlViewSomething extends ezcMvcViewSomething
>> {
>> public function handleResponse( ezcMvcHtmlResponse $response )
>> {
>> // Process a template and print the result...
>> }
>> }
>
> Actually, the template parsing would be done in createResponse(), which
> returns
> an ezcMvcResponse struct, with the headers and body variables ready.
> We could use ezcMvcHttpOutputWriter, which would set the headers and echo the
> response body?
Yeah, that was basically my idea. See my answer to Dericks mail for
further information.
>> ezcMvcController
>> ----------------
>>
>> So far the design defines that the action is selected internally by the
>> controller. While I can live with this solution, I think the decision
>> belongs more to the dispatcher. This avoids quite some duplication in
>> controller code, I'd say.
> Do you really prefer to set a mapping between controllers methods and request
> variable 'action' or something like that?
> Same for sub-actions?
> Providing an abstract class that does that would work as well.
Sounds good to me, too.
Regards,
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
--
Sdk-public mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/sdk-public
