Ticket #10901 (closed PLIP: fixed)

Opened 6 years ago

Last modified 6 years ago

Set and enforce base coding standards for our own JavaScript

Reported by: smcmahon Owned by: smcmahon
Priority: minor Milestone: 4.1
Component: JavaScript Version:
Keywords: Cc: plip-advisories@…

Description (last modified by smcmahon) (diff)

Proposer: Steve McMahon
Seconder: none yet


Browser-executed JavaScript is a mine field where many legal language constructs are unevenly available from browser to browser or fail to work with different compression schemes. Further, the apparently C-ish semantics encourage some practices -- like trying to do block-level scoping -- that can introduce subtle bugs. There is also a nasty namespace problem.

Douglas Crockford's "JavaScript: The Good Parts" defines a safe-and-sane subset of the language and a set of practices (like avoiding variable declaration in blocks) that help make js safer and more readable.

JSLint can be used to check compliance with these coding standards.


Cleaning up existing code isn't terribly difficult.

Proposal & Implementation

Create a documentated (in the developer manual) specification for JavaScript coding standards for js that is ours (not third party) in the plone core. This would basically specify use of the "Good Parts" JSLint switches with instructions on how to turn on/off tests that don't make sense in individual scripts and to declare use of globals. It would also specify some namespace conventions.

Clean up the existing scripts, starting with those in the ecmascripts skin folder in Plone itself, then moving on to the plone.app.* and plone.* spaces. I wouldn't bother with archetypes or third-party components like KSS.

It should also be possible to implement a test suite, possibly using something like Hudson, to find regressions.

This PLIP would probably be a nice fit with the PLIP to move third-party js into the collective, since it would be easier to identify what's our own code.


Documentation in developer manual. Cleaned up scripts. Test suite.


Breaking code in the course of cleaning it up. This is no small risk given our lack of browser-level test coverage for most of the js components.


Steve McMahon Others needed!



Change History

comment:1 Changed 6 years ago by smcmahon

  • Description modified (diff)

comment:2 Changed 6 years ago by smcmahon

  • Description modified (diff)

comment:3 Changed 6 years ago by esteele

Your PLIP has been accepted for consideration for Plone 4.1.

Framework Team voting on this PLIP was: Alec +1 Craig +1 Elizabeth +1 Laurence +1 Martijn +1 Matthew +1 Rob +1 Ross --

The initial implementation deadline for your PLIP is October 1st, 2010. The Framework Team would certainly appreciate you finishing beforehand so that they may begin evaluating it as soon as possible. Announce its readiness here once your implementation is ready for review.

comment:4 Changed 6 years ago by smcmahon

  • Owner set to smcmahon

comment:5 Changed 6 years ago by smcmahon

  • Status changed from new to assigned

comment:6 Changed 6 years ago by cah190

  • Cc plip-advisories@… added

comment:7 Changed 6 years ago by smcmahon

Baseline implementation of this PLIP is now complete enough for review.

The implementation has two parts:

1) The cleanup of existing javascript in plone_ecmascripts in a branch of Products/CMFPlone;

2) The drafting of a new javascript section of the developer manual, available in unpublished form at  http://plone.org/documentation/manual/developer-manual/client-side-functionality-javascript

Actual enforcement of jslint standards will require additional work with hudson.plone.org.

comment:9 Changed 6 years ago by eleddy

(In [46008]) review of javascript standards, refs #10901

comment:10 Changed 6 years ago by esteele

  • Status changed from assigned to closed
  • Resolution set to fixed

(In [46255]) Merge in PLIP #10901. Closes #10901

comment:11 Changed 6 years ago by esteele

(In [46256]) Merge in PLIP #10901. Closes #10901

Note: See TracTickets for help on using tickets.