Having worked as a front end developer, integrating the UI with backend systems, I am presenting below some of the myths and facts concerning UI (html, css, javascript, images, fonts) code integration with websphere portal and a few best practices one should follow –
Myth – Websphere portal is not compatible with latest front end frameworks like bootstrap, foundation, jQuery Mobile, etc.
Fact – Websphere portal is completely compatible with all the latest front end frameworks and there should be no reason why one should be concerned about including the front end framework in the portal. Basically, the front end frameworks include a css file, which is responsive, follows a grid system, provides styling for UI elements and takes care of accessibility and cross browser compatibility to an extent. The html in the portal will only be referencing the class names that are defined in the framework’s css file, enhancing the user experience and this css file is included in the portal theme.
Myth – Websphere portal is not compatible with jQuery and associated plugins.
Fact – Websphere portal comes with dojo javascript library as the default framework and many of the portal elements like WCM, use dojo’s javascript functionality for client side manipulation. However, on starting a new project, there are certainly workarounds available to make sure portal’s dojo does not interfere with jQuery. On a websphere portal 8 project – starting from scratch, if there is no dojo being used(by the portal theme and associated portlets) but only referenced in the portal, then jQuery should be working fine without any issues. We might see some conflicts if we try to use both dojo functions and jQuery functions, but using only one of them with the other being referenced (like portal needs dojo reference), should be just fine.
Myth – All the css, javascript, images associated with a portlet should be inside that portlet.
Fact – This is a bad practice. All of the css, behavioral javascript and images for each portlet should be in the portal theme. Because, if you have 3 portlets on a page, then the page load would take a long time, as when each of the portlet loads, its associated css, js and images will also load then. But if you are loading all of them at the bottom of the page in the theme, then the portlets would be rendered without the interference of static assets, which get loaded at the bottom. There are various compression and minifying tools available to reduce the load size and http requests of these static assets. This way, an UI developer has direct access to all of the portal’s static assets, in the theme, can make changes and deploy, while really not worrying about making changes to each individual portlets.
Myth – To make a change in the css file, this should be done in the portal theme, deployed to QA, tested and then served to production.
Fact – In today’s web development world, where the UI is constantly changing and more changes to the css is needed as expected earlier, the changes to css in the theme, deployed, tested and served to production is a tedious and long process. As an alternative, the css file for the whole portal theme can reside in a web server or IHS (IBM HTTP Server), and then referenced in the theme. Both the UI developer and the portal developer should have access to this web server, so that changes can be done directly to this css file and pushed to any environment without the need for a deployment. Same goes for library javascript files and images.
Best Practices a Front End Developer needs to follow while working with portal theme.
1. For prototyping, use a build tool and a generator such as yeoman build and grunt tasks. This would throw up production ready, testable, minified, compressed static assets – css, images and javascript.
2. Move the css to a web server or IHS and reference this css in the theme from the web server so that, any change to the css does not really require a theme deployment. All it needs is front end developer access to the web server. Same goes with library javscripts (jQuery, plugins, etc) and images. To swap a logo, it can be done in the images folder on a web server, tested in QA, pushed to staging, verified and finally served in the production.
3. Make sure there is no inline javascript inside the portlet, as this greatly affects page load performance. All the javascript should be loaded at the bottom of the page. There should be no library files in the portlet, as this would result in conflicts between different library versions among different portlets.
4. If you are parsing large json data and integrating that with the html in the jsp of the portlet, then just throw up the json on the portlet. Make use of handlebar or mustache templates to parse the json and inject that json data directly in the html. This helps in separating the html from the data and also any changes to the html can be done without altering backend logic.
I have one clarification on your 4th myth, “Myth – To make a change in the css file, this should be done in the portal theme, deployed to QA, tested and then served to production.”
There are reasons not to put the css in the theme, but it does NOT mean you get to entirely short-cut a change control process altogether. Since changes to the css will impact the assets deployed to Portal (which is the whole point), it also needs testing like anything else. I think you’re just saying you want to accelerate the process by having a different deployment mechanism than the portal theme.