So over the last couple of months I’ve been thinking and tinkering with code, wondering, “What’s the best approach for creating WebCenter Content (WCC) components that I can consume and reuse across multiple platforms and environments?”
Is it pagelet producer or maybe an iFrame? These solutions just weren’t good enough or didn’t allow the flexibility I really wanted.
I needed a WCC Solution that could easily be consumed into mobile, either Cordova (Hybrid APP) or ADF Mobile (AMX views), and that worked on different devices/platforms as well as on any enterprise app, i.e. Sharepoint (.Net), Lifreray, WebCenter Portal (ADF) or even consumed into the new WebCenter Content ADF WebUI. It also needed to provide the added advantage that there would not need to be multiple branches of code or redevelopment of the component for each platform and environment.
And in the famous words of Victor Frankenstein.. “It’s Alive!!”
After tinkering around and trying different approaches, this is the solution I created to support the above model.
I’m not saying this is the right approach or supported by the enterprise vendors, but an approach that is reusable and can work on all enterprise apps.
[VIDEO CONVERTING]…
Here’s a quick video of a drag/drop MultiUploader component I created for WebCenter Content Classic that I can reuse on .Net and ADF WebCenter Portal/Content as well as mobile.
Read on to find out more on how this was achieved.
1) First, I’m going to dig into WebCenter Content and explain the underlying structure of the component.
To create a flexible base model, I created a light Javascript framework, very similar to AngularJS or ReactJS.
This would be the base component that would enable additional components on the page with the use of Mustache (JS templates) to drive and inject dynamic functional areas of content into a specified DOM node by ID or className.
Any changes of layout with the component are handled via an AJAX request to a cached mustache template which updates the DOM when needed (similar to ADFs PPR). Any user interaction is handled through event-driven actions from the imported templates.
RequireJS is used to supply a flexible module loading framework, where I do not need to be worried over conflicts of JS libraries and is used to load in mustache templates and additional JS functionality when needed.
You’re probably thinking that there are going to be a lot of AJAX requests going back and forth and it’s going to be slow. Just check out the video – the answer is not really. The mustache templates are going to be smaller than average images you load on a page.
So as an example for the MultiUploader, I only have 1 mustache template that is 9kb. All interaction is handled by 2 JS files that are 39kb uncompressed.
2) As mentioned, a base model WCC component, “FishbowlModuleLoader”, will load in and initiate all other components on the page and will only load and cache required templates and JS files as and when is needed. There is no point to load in all templates and JS functionality on a page if it is not needed, which improves performance and interaction of the component.
3) Following is a quick overview of how the WCC component “FishbowlMultiUploader” works.
WebCenter Content Resource Asset
This is the base structure of the Content Component configuration, “fb_multi_upload_page_body”. It is consumed into a custom template, “MULTI_UPLOAD_PAGE”, which is requested via a custom service request, “?IdcService=GET_FB_MULTI_UPLOAD_PAGE”.
<!--
Name: fb_multi_upload_page_body
Author: John Sim [18/06/2014]
Parameters:
Description: Page Body for Multi Checkin used in MULTI_UPLOAD_PAGE template
-->
<@dynamichtml fb_multi_upload_page_body@>
[[% FB fb_multi_upload_page_body Template body MULTI_UPLOAD_PAGE %]]
<div id="FB-multiCheckin" class="FB_multiCheckin"></div>
<script>
/**
* CREATE CHAIN WRAPPER
* Chain method will load from Base ModuleLoader requirejs core script
*/
FB.Base.chainPSA = FB.Base.onPortalInit(FB.Base.chainPSA, function() {
//set base mustache template name to load and inject
var vUID = 'FB_multiCheckin', //(UID) Unique Classname to inject template into - can't use IDs in portal
oConstructor = {
vTemplate: 'import/tpl/multiUploadTpl', //location of template.mustache to load
oParams: { //Obj list of default params pulled from multiUploader.xml Input definition
maxUploadSize: '10mb',
defaultDocType: ('<$multiUploadDefaultType$>' !== '')? '<$multiUploadDefaultType$>': 'Document',
defaultSecurityGroup: ('<$multiUploadDefaultSecurityGroup$>' !== '')? '<$multiUploadDefaultSecurityGroup$>': 'Public',
defaultAccount: 'Workspace/'+userName,
author: (typeof(userName) !== 'undefined')? userName: '',
httpEnterpriseCgiPath: (typeof(httpEnterpriseCgiPath) !== 'undefined')? httpEnterpriseCgiPath: '',
idcToken: (typeof(idcToken) !== 'undefined')? idcToken: '',
httpWebRoot: (typeof(httpWebRoot) !== 'undefined')? httpWebRoot: '',
enableTagging: true,
enableEmails: true,
enableBarcode: true,
enableCheckinProfiles: true,
showHelpOption: true
},
containerID: vUID
};
//check if array exists from other custom JS Portlets
if (typeof(FB.loadTemplate) === 'object') {
FB.loadTemplate.portletUID.push('FB_multiUploadContainer_' + vUID);
//create empty object
} else {
FB.loadTemplate = {
portletUIDList:['FB_multiUploadContainer_' + vUID],
portlets: {}
};
}
//inject params
FB.loadTemplate.portlets['FB_multiUploadContainer_' + vUID] = oConstructor;
});
/************************/
</script>
<@end@>
This is where the mustache template will be injected into to provide the multiUpload component functionality.
<div id="FB-multiCheckin" class="FB_multiCheckin"></div>
The oConstructor specifies the configuration of the the component to inject.
vTemplate points to a JS file that requireJS imports and configures the base multiUploader components from the params defined.
oParams contains all configuration for the app; at the moment, these are mostly hard coded, but could be defined as iDoc Variables when you install and enable the component within WCC.
var vUID = 'FB_multiCheckin', //(UID) Unique Classname to inject template into - can't use IDs in portal
oConstructor = {
vTemplate: 'import/tpl/multiUploadTpl', //location of template.mustache to load
oParams: { //Obj list of default params pulled from multiUploader.xml Input definition
maxUploadSize: '10mb',
defaultDocType: ('<$multiUploadDefaultType$>' !== '')? '<$multiUploadDefaultType$>': 'Document',
defaultSecurityGroup: ('<$multiUploadDefaultSecurityGroup$>' !== '')? '<$multiUploadDefaultSecurityGroup$>': 'Public',
defaultAccount: 'Workspace/'+userName,
author: (typeof(userName) !== 'undefined')? userName: '',
httpEnterpriseCgiPath: (typeof(httpEnterpriseCgiPath) !== 'undefined')? httpEnterpriseCgiPath: '',
idcToken: (typeof(idcToken) !== 'undefined')? idcToken: '',
httpWebRoot: (typeof(httpWebRoot) !== 'undefined')? httpWebRoot: '',
enableTagging: true,
enableEmails: true,
enableBarcode: true,
enableCheckinProfiles: true,
showHelpOption: true
},
containerID: vUID
};
This is a simple check to see if other components exist on the page and append the new component within the JS Array “PortletUIDList” associated with a JS Object holding the component params in “portlets”.
//check if array exists from other custom JS Portlets
if (typeof(FB.loadTemplate) === 'object') {
FB.loadTemplate.portletUID.push('FB_multiUploadContainer_' + vUID);
//create empty object
} else {
FB.loadTemplate = {
portletUIDList:['FB_multiUploadContainer_' + vUID],
portlets: {}
};
}
//inject params
FB.loadTemplate.portlets['FB_multiUploadContainer_' + vUID] = oConstructor;
Finally, the JS configuration is wrapped in JS chain wrapper that will only initialize when required. JS has loaded in all its core base libraries like Jquery, etc.
FB.Base.chainPSA = FB.Base.onPortalInit(FB.Base.chainPSA, function() {
//code
});
4) So lets take a look at how the base component “FishbowlModuleLoader” works.
Essentially, this defines the FB.Base.chainPSA chain wrapper method in the header – does not need jquery or any other library.
<!--
Name: std_html_head_declarations
Author: John Sim [18/06/2014]
Parameters:
Description: Add required header resources
-->
<@dynamichtml std_html_head_declarations@>
[[% FB std_html_head_declaration Update head add JS libs for module loader %]]
<$include super.std_html_head_declarations$>
<script>
/**
* CREATE BASE JS CONTAINER OBJ
* DONOT ADD JQUERY this is base class to assist PSA javascript methods to init after page loaded.
*/
var FB = window.FB || {},
Base = Base || (function() {
return {
//create multi-cast delegate.
onPortalInit: function(function1, function2) {
return function() {
if (function1) {
function1();
}
if (function2) {
function2();
}
}
},
//used for chaining methods
chainPSA: function() {}
}
})();
//Use Base method if FB.Base hasn't been created
FB.Base = FB.Base || Base;
/************************/
</script>
<@end@>
You could cache this and put it in a script file, I’ve just put it inline easier for you to read.
In the footer, we define requireJS and the configuration that loads in base libraries that we need for all components ie Jquery and maybe a few others.
Also we setup fb.core.js as our base script to import and load in the core framework I built to handle routing and DOM event interaction as well as global vars.
<!-- Name: std_page_end Author: John Sim [18/06/2014] Parameters: Description: Component Module Loader RequireJS setup --> <@dynamichtml std_page_end@> [[% FB std_page_end Add Module Loader RequireJS lib %]] <$include super.std_page_end$> <!-- Init FB Component Module Loader --> <script src="<$HttpWebRoot$>resources/FishbowlModuleLoader/js/core/config.js"></script> <script src="<$HttpWebRoot$>resources/FishbowlModuleLoader/js/libs/requirejs/require.min.js" data-main="fb.core"></script> <!-- Init FB Component Module Loader --> <@end@>
fb.core.js so here is where the magic begins:
// REQUIREJS Base configuration
require([
//Dom ready req plugin
'domReady',
//core
'import/Layout',
'import/Action',
'import/Navigation',
'import/Global',
//Plugins
'Moment', //date plugin momentjs
'ftlabsFastClick', //fix touch 300ms delay
'fb' //fb global methods
], function(domReady, Layout){
console.info('[ALL MODULES LOADED]');
domReady(function() {
console.info('[DOM READY]');
//initialise layout DOM events ie click, touch etc.
Layout.init();
//load JS Components
if (FB.Base.chainPSA) {
FB.Base.chainPSA();
}
//check if any JS driven template containers exist
if (typeof(FB.loadTemplate) !== 'undefined') {
var aPortletList = FB.loadTemplate.portletUIDList,
lPortletList = aPortletList.length,
x = 0;
//loop and request all templates required
for (x;x<lPortletList;x++) {
var vPortletUID = aPortletList[x],
oPortlet = FB.loadTemplate.portlets[vPortletUID];
//define temp object info to pass into script when init
define('temp'+x, oPortlet);
//request and initialise portlet template & pass params
require([oPortlet.vTemplate,'temp'+x], function(tpl,oPortlet) {
console.log('[IMPORTED TEMPLATE]',tpl.component,oPortlet);
tpl.init(oPortlet);
});
}
}
});
});
Once the Dom has fully loaded, FB.Base.chainPSA(); is initiated. This sets up and configures the FB.loadTemplate object that contains all information associated to required components that will need to be loaded into the page.
Here we loop through and load in all templates, and pass across the component configuration to the templates to be initialized:
//loop and request all templates required
for (x;x<lPortletList;x++) {
var vPortletUID = aPortletList[x],
oPortlet = FB.loadTemplate.portlets[vPortletUID];
//define temp object info to pass into script when init
define('temp'+x, oPortlet);
//request and initialise portlet template & pass params
require([oPortlet.vTemplate,'temp'+x], function(tpl,oPortlet) {
console.log('[IMPORTED TEMPLATE]',tpl.component,oPortlet);
tpl.init(oPortlet);
});
}
And thats all there is to it.
5) Lets dig into WebCenter Portal now. How can you reuse all that code you’ve written for WebCenter Content Classic within ADF?
Easy: let’s create a JS driven taskflow template that we can dump into the resource catalogue and drag, drop, and reuse it throughout any page where ever it is needed.
I’ve created a new post for this part:
Read on here to find out how to create JS Driven Taskflow templates.
Some gotcha’s –
Some things to think about if you do decide to use this approach.
- You will need to make sure that all AJAX requests are made on the same domain.
- or enable CORs from UCM to accepts requests cross domain. (Mobile works crossdomain)
- WCC needs to be accessible by the users browser
- You can setup a proxy service and only allow access to the custom services you require to lock down other UCM environment access if needed.
And finally – one thing that comes to mind here: I am using static mustache templates but there is nothing stopping you from creating a custom WCC service to generate mustache templates with embedded idoc if you want..
