On Jul 3, 9:05 am, Fabian Lange <[EMAIL PROTECTED]>
wrote:
> 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.
Fabian --
If you're suggesting the behavior of helpers be changed by way of
search and replace, what would be the benefit of refactoring the
helpers system at all? Replacing "sfUrlHelper::linkTo()" with
"myUrlHelper::linkTo()" is the same as replacing "link_to()" with
"my_link_to()".
- Kris
> 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: [email protected] [mailto:[EMAIL PROTECTED]
>
> On Behalf Of Francois Zaninotto
> Sent: Donnerstag, 3. Juli 2008 11:37
> To: [email protected]
> 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 [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-devs?hl=en
-~----------~----~----~----~------~----~------~--~---
