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 -~----------~----~----~----~------~----~------~--~---
