The module framework allows extensions to contribute to different areas of a page to provide flexibility, enhance the user experience, and maximize performance.
The framework
provides logical points where modules can contribute data into a theme at run
time and to optimize those contributions by combining them where possible. This
framework allows multiple disparate remote sources to be combined into one
request for greater performance.
It also provides
a way to enable and disable features of a theme by means of configuration,
through a profile. You can spend your time focusing on the interface design of
the theme without being concerned about the details of how to get features to
work correctly within their theme. It also provides them an easy way of turning
off features that they do not need in one environment that they might use in
another environment.
For example, you
can disable editing capabilities in a production portal environment while
enabling them in a development environment. The same theme code can be used
across such environments where the only variable is the module inclusion
profile.
Modules are registered extensions and then consumed by a
module profile. Each module is enumerated by the modules unique identifiers.
Modules might require other modules to allow the automatic inclusion of
necessary code required to make a particular feature work.
Deferred and
nondeferred modules:
The module
framework allows a profile to specify whether to defer a particular module. By
default, a module is loaded when the initial page loads, but modules that are
specified as deferred modules are loaded after the page loads.
Nondeferred
modules are enabled whenever a request for a page is made to the portal servlet
resulting in a full page refresh. Use a client-side JavaScript module to load
resources associated with deferred modules on demand. For example, load
deferred modules when entering edit mode for a page. Resources that are not
required in view mode can be lazy loaded when the page mode is changed to edit.
Note: If you enter edit mode while using the deferred profile
available out of box, the following error displays when using a JavaScript
console: dojo.back.init() must be called before the DOM has
loaded. If using xdomain loading or djConfig.debugAtAllCosts, include dojo.back
in a build layer. This error is thrown by dojo because the dojo.back
package is loaded in a deferred way. This code path is used only by older
browsers which are no longer supported. This JavaScript error has no affect on
functionality.
If a nondeferred
module requires a deferred module, the server-side combiner framework promotes
the deferred module to be nondeferred. The promoted module is then loaded
during the initial page rendering process. The module is not deferred, and all
of its contributions to each extension point are displayed in view mode. Also,
the contributions are not included when any remaining deferred modules are
loaded later.
Because
deferred modules are loaded distinctly after a page loads, the types of resources
that can be deferred are necessarily a subset of what can be loaded. CSS,
JavaScript code, and markup can be deferred. Therefore, the following rules
define when contributions to various places are loaded for deferred modules.
- CSS contributions to the head are deferred and then inserted into the <head> element on demand by using the <link> element.
- JavaScript configuration, both static and dynamic for both head and config spots, is deferred and loaded as JavaScript.
- Static JavaScript code contributions to the head and config spots are deferred and loaded as JavaScript.
- Markup contributions are lazy loaded by requesting the markup data for all deferred modules that contribute to the config or head markup section. This data is inserted into the page at the appropriate location based on where the spot is defined by the theme template.
Note: Because markup contributions can be lazy loaded when a module is
deferred, certain limitations apply to the markup inserted dynamically using
JavaScript. Script elements, for example, do not run when inserted into the
markup as an HTML string. Modules that can be deferred must not generate script
elements in their markup contribution to the config spot, unless they are used
for another semantic purpose, for example, setting the type attribute to some
value unknown to the client browser. The framework does not check for or handle
any markup that results in side effects or unintended behavior. It is up to the
module developer to handle any unintended behavior.
Do not use portal render request-dependent attributes,
because there is no guarantee that those attributes are available in all cases.
For example, when used in deferred mode, the render context is not available.
No comments:
Post a Comment