-----------------------------------------------------------------------------------
---------------- How to develop a primitive editor plugin in AXEL  ----------------
-----------------------------------------------------------------------------------

Stéphane Sire
Last update: June 22nd, 2010     

Summary
=======
Primitive editor plugin functionalities 
=======================================

Primitive editor plugins manage: 

* generation of a static presentation of the data into the DOM (what we call "the handle")
* conversion of content from and to XML (respectively XML loading and XML linearization)
* generation of a interactive presentation for editing (what we often call "a device" or "a lens")
* control of user interaction for editing content

Primitive editor plugins are implemented with a Factory design pattern. The factory object registers itself to the AXEL document editor generator object (editor/classical/generator.js) with the same identifier that is used in the  XTiger element.     

For example the factory object for the 'text' primitive editor is defined in xtiger.editor.TextFactory

The factory object must create what we currently call the editor model object ("the model"). Model objects will in most cases  instantiate extra objects to manage interaction with the user, the architecture of each primitive editor is to some extent under the control of the plugin's developer, we recommend using an MVC architecture to implement each plugin as a set of classes.

For example xtiger.editor.TextFactory creates instances of a hidden _TextModel class. 

TO BE COMPLETED  

Explain createFromTree and createFromSeed...

Delegation to filter pattern anchored on the model's life cycle

Can / execute pattern for third party object (e.g. devices) to call third party filter extensions not part of the default model's life cycle  
Plugin API introduction
=======================

We take the 'text' primitive editor plugin as an example to explain our current view of how a plugin should be written. The 'text' primitive editor is a good example as it also support filters.

For a complete description of each methods and its parameters, please have a look at the source code of generate the documentation from the source code using the ant "buil.doc" target.

Plugin model objects should define the following methods. All these methods should apply the delegation design pattern so that filters can be applied to the plugin to extend its behavior.

All the methods subject to delegation have a default behavior (similar to the default action in HTML terminology). For this reason delegate filters should chain calls up to the default method of the original object (using the remapping mechanism described in the "howto-filter" document). They should break the delegation call chain only when they do something not compatible with the default behavior.   

The * on a method means that a priori we didn't find any reason yet to use delegation to filters for it            
Methods subject to delegation by filters
========================================
create
~~~~~~

The model has just been allocated into memory (i.e just after new). At that time the object does not contain any useful information.

Default behavior: nop                                                                                                               

Note: not yet called in 'text.js' !
init
~~~~                         

The model is initialized with data from different sources:
- some properties that are stored in the param attribute of the xt:use element
- some initial data that is contained in the template tree
- an optional option attribute of the xt:use element to make the editor optional

Note that when init is called, the handle (the DOM presentation of the model) have already been created and the model has been assigned a unique key which is passed to init as parameter.

Default behavior: store initial data, interprets and copies the initial the value into the handle, sets the optional status, stores the DOM document the model belongs to

      
awake
~~~~~

The model starts listening for user events.

Default behvaior: add event listeners to detect user events to trigger content editing


duplicate
~~~~~~~~~

The model ...

This is considered an optional callback.... 

Default behvaior: no operations (undefined)


      
load
~~~~

The model loads data from the current point of the DOM data source.

Default behavior: reads data and copies it to the handle, replacing any existing data
save
~~~~  

The model generates XML content inside a DOM logger from its current state.     

Default behavior: copies the handle first child node data as text in the DOM logger
focus
~~~~~

The model receives focus (e.g. form the keyboard)       
                                                
Default behavior: calls startEditing
startEditing
~~~~~~~~~~~~     

The model switches to editing mode

Default behavior: 'text' starts it's 'text-device' which itself initializes and shows the editing field (input or textarea)   
  
getData
~~~~~~~

The user has activated the editing of the model content

Default behavior: takes the content of the first child of the handle as the content to edit
unfocus
~~~~~~~                

The model has lost focus (e.g. from the keybord)

Default behavior: calls stopEditing
stopEditing
~~~~~~~~~~~

The model returns to static presentation mode of the handle

Default behavior: the associated device terminates editing and cause a call to update 
update
~~~~~~

The user has edited some new content which is different from the default content

Default behavior: copies user's data inside the handle
_setData 
~~~~~~~~

Sets the content of the handle.
clear
~~~~~

The model should resets it's content to the same content as after initialization

Default behavior: copies the default content to the first child of the handle
set 
~~~ 

The model is selected 

Default behavior: sets the checkbox as selectedm propagates selection to ancestor's repeaters
unset
~~~~~

The model is unselected 

Default behavior: unset the checkbox
remove
~~~~~~

The model has been removed from the editor. Note that this method is not called if the model was the only slice inside an optional repeater that becomes unselected.

Default behavior: does nothing.
Public methods
==============

These methods can be called from third party objects
can
~~~

Asks if the model is able to execute an optional method whose name is given as parameter
execute
~~~~~~~                                                                                 

Executes an optional method whose name is given as parameter and with the given parameters  
getParam
~~~~~~~~

Returns a parameter value set on the xt:use param attribute or its default value
getUniqueKey
~~~~~~~~~~~~

Returns the unique identifier associated with the model 

Note: this is generated by the default init method
getHandle
~~~~~~~~~   

Returns a DOM node, usually the top node of the handle
getGhost 
~~~~~~~~

Used by text device to compute initial shape for editing
getDocument
~~~~~~~~~~~

Returns the document    
isFocusable
~~~~~~~~~~~

Returns true if this model can receive focus
isModified
~~~~~~~~~~

Returns true if the model content has been modified and is different from the default content
setModified
~~~~~~~~~~~

Signals that the editor content has been modified. This method should be called by filter delegate if they change the model content.

NOTE: it is not clear if setModified can be set to true if the content has been set to the default content, that should be avoided ! [maybe that will be guarded in setModified that could be renamed to updateModificationStatus]