-- Jurian Sluiman <[email protected]> wrote (on Wednesday, 26 January 2011, 08:37 PM +0100): > On Wednesday 26 Jan 2011 19:54:29 Matthew Weier O'Phinney wrote: > > There's likely always room for improvement. ;-) > > > > The main things to consider are: > > > > * will the feature be used enough to justify making the changes? > > * and will you be able to maintain those features reasonably? > > * will the changes make usage more complex for the standard use cases? > > * will the changes reduce performance significantly? > > > > I certainly don't want to discourage you, but as we move forward with > > ZF2, we're trying to be careful about limiting the use cases so that we > > can focus our efforts on what developers are actually using -- and > > provide interfaces and other extension points for use cases that fall > > outside our implementations. > > Of course, I understand. You don't discourage me, I know the reasons need to > be good to change something that works :) > > There are actually two things I don't like about these view helpers. To be > clear, I talk about HeadLink, HeadMeta, > HeadScript, HeadStyle, HeadTitle, InlineScript and the Placeholder itself. > > 1) An overly complex structure. Above helpers store actual simple lists of > strings (perhaps with a little bit meta data). In this design the following > classes are created: a Zend_View_Helper_Placeholder with > a Zend_View_Helper_Placeholder_Registry and a > Zend_View_Helper_Placeholder_Container which extends > Zend_View_Helper_Placeholder_Container_Abstract because there is also a > Zend_View_Helper_Placeholder_Container_Standalone. Why?
I'd need to go back through the code to recall all the design decisions. IIRC, many of them were dictated by the following requirements: * we needed per-helper registries, but * these needed to be available across all view instances, and * we didn't want a dependency on Zend_Registry (Those were the requirements the community decided upon). We could very likely simplify the implementation now with LSB and/or simply pushing the storage into Zend_Registry. I'm not sure how much any of this is really relevant to the need you explained in a previous post, however... > 2) The usage of magic methods with __call. The code is hard to read (for > example I browse many times through the ZF code base to understand the > working > princple rather than reading the manual). Directly implement a method > addScript is much better than to discover a __call() is used with a > preg_metch() to add a <script> tag. Agreed -- that's one thing I'd like to change on all of these. While it's more "lines of code", it's also lines of code that are a ton easier to understand, and having the explicit method names makes discovery of functionality easier. > If the helpers could be simplified, "extreme" use cases like the question I > asked are easier to accomplish and I think even performance can be increased > (but that needs to be tested). Performance will mainly be increased in this particular case by a cleaner broker system (already in place in ZF2!); the operations themselves are scant microseconds each otherwise. But I agree with simplification for the purpose of making them easier to learn and maintain. -- Matthew Weier O'Phinney Project Lead | [email protected] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
