---------------------------------------------------------------- ---------------- AXEL integrator's FAQ -------------------- ---------------------------------------------------------------- Last update: January 16, 2010 by S.Sire This document gives some advices for integrating AXEL into your application. It is presented as a FAQ. You are welcome to share your experience to improve it. PLEASE READ THIS DOCUMENT BEFORE USING AXEL Summary =======
How to build the library ? ========================== The library comes with the latest sources concatenated and minified inside axel/axel.js. However it is wised to make a fresh version by running the "build.lib" target in the scripts directory ("cd scripts" then "ant build.lib"). This requires that you install the Yahoo UI compressor onto your machine, and that you edit the "scripts/ant.properties" file to point to it. You can get the Yahoo UI compressor at http://developer.yahoo.com/yui/compressor/
How to build the library for debugging purpose ? ================================================ Follow the instructions above with "build.debug" target instead. The generated library will be a concatenated version of all the library files including comments, which is more convenient for debugging purpose. This does not requires to installe the Yahoo UI compressor.
How to select which source files to include into the library ? ============================================================== The files to include into the library are defined by the "core.lib.files", "editor.lib.files", "devices.lib.files", "filters.lib.files", "services.lib.files" and "util.lib.files" in the "scripts/ant.properties" file. You can remove some files to generate a smaller library. The dependencies between the source files are explained in the "How to know which files to include in the library ?" entry of this FAQ>
How to choose between the basic XML loading algorithm or the robust one ? ========================================================================= When loading XML data in a template with xtiger.util.Form.loadData, as described in the tutorial, the library uses the XML loading algorithm defined by the defaultLoader property of xtiger.editor.Generator. That property is set by the latest of the two source files "xmlrobustloader.js" and "xmlloader.js" which is included in the library. The basic algorithm is set as the default one in this distribution (i.e. "xmlloader.js" is included after "xmlrobustloader.js"). Alternatively you can explicitly set the loader object by calling the setLoader method of xtiger.util.Form with either a new xtiger.editor.RobustLoader, or a new xtiger.editor.BasicLoader argument to select respectively the robust or the basic algorithms (in that case do not forget to include either "xmlrobustloader.js" or "xmlloader.js" into the library). The robust loader uses a greedy algorithm for loading XML data. It supports some forms of backward compatibility at the data level when a template has been modified. The drawback is that the template must conform to a set of restrictions on the full XTiger XML specification. The modifications themselves are limited to a restricted set of modifications. Both the XTiger XML restrictions and the allowed modifications are defined in a "Guidelines for writing robust XTiger XML templates" document written by Antoine Yersin which is available on demand (contat us). In conclusion be very careful if you want to use the robust XML loading algorithm. In particular USING THE ROBUST XML ALGORITHM ON TEMPLATES WHICH ARE NON ROBUSTS may lead to some data loss and distortions when editing data.
How to test the core features of the library after checkout ? ============================================================= The first thing to do is to open test/auto/loadSave.xhtml and to hit the "Run Test" button at the upper right, within each browser and on each operating system that you intend to support. The test configuration is described in test/auto/configuration.js, hence you can also customize it with your own test. Each test is defined by a template and an XML sample data file produced with the template. The test will load the template, transform it, load the XML sample data, dump the XML data, and compare it with the initial data. It FAILS if there is a difference, which means something is wrong. You are encouraged to create your own configuration and make extensive tests on your own data when ugrading the library to a newer version. Currently all the tests configured by default PASS on Firefox 3, Safari 4, Opera 10. The tests with the "wiki" filter (Fiche-Projet and Article) FAIL on Internet Explorer 7 & 8, we will debug this later, in the meantime do not use these filters on IE. The tests with the "richtext" plugin FAIL on Opera and Internet Explorer 7 & 8. This is due to some minor differences in the serialization results. However it doesn't mean the plugin is not functional but only that different browsers give different HTML serializations which are all valid and can be viewed in any browser. All the tests above can be executed directly from the file system on Firefox 3, Safari 4, Internet Explorer 7 & 8, Opera 10, on Windows, Mac OS X, and Ubuntu. For Google Chrome there is a security restriction that prevents to open URLs with XMLHTTPRequest from the file:// domain. In that case you must launch the test from behind a Web server (see "How to configure scripts/server/server.rb to execute the tests" if you want to use the test server provided with AXEL).
How to test the interactive features of the library after checkout ? ==================================================================== The second thing to do is to test the library with user interactions. There are two ways to proceeds, unfortunately none is automatized yet and requires user interaction... The first way is to open each pre-defined template distributed with the library from the test/gui folder inside a target browser. There should be different templates for the core library and each of the plugins. Each template imports the AXEL library which has been generated inside the axel folder (see "How to build the library ?") and transforms itself to become auto-editable. Then follow the instructions of each template that describe some interactive tests to performs. The second way is to open editor/editor.xhtml, select a template (Page shortcut drop down list) and hit the "Visualize" button to generate the corresponding editor and enter data. You can also use the preferences button to load XML data inside a template. Here are some possible tests: - open Curriculum.xhtml template and load ../data/cvHaddock.xml - open Carte-Resto.xhtml template and load ../data/carteResto1.xml or ../data/carteResto2.xml - etc. (all the sample templates are in the templates folder) You can also directly test your own template by entering its path by hand. We strongly advice that you do so with your own template and test the interactive features before upgrading the library to a newer version. The editor.xhtml application can be run directly from the file system with Firefox 3, Safari 4, Opera 10 and Internet Explorer 8. It renders the templates inside an iframe. This is convenient as it also loads the external CSS files. We have some problems with Internet Explorer 7 not loading correctly the templates (MIME-Type sniffing issue, and/or not injecting the AXEL style sheet inside the iframe). In that case you can use editor/editornoframe.xhtml that does the same thing but without an iframe. The drawback is that in that case any external CSS files included by the template will not be loaded. For your convenience you can also open demos/index.html that contains links to several demonstrations; they are built the same way editor/editor.xhtml (i.e. an iframe).
How to learn about AXEL API to load and transform templates into editors ? ========================================================================== You should read the AXEL tutorial that starts in examples/tutorial/tutorial.xhtml Alternatively you can look at the source code of: - editor/editor.xhtml or demos/launch.xhtml : to see how to load a template and transform within an iframe - editor/editornoframe.xhtml : to see how to load a template with an Ajax request and transform it to a div in your application Web page - examples/standalone/curriculum.xhtml (NOT YET AVAILABLE) : to see how to transform a Web page into an "editable" Web page by directly embedding the template within it
How to write portable (cross-browser) templates ? ================================================= Use the file templates/Template.xhtml as a starting point for your templates
How to Serve portable (cross-browser) templates ? ================================================= We do not have a definitive answer. But we have noticed the following facts. From the local file system, to open a template file either in a Web page or in an iframe, the file should have a .xhtml extension. In addition for Internet Explorer you should include the following META tag (it seems the META tag prevails for MIME-type sniffing when opening file from the local file system): <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> From the local file system, to open a template with the XMLHTTPRequest object or with an ActiveX object, we have no opinion :) From a Web server, to open a template file either in a Web page or in an iframe you should serve it with the "application/xhtml+xml" MIME type for all browsers excepted for Internet Explorer. For IE you should serve it with a "text/html" MIME-type. Be careful however that the "text/html" MIME-Type will fail on all the other browsers. Hence you should implement content-type switching on the server. Alternatively you can server a template from a Web server to an XMLHTTPRequest object or an ActiveX object. It seems that in that case the best thing to do is to serve it with a "text/xml" MIME-type which is acceptable on all the browsers.
How to configure scripts/server/server.rb to execute the tests ? ================================================================ scripts/server/server.rb starts a Web server that listen on port 8042 (http://localhost:8042/demos/index.html) and that serves the full library distribution. You can use it to launch the sample applications and do some testing from behind a Web server in case you have problem to launch them from within the file system. Read the previous entry "How to Serve portable (cross-browser) templates" to learn how to properly configure their MIME-Type. The server.rb script does not implement contextual MIME-TYPE switching, hence you must set your own by hand depending on the case, and using an instruction such as my_mime_types.update({"xhtml" => "text/html"}) (see the source code).
How to get some documentation about the available plugins ? =========================================================== This is a weak point we are working on. As a starting point we are writing some How-To style guides in the docs folder. We currently have a link-plugin-howto.txt guide for the "link" plugin, a photo-plugin-howto.txt guide for the "photo" plugin and a video-plugin-howto.txt guide for the YouTube "video" plugin. The "string" and the "text" (which should be preferred) plugins are described in the specification (the XTIger-XML-spec.html document in the docs folder). Alternatively you can have a look at the templates given as example in the templates folder, more specifically the Editors.xhtml and the Plugins.xhtml templates should be seen as catalog files of existing plugins.
How to build some documentation from the source files ? ======================================================= We have started to experiment with using JSDoc style comments to automatically generate documentation from the source files. However at that moment only very few files have been properly commented. However if you want you can try to generate the documentation with the "build.doc" target defined in the ant script in scripts/build.xml. You must first install JSDoc-toolkit and sets its path inside the "jsdoc.generator.dir" property of the scripts/ant.properties file. The documentation will be generated in the folder defined by the "doc.build.dir" property and that defaults to docs/jsdoc. Let us know if you think JSDoc style documentation is more important than writing a separate developer's manual, since we are still balancing between both alternatives. Meantime if you want to learn about the intricacies of the library you should directly read the comments inside the source code. You can get JSDoc-toolkit at http://code.google.com/p/jsdoc-toolkit/
How to know which files to include in the library ? =================================================== All the files in "src/core" are required except "iebrowser.js" which is required only to run on Internet Explorer. All the files in "src/editor/classical" are required except "string.js" and "xmlrobustloader.js". "string.js" is required only if your templates use the 'string' primitive editor. "xmlrobustloader.js" is required only to use the robust loader algorithm. In that case you can omit "xmlloader.js" if you don't use the basic loader algorithm. You must leave "xmlloader.js" after "xmlrobustloader.js" to set the default loader algorithm to the basic one. You need the files in "src/plugins" according to the primitive editors you use in your templates: text.js: 'text' primitive editor (depends on text.js device) select.js: 'select' primitive editor (depends on popup.js device) link.js: 'link' primitive editor (depends on popup.js device) richtext.js: 'richtext' primitive editor (depends on popup.js device) photo.js: 'photo' upload primitive editor (depends on popup.js, upload devices and documentid.js filter) video.js: 'video' primitive editor for YouTube video (depends on popup.js device) You need the files in "src/devices" according to the primitive editors you use in your templates as stated above. For your information: text.js: input and textarea text entry fields popup.js: popup menu that may segmented lens.js: generic lens device (mega popup) for all lens based primitive editor upload.js: transfers a file (image file) to a server through an iframe requires a server that implements a corresponding communication protocol autocomplete.js: communication layer for the 'autocomplete' filter requires a server that implements the autocomplete protocol (this is not yet available in public release) You need the files in "src/filters" according to the filters you use in your template. The only exception are "service.js" which is required to use services and "documentid.js" which is required to use the 'photo' primitive editor. For your information: common.js: 'noxml' filter documentid.js: 'documentid' filter to be used with 'photo' plugin wiki.js: 'wiki' filter of the 'text' primitive editor (still some bugs on IE) image.js: image inclusion by URL filter of the 'text' primitive editor initially developed for the Article.xhtml template layout.js: 'layout' filter of the 'text' primitive editor used in the Story.xhtml template to edit CSS within a document (does not run on IE) video.js: YouTube 'filter' of the 'text' primitive editor, alternative to 'video' plugin service.js: 'service' filter for each of the primitive editors required if you intend to use services debug.js: 'debug' filter for each of the primitive editors autocomplete.js: 'autocomplete' filter for 'text' editor (depends on autocomplete.js and popup.js device, not yet available in the public release) You need the files in "src/services" if you use the services and depending on the services you use in your templates. For your information: service.js: required if you use any service All the other files are optional and only needed if you use the corresponding service (i.e. <xte:service key="..." types="service-identifier"/> ) common.js: 'copy' and 'copycond' (conditional copy) services capitalize.js: 'capitalize' service for demonstration purpose, used in templates/Services.xhtml debug.js: 'debug' service date.js: 'date' service (supports constraints between start date and end date) suggest.js: 'suggest' service, implement a client-server protocol to fetch and present suggestions to update primitive editor's content model (depends on popup.js device, not yet available in the public release) The files in "src/util" are optional: ioutils.js: only required if you are using xtiger.util.Logger debug.js: defines xtiger.debug.load which works with local file system on Internet Explorer.