Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 86 rates

Implemented in 4.4

 

Official Documentation Available

This topic is now covered in Early execution of components.

Introduction

This page describes the mechanism of preexecution of paragraph models and design decisions taken.

Requirements

  • The RenderingModel of a paragraph shall receive a callback before the template is rendered.
  • The callback can return special instructions that effect the rendering. If it does not then rendering proceeds as normal and when the paragraph is to be rendered the previously model and its actionResult is used instead of executing it again.
  • The special instructions supported are:
    • skip-rendering which causes the rendering engine to abort page rendering. The template is never rendered.
    • redirect:<url> sends a redirect to the client and stops page rendering. The url can be absolute or relative inside the web application (i.e. the context path is added by Magnolia).
    • permanent:<url> sends a permanent redirect (301) to the client and stops page rendering. The url can be absolute or relative inside the web application (i.e. the context path is added by Magnolia).
    • forward:<url> performs a forward() to the returned url. The url is relative or absolute within the web application.

Implementation

  • A new filter is configured before the rendering filter.
  • The filter listens for a request parameter containing the uuid of a paragraph to preexecute.
  • The filter calls execute() on the paragraphs RenderingModel.
  • The filter checks the returned value for special instructions and performs them.
  • If the result is not a special instruction the filter stores the returned actionResult and model as request attributes and passes on to the rendering pipeline. The request attribute is stored with a name that includes the uuid.
  • AbstractRenderer checks for attributes set by the filter for the paragraph it is about to render.
  • If they are present their values are used otherwise the model is executed like normal.

Design considerations

  • The name of the request parameter is mgnlModelExecutionUUID.
  • The name preexecution is strange, maybe early execution is better? We've settled on Model Execution.
  • It might be better to have a new method on RenderingModel that is executed early. The reasoning is that very often you'll want to test in the execute() method if the model is being preexecuted or not and do different things. The method can be added by implementing an interface, like PreexecutionAware or Preexecutable.

Weak points and potential problems

  • A paragraph instance (the piece of content) can be rendered multiple times for a single page. What should happen then, do we reuse the value acquired in the filter for all renderings of that paragraph or just the first? Currently it is reused everywhere...
  • Can this be a security risk? Is it wise to add this feature enabled by default to all existing websites? The idea of the interface above might solve any such concerns.
  • When the model is preexecuted it does not have access to its parent model.

Future improvements

  • It might be a good idea to support redirect: permanent: and forward: as return values from template models too. See for instance RedirectTemplateModel in STK for which RenderingModel.SKIP_RENDERING was introduced.
  • No labels