Hi,
Francois is right with regard to how it works, but I disagree with the
implication he sees.
If you choose to use a helper you do not want it to magically change its
behaviour.
Why should it be a problem to exchange the sfJavascript to myJavascript
where needed?
You even can do a conscious decision where to make this replacement.
You can do conscious decisions where to keep the old behaviour.
If you really want to replace it everywhere, this is no problem, just do a
search and replace on the whole project.
By introducing magic we introduce uncertainity.
sfHelper->get('Javascript')->link()
what will it return (despite the fact that this notation looks strange :-))?
And just a word of warning: I don’t see DRY violated by using static calls.
You really think magically&programmatically replacing behaviour is a good
idea for a web framework?
.:Fabian
PS: And If you try to say: Yes I want to javascript helper to output
different javascript based on the browser used. Then ok: If you want this
you can introduce this magic in your myJavascript helper class. Therefore
you don’t need the magic to switch the class completely. And even if you
really really want to do this, use a Adaptor pattern for this
-----Original Message-----
From: symfony-devs@googlegroups.com [mailto:[EMAIL PROTECTED]
On Behalf Of Francois Zaninotto
Sent: Donnerstag, 3. Juli 2008 11:37
To: symfony-devs@googlegroups.com
Subject: [symfony-devs] Re: roadmap for helpers in 1.2
You can't override it partially.
Imagine that you have
class myJavascript extends sfJavascript
{
public static function link_to_remote()
{
//do things
}
}
Ho do you change all calls to sfJavascript::link_to_remote() by calls
to myJavascript::link_to_remote() without changing the template code ?
That's why a variable containing an instance of the helper object is
more extensible.
François
2008/7/3 Andreas Hucks <[EMAIL PROTECTED]>:
>
> Why not static methods?
>
> sfJavascript::link_to_remote()
>
> Supports autoloading, namespaces, is clean and readable, is OOP.
>
> Cheers,
> Andreas
>
>
> Bernhard Schussek schrieb:
>> I don't like the $h idea. It's complicated to understand for new
>> developers, the extra squared brackets and quotes add unnecessary
>> complexity and are prone to errors and last but not least, the array
>> syntax is totally misused.
>>
>> IMO we should opt for the most simple, but most obvious solution: By
>> simply defining the objects in the template.
>>
>> <?php $Url = new sfUrlHelper ?>
>>
>> <html code...>
>>
>> <?php echo $Url->link_to(....) ?>
>>
>> This way it's very easy to grasp what's going on, without adding
>> unnecessary extra magic.
>>
>>
>> Bernhard
>>
>>
>> On Wed, Jul 2, 2008 at 9:41 PM, Tristan Rivoallan
>> <[EMAIL PROTECTED]> wrote:
>>> On Wed, Jul 2, 2008 at 8:03 PM, Marijn Huizendveld
>>> <[EMAIL PROTECTED]> wrote:
>>>
>>>> I can see some advantages besides the namespacing. Let's just say
>>>> that all the helpers inherit their functionality from the library.
>>>> Becase of the oop nature those helper functions are easily
>>>> overwritten without _losing_ the original functionality. E.g.
>>> indeed. i said i liked the "$h" idea because it was not too cumbersome
>>> to use. (even if it's a bit more complicated than the actual helpers).
>>>
>>> ++
>>> 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
-~----------~----~----~----~------~----~------~--~---
