Creating a Magnolia page for rendering from Scipio ERP is a two-step process: you first write the page itself, or more specifically the template for it, using Scipio ERP-specific API facilities; then you map an Scipio ERP controller request or view to the page so it is invoked for rendering through an Scipio ERP webapp or store. Any Scipio ERP Request that falls into the Scipio ERP request flow will output the page that is specified. This gives a lot of freedom when reusing or implementing new processes in the system.
Page Development
Page authors edit templates and pages in Magnolia instances using the Magnolia author webapp (http://localhost:[port]/magnoliaAuthor) and regular Magnolia means, but supplemented with a Scipio ERP-specific API for code and some Scipio ERP helper applications. It is here that the authors are able to add and modify content to the created pages.
Understanding the Request Flow
To give a general idea, the progress of a typical Scipio ERP request is summarily:
SCIPIO ERP-side:
A request is made directly or indirectly to an Scipio ERP webapp.
If the request matched a Scipio ERP Process Mapping source path, it is process and forwarded. Afterward or otherwise, the request continues on as normal, and for it to be relevant to Scipio ERP, toward the webapp’s controller.
Eventually the webapp/store’s controller receives the request and the request’s events are run.
If the request response is a view, Scipio ERP intercepts the view rendering for it.
If the view matched a Scipio ERP Process View Mapping or View Mapping, Scipio ERP sets up a new CMS rendering request to the CMS page defined by URI in the mapping. The rendering request is a separate request.
The CMS rendering request is invoked by Scipio ERP, and Scipio ERP serializes and passes with it a number of predefined request/session/application/context attributes, as well as other attributes of simple types. In addition, it attempts to serialize and pass attributes specified by name by the developer, which are (for one) specified in View Parameters.
CMS-side
Scipio ERP intercepts the CMS request received by Magnolia. Scipio ERP checks the request and at this point may reject invalid or suspicious requests.
Otherwise, if the page to be rendered has a Scipio ERP-initialized page template and the request was valid, Scipio ERP prepares a rendering context (the main Scipio ERP context, SCIPIORenderContext/catoCtx; an Scipio ERP/OFBiz screen context emulation, catoCtx.ofbizCtx; and mock servlet objects representing the original request, catoCtx.ofbizRequest, catoCtx.ofbizSession, etc.) and stores it in the Magnolia context.
Scipio ERP wraps the page template section rendering in an Scipio ERP transaction (currently always enabled unless globally disabled via properties).
Scipio ERP invokes any Groovy/Minilang script includes associated with the template (via Scipio ERP Template Helper app), before the template model is executed, using the emulated OFBiz screen context (catoCtx.ofbizCtx).
Magnolia invokes the template model and finally the template itself, with the Scipio ERP context and templating functions made available to them. The client’s code may use the Scipio ERP context and facilities (Scipio ERP Render & Platform Communication API) to read Scipio ERP data from the request/session/application/context attributes passed across the invocation or – more importantly – from the OFBiz database or API (using delegator, dispatcher, etc.).
The CMS produces a final output.
Scipio ERP-side:
If the CMS rendering request did not succeed, an internal server error is produced and logged.
Otherwise, its output is transferred to the original Scipio ERP webapp request’s output, finalizing the view rendering.