On Wed, 19 Jan 2011 09:31, Benjamin Eberlei wrote: > Well bad-practice is the fact that currently each form element generates > its own javascript code. > > If there were a bunch of zf jQuery plugins that are integrated and those > are used through classes then the extension might be more helpful, but this > requires a complete rewrite and stricter focus on separation of JS and PHP, > where form elements only render additional classes and these are hooked > into by general selectors on the jQuery side.
Generally, JS is often used for client-side form validation, but that's not the only capability. (see below) > In any case from a > deployment perspective it is worse to ship each javascript code rqeuired of > a single page in the page rather than shipping one application wide > javascript file that is minified and delivered gzipped (prefered > approach!). As an idea for a possible rewrite, make it possible to append jQuery plugins, so that they are in a correct order, provide ways to write your own PHP implementation of a jQuery plugin (plugin broker). Compatibility with Zend\Dojo\Form should be urgent, If it's not the case at the moment. Integration of jQueryUI is at least an option. Maybe a second ZF component for minifying and gzipping solves Benjamin's approach, this would also be useful for developers in generally. (Yeah, I know about mod_deflate and others) > The first approach is what ZendX jQuery plugin currently does and there is > just no way to go from that approach to a javascript based file approach > without starting from the beginning. If jQuery remains as a part of ZF, it should be a (sorry for the buzzword) "state-of-the-art" implementation and provide options, other (PHP) frameworks doesn't deliver.
