Month: May 2014

Removing the unnecessary cocoon views

Triple’A Plus® Web contains more than needed in a production environment. One way of knowing it is for example to look at the front end code for example like the main client side script xgui2html.js. The debug instructions are coupled with the logic or the debug toolbar that is inserted in the layout via the green dot appearing on the top right of the screen.

Another example is the delivery of several cocoon views for debugging purpose. Appending to the http query string the parameter cocoon-view with a certain value activates a view of the page. For example: with the value pdf the page (activity) is rendered as a PDF document, with the xls value as an Excel spreadsheet, i18n-content as an XML document containing the translations but before HTML generation.

The list of cocoon views supported by the WUI is not defined completely in the sitemap of the application… In the table below the views and their purpose.

  • content: the raw XMLview
  • popup: view that is exclusively used for popup windows / not suitable for mobile applications
  • layer: this view opens the target as a layer in the main window
  • pdf: renders the current page as a PDF document
  • xls: renders the current page as an Excel spreadsheet
  • frame: view that is used when the page is to be included as an html frame document
  • embed: view that embeds the activity/modules in a page. This view is mainly used in portals
  • analyze: this compares the page against the scheme and will reveal the violations of the scheme rules on the screen as HTML.
  • xsource: aka XGUI Source Code Analyzer, is very similar
  • i18n-keys: The WUI is rendered as an HTML document without the i18n translations replacement
  • i18n-content: returns the result as XML document after i18n keys replacement and before HTML serialization.

If they are very useful for development purpose, they constitute a security risk as they can provide information before the HTML transformation. Inside a secured and controlled network, the threat is purely internal but when the application allows clients to connect externally, they shall be removed from the sitemap.

This post is about how to do it and deliver it in a customization package

Create a project based on the custo-manual template with as custo value: wui-sitemap. The project name in the DS navigator will appear as: wui-sitemap-custo-manual.

wui-sitemap-custo-manual

After the regular clean-up of the project artifacts like the helloworld.cmd script, the correct setup of the block.xml file (id & weight), create a block.xmap file in the src/main/resources/Block-inf folder.

The views that can be removed are

<!--
===============================================================================
 SITEMAP PATCH
===============================================================================
Block Name: WUI-SITEMAP-CUSTO-MANUAL
===============================================================================
 -->
<patches>
 <patch xpath="/sitemap/views" remove="/sitemap/views/view[@name='analyze']"></patch>
 <patch xpath="/sitemap/views" remove="/sitemap/views/view[@name='xsource']"></patch>
 <patch xpath="/sitemap/views" remove="/sitemap/views/view[@name='i18n-keys']"></patch>
 <patch xpath="/sitemap/views" remove="/sitemap/views/view[@name='i18n-content']"></patch>
</patches>

Adapt the file content to your needs: add or remove patch tag node as you wish  or change the value in the @name attribute. After that, add the project to the embedded server, start it and after the login, append “cocoon-view=i18n-content”. If you see something else than an HTML page, it means the patch isn’t properly applied.

In conclusion, this project can be packaged separately, to install it only in a production environment or wherever needed.

 

A warm up

Triple’A Plus customization projects bring the best of the business and the technical world to meet in an environment very quality and reliability are key.

The Triple’A Plus solution consist in mainly two parts called by convention CORE and WEB. The CORE part consist of the metadictonnary & format model, the language scripting, the financial servers, the database and the GUI client. The WEB is a J2EE suite of web applications including the WUI a web client for portfolio managers. The solution is also a reporting solution and since the R13 is also availabe as a mobile app for iOS and Android.

Although Triple’A is a mature product with a stable GUI client, the web version is still evolving and will be unstable for a while. When I joined Odyssey Financial Technologies, the company had just released the 1.20.4 version of the Odyssey Component Suite (OCS). Clients were still in OCS 1.10.X or 1.00 and will be migrated in future version. In 3 versions (1.10,1.20,1.30), the product has introduced important functionality to support the business and has tried to ease how they can be customized. On one side product evolves and on the other side the web techniques change permanently. Today’s best practice will be replaced by a new technique or a different mechanism to implement it.

One challenge of the product for the community of users is its learning curve and the lack of a developer community like in other products offering the same type of tools. I refer to a company called Sitecore which focuses exclusively on the product development and leaves the implementation to trained & certified developers the company trains. The CMS company has an important community of developers which also provide feedback on the product or develop their own components.

How many times, have you ask yourself how do I do it in this version?

Example: The OCS 1.30.5 version introduced the DPI installer, a tool to deploy and package OCS. The component relied on a file all-in-one.dpi.properties containing all the configuration properties to install the solution. To separate the bank user defined keys from the ones of the product, the best practice was (yes was) to specify the path of another properties files in the all-in-one.dpi.properties, a kind of extension. In R11, the extension mechanism has disappeared, and in R12, the best practice is to use a otf-registry-extension.xml file. This file extends the otf-registry.xml which can complete the  all-in-one.dpi.properties. If you are not lost after all these name, the relevant information to keep in mind is that the customers are often redoing/reviewing their customization from one version to the other as the introduction of new features in every version is disruptive.  The installer wizard has changed in every version that I had in hand too, funny 🙂

As a frequent user of the Design Studio IDE, I see the possibilities of the product as well as the challenges it still has to face. The IDE does tremendous code generation over thousands of artifacts and can be used to develop any kind of application! Yes, Design Studio is able to create an application that can be included in the WUI and has nothing to do with Portfolio Management and Financial purposes. The tool after all helps to design pages like a CMS since R12 and the User Defined table.

Understanding how the WUI works is key to save a lot of time during the customization phase. Design Studio is a writer of screens and does what web consultants used to do in a normalized way. Though the IDE comes like a toolkit, it is up to each customer to find the best way to implement it.  In depth knowledge of the documentation, the APIs, the taglibs can help extracting more from the IDE.

Take the XGUI tag lib that generates all the HTML code. DS generates for the Pages and Modules as XSPs with XGUI content for the layout. Other tab librairies are used too like UDP (Uniform Data Presentation) which relies also on XGUI in the end. DS editor contains two tabs, one showing he generated code. Therefore, if you start from a blank page and add a widget you can see the code that it will generate as XGUI but also as HTML.

Sometimes a layout requirement can be more easily solved by CSS (Cascading Stylesheet) by adding a class attribute to the widget in the page  than adding other widgets like the glue or the spacer.

Web Customization of TAP is a vast topic. It can be about project governance like how to implement customization with a durable vision, the best practices to maintain the solution, or it can be of how to create a new component, or extend a library or redesign the front-end, or evaluating the impact of a hot fix against the customization, or developing tools / techniques that help diagnostics and facilitate migrations.

The next posts will be all about the knowledge I accumulated over the years on the solution worth sharing, the best practices or techniques discovered, what to consider in an implementation.