JavaScript Library Partitioning Runtime

In Hello, Library Partitioning! we took our first peek at the new ADF Faces JavaScript Library Partitioning feature.  In order to support this functionality, ADF Faces introduces two new configuration files.  In this entry, we’ll see how the metadata defined by these configuration files is used to optimize the JavaScript footprint of ADF Faces.

ADF Faces loads the library partitioning configuration files at application initialization time, starting with the “feature” configuration file.  Since the goal is to allow custom component authors to leverage the library partitioning system for their own JavaScript code, we use a tried and true technique for locating all available feature configuration files: ClassLoader.getResources().  Given a path to a resource file, ClassLoader.getResources() scans all jars on the class path and returns references to any matching files that are found.  This mechanism should be familiar to JSF users: it is the same approach used to locate faces-config.xml files.

In order to locate feature configuration files, ADF Faces searches for all “adf-js-features.xml” files in the “META-INF” directory.  This allows custom component authors that want to participate in JavaScript library partitioning to simply drop a “META-INF/adf-js-features.xml” file into their jar.  No explicit registration is necessary.  Any feature configuration files found are loaded into memory and merged into a common data structure.  Of course, ADF Faces provides its own feature configuration file so that its own features are always available.

In the case of the “partition” configuration, we only have one configuration file per application.  ADF Faces looks for this file, named “adf-js-partitions.xml”, in the “WEB-INF” directory of the web application.  If no such file is found, ADF Faces falls back to a default partition configuration that it provides.  The default partitioning is meant to provide reasonable behavior for most applications, though application developers are welcome to optimize as needed for their application.

Now that we’ve got all of this information available, how is it actually put to use?

During the render traversal, ADF Faces collects information about which JavaScript features are required by the page.  At the end of the traversal, the complete set of JavaScript features required by the (rendered) page contents is known.  Once we know the set of required JavaScript features, we use our partition configuration to map this to the set of required partitions.  And given the set of required partitions, we simply render HTML <script> references to these partitions, just before the end of the HTML document.

That’s it!  By using this technique, we end up pulling in just those “chunks” of JavaScript code that are needed by the page, thus reducing the total amount of code that needs to be downloaded/loaded.

About these ads

One Response to “JavaScript Library Partitioning Runtime”

  1. AMIS Technology blog » Blog Archive » ADF 11g - reducing the price of richness or how to streamline downloading Javascript Resources for ADF 11g Rich Client components Says:

    [...] Schwartz on JavaScript Library Partitioning and Compression & [...]

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.

Join 25 other followers

%d bloggers like this: