<?xml version="1.0" encoding="UTF-8"?><rss
version="2.0"
xmlns:content="http://purl.org/rss/1.0/modules/content/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:atom="http://www.w3.org/2005/Atom"
xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
> <channel><title>Comments on: Scaling Zend_Form</title> <atom:link href="http://matthewturland.com/2008/11/05/scaling-zend_form/feed/" rel="self" type="application/rss+xml" /><link>http://matthewturland.com/2008/11/05/scaling-zend_form/</link> <description></description> <lastBuildDate>Fri, 11 May 2012 20:03:11 +0000</lastBuildDate> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>1</sy:updateFrequency> <generator>http://wordpress.org/?v=3.3.2</generator> <item><title>By: Matthew Turland</title><link>http://matthewturland.com/2008/11/05/scaling-zend_form/comment-page-1/#comment-252</link> <dc:creator>Matthew Turland</dc:creator> <pubDate>Thu, 09 Apr 2009 23:51:45 +0000</pubDate> <guid
isPermaLink="false">#comment-252</guid> <description>@till The referenced SVN changeset was in response to my finding regarding the translation bottleneck, but everything else I&#039;ve described here is modifying Zend_Form behavior that exists by design. So, there aren&#039;t really any issues to report as this is the way that these components are intended to function and my use cases are for them are (apparently) unorthodox.</description> <content:encoded><![CDATA[<p>@till The referenced SVN changeset was in response to my finding regarding the translation bottleneck, but everything else I&#8217;ve described here is modifying Zend_Form behavior that exists by design. So, there aren&#8217;t really any issues to report as this is the way that these components are intended to function and my use cases are for them are (apparently) unorthodox.</p> ]]></content:encoded> </item> <item><title>By: till</title><link>http://matthewturland.com/2008/11/05/scaling-zend_form/comment-page-1/#comment-251</link> <dc:creator>till</dc:creator> <pubDate>Thu, 09 Apr 2009 09:41:52 +0000</pubDate> <guid
isPermaLink="false">#comment-251</guid> <description>Interesting bits! :-) Did you open issues for your findings? E.g. disabling the translator?</description> <content:encoded><![CDATA[<p>Interesting bits! :-) Did you open issues for your findings? E.g. disabling the translator?</p> ]]></content:encoded> </item> <item><title>By: Matthew Turland</title><link>http://matthewturland.com/2008/11/05/scaling-zend_form/comment-page-1/#comment-230</link> <dc:creator>Matthew Turland</dc:creator> <pubDate>Fri, 07 Nov 2008 00:39:14 +0000</pubDate> <guid
isPermaLink="false">#comment-230</guid> <description>Whether or not several smaller forms would work really depends on the requirements of the application. Dividing a form into subforms only works if you only display a subform worth of fields per page load and it&#039;s the obvious solution if that&#039;s conducive to fulfilling the requirements. Otherwise, dividing the form into subforms does nothing but add unnecessary overhead.The intent of this blog entry wasn&#039;t to suggest that either approach of having one larger form or several smaller forms is better than the other, but to describe how to modify Zend_Form such that it performs better in situations where the developer is forced by requirements to have one large form and some of the flexibility provided by Zend_Form is not necessarily needed.I personally used the approach I described with a form having over 250 fields and was able to reduce the page load time from 4.5 to 1.5 seconds. This still isn&#039;t an ideal request per second rating, obviously, but it&#039;s a significant improvement and I think it points to an area where Zend_Form could be improved as well.</description> <content:encoded><![CDATA[<p>Whether or not several smaller forms would work really depends on the requirements of the application. Dividing a form into subforms only works if you only display a subform worth of fields per page load and it&#8217;s the obvious solution if that&#8217;s conducive to fulfilling the requirements. Otherwise, dividing the form into subforms does nothing but add unnecessary overhead.</p><p>The intent of this blog entry wasn&#8217;t to suggest that either approach of having one larger form or several smaller forms is better than the other, but to describe how to modify Zend_Form such that it performs better in situations where the developer is forced by requirements to have one large form and some of the flexibility provided by Zend_Form is not necessarily needed.</p><p>I personally used the approach I described with a form having over 250 fields and was able to reduce the page load time from 4.5 to 1.5 seconds. This still isn&#8217;t an ideal request per second rating, obviously, but it&#8217;s a significant improvement and I think it points to an area where Zend_Form could be improved as well.</p> ]]></content:encoded> </item> <item><title>By: Jani Hartikainen</title><link>http://matthewturland.com/2008/11/05/scaling-zend_form/comment-page-1/#comment-229</link> <dc:creator>Jani Hartikainen</dc:creator> <pubDate>Thu, 06 Nov 2008 23:07:50 +0000</pubDate> <guid
isPermaLink="false">#comment-229</guid> <description>An interesting approach,  but personally I&#039;d rather make a few small forms than a gargantuan 100-field one. For example, I&#039;d hate to see the browser/os/something crash while filling that...</description> <content:encoded><![CDATA[<p>An interesting approach,  but personally I&#8217;d rather make a few small forms than a gargantuan 100-field one. For example, I&#8217;d hate to see the browser/os/something crash while filling that&#8230;</p> ]]></content:encoded> </item> </channel> </rss>
<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Minified using apc
Page Caching using disk: enhanced
Database Caching 7/13 queries in 0.006 seconds using apc

Served from: matthewturland.com @ 2012-05-17 18:36:52 -->
