Make KSS optional

[hannosch]

Overview

KSS is the framework used to provide a limited set of AJAX-functionality for Plone. Most of Plone's JavaScript is based on jQuery instead.

After depending on KSS inside the Plone 3 release series, KSS has neither seen the kind of wide-spread adoption inside nor outside the Plone community which warrants it to be part of the core distribution.

In the latest Plone 3.x release the main remaining feature powered by KSS is inline-validation of Archetypes content. The way inline editing has been implemented has proven to be a failure from a usability perspective. The overhead of KSS as a framework compared to the actual value provided to core Plone does no longer warrant it to be part of the core distribution.

I'd suggest we remove the hard KSS dependency and move all KSS Plone integration into the plone.app.kss and archetypes.kss packages. Interested parties and packages can then depend on plone.app.kss.

From David Glick:

These are the things that will currently stop working if you disable KSS:

• inline editing
• inline validation
• lock on edit (parts of it, anyway)
• auto-refreshing of portlets with a kssPortletRefresh class (yeah, I didn't know we had this feature either)
• some of the action menu stuff (e.g. AJAX changing of workflow state)
• navigation of the calendar portlet to different months
• triggering the initialization of some plain Javascript features (form tabbing, changed form unload protection) after page load
• AJAX update of sharing page
• folder_contents pagination and sorting (I think someone already rewrote this on plone.app.javascript trunk)

Progress

Implemented with r25107 (on trunk).

[limi]

+1.

An additional concern is the file size of KSS, which means that you can't realistically do web sites (intranets excluded) that have KSS for anonymous users, since the payload is massive.

Nothing in the core should depend on KSS, but it should be available as a tool for those who want to use it for intranet development and/or richer applications, since it comes with a significant overhead.

For basic JS functionality, we already depend on jQuery, and this will continue to be the standard in the core.

[wichert]

As an alternative I strongly suggest that we move towards a component library approach, similar to what I outlined in my goals for future Plone post from a while ago.

For the people at the UI sprint we'll have some excellent examples of how that looks and how you can use it.

[limi]

I believe we're now targeting this for 4.0 as well.

[alecm]

No risks? People like inline editing, even if the current UI for activating it is bad. Without it Plone can be painfully slow to work with. Are we planning an alternative for 4.0 (I see no PLIP)? This probably makes sense to do with the move to deco/blocks, but it may break too many expectations if done earlier.

[davisagli]

This needs an owner.

[wichert]

There is no intention to drop inline editing support. The idea is to rewrite the parts of Plone that currently use KSS to use either baseline javascript or perhaps jQuery.

[alecm]

Perhaps there's no intention to do that, but the PLIP seems to indicate that iniline editing in its current implementation is not worth having. It provides no suggestion for recreating the functionality. If it had that I'd be +1 on this "PLIP", without an indication of that intent or an assessment of risks, I'm strongly -1.

[hannosch]

This "PLIP" was written by me for Plone 5, under the assumption that Deco/Blocks is part of that release and we have essentially a new way of doing "fast editing". In that scenario it makes sense to me to retire the whole inline editing / validation story and remove KSS. If we aim to retire KSS for the new Plone 4, then the story looks a bit different. Right now the text of this ticket is incomplete if targeted for Plone 4.

[alecm]

In that case having to rewrite inline editing support and break compatibility with apps that depend on KSS, only to have the new code jettisoned in favor of deco/blocks for 5.0 seems highly undesirable.

-1 from me

A PLIP to make a slightly better inline editing activation UI using KSS would be much appreciated though.

[pupq]

I'd say -1 from integrators perspective.

They can already use jQuery directly, if they want (& some do, of course).

If KSS is optional, add-on products won't be able to realistically ship KSS actions. And KSS will wither and die, I think, if its not in the core. I think a high-level, easy-to-understand system like KSS is important to our story.

Of course, if no one can maintain it, and no one is available to shrink it down to a smaller, more componentized size, this may not be realistic.

But perhaps it's worth considering what we'd lose if we lose KSS, and figure out if we have the energy/will to save it.

[dannyb]

One of the real problems imho with KSS is not so much the payload but the time it takes to do its work. We had a few KSS rules that make pngs transparent in IE6, scans for tables and images that are too large and wrap a lightbox around them and support an ajax-based issuetracker and I notice that with each page load there is a beachball in FF 3.0 that lasts a couple of seconds. After we used javascript directly for these things, this beachball was gone. It hurts because I love KSS' concept and writing this non-kss ajax code was A LOT more work and is much harder to maintain but a couple of seconds delay was unacceptable for us.

[erikrose]

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.)

[MatthewWilkes]

While I agree with the sentiment of ditching KSS, now seems like the wrong time, let's keep it until we have the right solution in Plone 5, rather than bodging now.

FWT Vote: -1

[rossp]

FWT vote -1 since there isn't a replacement yet. I'd be +1 if this were just about refactoring KSS stuff so that making it optional or removal in 5.0 was easier.

[davisagli]

FWT vote -1. Ditto what rossp said.

[raphael]

FWT vote: -1 for Plone 4 (OK for Plone 5)

[calvinhp]

FWT Vote: -1 timing seems bad due to the potential for a more complete solution in Plone 5

[erikrose]

I'd rather not change a bunch of stuff that's just going to change again in 5. FWT vote: -1.

[esteele]

Rejected for Plone 4.0 by FWT vote.

[limi]

Adding David Glick's list what will be affected.