Let me try to summarize my thoughts here.
I personally want object helpers because I may want it to be extended/
overriden. Make it more "OOP syntax friendly" or more "modular" is a
bonus.
Yes, I like using this in templates:
[php]
// templateSuccess.php
$_url = sfHelper::get('url');
$_url->linkTo(..)
[/php]
and this in actions:
[php]
// *Action.class.php
$_url = $this->helper->get('url');
$_url->linkTo(..)
[/php]
To be honest I cannot find any compelling reason to argue it's far
better than sfHelper::loadHelpers() + link_to.
It can be a matter of taste.
But I do want helpers to be extensible and overriddable.
A real case: I need to append a session id to every links. Now I write
a "my_url_for" and "my_link_to" to serve this purpose.
For object helper, I can have a sfHelper to replace the alias "url"
with myUrlHelper which overrides the original urlFor() method.
This is not possible if helper class is implemented with static
methods:
[php]
<?php
class StaticLinkHelper
{
public static function link()
{
echo "Called StaticLinkHelper::link()\n";
}
public static function to()
{
self::link();
echo "Called StaticLinkHelper::to()\n";
}
}
class OverridenLinkHelper extends StaticLinkHelper
{
public static function link()
{
// This can't be called!
echo "Called OverridenLinkHelper::link()\n";
}
}
$olh = new OverridenLinkHelper;
$olh->to();
[/php]
We cannot override StaticLinkHelper::link() due to the way PHP deals
with static calls,
at least before PHP 5.3. Otherwise it may be a wise idea to declare
some helper method as
static - after all $_url->linkTo() still works no matter linkTo() is
static or not.
But consider the current url_for function:
[php
function url_for($internal_uri, $absolute = false)
{
static $controller;
if (!isset($controller))
{
$controller = sfContext::getInstance()->getController();
}
return $controller->genUrl($internal_uri, $absolute);
}
[/php]
Instead of copying and wrapping it into UrlHelper::url() (or
UrlHelper::to()),
I still prefer to have the controller initialized at the __construct()
or initialize() stage.
So my answer is "yes" to
1. Whether we should have object helpers;
2. Should non-static methods be used;
3. Should there a "sfHelper" class/object to aggregate helpers and
offer helpers to registered with aliases; and
4. Should helper alias be overridden when needed.
Okay, I need to admit that I don't have much idea with IDE and
designers because
(1) I'm yet to find a comfortable IDE for me, and
(2) My working company doesn't assign me a designer working solely for
the templates :P
What if a "compatibility layer" is offered as a plugin, just like the
compat 1.0 one?
So symfony can bundle with object helpers by default, and for those
who wants IDE and
have non-technical designers, they can download the plugin which
offers them
"url_for()" and friends. This is explicit, with code hint, and as
url_for() still
make calls to the class helpers, it is still possible to be extended/
overridden at programming level.
The only difference is that it is not meant to be a compatibility
layer that will be deprecated.
I would like to add that I actually think the extending/overriding
functionality as something like
factory.yml -- it should be an "advanced feature" which developers
should better avoid to
touch it unless they are fully aware of what it is about.
Lastly, some personal thoughts concerning plugins.
I think plugin developers should avoid overriding standard helper
behaviors. So if a developer wants
its own urlFor() method one should always write one's own
"fooPluginUrHelper".
This can avoid application developers (users of plugin) experiencing
strange behaviors
without being acknowledged. However this shouldn't be enforced -
plugin authors may offer cool
features by overriding helper behaviors.
Combining all the above, application developers can override the
behavior of helpers used by the plugin
thanks to symfony's config file structure.
Tamcy
On Jul 4, 4:51 pm, "Bert-Jan" <[EMAIL PROTECTED]> wrote:
> > On Fri, Jul 4, 2008 at 10:00 AM, Andreas Gehrke <[EMAIL PROTECTED]> wrote:
>
> >> I agree. Templates is for designers and helpers should be easy to use
> >> and very explicit. Designers don't know OOP and shouldn't be forced
> >> understand it.
>
> >> Please keep the existing explicit syntax. It works great :-)
>
> >> Btw, the above discussion clearly bear the mark of being between
> >> developers. Shouldn't this decision at least be discussed with the
> >> designers whom actually are going to use the functionality?
>
> > you are right : it must remain explicit and clear for designers.
> > but developers being able to override default helpers is also a good
> > thing for designers, as developers could provide better tools to them.
>
> > i don't think that anyone needs to understand oop to write
> > $url->link_to(); or $form->checkbox_tag(); ? Actually, it makes more
> > sense + wouldn't designers be happy to get syntax hints +
> > documentation as they code ?
>
> Having hints is my only reason for using Zend Studio to write code...
>
>
>
> > ++
> > tristan
> > ++
> > tristan
>
> > --
> > Tristan Rivoallan
> >http://www.clever-age.com
> > Clever Age - conseil en architecture technique
> > GSM: +33 6 219 219 33 Tél: +33 1 53 34 66 10
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
