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
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 <rau...@gmail.com> wrote:
> 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
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 <rau...@gmail.com> wrote:
> 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
> 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.
Clearly you're not getting me. Re-read my original post. I actually have never used them and I'm a heavy symfony user.
> 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.
I could, and there certainly are such plugins already. But it's the standard symfony provides which I'm concerned about.
> 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.
You misunderstood me. To me the PHP functions should be consistent across all the proposed plugins (visual_effect, sortable_element, etc etc remain all the same API-wise). The only thing that changes is the generated javascript.
> How would you get anything done if you are constantly updating > everything to the latest and greatest?
That's the problem to solve. Since Javascript is subject to so many modifications and is so dynamic (specially due to the number of frameworks), Symfony shouldn't choose for the developer, but the other way about. In any case, it could provide the would-be 'JavascriptPrototypeHelper' by default (and this is not just a naming issue, as I said, moving to a whole plugins-based approach is far more convenient)
If I am not mistaken, this is the approach for the upcoming 1.1 version. All the helpers actually become a plugin and I am sure it will be easy to NOT install the prototype helpers or replace them with their YUI alternatives, etc. Please, check into the features/changes of version 1.1 and see if this is not what you are talking about.
On Fri, Apr 25, 2008 at 12:32 PM, Guillermo Rauch <rau...@gmail.com> wrote:
> On Apr 25, 2008, at 1:25 PM, shanncan wrote:
> > 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. > Clearly you're not getting me. Re-read my original post. I actually > have never > used them and I'm a heavy symfony user.
> > 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. > I could, and there certainly are such plugins already. But it's the > standard > symfony provides which I'm concerned about.
> > 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. > You misunderstood me. To me the PHP functions should be consistent > across all the proposed plugins (visual_effect, sortable_element, etc > etc > remain all the same API-wise). The only thing that changes is the > generated javascript.
> > How would you get anything done if you are constantly updating > > everything to the latest and greatest?
> That's the problem to solve. Since Javascript is subject to so many > modifications and > is so dynamic (specially due to the number of frameworks), Symfony > shouldn't choose > for the developer, but the other way about. In any case, it could > provide the > would-be 'JavascriptPrototypeHelper' by default (and this is not just > a naming issue, as > I said, moving to a whole plugins-based approach is far more convenient)
In the end a standard has to be set. Whether it is a helper or plugin
doesnt really matter as ultimately it is you that decides what is
used. For the latest and greatest you'd have to write your own version
of the PHP class that outputs the code in order to use the latest
functions in the Javascript anyway. If that is the case - just create
a basic plugin.
On Apr 25, 5:32 pm, Guillermo Rauch <rau...@gmail.com> wrote:
> > 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.
> Clearly you're not getting me. Re-read my original post. I actually
> have never
> used them and I'm a heavy symfony user.
> > 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.
> I could, and there certainly are such plugins already. But it's the
> standard
> symfony provides which I'm concerned about.
> > 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.
> You misunderstood me. To me the PHP functions should be consistent
> across all the proposed plugins (visual_effect, sortable_element, etc
> etc
> remain all the same API-wise). The only thing that changes is the
> generated javascript.
> > How would you get anything done if you are constantly updating
> > everything to the latest and greatest?
> That's the problem to solve. Since Javascript is subject to so many
> modifications and
> is so dynamic (specially due to the number of frameworks), Symfony
> shouldn't choose
> for the developer, but the other way about. In any case, it could
> provide the
> would-be 'JavascriptPrototypeHelper' by default (and this is not just
> a naming issue, as
> I said, moving to a whole plugins-based approach is far more convenient)
I very much like the approach that the sfUJS plugin is taking, but would like to see it expanded some.
Right now in the sfUJS plugin you define the actual Javascript code within blocks that the template parser knows to pull out and add to an external JS file. This is still very dependent on the JS library used. Certainly, with a lot of consideration towards designing something like this, it would be possible to use Javascript Helper style method calls that setup the XHTML in a "standard" sort of way, so that different "javascript behavior layers" (written in the devs library of choice) could be included that will act on the XHTML generated by the template.
This could keep the Javascript out of the XHTML (as it should be), and allow a developer to use the JS framework of his/her choice (perhaps because that developer enjoys certain widgets developed for that framework, or any other number of factors influencing the decision).
A standard naming convention would need to be used (for the XHTML classes/ids generated by the PHP helpers), and a behavior layer for each supported framework would have to be maintained (but I'd imagine the community would adopt that, since most JS frameworks have a pretty loyal fan base).
I don't use the symfony JS helpers for the same reasons as others have mentioned.
1) I don't want Javascript in my XHTML (onclick, onload, onhover, etc...). 2) I don't use Prototype.
Just for perspective, the Django project has avoided adding any "official" Javascript helpers, because they don't want to tie Django users to one particular JS framework. Which seems to generate quite a few requests for such helpers in their maillist practically weekly.
If symfony could support Javasacript helpers in an unobtrusive manner AND transparently support a number of the popular JS frameworks, it would be a powerful solution.
There is a new level of maintenance though, and I think a lot of resources would have to be devoted on developing a "standard" for the XHTML markup. All JS frameworks that matter have CSS selector support, so this is certainly feasible, but worth it?
shanncan wrote: > You mean - create an adaptor approach?
> In the end a standard has to be set. Whether it is a helper or plugin > doesnt really matter as ultimately it is you that decides what is > used. For the latest and greatest you'd have to write your own version > of the PHP class that outputs the code in order to use the latest > functions in the Javascript anyway. If that is the case - just create > a basic plugin.
> On Apr 25, 5:32 pm, Guillermo Rauch <rau...@gmail.com> wrote:
>> On Apr 25, 2008, at 1:25 PM, shanncan wrote:
>>> 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.
>> Clearly you're not getting me. Re-read my original post. I actually >> have never >> used them and I'm a heavy symfony user.
>>> 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.
>> I could, and there certainly are such plugins already. But it's the >> standard >> symfony provides which I'm concerned about.
>>> 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.
>> You misunderstood me. To me the PHP functions should be consistent >> across all the proposed plugins (visual_effect, sortable_element, etc >> etc >> remain all the same API-wise). The only thing that changes is the >> generated javascript.
>>> How would you get anything done if you are constantly updating >>> everything to the latest and greatest?
>> That's the problem to solve. Since Javascript is subject to so many >> modifications and >> is so dynamic (specially due to the number of frameworks), Symfony >> shouldn't choose >> for the developer, but the other way about. In any case, it could >> provide the >> would-be 'JavascriptPrototypeHelper' by default (and this is not just >> a naming issue, as >> I said, moving to a whole plugins-based approach is far more convenient)
|
