As I demonstrated before helpers could simply be functions generated from classes, the feasbility is proven here : http://trac.symfony-project.org/browser/plugins/nahoClassHelpersPlugin Take a look at this forever-draft work that tries to give a toolkit to get rid of these silly helpers as functions, still being able to call fast-written functions in templates for full backward compatibility.
Have a look here too : http://groups.google.com/group/symfony-devs/browse_thread/thread/f20eb32c81439d60 I hope it could up this idea :) On 8 sep, 18:47, Kris <[email protected]> wrote: > As Tom says above, helper functions should not be used in controller > or model code. > > Breaking scope is not ideal. Each method should be a 'black box' that > knows nothing beyond it's scope, and gets required objects/variables > through dependency injection. Functions in PHP have the global > scope. If you write a helper function that is needed by one of your > classes, then you really should wrap the helper function in a class of > it's own. Then pass the object and call your method. Your code will > be cohesive, decoupled and interface driven. > > Helper functions are there to manipulate and automate GUI tasks. In > that sense, helper functions should be acceptable at the View layer, > since the output of the application should happen in the global > scope. But you don't want to use them anywhere else. > > On Sep 8, 10:36 am, Stefan Koopmanschap <stefan.koopmansc...@symfony- > > project.com> wrote: > > On Tue, Sep 8, 2009 at 4:15 PM, Jacob Coby<[email protected]> wrote: > > > > On Sep 8, 2009, at 9:52 AM, Szabolcs Heilig wrote: > > > >> After reading that i'm imagining a helper system where symfony form > > >> helpers, > > >> link helpers, etc will be in helper classes. These classes can be > > >> inherited > > >> by AJAX, Lightbox link helper classes and use and extend codebase > > >> of the basic > > >> link helpers, etc. > > >> In this case you only have to change the class before the link_to() > > >> helper > > >> method to open your link in a lightbox instead. > > > >> I think it will be a big win against the loss of longer helper calls > > >> in the template code. > > > > How is changing sfUrl::link_to() to myUrl::link_to() any better than > > > changing link_to() to my_link_to()? It's the same amount of work and > > > the same amount of testing. It's just that one has been wrapped in > > > class boilerplate to namespace it. > > > > Helpers are part of the view, and are by definition orthogonal to the > > > controller. They will need to go through the same gyrations to access > > > request/response objects or the context or the controller whether in a > > > class or not. > > > > Changing helpers to be based on classes has been brought up several > > > times in the past. I've not seen any compelling arguments as to /why/ > > > using classes for helpers is better. It just means more typing. > > > What about the above idea of extending classes? You could have > > (partial) code reuse which would be very useful, where this is not > > easily done right now (because you have to manually load the base > > helper in your helper before you call it). > > > Anyway, I was *not* saying symfony helpers will be that way, I was > > only saying I was doing it that way for my custom helpers (since I > > personally prefer that approach). > > > -- > > Stefan Koopmanschap > > Symfony Community Manager > > [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
