Search:


Wisdom.Philosophy

Recent Changes
Printable View
Page History
Edit Page

The Wisdom Approach to client-side code:

  • Enable quick, cross-browser compatible implementation of front-end features without large black-box code hierarchies to learn.
  • Keep separate low-level base/utility code from high-level widgets and features (ie. logging and geometry vs widgets and modules). This enables custom builds of the library that contain only minimal required functionality.
  • Enable piece-meal usage. Just because a user wants to make use of the wisdom SlideShow component, does not mean they should have to bring a lot of other inter-operating baggage into the fold.
  • Prefer CSS to Javascript when implementing features, unless to allow for legacy browser compatibility. This means many wisdom "features" can be static templates.
  • As far as practical, try not to hijack elements and turn them into opaque wrapper APIs - rather inter-operate with well-supported CSS and DOM techniques, proving utility shims here and there.
  • Following on from above, wisdom attempts to leave well-standardized things alone, for example wisdom.ui.Form does not completely wrap an HTMLFormElement? but simply contains and augments it. Wisdom widget objects should be created via constructor function in a fire-and-forgot manner, so that further interaction with Wisdom APIs remains minimal.

See also

This is part of the Reference Documentation for the Wisdom Javascript Library? (or wisdom.js)