I agree that the name of the helper should change but its inclusion is necessary.
This is a pigheaded sentence (and I dont mean offense) but : Don't use them if you don't like them. What I mean by this is : Symfony is a framework, it's the basic building blocks. If you want better functionality in certain areas (i.e Javscript and AJAX) then create the better solution. Provide the solution as a plugin back to the community. The problem with new versions of anything is that function names change and expected outputs from functions cannot be guaranteed to be the same. At some point you have to settle on something - and this is what has been done. IMO the functionality of prototype and scriptaculous included with symfony is extensive for a good UI. How would you get anything done if you are constantly updating everything to the latest and greatest? On Apr 24, 5:47 pm, Guillermo Rauch <[EMAIL PROTECTED]> wrote: > Hello everyone, > > I'm writing to share my thoughts on the decision of including > Prototype/script.aculo.us Javascript helpers by default on the Symfony > package, as well as its promotion. This is just my point of view. > > First of all, I think inline javascript code being output by the > framework directly on the XHTML template is really a practice that in > our current era of web development looks outdated to me. I won't dwell > into the reasons of this, what I think is best explained > here:http://en.wikipedia.org/wiki/Unobtrusive_JavaScript > . > > Of course, with the flexibility of Symfony, one can opt out of this > practice and ignore the JavascriptHelper altogether. But I'm more > concerned about Symfony shipping with an obsolete programming > technique, as well as its propaganda on the site > (http://www.symfony-project.org/tutorial/1_0/symfony-ajax > ) and even on the homepage (easy ajax being the first button). One of > the remarkable aspects of Symfony is all the great choices made by > their creators in regards to programming patterns and modern > techniques, and to me, this just doesn't fit in. > > Two counter-arguments will arise, though: > - Those who defend this technique based on the possibility of rapid > development/GTD/etc. > - Those who still want support for their current deployments based > on this technique. > > My answer to that is an officially supported Symfony plugin (just like > sfGuardAuth) that includes the helpers, which has multiple benefits: > - Firstly, the developer decides what JS framework empowers the > Javascript Helper (another issue with the current one is that we call > it JavascriptHelper as if Prototype/Script.aculo.us and Javascript > were synonyms). This would be possible through the creation of several > plugins (sfMootoolsJavascript, sfJqueryJavascript) which define the > Javascript helper. > > - Secondly, it's easy for the developer to choose whether or not to > upgrade prototype (for example), by picking the right plugin version. > Right now not only are they 'forced' to use prototype, but I'm sure > they're often stuck with the version shipped with Symfony. And > upgrading prototype/script.aculo.us many times means upgrading the > helper (which, as a matter of fact, is impossible right now without > creating your own helper and rewriting the functions by yourself) > > So basically that's my view of how JS support can be taken to a next > level, possibly for 1.2. > Let me know what you think > > Guillermo Rauchhttp://devthought.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
