Confirmed users
230
edits
Gaia/Architecture Proposal: Difference between revisions
→Front-End
(→Bridge) |
|||
| Line 220: | Line 220: | ||
''Note:'' There seems to be a common negative feeling about <iframe>s. Please note that <iframe>s are just a tool to achieve this compartmentalization, enabling us to expose the app structure (which ''View'' is displayed? which ''View'' is under active use, which ''View'' will be displayed next...) to the engine. So are <iframe>s the future of the Web? Probably not, but a high level encapsulation is definitively needed, and the only thing that provides this level of encapsulation today is an <iframe>. ''And they're cheap!'' | ''Note:'' There seems to be a common negative feeling about <iframe>s. Please note that <iframe>s are just a tool to achieve this compartmentalization, enabling us to expose the app structure (which ''View'' is displayed? which ''View'' is under active use, which ''View'' will be displayed next...) to the engine. So are <iframe>s the future of the Web? Probably not, but a high level encapsulation is definitively needed, and the only thing that provides this level of encapsulation today is an <iframe>. ''And they're cheap!'' | ||
=== Content Wrapper === | |||
The Content Wrapper is a container that hold all views. It is responsible for basic tasks such as transitioning between views. | |||
Its existence is tied to the lack of APIs to achieve the mentioned encapsulation without a container. If the platform offers enough APIs, the Content Wrapper will go away. | |||
It offers a simulated browser in order to support the ability to prototype: | |||
* Page Transition API shim | |||
* Behavior of Views | |||
** View is unloaded and forgotten when it is leaved | |||
** View is unloaded and put in the [https://developer.mozilla.org/en-US/docs/Using_Firefox_1.5_caching Back-Forward Cache] when it is leaved | |||
** View is running in the background competing on the event loop | |||
** View is running in the background deprioritized on the event loop | |||
* Single point of coordination for the the bridge | |||
** Error reporting for Servers | |||
* Unbreakable navigation on capsule errors | |||
* Custom pre-rendering support | |||
* Multiple layouts with one entry point | |||
* Unified navigation between user visible capsules of multiple apps | |||
* ... | |||
Once those are figured, it would be a good time to get rid of the Content Wrapper. | |||
As a result, it should not be used to store shared logic, nor shared code. | |||
It should not be used to communicate between views, or to hold views state. | |||
To summary, you must ignore it as much as you can while working on a particular view and focus on the view itself. | |||
In order to protect developers from mistakes, views will run into a sandbox that won't let them access this wrapper directly. | |||
=== Features === | === Features === | ||