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
