gsoc:2009:phdoe

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
gsoc:2009:phdoe [2009/08/13 08:01]
mrkschan update executing timeline
gsoc:2009:phdoe [2017/09/22 13:28] (current)
Line 9: Line 9:
   * Mailing list: phpdoc@lists.php.net   * Mailing list: phpdoc@lists.php.net
   * Blog: [[http://mrkschan.blogspot.com/search/label/gsoc]]   * Blog: [[http://mrkschan.blogspot.com/search/label/gsoc]]
 +  * Live at: [[https://edit.php.net]]
 ===== Abstract ===== ===== Abstract =====
 Currently, the documentation work is synchronized by cvs. But still, there are potential conflicts due to redundant work. Besides, it's not that easy to share the works or even pipelining the works in a distributed environment. Therefore, a centralized environment is introduced. Currently, the documentation work is synchronized by cvs. But still, there are potential conflicts due to redundant work. Besides, it's not that easy to share the works or even pipelining the works in a distributed environment. Therefore, a centralized environment is introduced.
Line 198: Line 199:
 This section list out ideas for future development. This section list out ideas for future development.
  
-**Further re-structuring the entire thing.** +==== Further re-structuring the entire thing ==== 
 +=== Ideas ===
   * Create a core module /core, replacing the /php and /js. The core module basically include glues.   * Create a core module /core, replacing the /php and /js. The core module basically include glues.
-  * The core will look for module from /module. /module contains the actual module like /module/patch. In each of the module folder... there will be something like /module/patch/{view.js, model.sql, controller.php}. +  * There will be a folder containing all the available modules ... /module-available. 
-  * Core will basically glue (concat) controller.php in /module/{all}/ for the doc-editor backend, and also glue view.js for the ui +  * The core will look for modules from /module-enabled. Modules inside /module-enabled are soft link (or clone) from /module-available. 
-  * Installer will become a script that glues the model.sql in /module/{all}/+  * /module-available contains the modules available to be used, like /module-available/mod_patch. In each of the module folders... there will be something like /module-available/mod_patch/{view.js, model.sql, controller.php}. 
 +  * Core will basically glue (concat) controller.php under /module-enabled/{all}/, and it also glues view.js for the ui 
 +  * Installer will become a script that glues the model.sql under /module-enabled/{all}/
 +  * ui module naming convention? mod-{module_name}-what? 
 +=== Concerns === 
 +  * How to handle inter-module interaction? Using central registry? 
 +    * For UI, may try having a central registry that register module 
 +    * any interaction will be passed through this single agent 
 +    * event listener could be used in case for interaction 
 +    * if interaction beyond this scope ... may try returning js from XHR that would invoke appropriate handler
  
 +==== WYSIWYG doc-book edit ====
 +=== Ideas ===
 +  * we may try using http://www.wymeditor.org/. In one of it's demo http://files.wymeditor.org/wymeditor/trunk/src/examples/15-rdfa-editor.html#, the wymeditor parse a RDF for display
 +  * we may supply doc-book elements and attributes, providing appropriate CSS. Plus, doc-book xml <-> html mapping
 +=== Concerns ===
 +  * Is wymeditor support doc-book xml <-> html mapping and additional element for its parser?
gsoc/2009/phdoe.1250150484.txt.gz · Last modified: 2017/09/22 13:28 (external edit)