development/javascriptplatform/Concepts – SilverStripe Open Source Trac

wiki:development/javascriptplatform/Concepts

Context Navigation

Last modified 4 years ago

Home | Concepts | Research | Migration Path

General Concepts

Consensus (more or less)

encapsulated components that can run unobtrusively and independent of cms-context => event-based architecture
provide events and prototype extension rather than method hooks
keep initial rendering on the server for graceful fallbacks (e.g. for mobile browsers)
using private methods to control API usage - implicit through underscoring members, or explicit through module pattern? ( http://yuiblog.com/blog/2007/06/12/module-pattern/)
namespacing to avoid conflicts on global scope and easier extensibility

Unclear

linkage between serverside and clientside controllers (limiting scope)
borrowing best practices from jquery ui project (?)
staying in "class" scope where possible - no event binding to dom object scopes
use "heavier" controller layer in cms to e.g. react to error-events through extjs?
decouple data storage from dom-elements

Discussion

how far can we re-architect the clientside without affecting the serverside? consistent json-responses?
seamless integration of jquery widgets: theming, event-handling, extension
assuming a similiar maturity level, where do we see the advantages of jquery over extjs in a backend context?
how unobtrusive should the backend be? navigating a tree with html links to non-ajax forms? we don't want a "light javascript" version, right?
how much maintenance and development effort are we willing to spend for graceful degradation?

UI Framework vs. JS Library and Custom Widgets

UI Frameworks enforce a common coding style and have less redundancy (e.g. localization, skinning)
Global skinning!

Website UI vs. Backend UI

As a baseline, we need widgets which work in a frontend-context as well as integrate nicely in the backend (e.g. a calendar-dropdown)
UI-frameworks tend to be heavy for frontend usage

Gradual Transition vs. Full Switch

It will be a gigantic task to switch all components at once, the codebase will be out of sync for a couple of months
Gradual Transition means overhead in our js-footprint within the CMS

JS/PHP Interaction Patterns

Generate less serverside javascript (e.g. through FormResponse?.php)
Provide serialized data to client (json), who knows what to do with it
(Ingo) Don't return raw HTML-snippets by default (too limiting in terms of control and extensibility)
- (Sam) I disagree; in a huge number of situations, this is a very natural loading mechanism. It also helps ensure that ajax code is reusable in non-ajax contexts. Instead, I think we want a clean way of sending HTML + JS to execute afterwards.
- (Ingo) We could use the HTTP Accept header to let the script control if it gets serialized JSON or HTML, but you're right, having a "best practice" of json might discourage unobtrusive coding. I'm still unconvinced about server-generated javascript-logic though, in my opinion this makes the clientside harder to debug, more side-effects, less self-contained, less secure (evaluated javascript) - Mark, what do you think?
Run standard evaluator against data-structures, which e.g. automatically updates the statusbar when {status:'My Status', data:otherdata} is defined
Let clientside handle more application state that just gets synced up through JSON (at the moment the CMS-javascript is mostly a dumb string evaluator)
Interesting Patterns:

Rich Text Editors

Ingo: Do we want to switch from TinyMCE if the UI frameworks provides an acceptable baseline solution?
Integration between TinyMCE dialogs and the new framework might prove messy. But then again, clients are used to the extended TinyMCE functionality
TinyMCE is a lot over overlap in UI-javascript-logic (tooltips, toolbar, localization, popups, calendar, ...)
perhaps make the editor-system pluggable while we're at it? (to support Textile and other rawtext-markups as well - GSOC08?)

Accessibility

How accessible do we want to be with silverstripe? its not enough to write unobtrusive markup, ideally this involves high contrast skins, sensible keyboard navigation of all widget-features and keyboard shortcuts. http://developer.mozilla.org/en/docs/ARIA:_Accessible_Rich_Internet_Applications/Relationship_to_HTML_FAQ http://yuiblog.com/blog/2007/12/21/menu-waiaria/ john resig on jquery ui accessibility: http://groups.google.com/group/jquery-ui/browse_frm/thread/ae9fdfc60a643619/233d4d4592abfc32?#233d4d4592abfc32

Mobile Support

Does a performance-heavy javascript-built UI-layer prevent mobile usage? (e.g. the iPhone caches max. 500kb per page, which is about the size of a full-blown YUI implementation without markup) Do we want to include the full UI in a mobile experience (would be possible with e.g. the iPhone), or build on a custom barebones UI anyway? http://yuiblog.com/blog/2008/02/06/iphone-cacheability/

Application Architecture

(Ingo) Basically you loose the concept of javascript-prototype extension because jQuery plugins are closures bound directly to dom-nodes (rather than subclassable prototype objects which might contain dom-nodes as attributes). closures seem more "native" in a widget-context, but don't make as much sense if you consider clientside management of application-state, event-driven interfaces and inter-widget communication (LeftAndMain?.js). Customization of jQuery plugins is only possible through hooks, while you can simply extend/inherit the PrototypeJS classes.
On the flipside, jQuery can be extended to support this development style, but its early stage (see below)
Dan Webb in favour of prototype/lowpro ( http://www.danwebb.net/2008/1/31/low-pro-for-jquery)
(Ingo) jQuery UI solved this with hooks, have a look at ui.sortable.ext.js (note the "start"/"stop" function - i'd call it a hack...). This means even when implementing lowpro for jquery within silverstripe, we have to battle with inheritance for the jQuery UI library (unless this approach is adopted officially soon, which i'm not convinced of):
```
$.ui.plugin.add("sortable", "cursor", {
		start: function(e,ui) {
			var t = $('body');
			if (t.css("cursor")) ui.options._cursor = t.css("cursor");
			t.css("cursor", ui.options.cursor);
		},
		stop: function(e,ui) {
			if (ui.options._cursor) $('body').css("cursor", ui.options._cursor);
		}
	});
```
Lowpro for jQuery trunk: http://github.com/danwrong/low-pro-for-jquery/tree/master/
Livequery (keeps behaviour in dom after ajax-updates): http://brandonaaron.net/docs/livequery/
John Resig on class instanciation: http://ejohn.org/blog/simple-class-instantiation/
Dan Webb on Dojo XHTML extension: http://www.danwebb.net/2007/10/7/custom-attributes-and-class-names
Javascript module pattern for private members: http://yuiblog.com/blog/2007/06/12/module-pattern/
Discussion:
- On jQuery mailinglist: http://groups.google.com/group/jquery-dev/browse_thread/thread/156c24d9164aaec1
- Forum post about low pro for jQuery: http://groups.google.co.uk/group/low-pro/browse_thread/thread/29b96e32fb68f45e #
- About the "Remote" classes in lowpro: http://groups.google.co.uk/group/low-pro/browse_thread/thread/2c3f0d65b69165b3