#####################################################

(WIP) Text editor app migration 17/05/2019

This approach needs an extra manifest file along with usual appcache file: a gadget_officejs_[tool].configuration, that contains mainly the urls to get and cache in indexedDB the configuration elements of the app (like form definitions, portal type actions, etc.). This caching-storage process is done in gadget_officejs_jio_js createJio method, and the manifest gadget name is hardcoded (e.g. "gadget_officejs_text_editor.configuration"). It should be generated using some web site configuration, but at that point of the app, there is no router.html (to use gettSetting) or a way to get web-site properties like e.g. ${cache_file} in bootloader. Those configuration urls, along other needed elements, are in the appcache manifest too. The Front Page Gadget of the site is the ojs_controller, which handles different views (modules/lists pages, doc pages) and by default it renders the view for the "parent_portal_type" set in the web-site router. (e.g. in text editor, "parent_portal_type" = "Web Page Module")

Some new forms and actions were created for this migration, the idea is to use the previous work in js side as it is (generic) and only migrate apps changing the configuration side. Note: this approach needs a explicit portal action to add elements (e.g. new_text_document action in portal type Web Page Module); so for now the 'add' icon in the header is missing, the action button (and page) must be used to create documents. In order to have the add icon back, the form definition must contain in the corresponding link, the information of the portal action. There is need of some specification to decide in any portal type, which is the action that correspond to the document creation (e.g., the action to add elements for Web Page Module is new_text_document, and not list_ui or jio_view).

For now, there are hardcoded paths in the hateoas script to get the form-path of the actions, because in the context of getting portal actions (via hateoas url) the expression string:${object_url} isn't evaluated (that is done usually on the context of getting the form-json of specific documents -e.g. hateoas url for post_module/12-).

TODO: web_viewAsJio and unit tests

#####################################################

Commits description until rabase

• editable form view isn't removed due it is generic enough (not attached to specific views, forms, etc.)
• submit handling in controller gadget
• appcachestorage sync saves the configuration elements (like form definition) as metadata documents, and respect the json format that allows jio_allDocs queries.
• portal type actions added to appcache and configuration manifests (corresponding hateoas urls).
• hardcoded form path removed in controller. Now it gets the jio_view portal type action using jio_allDocs and with the result it gets the form definition. All generic based on context (jio-doc) portal type.
• the app works offline properly
• all test passing

Problems: the portal type actions content got from hateoas contains TALES expressions. For example: some_portal_type -> some_action -> action field: string:${object_url}/my_view this means that the action document saved in local storage contains this TALES (that obviously can't be evaluated in JS side). For now, there is a hardcoded value in hateoas script for the html post view. Possible solutions:

• set in the portal type action the evaluated final value without TALES (e.g. action field = skins/blabla/my_view) this fails when rendering the posts because portal.portal_actions.listFilteredActionsFor(traversed_document) in hateoas expects a TALES expression.
• try to evaluate the expression in the hateoas script to return final value in the action json I couldn't achieve this yet because the eval is done by listFilteredActionsFor when the traversed_document is a post, and not when it's the action

#####################################################

Commits until 15/03/2019

Description: the appcache content is save as documents (jio.put) instead of attachment, so then from the rendering side, controller can do jio.get appcachestorage uses a new manifest (configuration) that only contains urls for configuration resources like form definition json.

Getting rid of editable form view so the full rendering (form + header) and content submit is done in the controller.

#####################################################

Commits until 14/03/2019

Description: the form definitions are added to appcache, and after data storage creation the content of appcache is copied there. Then for the rendering (controller gadget), the form definition is get from data storage.

Implementation details: appcache storage is used to access the appcache data and do a sync with the data storage. This occurs right after data storage is created. In the controller gadget, the form definition is get using getAttachment due to appcachestorage definition.

Problems: use appcachestorage brings the following issues:

• it uses getAttachment, so then controller gadget needs to do a getAttachment to get the form definition as a blob, instead of jio.get.
• appcachestorage saves every resource listed in the appcache file, including gadget js, html, etc. that are not needed at this point.
• the ids generated by appcachestorage are based on long urls, including an "origin_url" based on the current page of the app when the sync occurs. The idea is to have simple ids like "skins/couscous/portalType_viewAsJio".

Tests: same tests as usual. They are still failing, now because the ids for getAttachment are hardcoded urls and during the tests they are different. The app works offline and the tests should pass when appcachestorage ids issue is solved.

#####################################################

Commits on 11/03/2019

Description: the hardcoded JSON form was removed and the controller gadget gets the form definition for the document view from jio. The rendering is done in the controller using the form definition and the context (jio doc). (hateoas script extended to return the form definition with all properties raw values, overrides, etc.).

API in JS controller: .declareMethod("getFormDefinition", function (jio_key) //calls jio.get with path to form (generated from the context portal type); .declareMethod("renderForm", function (form_definition, document) { //renders the view using the form definition and the context (jio document)

Problems: the app doesn't work offline or with local storage anymore because of erp5-jio-storage.get. Next task is to somehow save the json form (in storage or appcache) to make it work local and offline again.

Tests: the tests are the same, but now they fail because the app doesn't work offline anymore.

#####################################################

INITIAL DESCRIPTION:

This MR contains work for the new OfficeJS chat application and for OfficeJS improvements on form rendering. For more details please check: https://www.erp5.com/NXD-Work.Description.Roque.Porchetto

Please refer to previous MR for discussion on the changes made here:  !821 (closed)