This sixth version is built upon the same principles as all previous versions: XML as a data transfer format across layers, XSLT for the presentation layer, SQL as primary data manipulation language.
Applications built with Activsoft's engine, either web applications or mobile applications, work as classical client / server applications: the client sends a request with certain parameters to the server, the server authenticates the user (if needed), authorizes the request (if needed), records data (if requested) then creates a new document that the client is supposed to display.
That doesn't mean you can't create full AJAX applications with the engine; JSON or XML is just another type of document to be interpreted by the client.
Starting with version 6, the request handling flow follows the ASP.NET flow (ASP.NET application lifecycle); this flow is simulated for other platforms (PHP, Java, mobile). The engine intervenes in the following phases:
BeginRequest: determines if the engine intercepts the request, and if so, determines the handler, creates the Config object and loads the request data into it
AuthenticateRequest: calls the handler's AuthenticationManager, if any
AuthorizeRequest: calls the handler's AuthorizationManager, if any
ProcessRequest: runs the handler; it runs all actions, loads the XSLT file, runs all extractors, determines the IRenderer, persists the session and runs the IRenderer.
Data modification is done through actions, which are classes implementing the IAction interface. Each action is independent from the others; in particular, more than one action can act for one client request.
We advise to use a single parameter determining the action to be executed, each action testing the value of this parameter to decide whether to act or not and what to do, but the action model does not enforce this choice.
We also advise to use the "redirect after post" pattern to avoid replaying actions in case of client requested refresh - to do this, you just have to add the RedirectAfterPostAction at the end of the action list - but the action model does not force you to use it.
XSLT file loading is done via classes implementing the IXslTransformGenerator class. Out of the box, we provide a simple XSLT loader reading the XSLT file directly, the filtered XSLT loader which applies a list of filters to the XSLT file to translate custom tags into standard XSLT tags, and a mobile loader built to alleviate the specifics of mobile file loading.
The dynamic document generation flow - either HTML, XHTML, various text formats, PDF, etc. - is the following:
a list of data extractors populate an XML stream with data depending on an application-wide template number and a parameter map
an XSLT stylesheet is loaded according to the template number; this file may be filtered to translate domain specific tag libraries to plain XSLT tags
the XML stream is transformed into another text format by the XSLT stylesheet
the resulting document is either directly sent to the client, or transformed by another tool to a binary format (FOP for PDF, a custom XML writer for Excel binary files, etc.)
After actions have been run, the XSLT file loaded, and the data extracted in memory in XML format, the IRenderer creates the output to return to the client.
The reason to have a custom IRenderer instead of a simple XSLT transformation is that, in many cases, you need to filter the output of the transformation:
to output PDF, we use FOP to transform XSL-FO content getting out of the XSLT transformation
to create Excel files, we use custom XmlWriters to output either binary or OpenXML by interpreting the XHTML table tags created by our table control
The request handling flow is completely configured using .NET's app.config, which provides a complete inversion of control implementation.
All services (actions, extractors, renderers, etc.) are created using the factory pattern, each factory overriding ConfigurationSection to be fully customizable in the application configuration file.