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? Jay 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 <[EMAIL PROTECTED]> 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) >> >> 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 -~----------~----~----~----~------~----~------~--~---
