Hello, JavaScript Library Partitioning!

In Almost Getting To The Point, we took a look at requirements for a solution to the JavaScript size vs # of round trips dilemma.  In this entry, we’ll see how those requirements translate into an actual solution as implemented by the ADF Faces “JavaScript library partitioning” feature.  In this solution, we have three types of JavaScript artifacts:

1. The JavaScript “class”

This is a coherent set of code contained in a single file, which typically implements the equivalent of a class.  For example, the “oracle/adf/view/js/component/rich/layout/AdfRichPanelStretchLayout.js” file contains the JavaScript code for the af:panelStretchLayout’s JavaScript component class.

In our solution the class is the smallest unit of content that can be aggregated.

2. The JavaScript “feature”

Since component authors do not want application developers to have hard dependencies on JavaScript file names or paths, we introduce the concept of the JavaScript “feature”.  The JavaScript feature is a collection of JavaScript files that are associated with a logical identifier that describes the feature.

For example, the af:panelStretchLayout component implementation is contained within two JavaScript files:

* oracle/adf/view/js/component/rich/layout/AdfRichPanelStretchLayout.js
* oracle/adfinternal/view/js/laf/dhtml/rich/AdfDhtmlPanelStretchLayoutPeer.js

These two files are grouped into the “AdfRichPanelStretchLayout” feature.  This allows application developers to refer to the af:panelStretchLayout code by the name “AdfRichPanelStretchLayout”, without having to worry about the number, name or locations of files that are used to implement this feature.

3. The JavaScript “partition”

JavaScript “features” are usually small units of JavaScript code – typically a few related files that combine to implement a single area of functionality (such as a user interface component).  JavaScript “partitions” group JavaScript features into larger collections with the goal of influencing download size/number of round trips

For example, it’s not uncommon for applications that use the af:panelStretchLayout component to also use the af:panelSplitter component.  These two components often go hand in hand.  Assuming we have both an “AdfRichPanelStretchLayout” feature and an “AdfRichPanelSplitter” feature, these two features would be a good candidate to be placed in the same JavaScript library partition.

Looking at the division of responsibilities, we have:

  • Component authors place their JavaScript code in files.
  • Component authors are responsible for grouping these files into logical “features”.
  • Application developers are responsible for further grouping these features into larger “partitions”.

In order to support these responsibilities, the ADF Faces JavaScript library partition solution introduces two new configuration files: the JavaScript feature configuration file and the JavaScript partition configuration file.  Let’s take a look at each of these.

The feature configuration file is an XML-based file that groups JavaScript files into features.  A (slightly simplified) sample feature definition for our AdfRichPanelStretchLayout feature:

<?xml version="1.0" encoding="utf-8"?>

<features xmlns="http://xmlns.oracle.com/adf/faces/feature">

  <!-- Define the contents of the AdfRichPanelStretchLayout feature -->
  <feature>
    <feature-name>AdfRichPanelStretchLayout</feature-name>
    <!-- This feature contains two classes - the component and the peer -->
    <feature-class>oracle/adf/view/js/component/rich/layout/AdfRichPanelStretchLayout.js</feature-name>
    <feature-class>oracle/adfinternal/view/js/laf/dhtml/rich/AdfDhtmlPanelStretchLayoutPeer.js</feature-name>
  </feature>

  <!-- Other feature definitions go here -->

</features>

Pretty simple really.
The partition configuration is similar, but groups features into partitions:

<?xml version="1.0" encoding="utf-8"?>
<partitions xmlns="http://xmlns.oracle.com/adf/faces/partition">

  <!-- Define the contents of the "stretch" partition -->
<partition>
<partition-name>stretch</partition-name>
    <feature>AdfRichPanelStretchLayout</feature>
    <feature>AdfRichPanelSplitter</feature>
  </partition>

  <!-- Other partition definitions go here -->
</partitions>

ADF Faces provides a feature configuration file for its own set of components/framework features and also provides a default partition configuration so that application developers are not required to define a partitioning themselves.

So, now that we’ve got all of this wonderful information about our JavaScript code base, what do we do with it?  That’s the topic of the next entry of course. :-)

About these ads

3 Responses to “Hello, JavaScript Library Partitioning!”

  1. JavaScript Library Partitioning Runtime « Andy Schwartz’s Weblog Says:

    [...] Andy Schwartz’s Weblog Just another WordPress.com weblog « Hello, JavaScript Library Partitioning! [...]

  2. Martin Kuenkele Says:

    Hello Andy,
    does a feature ‘defered loading’ make sense i.e. the features for the first page will be downloaded before the page itself but other features will be downloaded later ? I think this could also reduce waiting time for the first time because not the whole library will be necessary. During the time the user is studying the content of the first page the remainder will be downloaded and afterwards the full palette will be available.

  3. Lucas Jellema Says:

    Hi Andy,
    Very Interesting article. I would like to second Martin’s question: what is the time of loading of the resources for a specific session? Like Martin says, the first page may only have a few simple components (login page for example) and a need to be loaded very quickly. While the user is looking at this first page/entering login information etc. ideally the other resources needed for the richer pages yet to come could be loaded. Or at least they only get loaded on the second page.

    With ADF Faces in particular – what is the hook for the framework to make the JavaScript resources being requested from a page? If I were to use a JSF RI based home page or even a Trinidad JSF page – would all these resources be loaded when that first page is shown?

    Can I somehow defer loading of the full set of ADF 11g RichClient Components JS until I hit the first page that really needs it.

    thanks for any suggestions,

    Lucas

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: