[Components] MmvTools requirements and design
Hello, James and I (as well as others through meetings), have been working the past days on the MvcTools component and design. The fruits of this labour are now in SVN[1]. We'd like you to ask to look at this and provide feedback. [1] http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/ regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
> > James and I (as well as others through meetings), have been working the > past days on the MvcTools component and design. The fruits of this > labour are now in SVN[1]. We'd like you to ask to look at this and > provide feedback. > > [1] http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/ > Overall, this looks good. A couple of thoughts come to mind on the first read-through: * Is there a reason for the Dispatcher (from the example in the design) to have visibility on the ezcViewHandler class? It might provide cleaner separation for the dispatcher to only call the ViewManager and provide the request and result objects. * At what point are output filters run? -- Joe Kepley Director of Development - Blend Interactive, Inc. http://www.blendinteractive.com - 136 S. Dakota Avenue Sioux Falls, SD 57104 o: 605.334.7077 m: 605.728.6550 f: 866.686.5491 -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Derick Rethans
> Sent: 25 June 2008 16:11
> To: Components
> Cc: Public SDK List
> Subject: [Components] MmvTools requirements and design
>
> Hello,
>
> James and I (as well as others through meetings), have been
> working the past days on the MvcTools component and design.
> The fruits of this labour are now in SVN[1]. We'd like you to
> ask to look at this and provide feedback.
>
> [1]
> http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/
For the latter two layers I have a similar setup.
Though have don't have an equivalent ezcMvcResult class,
and use ezcMvcResponse directly. Partly because I
Last-Modified & Etag headers directly, so can compare request &
response headers for 304s.
My ezcMvcResponse (called HttpContent) also has subclasses for various types
of content.
TextHttpContent, CSSHttpContent, ImageHttpContent together with a method
function getTransform(HttpRequest $request) { } which returns a list of
transforms/filters to perform.
Eg. TextHttpContent handles encoding negotation.
CSSHttpContent inherits from TextHttpContent, so also can be
gzipped/deflated, but is also minified first.
ImageHttpContent's getTransform() looks at $request parameters to see if the
image needs to be scaled etc.
My ezcViewManager equivalent (TransformManager) iterates through the
transforms, caching each of the HttpContents
returned.
So the TransformManager can avoid doing some or all of the transforms
required.
Jared
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
Just to be sure: in the shortened example how does the view manager pick up the correct view handler for the rendering of the response, if the request obj, carried through the process is to "abstract from the request protocol and format"? It would generally need to carry the 1 - the abstracted data, 2 - the full raw data (get,post,cookies, headers) and 3 - some protocol+format info in a somehow standardized way. If we omit part 3, analysis of part 2 has to be done many times over (view manager and router both might need it in picking up the appropriate controller/view handler). If part 3 is only present in a custom subclass of request, ie not standardized, we force a set of parser+router+viewmanager to be developed in sync every time... Is this the intended behaviour? Gaetano > Hello, > > James and I (as well as others through meetings), have been working the > past days on the MvcTools component and design. The fruits of this > labour are now in SVN[1]. We'd like you to ask to look at this and > provide feedback. > > [1] http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/ > > regards, > Derick > -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
On Thu, 26 Jun 2008, Gaetano Giunta wrote: > Just to be sure: in the shortened example how does the view manager pick > up the correct view handler for the rendering of the response, if the > request obj, carried through the process is to "abstract from the > request protocol and format"? > It would generally need to carry the 1 - the abstracted data, 2 - the > full raw data (get,post,cookies, headers) and 3 - some protocol+format > info in a somehow standardized way. > If we omit part 3, analysis of part 2 has to be done many times over > (view manager and router both might need it in picking up the > appropriate controller/view handler). > If part 3 is only present in a custom subclass of request, ie not > standardized, we force a set of parser+router+viewmanager to be > developed in sync every time... Is this the intended behaviour? Actually, when you mention under nr 3 - is actually going to be part of 1 - the abstracted data. Unless I got confused. Do you have an example of data that you expected to see in 3? regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
Derick Rethans a écrit :
On Thu, 26 Jun 2008, Gaetano Giunta wrote:
Just to be sure: in the shortened example how does the view manager pick
up the correct view handler for the rendering of the response, if the
request obj, carried through the process is to "abstract from the
request protocol and format"?
It would generally need to carry the 1 - the abstracted data, 2 - the
full raw data (get,post,cookies, headers) and 3 - some protocol+format
info in a somehow standardized way.
If we omit part 3, analysis of part 2 has to be done many times over
(view manager and router both might need it in picking up the
appropriate controller/view handler).
If part 3 is only present in a custom subclass of request, ie not
standardized, we force a set of parser+router+viewmanager to be
developed in sync every time... Is this the intended behaviour?
Actually, when you mention under nr 3 - is actually going to be part of
1 - the abstracted data. Unless I got confused. Do you have an example
of data that you expected to see in 3?
Yes, it might be part of 1.
But I still would like to have it separated in a clear way from the
actual data that should be accessed by controller. I fear if we do not
make it 'just a little bit' hard, every controller action coder will
happily take advantage of all the raw data goodies in the request, and
get away with no abstraction/encapsulation...
Ex. of request obj (see previous post for context: multi-protocol ws
server):
methodname = "getStateNamebyNr" (part 1)
methodparams = array(51) (part 1)
requestprotocol = "soap" (this is part nr. 3)
requestacceptedcharset = "utf8" (this is normally kept in part 2 until
the view manager needs it, or also maybe also parsed from http request
headers by the router and stored into part 1?)
requestacceptedcompression = array("gzip","compress") (just like the one
above)
requestacceptedlanguage = etc...
regards,
Derick
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
On Wed, 25 Jun 2008, Joe Kepley wrote: > > > > James and I (as well as others through meetings), have been working the > > past days on the MvcTools component and design. The fruits of this > > labour are now in SVN[1]. We'd like you to ask to look at this and > > provide feedback. > > > > [1] http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/ > > > > Overall, this looks good. A couple of thoughts come to mind on the first > read-through: > > * Is there a reason for the Dispatcher (from the example in the design) to > have visibility on the ezcViewHandler class? It might provide cleaner > separation for the dispatcher to only call the ViewManager and provide the > request and result objects. It's purely for testability. > * At what point are output filters run? I've clarified this in the design document: ezcMvcRequestFilter --- Provides an interface for request filters. Request filters can be used to modify the request data before it is used by the controller. They are run in the runRequestFilters() method of the ezcMvcController interface. This method should be called in the run() method of the controller, before the actual logic is applied:: public function filterRequest( ezcMvcRequest $request ); ezcMvcResultFilter -- Provides an interface for result filters. Filters that implement this interface can be run after a controller have run their action. They are run in the runResultFilters() method of the ezcMvcController interface. This method should be called in the run() method of the controller, after the actual logic is applied on the result object:: public function filterResult( ezcMvcResult $result ); ezcMvcResponseFilter Provides an interface for response filters. Response filters are run after the view handlers have created a response from the result by the view handler. This can modify the final output stream and headers. They are run in the runFilters method of the ezcMvcViewHandler interface:: public function filterResponse( ezcMvcResponse $response ); regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
On Wed, 25 Jun 2008, Jared Williams wrote:
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Derick Rethans
> >
> > James and I (as well as others through meetings), have been
> > working the past days on the MvcTools component and design.
> > The fruits of this labour are now in SVN[1]. We'd like you to
> > ask to look at this and provide feedback.
> >
> > [1]
> > http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/
>
> For the latter two layers I have a similar setup.
>
> Though have don't have an equivalent ezcMvcResult class,
> and use ezcMvcResponse directly. Partly because I
> Last-Modified & Etag headers directly, so can compare request &
> response headers for 304s.
>
> My ezcMvcResponse (called HttpContent) also has subclasses for various types
> of content.
>
> TextHttpContent, CSSHttpContent, ImageHttpContent together with a method
>
> function getTransform(HttpRequest $request) { } which returns a list of
> transforms/filters to perform.
>
> Eg. TextHttpContent handles encoding negotation. CSSHttpContent
> inherits from TextHttpContent, so also can be gzipped/deflated, but is
> also minified first. ImageHttpContent's getTransform() looks at
> $request parameters to see if the image needs to be scaled etc.
>
> My ezcViewManager equivalent (TransformManager) iterates through the
> transforms, caching each of the HttpContents returned. So the
> TransformManager can avoid doing some or all of the transforms
> required.
In our case, the view handlers do this, and not the view managers. I
think the updated design/requirement documents should make this more
clear.
regards,
Derick
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
On Wed, 25 Jun 2008, Derick Rethans wrote: > James and I (as well as others through meetings), have been working the > past days on the MvcTools component and design. The fruits of this > labour are now in SVN[1]. We'd like you to ask to look at this and > provide feedback. > > [1] http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/ After going through your comments, we've updated the requirements and design documents. You can see the differences here: http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/requirements.txt?r1=8470&r2=8481&pathrev=8481&diff_format=h http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/design.txt?r1=8472&r2=8482&diff_format=h and the full documents, including new updated diagrams are at the same location [1] again. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
Gaetano Giunta wrote:
> Derick Rethans a écrit :
>> On Thu, 26 Jun 2008, Gaetano Giunta wrote:
>>> Just to be sure: in the shortened example how does the view manager pick
>>> up the correct view handler for the rendering of the response, if the
>>> request obj, carried through the process is to "abstract from the request
>>> protocol and format"?
>>> It would generally need to carry the 1 - the abstracted data, 2 - the
>>> full raw data (get,post,cookies, headers) and 3 - some protocol+format
>>> info in a somehow standardized way.
>>> If we omit part 3, analysis of part 2 has to be done many times over
>>> (view manager and router both might need it in picking up the appropriate
>>> controller/view handler).
>>> If part 3 is only present in a custom subclass of request, ie not
>>> standardized, we force a set of parser+router+viewmanager to be developed
>>> in sync every time... Is this the intended behaviour?
>>>
>>
>> Actually, when you mention under nr 3 - is actually going to be part of 1
>> - the abstracted data. Unless I got confused. Do you have an example of
>> data that you expected to see in 3?
>>
> Yes, it might be part of 1.
> But I still would like to have it separated in a clear way from the actual
> data that should be accessed by controller. I fear if we do not make it
> 'just a little bit' hard, every controller action coder will happily take
> advantage of all the raw data goodies in the request, and get away with no
> abstraction/encapsulation...
>
> Ex. of request obj (see previous post for context: multi-protocol ws
> server):
ezcMvcRawRequest can be composed of an ezcMvcHttpRequest, in property 'http'.
> methodname = "getStateNamebyNr" (part 1)
Added to ezcMvcHttpRequest property 'method'.
> methodparams = array(51) (part 1)
Added in property 'parameters'.
> requestacceptedcharset = "utf8" (this is normally kept in part 2 until the
This is already in ezcMvcRequestContent.
> requestacceptedcompression = array("gzip","compress") (just like the one
> above)
Added to ezcMvcRequestContent property "compressions".
> requestacceptedlanguage = etc...
This is already in ezcMvcRequestContent.
Thanks for your input!
Feel free to have a look at the request class diagram and suggest more
variables:
http://svn.ezcomponents.org/viewvc.cgi/*checkout*/experimental/MvcTools/design/request.svg
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Derick Rethans > Sent: 26 June 2008 14:30 > To: Components > Cc: Public SDK List > Subject: Re: [Components] MmvTools requirements and design > > On Wed, 25 Jun 2008, Derick Rethans wrote: > > > James and I (as well as others through meetings), have been working > > the past days on the MvcTools component and design. The > fruits of this > > labour are now in SVN[1]. We'd like you to ask to look at this and > > provide feedback. > > > > [1] > > http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/design/ > > After going through your comments, we've updated the > requirements and design documents. You can see the differences here: > > http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/d > esign/requirements.txt?r1=8470&r2=8481&pathrev=8481&diff_format=h > http://svn.ezcomponents.org/viewvc.cgi/experimental/MvcTools/d > esign/design.txt?r1=8472&r2=8482&diff_format=h > > and the full documents, including new updated diagrams are at > the same location [1] again. > > regards, > Derick The other thing I'm trying todo is get the system to automatically maintain various headers during GET requests. Like testing/accessing any request variables not from the url, (Accept-*, or cookies) means you have to add it to the response Vary header. Accessing cookies, like seeing if the user is logged in, probably means to send Cache-Control: private header. Also trying to maintain the rest of the Cache-Control directives, using a similar idea to ESI (http://www.edge-delivery.org/overview.html) Basically have each component in the response have its own (sub-)set of http headers. So default headers would be for example, Cache-control: public, max-age=86400, and no Vary header. Then as the response is being built they would be altered if need, either because of Vary, or to reduce the max-age. Jared -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
Re: [Components] MmvTools requirements and design
Jared Williams wrote:
> The other thing I'm trying todo is get the system to automatically
maintain
> various headers during GET requests.
Like with ezcDbInstance?
> Like testing/accessing any request variables not from the url, (Accept-*,
or
> cookies) means you have to add it to the response Vary header.
>
> Accessing cookies, like seeing if the user is logged in, probably means to
> send Cache-Control: private header.
With the controller and view layer separation in MvcTools, you don't have to
worry about that because you are free to send the GET response in an
arbitary
order.
> Also trying to maintain the rest of the Cache-Control directives, using a
> similar idea to ESI (http://www.edge-delivery.org/overview.html)
>
> Basically have each component in the response have its own (sub-)set of
http
> headers.
>
> So default headers would be for example, Cache-control: public,
> max-age=86400, and no Vary header.
>
> Then as the response is being built they would be altered if need, either
> because of Vary, or to reduce the max-age.
You should wait for the design to be final before making a filter class::
class yourExtension implements ezcMvcRequestFilter, ezcMvcResultFilter,
ezcMvcResponseFilter { [...] }
Where yourExtension can be ezcMvcEsiExtension.
Regards, James.
--
Components mailing list
Components@lists.ez.no
http://lists.ez.no/mailman/listinfo/components
