Bernfried's Web Development World

With this post I’d like to start a collection of articles about an custom module I always wanted to see in Delivery Server as a standard feature. A feature which should ease the development of web applications using XML (DynaMents) and XSL(T) for the presentation layer, Java (Open API and more) as implementation language for the business layer, and the Delivery Server Content Repository as well as relational Databases as the data layer. Nearly 10 years ago a first attempt was made called the “Application Framework Module”, but it never reached a level of productivity that customers started to use it. I thought it’s time for a second try.

Motivation

Before I dive into details of the new application framework I first would like to talk about my motivation. Why do I think that Web Application Development and Delivery Server belongs together?

• I think it’s a common understanding that today’s internet websites, intranets, and extranets getting more and more interactive which requires applications and application integrations developed in Java.
• In many cases content flow is driven by results of applications e.g. based on a user input and validations an error or success page is shown.
• Validating user input can be realized using DynaMents. But the larger form requests get the more difficult and complicated it becomes with DynaMents. A Java routine does a much better and more efficient job.
• A framework can provide many standard features which will reduce redundant work e.g. validation of requests can be declarative instead of programming it again and again.
• I identified many situations where Java programming based on the Open API was much faster than using many DynaMents and I believe that one Iolet Call will be more performant than 20 Attribute-DynaMents.

I know that it was/is an advantage that Delivery Server offers a non-programming way to fulfill many requirements but that doesn’t mean that it’s the better solution from a technical perspective. So, that should be enough thoughts about my motivation and I like to start with the introduction of my WBF-Framework for Delivery Server.

Introduction of the WBF-Framework

The whole WBF-Framework is implemented based on the Open API of Delivery Server 11.0. A MVC pattern is used to ensure a clear separation of concerns.

The Controller

As entry point to the Delivery Server a Weblet called “wbf” is used. This weblet receives all requests which require an action. So it’s the controller of the framework. Following tasks are fulfilled by this weblet:

• Initially read all application settings required for the validation and execution of requests.
• Receive HTTP requests and analyze all request parameters (POST/GET) and the request URI for the project, application, and action needed.
• Call the validation of all relevant parameters of the identified action and return error codes if validation fails.
• Call the execution of the identified action if validation was successful and return all necessary  data for the presentation.
• Forward or redirect the request to the defined result page and provide all response data as XML in request or session attributes.

The Model

Within the action the required data of the model can be read from or written to data repositories. Using the Open API the User and Content objects of Delivery Server are accessible. But there is no restriction to stick to Delivery Server Repositories. The whole world of Java is available to use other data sources like RDBMS, LDAP, and more even in combination with Delivery Server objects. The Action object of the WBF Framework provides request, response and error objects to handle all typical task like validation, access to all request parameters, and writing all results to the response.

The View

The presentation layers is completely based on Delivery Server’s xml/xsl(t) features. Every action response is automatically transformed to XML and provided in the defined scope (request, session). XML contents retrieve the response xml using Attribute-DynaMents and op=”xml”. And then it’s an easy task to render html or json, or whatever text format with XSL(T) stylesheets and templates. All originally sent request parameters are automatically returned and error codes from the validation/execution of actions are also available in a standardized way.

Configuration

The whole configuration of the WBF-Framework is done within a Delivery Server content using content attributes. Following settings are maintained:

• Names of all possible url parameters like project name, application name, …
• Default values for all controller parameters
• IP Address Security Patterns
• Applications and their actions with all action forwards, validation rules, class paths, …
• Authorization information based on Delivery Server Roles and User groups

This configuration data is only read if an hot-deployment is done or the Delivery Server gets restarted and stays in memory for the rest of time.

Debug Mode

In order to reduce development time an optional debug mode comes with the WBF-Framework which allows you to access following information of the last request:

• HTTP request parameters
• HTTP header fields
• Session attributes which live the whole session (called persistent session attributes)
• Session attributes which live only till next request (called transient session attributes)
• User attributes of the session user
• Identified request controller data (web module name, application name, action name, project name, referer page)
• Action forward definition (xml/html and xsl via forward or redirect or action redirect)
• Request log (WBF-Framework specific log entries of the last request dependent on activated log categories)

This helps a lot. If you for example need to know the attribute name of a action response value, you can just find it under “Session (persistent)” and copy it to your attribute DynaMent.

That’s it for the first part. The next article will start with an concrete example and explain step by step the functionality of the WBF-Framework.