Ayms
Introduction
Continutation of: "Extract Widget" Patent FR2962237B1 - Process to create an application of gadget type incorporated into a container of widget type and Patent FR2962237B1 - Main claim, scope and applications and Polymer vs Extract Widget patent - Code comparison
Almost everything can be summarized by Google's Eric Bidelman citation: See the irony? The web's most basic content, HTML, requires the greatest amount of effort to work with. Fortunately, Web Components are here to get us back on track, problematic that the gist about the code perfectly reflects.
Which applies to the whole Web Components in fact, not only "imports" where the citation comes from, as strange as it may seem, nothing appropriate existed and was foreseen at that time to extract, import, inject and manipulate/protect HTML code (and related objects) inside a page, that's very exactly the scope of the patent.
The component model discussion provides all links to the state of the art in 2011, some extracts: All it says (note: like the patent) is that your components are DOM objects and inherit the DOM Core APIs. You can add your own properties and extend the API surface and why some other solutions are not proposing the same thing But the bizarre combo of xml, .css, and .js in XBL one is poorly supported by tooling and thus is just a mess. Create a great JS solution then let tools build on that to finally perform a component model comparison with existing specs and implementation
Component model comparison with the patent:
The Component Model is not necessarily the ultimate model for now, as we can see below it does not cover all the cases and does not foresee the extraction mechanisms that inherently go together, if we consider the principles of the design Reuse existing mechanisms as much as possible, gently extending them if necessary (like the patent describes) and try to compare the outcome (the Component Model) with the patent:
- Extensibility (create or extend DOM objects based on other DOM objects and/or their prototype) : Yes, the gadget is composed of DOM elements and support the extensions methods provided by the DOM and javascript
- Consistency (all the gadgets in the page should be composed of the same "thing" and follow the same rules for creation, manipulation and interactions): Yes, the gadget is composed of DOM elements, "Because components are just DOM objects, they inherently share the same traversal and manipulation APIs"
- Encapsulation (gadgets should be able to hide and/or forbid access to their implementation like their DOM elements and styles): Yes, the gadget is injected/rendered with its own "descriptive parameters and content", which implies necessarily that the gadget has the ability to encapsulate its content and properties, for example the styles: "Ainsi la page aura pour elle-même toujours ses propres styles....tandis que les styles du gadget...permettant ainsi sa reconstitution parfaite"
- Composability (methods between gadgets to compose elements from the gadgets or part of them): Yes, the gadget is composed of DOM elements ("Being DOM objects, components fit naturally into the document DOM tree and support all of its composition properties")
- Desugaring: Yes, among others the patent describes a process to create gadgets using only their descriptive parameters or a javascript server side method that will reconstruct its content associated with their descriptive parameters by processing the input (scripts, styles, html) to produce a simple DOM gadget, more generally it describes gadgets as DOM objects not requiring complex processes to build and use them.
- Performance: Yes, the patent describes standard DOM-based element so handled by the DOM, which is supposed to be optimized, of course the implementation of the patent should insure efficient mechanisms to render/manipulate the gadgets like DOM parsing (as opposed for example to innerHTML/outerHTML methods)
- Confinement (scripts attached to a gadget should be able to execute in a confined place or not, in the gadget's context or not): Yes, like for encapsulation the gadgets can interact with the rest of the page, and vice versa but it is obvious that for some gadgets the "descriptive parameters and content" can generate methods like confined scripts that cannot interfer with the rest of the page (and vice versa). An example covering all the possibilities of confinement (or deconfinement) can be found here: |wrap| suggestion in strict mode, this is a proposal of us coming from our different implementations of the patent where each gadget has its own "window" (like) object where the scripts get loaded and executed, the gadget can decide to confine them or not, each gadget's "window" is not a new global in the page but acts as such locally for the gadget.
We can add other properties to the initial model, this is covered by the patent and our implementations of it and does not really exist anywhere as universal methods, including in the Web Components for now (or is still unclear and under discussion):
- Interoperability: some gadgets can have been developped to work in different environments, they might do things such as window.a='a' instead of var a='a' (or the deprecated a='a') or they might have decided to customize some functions like xhr=my_xhr, for example the concepts of the above method would allow this, executing scripts for gadgets that manipulate the window global object but locally inside the gadget, where the window object of the scripts gets bound to the window (like) object of the gadget.
- Accesibility and security: the gadget can decide to confine or not, encapsulate or not, so for example its DOM tree and properties are accessible to others, however it should not be able to hack the DOM and alter the behavior of others (like for example doing xhr=send_everything_to_myself), at least for gadgets from different origins, which the above proposal foresees too.
Note: Encapsulation, Confinement, Interoperability, Accessibility and security seem to be discussed around this proposal by the Web Components.
- Dynamic ability: the gadget renders dynamically according to the modifications of its source (stock price for example) or user's interaction to modify/update it.
- Selectivity: we don't need the whole gadget but just part of it based on selective criteria, the selected part can be just an information (price for example) or a part of the gadget (price+image+product title without the product description) that would render with the properties of the gadget as it renders in the full gadget.
- Adaptability: the gadgets adapts according to the device where it is rendered.
- Virtualization: the patent describes a server side processing for the gadgets, the server side processing performs a virtual rendering of the gadget, and returns the gadget with the virtual rendering information attached to it and its properties, including information/methods to follow it during its lifetime if necessary, this can be used to offload the gadget processing to a server which returns the gadget rendered and able to interact with it (for example on mobile devices, but the patent explains the more global rationale for all devices, ie why to load and process tons of things from which the client will use a very small part when you can just retrieve the desugared result easy to understand and manipulate), or to adapt to a specific device format, or to attach some properties to a gadget to allow to "gadgetize" an element that was not initially a gadget (for example a part of a site, you render it on server side and set the required properties like width/height to render in the target site, and/or add custom properties to turn it into a gadget), or to select/define/modify specific parts of a gadget and/or specific properties and behavior, or to extract a gadget (on the server or on the web) or part of it based on some criteria, or more generally to simply produce gadgets that are compatible with any browser and incidently can be crawled and indexed.
Apparently this is what the Web Components are trying to specify too as well as other component projects, see the links in the previous gist, for example AngularJS2 which describes the state of the art showing that similar concepts never showed up before mid-2011 at the earliest (so after the patent), Virtualization with server side rendering is why we made node-dom
- Extractability: ability to extract gadgets from any site and not only from the constructor sites with their own descriptive properties and content like styles and scripts.
Conclusion
The Web Components and other components projects are a partial implementation of the patent.
All the discussions that we see in the WebApps archives in 2011 that leaded to the Web Components model, until today's discussions, are very similar to some of the problematic we had with our projects implementing the concepts of the patent, too bad that we could not participate, probably we could have helped to spare some time for the Web components to show up (and saved our projects).