Description Susan McCourt 2012-01-22 17:50:14 EST

The initial contribution for the settings page has most of the relevant code in settings.js.  This was nice for seeing everything all in one place, but as the function grows we will want to parcel this out better.  Some suggestions/thoughts as this stuff gets better integrated into Orion (not critical for 0.4, but should evolve as we try to make use of more of your stuff in other pages.)

- traditionally the *.js that matches the *.html is what we call the "glue code."  It is the code that knows how the html page is laid out, instantiates helper objects, and passes in dom id's, etc.  It also defines command framework commands and registers them on the page.  So settings.js should probably be trimmed down to do just that.

- the code that is managing editor themes should live in its own file.  Assuming there is no desire to make this available for stand alone editors, I suggest a file like web/orion/editorSettings.js.  But we should check with Felipe/Silenio as to whether we want this dynamic setting ability available underneath, in which case some code may move down, and the part that knows how to live in the pref page would live in client.core/web/orion

- likewise, the plugin code should be separated 

- we need to define an extension point for pref page contributions, so the glue code would just look for all extensions and then build the sections one by one.  For an example, see fileCommands.js  line 742.  (in that case the contributions are being iterated and commands are being built.  In this case we'd iterate the contributions and build sections.)

- the navigator ui should be separated out so we can use in other pages.  It'd be nice for this to evolve into a generic (section selector) that could be used in other pages.  I could imagine something like this in the glue code:

    new SectionNavigator (parentDomID, "Categories", targetPageId)

and then it could look for sections and add their "names" to the navigator.  In other words, rather than build the "categories" from the preferences page extensions, it'd be cool to build the categories from the elements in the adjacent div, so that we could use this style of traversal for other sectional pages.  (see also bug 368848)  

- some of the utility methods like "processInputType" could move into util.js if they are truly static.  We have helpers here that generate bits of UI and other stuff.  I could imagine that the command parameter collector and the preferences UI would use the same utility methods so that we are consistent in our use of color pickers, numeric pickers, etc. etc.