Thoughts on converting helpers to classes

Here is my thoughts (after reading synace patch here 
ht
tp://www.symfony-project.com/trac/changeset/2100).

Pros
----

- Namespace organization: YES

- Extensibile/Overridable: NO
   Helpers in your patch are static methods, so you cannot
simply extend 
an existing helper method. If you do so, you will have to
change all you 
calls with the new class name in all your templates (not
very practical):

<?php UrlHelper::link_to(...) ?>

to

<?php MyUrlHelper::link_to(...) ?>

- Autoloading: YES

Cons
----

- Clutter: YES, it is far more verbose and PHP templates are
already 
quite verbose (see my proposal below for one possible
solution).

- BC: I don't like the solution to have some eval() in the
code to 
create dynamic functions. I'd rather prefer to keep the old
function 
files with just the call to the helper in the class (for
performance 
reasons too) (see my proposal below for one possible
solution).

Proposal (to be discussed)
--------------------------

To be more concise and to be able to override existing
helpers, we can 
perhaps create a helper instance that autoload real helpers:

So, instead of having:

<?php UrlHelper::link_to(...) ?>
<?php AssetHelper::image_tag(...) ?>

we can have something like:

<?php $h->link_to(...) ?>
<?php $h->image_tag(...) ?>

$h (or whatever we want it to be called) is an instance of a
proxy class 
that forwards calls to the real helper classes (this $h is
created by 
the sfView and injected in the template parameters as for
the 
$sf_request, $sf_response, ...).

For this to work, we need some sort of helper registration
when defining 
new helpers:

class UrlHelper extends sfHelper
{
   public function link_to(...)
   {
   }

   ...
}
sfHelper::register('link_to', array('UrlHelper',
'link_to'));

We can also introduce an initialize() method to solve one
problem with 
actual helpers of having the sfContext instance when needed:

class sfHelper
{
   protected $context = null;

   public function initialize($context)
   {
     $this->context = $context;
   }
}

With that proposal, we can override any helper with our own
method or 
function, you just have to re-register the helper (anywhere
in the code 
- but after loading the original helper class which is not a
problem if 
you extend it):

for a function (not recommended):

function my_new_link_to_function()
{
}
sfHelper::register('link_to',
'my_new_link_to_function');

or for a class:

class MyUrlHelper extends UrlHelper
{
   public function link_to(...)
   {
   }
}
sfHelper::register('link_to', array('MyUrlHelper',
'link_to'));

and we can even rename the old helper (just in case we need
it):

sfHelper::register('sf_link_to', array('UrlHelper',
'link_to'));

This is a jsut a proposal (no code for now).

Later, we can also simplify the registration process with
some shortcut 
methods like:

sfHelper::register_class('UrlHelper');
sfHelper::register_class('MyUrlHelper');

Conclusion
----------

I don't want to introduce such a major compatibility break
before 1.0, 
so we need to be BC if we decide to implement something.

That said, I have the same concerns about the current
implementation of 
helpers in symfony, and I have to find the best solution.

Your comments on the problem, on synace patch and on my
proposal are 
more than welcome.

It is not a small change in symfony and it is not very clear
(for me) 
how we have to do that, so don't hesitate to comment and to
propose your 
own solutions to the problem.

Fabien

synace wrote:
> http:/
/www.symfony-project.com/trac/ticket/374
> 
> I'd like to create a sfHelper class and move all
current helpers into
> classes.
> 
> Then, for backwards compatibility, keep helperHelper
and modify it as
> described to create shortcut functions in the global
namespace,
> emulating the current helpers for projects that use the
current helper
> functions.
> 
> Pros/Cons so far
> ----------------
> Pros:
> Namespace organization. Allow more developers to create
more helpers
> without the concern of conflicting method names. Scope,
knowing which
> method comes from which helper instantly.
> 
> Extensibile/Overridable. Simply create a new helper
that extends the one
> you'd like to use, and add new methods or customize
existing methods.
> 
> Autoloading. There's no need to call and define your
helpers manually.
> Symfony will autoload it for you.
> 
> 
> Cons:
> Clutter. More verbose method calls in template files.
> 
> 
> 
> Please post your thoughts, pros and cons. I will be
providing a patch to
> accomplish this shortly. I would like to see this
included before 1.0 is
> released.
> 
> ~synace
> 
> 
> 
> 
> --
> To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
> For additional commands, e-mail: dev-helpsymfony-project.com
> 
> 
> 

--
To unsubscribe, e-mail: dev-unsubscribesymfony-project.com
For additional commands, e-mail: dev-helpsymfony-project.com