Places:Design Overview: Difference between revisions

Jump to navigation Jump to search

Places:Design Overview (view source)

Revision as of 19:34, 27 January 2009

2,661 bytes removed ,  27 January 2009
no edit summary
No edit summary
Line 51: Line 51:


The original requirements for Places in Firefox 3 are detailed in the [[Firefox3/Product_Requirements_Document#Places|Firefox 3 PRD]]
The original requirements for Places in Firefox 3 are detailed in the [[Firefox3/Product_Requirements_Document#Places|Firefox 3 PRD]]
== Front End Architecture ==
The Front End Architecture utilizes a MVC (model-view-controller) design. This calls for clean separation between each of the three components. The benefits of this approach are improved maintainability, stability and extensibility.
Within the Places code, the Model can be considered to be the SQL tables
and the code that creates them, the query system to access them, and the
simple manipulation pathways provided through services like
nsINavHistoryService and nsINavBookmarksService.
The View is the piece that displays information from the Model in one
way or another. In code, these are menu.xml, toolbar.xml and tree.xml.
The Controller is the piece that interprets user actions on a selection
and carries them out - basically linking the Model and the View. In
code, this is controller.js.
The extent to which these services are kept independent can be seen in the following details:
* The Model does not in general deal with presentation.
* The Controller knows of "selection" only as a concept abstract from the details of the selected View (e.g. a complex tree selection versus a selected toolbar button or menu item). As far as the Controller is concerned, the selection is a list of Result Nodes, there are no View-specific selection ranges, etc.
* The Views know nothing about the functions performed when the user interacts with their content, since that is instance specific. The Views implement a View Interface which handle translating their unique selection characteristics into an agnostic form the Controller can deal with.
The idea is that someone can instantiate a View, attach a Controller, and define the behavioral characteristics that suit their use, in very little code. Examples:
'''Bookmarks Menu'''
* instantiate a Menu View, attached to the top level Browser Bookmarks Menu.
* attach the Controller
* attach a command event listener that handles user clicks in the menu
by loading the associated URL, if any, in a browser tab
* root the View on a Model query result, and tell it to populate itself
'''Folder Selector'''
* instantiate a Menu View, attached to a menulist in the Places Search popup.
* attach the Controller
* attach a command event listener that handles user clicks in the menu by re-rooting a Tree View elsewhere in the UI
* root the View on a Model query result, and tell it to populate itself.
As you can see, this careful distinction between each allows us to rapidly build new user interface components by connecting the same Views and Controller with different application specific functionality.
<center>http://www.bengoodger.com/software/mb/places/MVC.png</center>


== Details ==
== Details ==
Comrade693
590

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/125795"

Navigation menu