Labels
Zend Framework: ZendX_JQuery_View_Helper_JQuery Component Proposal
| Proposed Component Name | ZendX_JQuery_View_Helper_JQuery |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/ZendX_JQuery_View_Helper_JQuery |
| Proposers | Benjamin Eberlei |
| Zend Liaison | Matthew Weier O'Phinney |
| Revision | 1.0 - 14 July 2008: Initial Draft. 1.1 - 16 August 2008: Final Review Version (wiki revision: 28) |
Table of Contents
1. Overview
The jQuery helper allows to simplify the setup of an enviroment that uses jQuery as Javascript library and provides the possibilty to construct a wide range of ajax calls.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- MUST be a single view helper with multiple methods
- MUST be able to render as string
- MUST support direct deployment via CDN (Google Ajax Library API), using specified version
- MUST support using local install, via path
- SHOULD default to CDN if no path specified
- MUST have method for requiring plugin files (js and css)
- SHOULD be base component for further jQuery Plugins that use its infrastructure methods
The jQuery Ajax Helper should provide methods to build Ajax Requests using the jQuery Helper.
- MUST integrate with jQuery Library to append requests to onLoad Event.
- MUST add value to simply using jQuery Ajax Requests (Auto building most wanted callbacks)
- SHOULD allow inlining Javascript, but MUST default to stack Javascript to onLoad
4. Dependencies on Other Framework Components
- Zend_View_Exception
- Zend_Json
5. Theory of Operation
Theory of Operation:
Using the jQuery Helper enables one to setup an jQuery enviroment in a ZF MVC implementation very fast, specifing helper methods to include jQuery Javascript Files and additional plugin requirements.
The jQuery Link Helper allows to construct simple ajax calls from within a view template. The following call signature is proposed:
6. Milestones / Tasks
- Milestone 1: Finish First Proposal [DONE]
- Milestone 2: Community Review [DONE]
- Milestone 3: Finish First Implementation DONE (SVN: http://www.beberlei.de/dev/svn/ZendX_JQuery/)
- Milestone 4: Complete Unit Test Coverage [DONE]
- Milestone 5: Finish Component
- Milestone 6: Documentation
7. Class Index
- ZendX_JQuery
- ZendX_JQuery_View_Helper_JQuery
- ZendX_JQuery_View_Helper_JqLink
8. Use Cases
9. Class Skeletons
Congrats for idea and for work on this component. jQuery is a must to for ZF since jQuery is highly used by developers...
A jQuery view helper will be a great addition to the Zend Framework since many of its user, including me, use this library. Thank you!
A few notes, based on the dojo version: please try and mimic the dojo method names as much as possible so that we can start determining what might be put into an abstract class and/or interface. For example:
- setLibraryPath() -> setLocalPath() (this one also better encapsulates the distinction between a remote CDN resource vs. a local resource)
- addStyleSheet() -> addStylesheet() (same goes for the get variant)
I'd also recommend extending the new Zend_View_Helper_Abstract, which will negate the need for the setView() method. (note to self: must do this for the dojo() helper as well!)
Additionally, I'll just get this out of the way now: start using the ZendX prefix. We've already determined and publically stated that any JS toolkits outside of Dojo will be in the extras library. As such, you should show a use case indicating how you would attach the view helper to the view object ($view->addHelperPath('ZendX/View/Helper/', 'ZendX_View_Helper')).
Finally, do you think it likely that there would be additional jQuery components outside the view helpers at any point? If so, I'm going to recommend using a top-level namespace: ZendX_JQuery. The rationales are that it keeps all jQuery components grouped, making them easy to locate in the tree; it promotes encapsulation; and it promotes the idea of use-at-will.
Nice work, and ping me if you have any questions or would like help with identifying abstraction points (for a generic JS view helper interface or abstract class).
Thanks for the feedback. I will add all the changes to the method body tonight. Also i will claim ZendX_Jquery then. (or can it be JQuery? ZF Coding Standards Puzzle me on this specific application of the CamelCase rule).
Additional components are possible, ajaxForm, Autocomplete and such stuff. But at first i plan to implement this Helper and the basic jQuery Ajax Functionality and then maybe extend the functonality to include additional features.
We discussed CamelCasing yesterday internally, and I made the case that it's confusing to users when our CamelCasing rules conflict with known standard names. The one caveat is that the first letter following an underscore always has to be Uppercase to ensure class name lookups will work.
So, short answer: JQuery as a classname segment is fine.
Looking forward to seeing what other features you propose later!
Please consider the above: personally, I really like that I don't have to know or think upon the name of a component, just the rules. ZendX_Jquery would be a better choice.
3 more comments by: Matthew Weier O'Phinney, Benjamin Eberlei, Matthew Ratzloff
The use cases are a bit too abstract to see how this helper will actually be used in real application code. Is the idea to place calls to the methods such as addJavascriptFile() and addStyleSheet() in view scripts for specific controllers, and then place a single call to jQuery() in the head of the layout? I think fleshing out the examples will clarify this.
Also, how would you go about configuring things such as the library path, etc. just once (in some central place, such as the bootstrap or a plugin), or is this concern not even applicable?
You're right, the UC are to abstract. I will refine them tonight.
The calls to addJavascriptfile and addStylesheet are supposed to be called in addional helpers that facilitate the jQuery Helper. For example if you write your own View Helper that uses jQuery, you can make sure that the appropriate additional javascript libraries are loaded.
One central place to define the paths and directory variables is recommended. I can clarify this in an additional Use Case.
I have incorporated Bryces and Matthews suggestions into the proposal. For anyone who has already seen the uses cases, please re-look at Use Cases 00, 01 and 02.
@Bryce: The new UC-02 clarifies your questions about calling addJavascriptFile() and addStylesheet().
@Matthew: UC-00 shows how to initialize the jQuery Helper using addHelperPath().
Maybe these links will be helpfull:
http://jquery.hohli.com/
http://jquery.hohli.com/zf.html
Good to see that someone is working on this.
A small suggestion, please try to replace private with protected. private visibility is really limited to your helper otherwise. If I extended your helper, I couldn't access private methods and variables.
Question to all the jQuery people, would you like to have an infrastructure helper for the jQuery Events? Or should this be left out for further extensions of the component so far? I want to push the component to 1.7 which will be released soon after 1.6, so maybe there shouldn't be too much fucntionality in this proposal just yet to get it through the process?
That would be a helper that can be included in more practical helpers like the first proposed practical helper "jqLink" or any future implementations may they be called jqForm, jqAutocomplete, jqDatePicker (NOT included in this proposal) and so on to register/inject global and local ajax events or the common javascript events like onClick, onSubmit and so on into the ZendX_JQuery_View_Helper_JQuery::addOnLoad method.
Also, what are your suggestions on the jqLink() method header, escpecilly the $options Array. Are default effects like loading, flashing, disabling (or any others) on the wishlist?
'inline' True or false, wheater to inline the javascript in onClick="" atttribute or append it to jQuery onLoad Stack.
<promotingBestPractices>
I would suggest not to have the ability of using inline JavaScript.
</promotingBestPractices>
I second this (I think), no inline JS rather have jquery assign it all by itself.
I dont like inline JS aswell, but someone might. Since the difference between inline or onLoad/grouped javascript ist in my opinion just a small difference and not at all something you have to restrict, I leave it in as optional argument. Also the documentation will provide hints why not to use inline javascript and what difficulties might occur (escaping).
People like all kinds of things, but I think "inline" is not best practice, and the component should adhere to that. At least IMHO. ![]()
I agree that best practice is not having inline JavaScript code.
Consider these scenarios:
1. Inline JavaScript, for instance an anchor with onclick attribute, will be clickable before the page has finished loading, but it may attempt to trigger code that has yet to initialize or otherwise result in an error.
2. At the same time, there may be situations where you'd want to inline something, simply because you want it to be clickable before the page has finished loading completely. That could be the case if a page has lots of images and/or third party integration that results in the page being visible and (to the visitor) usable, but is not yet fully loaded.
So I agree with Benjamin and think it would be worth having the flexibility to generate either, but to default to what most would consider best practice; onload/grouped javascript.
The flexibility and loosely-coupled nature of the Zend Framework is what makes it so attractive.
Thank you all for the feedback, i have finished a new version of the component (see SVN http://www.beberlei.de/dev/svn) and integrated all your thoughts as good as possible. Open Questions (to me) are now:
1.) Should jqLink be renamed to something more insightful? jurl? (like url Helper), or jLink or something?
2.) Should jqLink use the Url helper as parent class? Or should it be standalone? (Not inheriting the MVC route match of the Url helper).
3.) Its the $options array layout "ok"? or are there any thoughts? (See Point 5 Theory of Operation with jqLink DocComment)
I move this proposal to the next stage now, since this are questions that are more likely to match the later proposal stages.
| Zend Comments This proposal is approved for immediate development in the extras/incubator, with the following feedback:
|
ZF Home Page
Code Browser
Wiki Dashboard
On the problem of the jQuery Plugin architecture i have already written two entries on my blog:
http://www.whitewashing.de/blog/articles/47
http://www.whitewashing.de/blog/articles/48
and the question is, how a ZF jQuery component could support additional components like the jQuery
UI Library, Zend_JQuery_Form that uses a jQuery plugin or a jQuery Autocomplete View Helper. All
of which would need additional downloads of JS and Stylesheets (No CDN available). They would
add lots of additional value to people who want to construct ZF MVC projects with ajax support
in a fast way with no direct concerns about the javascript overhead (But: Refactoring all the auto-build code is supported of course).
Because of the complexity of jQuery requirements (when deadling with additions) I included lots of
helper methods that cope with this problem, deadling with js and css include directory, adding
js and css files. All this stuff will be built into HTML markup, when <?php echo $this->jQuery(); ?> is called. I don't use headScript() and headStyle() for the same reasons as Matthew did not in his Dojo proposal, to group all the jQuery stuff together and make it independant, allowing for specific disabling of all the jQuery output, when refactoring occured.
Additionally I have also tested around a little bit already and have implementations of the DatePicker and Autocomplete components working that depend on a first jQuery View Helper implementation. They require the additional includes and stylesheets I talked about, so I won't add them to the proposal just yet.