anchor.diff:  
   * URL Resource
   * Ant Paths
  -
  -
  -UberFire Server Concepts
  -~~~~~~~~~~~~~~~~~~~~~~~~
  -
  -These concepts are expressed in the `uberfire-server` package,
  -which contains some server-side functionality.
  -
  -* UberFire Image Servlet
  -** UberFire Image Paths
  -* UberFire Servlet
  -** App template, header template, footer template, user data template
  -
  -
  -UberFire Widgets Concepts
  -~~~~~~~~~~~~~~~~~~~~~~~~~
  -
  -UberFire is not a widget library but does include a number of useful widgets 
  -for that can be re-used.
  -
  -UberFire Widgets are packaged into modules:
  -`uberfire-widgets-commons`, `uberfire-widgets-core-client`, and
  -`uberfire-widget-markdown`.
  -
  -The `uberfire-widgets-commons` module introduces the following concepts:
  -
  -* Animations
  -** Fade in animation
  -+
  -Simple linear animation to fade a Widgets transaparency from 100% to 0%.
  -** Fade out animation
  -+
  -Simple linear animation to fade a Widgets transaparency from 0% to 100%.
  -** Sequenced Animations
  -+
  -An extension of GWT's Animation allowing animations to be sequenced one after another.
  -** Sequencer
  -+
  -A utility class to place numerous SequencedAnimations into a List and run the whole as a single animation.
  -
  -* Popups
  -** ErrorPopup
  -+
  -A generic popup to show an error message.
  -** ConcurrentChangePopup
  -+
  -A popup allowing the user to take different actions when a concurrent modification to a Path has been detected by the framework.
  -** ModalFooterOKButton
  -+
  -Popup footer showing an "OK" button. Action for button is a Command.
  -** Busy popup
  -+
  -A popup that can be used to show a message when a log running task is being executed.
  -** ModalFooterOKCancelButtons
  -+
  -Popup footer showing "OK" and "Cancel" buttons. Actions for buttons are Commands.
  -** ModalFooterYesNoCancelButtons
  -+
  -Popup footer showing "Yes", "No" and "Cancel" buttons. Actions for buttons are Commands.
  -
  -* MultiPageEditor
  -+
  -UberFire's implementation of a TabBar that allows the tab section to be located in different positions.
  -
  -** Page
  -+
  -A page that can be added to the MultiPageEditor.
  -
  -* Miscellaneous
  -+
  -There are a number of miscellaneous widgets that largely exist in UberFire to demonstrate a "show case" web application.
  -Furthermore a large number of them exist solely because UberFire eminated from a need to develop a Workbench for
  -Drools Guvnor 6.0.x. Historically a lot of existing Drools Guvnor widgets were moved into `uberfire-widgets-commons`
  -however should be considered deprecated.
  - 
  -** Lazy stack panel and the LoadContentCommand
  -** Restricted entry text box
  -** Clickable label
  -** Context dropdown button
  -** Decorated disclosure panel
  -** Dirtyable: widgets, composites, containers, horizontal panes, vertical panes, and FlexTables
  -** Editor widget
  -** Form style layout
  -** Form style popup
  -** Pretty form layout
  -** Image button
  -** Info cube
  -** Info popup
  -** Numeric text boxes (for each Java numeric type from byte to BigDecimal)
  -** Popups
  -** Resizable textarea
  -** Small label
  -** UberBreadcrumbs
  -** Common resources: images, alted images, css, general resources
  -** Simple and paged tables: cells, columns, titled cells; sortable headers, sort direction
  -** Comparable image resources
  -** A collection of built-in images (gif & png) for corners, pager buttons, dialog status icons, and more (see also uberfire-widgets-core-client)
  -
  -The `uberfire-widgets-core-client` module introduces the following concepts:
  -
  -* Components implemented as MVP:
  -** DefaultFileEditor
  -+
  -A `@WorkbenchEditor` that provides the ability to upload and download any file not explicitly handled by another `@WorkbenchEditor`'s ResourceType.
  -** TextEditor
  -+
  -A `@WorkbenchEditor` that provides the ability to edit text files (*.txt) or "dot" files (file names prefixed with a ".", otherwise known as "Meta data" files) in a TextArea.
  -** FileExplorer
  -+
  -A `@WorkbenchScreen` that provides a simple Tree based explorer of an underlying VFS. Clicking a file launches the corresponding `@WorkbenchEditor`.
  -The FileExplorer also registers a menu with the UberFire framework that gives users access to the RepositoriesEditor and ability to clone or create new Repositories.
  -** FileNavigator
  -+
  -A `@WorkbenchScreen` that provides more sophisticated navigation of an underlying VFS. 
  -** MetaFileEditor
  -+
  -A `@WorkbenchEditor` that provides the ability to edit "Meta data" files (file names prefixed with a ".") in a TextArea. "Meta data" files are also called "dot" files.
  -** RepositoriesEditor
  -+
  -A `@WorkbenchScreen` that provides the ability to view Repositories configured within the underlying VFS.
  -** RepositoryEditor
  -+
  -A `@WorkbenchScreen` that shows details of a Repository configured within the underlying VFS.
  -** IFrameScreen
  -+
  -A simple `@WorkbenchScreen` that supports showing content from a URL within an IFRAME.
  -** Wizard framework
  -+
  -A simple framework to support the implementation of "Wizard" type dialogs, where content is completed over a series of pages.
  -
  -The `uberfire-widget-markdown` module introduces the following concepts:
  -
  -* Markdown
  -+
  -An example `@WorkbenchScreen` that demonstrates a "live" editor for the Markdown text formatting syntax (http://en.wikipedia.org/wiki/Markdown).
  -The editor is sub-divided into two region; one allows entry of text markdown and the other shows a "live" (i.e. updated in real-time) preview of the rendered mark-down.
  -
  -
  -UberFire Workbench Concepts
  -~~~~~~~~~~~~~~~~~~~~~~~~~~~
  -
  -These concepts are expressed in the `uberfire-workbench` package,
  -which provides annotation processors for the core annotations in
  -`uberfire-client-api`. 
  -
  -UberFire supports re-use or authoring of any widgets however promotes use of the MVP (Model, View, Presenter) design 
  -pattern. Both `@WorkbenchScreen` 's and `@WorkbenchEditor` 's need only declare a minimal number of "hooks" to UberFire. 
  -Legacy widgets too can be simply wrapped to work within UberFire.  
  -
  -* The Workbench physical hierarchy (top to bottom): 
  -** User application
  -** UberFire Workbench
  -** UberFire `@WorkbenchPerspective`
  -** UbefFire `@WorkbenchScreen` or `@WorkbenchEditor`
  -
  -* The Workbench logical hierachy (top to bottom):
  -** User application
  -** Workbench
  -** Perspective
  -** Panel
  -** Part
  -
  -* The Workbench logical-to-physical mapping (top to bottom):
  -** Perspective -> `@WorkbenchPerspective`
  -** Part -> `@WorkbenchScreen` or `@WorkbenchEditor`
  -
  -* The Workbench relationships:
  -** Workbench -> [1..n] -> Perspective -> [1..n] -> Panel -> [1..n] -> Part
  -
  -* Annotation processors for:
  -** `@WorkbenchPerspective`
  -** `@WorkbenchContext`
  -** `@WorkbenchEditor`
  -** `@WorkbenchScreen`
  -** `@WorkbenchPopup`
  -
  -* GWT Bootstrap and UberFireConfigurator
  -** FontAwesome resources
  -
  -* The UberFire MVP framework
  -** Places
  -+
  -Every `@WorkbenchPerspective`, `@WorkbenchScreen`, `@WorkbenchEditor` and `@WorkbenchPopup` is represented 
  -by a `Place`. In order to display a `Place` developers need tell UberFire to "goto" a `Place`. UberFire
  -provides a `PlaceManager` that can be injected into your own code and used to programmatically navigate 
  -to any `Place` you require.
  -
  -*** Place Requests
  -+
  -A request for UberFire to navigate to a place.
  -
  -**** DefaultPlaceRequest
  -+
  -A request to navigate to a `@WorkbenchPerspective`, `@WorkbenchScreen` or a `@WorkbenchPopup`. These do not require 
  -knowledge of the `Path` they represent as the logical identifier of the foregoing physical entity is used to
  -lookup a corresponding entity.
  -
  -**** PathPlaceRequest
  -+
  -A request to navigate to a `@WorkbenchEditor` that is registered to handle the specified Path.
  -
  -** Activities
  -+
  -Internally every class annotated with either `@WorkbenchPerspective`, `@WorkbenchScreen`, `@WorkbenchEditor` or `@WorkbenchPopup`
  -has a corresponding wrapper class generated by UberFire's annotation processor. These classes are called `Activities`. Every
  -`Activity` is a subclass of an internal UberFire classes that plugs into UberFire's life-cycle management.
  -+
  -Consquentially every `@WorkbenchPerspective`, `@WorkbenchScreen`, `@WorkbenchEditor` or `@WorkbenchPopup` can register
  -"hooks" for UberFire to invoke corresponding to it's life-cycle.
  -
  -*** `@WorkbenchPerspective` lifecycles
  -**** `@OnStartup`
  -+
  -Executed when a request to "go to" a component is received, but prior to it being displayed by the framework.
  -This gives the component an opportunity to perform any initialization work.
  -**** `@OnOpen`
  -+
  -Executed when the component is displayed.
  -**** `@OnClose`
  -+
  -Executed when the component is being hidden, i.e. before "going to" another Perspective.
  -**** `@OnShutdown`
  -+
  -Executed after the component is closed, giving it an opportunity to release resources or perform any tidy-up operations.
  -
  -*** `@WorkbenchScreen` lifecycles
  -**** `@OnStartup`
  -+
  -Executed when a request to "go to" a component is received, but prior to it being displayed by the framework.
  -This gives the component an opportunity to perform any initialization work.
  -**** `@OnOpen`
  -+
  -Executed when the component is displayed.
  -**** `@OnFocus`
  -+
  -Executed when an existing "open" component receives the focus from either the user or when the `Part` has been displayed.
  -**** `@OnLostFocus`
  -+
  -Executed when an existing "open" component looses the focus by another `Part` receiving the focus.
  -**** `@OnMayClose`
  -+
  -Executed prior to the `Part` being closed by the framework. This gives the component an opportunity to veto closure, 
  -for example should it contain data that may need persisting. The default is for the framework to close the `Part` automatically.
  -**** `@OnClose`
  -+
  -Executed when the component is being closed normally in response to the user clicking the "close" icon for the `Part`.
  -**** `@OnShutdown`
  -+
  -Executed after the component is closed, giving it an opportunity to release resources or perform any tidy-up operations.
  -
  -*** `@WorkbenchEditor` lifecycles
  -**** `@OnStartup`
  -+
  -Executed when a request to "go to" a component is received, but prior to it being displayed by the framework.
  -This gives the component an opportunity to perform any initialization work.
  -**** `@OnOpen`
  -+
  -Executed when the component is displayed.
  -**** `@OnFocus`
  -+
  -Executed when an existing "open" component receives the focus from either the user or when the `Part` has been displayed.
  -**** `@OnLostFocus`
  -+
  -Executed when an existing "open" component looses the focus by another `Part` receiving the focus.
  -**** `@IsDirty`
  -+
  -TODO
  -**** `@OnSave`
  -+
  -Executed when a `SavePlaceEvent` is raised corresponding to the `Part`.
  -**** `@OnMayClose`
  -+
  -Executed prior to the `Part` being closed by the framework. This gives the component an opportunity to veto closure, 
  -for example should it contain data that may need persisting. The default is for the framework to close the `Part` automatically.
  -**** `@OnClose`
  -+
  -Executed when the component is being closed normally in response to the user clicking the "close" icon for the `Part`.
  -**** `@OnShutdown`
  -+
  -Executed after the component is closed, giving it an opportunity to release resources or perform any tidy-up operations.
  -
  -*** `@WorkbenchPopup` lifecycles
  -**** `@OnStartup`
  -+
  -Executed when a request to "go to" a component is received, but prior to it being displayed by the framework.
  -This gives the component an opportunity to perform any initialization work.
  -**** `@OnOpen`
  -+
  -Executed when the component is displayed.
  -**** `@OnMayClose`
  -**** `@OnClose`
  -+
  -Executed when the component is being closed normally in response to the user clicking the "close" icon for the `Part`.
  -**** `@OnShutdown`
  -+
  -Executed after the component is closed, giving it an opportunity to release resources or perform any tidy-up operations.
  -
  -** Panels and Layouts
  -+
  -UberFire ships with a single "Window Manager" that is responsible for the layout and operation of the `Workbench`.
  -The default implementation has the concept of `Panel` 's laid out according to the points of a compass; i.e.
  -North, South, East and West. The "Window Manager" also supports re-positioning of `Part` 's by dragging them
  -to new locations.
  -+
  -`Panel` 's can be of different types: 
  -
  -*** Multi-part Workbench Panels
  -+
  -TODO
  -*** Multi List Workbench Panels
  -+
  -TODO
  -*** Multi Tab Workbench Panels
  -+
  -TODO
  -*** Simple Workbench Panels
  -+
  -TODO
  -*** Static Workbench Panels
  -+
  -TODO
  -
  -** Headers
  -+
  -`Header` 's represent horizontal sections of the Workbench that can contain arbritrary content.
  -They are included automatically above the Workbench user-space ordered according to their definition.
  -For example a `Header` could be defined to hold a top-level Menu defintion and another `Header`
  -could be defined to hold a top-level Toolbar definition.
  -
  -** The Workbench Menu Bar
  -+
  -UberFire supports context sensitive Menus. Menus can be defined at different levels:
  -
  -*** Workbench
  -+
  -Developers can place a `WorkbenchMenuBarPresenter` into a `Header` to provide a top-level Menu for the whole Workbench. 
  -*** `@WorkbenchPerspective`
  -+
  -Perspectives can annotate a method with `@WorkbenchMenu` to declare a method that returns a `Menu` definition. 
  -UberFire will show the menu definition automatically whenever the Perspective is displayed.
  -*** `@WorkbenchScreen` or `@WorkbenchEditor`
  -+
  -Static screens and Editors can annotate a method with `@WorkbenchMenu` to declare a method that returns a `Menu` definition. 
  -UberFire will show the menu definition automatically whenever the screen receives the focus.
  -
  -** The Workbench Tool Bar
  -+
  -UberFire supports context sensitive Toolbars. Toolbars can be defined at different levels:
  -
  -*** Workbench
  -+
  -Developers can place a `WorkbenchToolBarPresenter` into a `Header` to provide a top-level Toolbar for the whole Workbench. 
  -*** `@WorkbenchPerspective`
  -+
  -Perspectives can annotate a method with `@WorkbenchToolbar` to declare a method that returns a `ToolBar` definition. 
  -UberFire will show the toolbar definition automatically whenever the Perspective is displayed.
  -*** `@WorkbenchScreen` or `@WorkbenchEditor`
  -+
  -Static screens and Editors can annotate a method with `@WorkbenchToolbar` to declare a method that returns a `ToolBar` definition. 
  -UberFire will show the toolbar definition automatically whenever the screen receives the focus.
  -
  
positive.code: ** Each file in the VFS supports change tracking, revision control, and update notification
  ** File types can be associated with custom viewers and editors
  ** The contents of the VFS can also be searched using a performant full-text search engine
      (TODO: is this correct? I think this is the purpose of uberfire-metadata)
  * Application components can be written in Java or JavaScript. Components can interoperate
    regardless of which language they are implemented in.
  
  
negative.code: (in-browser) code.
  
  * Annotations
  ** Perspective
  +
  Marker annotation to allow a `@WorkbenchPerspective` to declare a method that returns a PerspectiveDefinition object, defining the workbench perspective.
  ** WorkbenchEditor
  +
  A marker annotation to declare a class as being a Workbench Editor. Editors relate to specific resources within the framework, defined by their ResourceTypeDefinition.
  ** WorkbenchPartTitle
  +
  A marker annotation to declare a method within a `@WorkbenchEditor` or `@WorkbenchScreen` that returns a String defining the title for the component.
  