codexa
[Strategize] Modularity
Objectives for this discussion:
- [ ] Decide upon an effective modularization strategy.
- [ ] Write a wiki page explaining that strategy.
- [ ] File bugs for the implementation of the strategy.
All comments are welcome!
I have been implementing a basic modularization strategy without defining it. This could cause problems for Firetext, so I have created an issue for us to discuss it.
Current concept
Parent
Definition: The parent is the core process and layout of the app. It serves as a hub, connecting all of the modules and components.
Components
Definition: Components are bundled sections of the app. They are inserted directly into the main layout.
Possible implementation: <component data-name="foo"></component> where foo is the component's name. This tag will be replaced with the contents of the component file.
Modules
Definition: Modules are independent and self-contained sections of the app. Modules, unlike Components, are loaded in <iframe> elements, and communicate with the parent through messages.
Please feel free to propose different ideas, or change the existing ones.
Possibly web components are applicable here. I've never used them though.
It would be great if components
- Could be used in Firetext without having to rewrite everything
- Could encapsulate the difference between desktop and mobile, as I proposed in #203
- There were already a few ready-to-use components useful to us
@twiss: web components sound great. Mozilla has a cross-browser polyfill for them here: http://www.x-tags.org/.
IMO we should still use our custom system for Modules. IIRC, <iframe>s offer performance and security benefits. In fact, I believe that Firefox OS uses frames extensively for that purpose. What are your thoughts?
Sounds good to me. Candidates for modules:
- Editor
- File system
- UI extensions, such as sharing documents or so
Note that some filesystems are capable of working in a worker thread, so that might be a possibility.
