As for the compatibility layer, due to the poor ability of PHP to
define functions dynamically, couldn't we imagine a code generator
that creates helper files in the cache with function helpers calling
their object counterpart? Something like the admin generator
mechanism...
That way, we would have:
- ability to use object helpers
- ability to extend existing helpers
- ability to override existing helpers
- ability to use function helpers
- BC
- performance (through cache)
What do you think ?
François
2008/7/4 Tamcy <[EMAIL PROTECTED]>:
>
> 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
-~----------~----~----~----~------~----~------~--~---
