I agree but i think it should still come with de Symfony default, like other plugins should too like sfGuardUser and etc. Cause there's some stuff that is really used a lot.
So in settings you could just comment one line to don't use a certain functionality. So could just have something like: Enable javascript support: ON # Put OFF to turn OFF this functionality This is just my point of view but certain functionalities are really used, i think it still shoul come with the default package, but you can disable what you will not use. On 24 abr, 13:47, 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 -~----------~----~----~----~------~----~------~--~---
