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?
/Andreas Gehrke
On Jul 3, 6:05 pm, 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.
>
> 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
-~----------~----~----~----~------~----~------~--~---
