Ticket #9250 (closed PLIP: fixed)
Add jQuery Tools to base install
Reported by: | limi | Owned by: | smcmahon |
---|---|---|---|
Priority: | minor | Milestone: | 4.0 |
Component: | JavaScript | Version: | |
Keywords: | Cc: | plip-advisories@…, grahamperrin@… |
Description (last modified by smcmahon) (diff)
We propose to include the jQuery Tools library in the base Plone install.
It has a good selection of some of the most common UI primitives, is extremely lightweight (less than 6KB!), and comes from an author with an excellent track record (Flowplayer). We are starting to feel the need for at least the following cases which jQTools provides solutions for:
- Tabs (like the ones we already use in fieldsets) + Accordions
- Overlay (aka. lightbox, modal dialogs, in-page pop-ups)
- A sane Flash embedding approach
We'd like to have this as a base set of options, so add-on product authors use a standardized set of these functions for consistency and ease of development.
Getting out front with the inclusion of a UI-oriented add on for jquery will help minimize the risk of developers of widgets and other add ons choosing different UI support, resulting in excessive js-component page weight.
Why JQuery Tools?
The question is how to provide key UI elements like accordians, tabs, and overlays (popups and help) without going too far overboard. The most popular JQuery-based contender for this class of page element bling is probably JQuery UI. The problem is that it's a truly huge library (a 150kb minified core with no functionality; over 250kb minified to do small things) that requires a buy in to a whole UI philosophy. JQuery Tools, by comparison, is tiny and austere. It would leave us room to add JS and CSS while still staying code light.
Implementation
Just including JQTools would be trivial: just adding to the JS registry. We could also add the base JQT images in a resource directory.
A more ambitious implementation, though not difficult, would be to have a framework for tying CSS selectors to the JQT bling so that no JS would be required to use them in templates.
Deliverables
A popup login form with AJAX functionality that will be both functional and also provide an example of how to use JQuery Tools within Plone.
A simple, lightweight mechanism for using the main effects via CSS (or JQuery selectors).
Participants
Steve McMahon (smcmahon) and Limi -- Steve will do python, tests and docs. Limi will work on clean visuals that should work with most page designs.
Change History
comment:2 Changed 7 years ago by smcmahon
Advantages:
JQuery Tools is astonishingly small, has good code quality, and is built on JQuery.
Risks:
- JQuery Tools doesn't attract widespread support. It's a new framework, and even if successful will take some time to approach the popularity of JQuery UI.
- JQuery Tools doesn't mature. There are some important features, like dynamic control of popup size, that are currently missing.
Ameliorating factors:
This is part of the Flowplayer project, which has an excellent track record. The principal author has been responsive to discussion about missing features.
comment:3 Changed 7 years ago by smcmahon
A couple of more bits of information that may help evaluate the practicality of this PlIP:
- I've been working on a 'proof of concept' for wiring css to JQT bling: http://pypi.python.org/pypi/Products.pipbox . We might -- or might not -- want to make that part of the implementation. But, even as a separate product, it would make it very easy to add JQT bling to templates without extra JS.
- I've already got a working implementation of JQT overlay with flexible scaling of the overlays. I think this mainly proves it's not a risky deficiency.
comment:6 follow-up: ↓ 10 Changed 7 years ago by alecm
I'd suggest not including new js libraries in Plone unless we have a specific plan to make use of them in the core. Unless the potential UI redesign (or other new 4.0 features) will be making use of this, there doesn't seem to be much advantage to including this vs. having a simple 3rd-party pypi distributed package which installs the library into your Plone site. If there comes a time that the Plone core needs functionality from this library it could declare this mythical 3rd-party package as a dependency and migrate it in with little hassle.
comment:7 Changed 7 years ago by smcmahon
Alec's point is certainly reasonable. My main reason for hoping this will get in is to give some guidance to product developers so that we don't end up in a situation where commonly desired bling is being implemented with different libraries in different popular products. If PloneFormGen uses JQ Tools for popups, another popular product uses JQueryUI and yet another lightbox, we're going to look very slow and bulky.
comment:9 Changed 7 years ago by pupq
In general, I think we do well to "help users pick". Plone offers such dizzying options, so, rather than "you can use any JS higher-level library", saying "We ship with and love _, but you can replace it if you'd rather with others" makes the 5% who care about the other ones happy, and *really* helps the 95% who just want some guidance on where to start.
If we can leverage this already to improve our core interface *and* it would help steer our users to making good UI *and* add-on authors could start to expect higher-level JS functions so add-ons would use this stuff, this is +1, +1, +1 :)
comment:10 in reply to: ↑ 6 Changed 7 years ago by limi
Replying to alecm:
I'd suggest not including new js libraries in Plone unless we have a specific plan to make use of them in the core. Unless the potential UI redesign (or other new 4.0 features) will be making use of this, there doesn't seem to be much advantage to including this
The plan is to make use of it in high-value situations, with the login form being the obvious candidate here — having to leave a page to log in should be unnecessary, and most sites implement some sort of modal pop-up for logins these days. There are a number of use cases where the tools that jQuery Tools supply are exceedingly useful, but I think the intention was to not promise too much in relation to this PLIP before we know that it's implemented and working well for a couple of simple cases.
Joel's point is also excellent, giving some guidance about best-practices is important.
comment:11 Changed 7 years ago by alecm
That was not part of the PLIP when I made my comment. Now that it is I am probably +1 on it. Providing best practices guidance is important, but it rings a little hollow if we aren't making any use of those "best practices" ourselves. If it's such an essential and helpful tool, then we should be able to find some easy ways to make use of it. If it's direct usefulness to Plone remains unknown, then including it is obviously premature.
comment:12 Changed 7 years ago by erikrose
- Owner smcmahon deleted
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:14 Changed 7 years ago by MatthewWilkes
FWT Vote: +0 - I don't know enough about JS to make an informed decision
comment:15 Changed 7 years ago by rossp
FWT vote -1. Until we use it in Plone core we should not depend on it. That said, I very much want to see more guidance about what integrators/new developers should use with Plone. There are so many good PLIPs that would be great if we had #8810 'Provide a "Plone Base" distribution'. So, at the risk of repeating myself, I think this would make a great add-on to include in the installers, but not Plone core.
comment:16 Changed 7 years ago by davisagli
- Owner set to smcmahon
FWT vote: +1. In general I'm against adding more Javascript to Plone, but this particular library has a high benefit-to-cost ratio.
Please keep the implementation in a separate package so that add-ons can depend on it even if the final implementation is not accepted.
Also please look into whether it may be worthwhile to rewrite some existing Plone javascripts using JQT, such as the fieldset tabbing using the tabs plugin.
Resetting owner to smcmahon as I believe that was intentional.
comment:17 Changed 7 years ago by raphael
FWT vote: +1 while stressing the comment above
comment:18 Changed 7 years ago by calvinhp
FWT Vote: -1 I actually love this idea and would love to see it included, but until we are going to actually use it on something like modal dialogs such as the login screen, it is too high of a risk. I'd love to see it included now in more documentation for product developers as the suggested way to do it. I'll be +1 once we actually want to use it in the core.
comment:19 Changed 7 years ago by erikrose
FWT Vote: +1 iff we actually make use of it. And when you're making the shiny new login popup whatchamajiggit, please don't forget that some of us don't use form-based login. :-) (I.e., make sure it's hide-able like the current login portlet.)
comment:20 Changed 7 years ago by esteele
Approved by FWT vote.
comment:23 Changed 7 years ago by smcmahon
comment:24 Changed 7 years ago by smcmahon
comment:25 Changed 7 years ago by smcmahon
comment:26 Changed 7 years ago by smcmahon
comment:27 Changed 7 years ago by smcmahon
comment:28 Changed 7 years ago by smcmahon
comment:29 Changed 7 years ago by smcmahon
comment:30 Changed 7 years ago by smcmahon
comment:31 Changed 7 years ago by robgietema
Added review in [29333].
comment:32 Changed 7 years ago by esteele
Your PLIP has been reviewed by the Framework team. Feel free to discuss any suggested changes either here in the PLIP ticket or on the mailing lists. Final deadline for this PLIP is set for September 23.
comment:33 Changed 7 years ago by esteele
comment:34 Changed 7 years ago by smcmahon
comment:35 Changed 7 years ago by smcmahon
comment:36 Changed 7 years ago by smcmahon
comment:37 Changed 7 years ago by smcmahon
comment:38 Changed 7 years ago by smcmahon
comment:39 Changed 7 years ago by smcmahon
comment:40 Changed 7 years ago by smcmahon
comment:41 Changed 7 years ago by smcmahon
comment:42 Changed 7 years ago by robgietema
comment:43 Changed 6 years ago by rossp
FWT vote: +1 for merge
comment:44 Changed 6 years ago by esteele
comment:45 Changed 6 years ago by MatthewWilkes
FWT Vote: +1 on merge
comment:46 Changed 6 years ago by esteele
This PLIP has been accepted for merging into Plone 4.0
The final vote was: Alec Mitchell +1 David Glick +1 Erik Rose +1 Laurence Rowe +1 Matthew Wilkes +1 Ross Patterson +1
Please merge your branches into the Plone 4.0 head by end-of-day Friday Oct 16. If you need assistance with merging, please contact me.
We'll be assigning a documentation ticket to this PLIP shortly. Please assist the docs team in documenting the changes and new features that this PLIP introduces.
comment:47 Changed 6 years ago by esteele
Please assist the doc team in creating/updating documentation relating to this PLIP. See #9603.
comment:48 Changed 6 years ago by smcmahon
comment:49 Changed 6 years ago by smcmahon
comment:50 Changed 6 years ago by smcmahon
comment:51 Changed 6 years ago by smcmahon
Merged. Merge affected Products.CMFPlone and plone.app.upgrade.
Also added plone.app.jquerytools to sources.cfg for dev buildout.
comment:52 Changed 6 years ago by esteele
- Status changed from assigned to closed
- Resolution set to fixed