Martel Valgoerad wrote:
> Of course it's a very reasonable thing to do. But I'm referring to
> bugs which
> are really critical - they render their modules useless since you
> can't even
> use them (View Helpers).
> And the next one - formatActionName. It's almost a one liner. I know
> you have
> lots of things going on and want to focus on the most important ones but
> come one... it will take 5 minutes or less to fix and test that one.
> And the
> bug is exposed for at least two weeks now.
> It makes the development harder because we all have to work on a
> tainted copy
> of the framework. For now it's easy to remember what fixes were
> applied to the
> code but with time it will only get worse.
> Above bugs are reported as tickets #8, #18 and #10. All of them have a
> If you want to get the patches in a different format just tell us.
> I bet you will get them in no time.
The best format to submit patches is unified diff. To expedite your
patches exponentially, submit them with unit tests.
> Glad to hear. I also think the current implementation is a bit
> inflexible. Would you mind sharing your ideas with us on the matter?
> Here's an idea - maybe a helper could have it's whole public interface
> exposed instead of a single method? This way you could keep all the
> current form helpers in one place (file or class). But I don't know if
> it's doable without cluttering the view with php code.
In the current implementation of Zend_View, a helper has no access to
the view instance. This means that helpers can't call each other.
Also, as you noted, each helper class exposes only one helper method.
This is very inefficient because loading twenty unique helpers means
loading twenty files, even if most of those helpers are very closely
related and could be packaged together (e.g. form helpers).