[BLOSSOM-190] Provide also to blossom the MutliSite features placed in STK (i18n, prototype merging, etc) Created: 01/Sep/14  Updated: 21/Sep/14  Resolved: 19/Sep/14

Status: Closed
Project: Blossom
Component/s: None
Affects Version/s: 3.0.3
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Christian Ringele Assignee: Tobias Mattsson
Resolution: Won't Fix Votes: 0
Labels: support
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Multi site feature is a base functionality provided by the EE (Pro) usage.

The mutli site configurations used in the MultiSiteModule (modules config node/sites) reflected by "info.magnolia.multisite.MultiSiteModule.sites" use the STK based SiteDefintion bean Site "info.magnolia.module.templatingkit.sites.Site".

But various features of this configuration are based on pure STK implementations:

  • i18n (the AbstractRenderer wrapps the nodes, not done by the blossom renderer)
  • templates/prototype merging (done by the STK renderer)
  • TemplatesAvailability class used for SiteDefition/templates node is pure STK (and not the one form the rendering module).

This limits the use of the blossom module in collaboration of the multi site module.
This functionality provided by the multi-site module should also be useable for the blossom module.

The way to solve this problem by using STK-Pages and adding blossom components is not applicable for all customers, but they still need to use the mutli site capability and its features.



 Comments   
Comment by Christian Ringele [ 01/Sep/14 ]

See customer comment: 01/Sep/14 11:33 AM

Comment by Tobias Mattsson [ 15/Sep/14 ]

Blossom and STK take different approaches for extending the base templating and rendering functionality in Magnolia. Therefore some core functionalities in STK are not usable in Blossom templates/components. This is also true for projects using only base templating and rendering. It is possible though to use some select features from STK in such projects and in Blossom templates. I'll try to outline this below.

The Site definition is an STK concept but as it is not directly tied to the STK templates it can be used in Blossom templates/components. The Site definition is resolved early in the filter chain and is then available at any time further into request processing. For instance in Blossom controllers and views. Multi site support is an extension to this functionality and therefore works as well. Content i18n support can be configured per site and the multi site module sets the request up for content i18n accordingly. Content i18n is a feature of Magnolia core and therefore works in Blossom as intended.

Themes are configured on the Site definition and can be used in Blossom templates. The code in STK that includes them is in htmlHeader.ftl which is included on all pages. This needs to be replicated in Blossom templates. This also applies to JS files configured directly on the Site definition.

STKTemplatingFunctions provides some functions that are usable as is in non-STK templates, while some rely on finding the site root page. They do this by walking up the hierarchy until it finds a page using an STK template with category set to "home". To use these in a project that mixes STK and Blossom the root page must fulfill this requirement.

Blossom and STK have different concepts for template availability. They can exist side by side and will not conflict.

Blossom does not participate in the STK template prototype mechanism.

It is possible to mix Blossom and STK templates/components in the same project. Blossom components can be added to pages using STK templates, the opposite works in theory but some STK components depend on the model class of the page they're on. Which means that they will only work on a page using an STK template.

The resources module and the inplace-templating (templates workspace) are not directly tied to STK and are usable as is in Blossom templates.

Comment by Christian Ringele [ 18/Sep/14 ]

Hi Tobias,

I only partially agree:
Multisite operates on STK's site definitions.

So If you buy Magnolia EE Pro for multi site, even if you don't want to use STK, you must.
This has as a consequence, that the site definitions are there and are used.
It is the base configuration for the multi site behavior.

SO You have site definitions, in there a i18n content configuration, which if you use it no blossom template will ever react to it. Why:
The blossom renderer does not wrap the rendered content with the i18nContentWrapper.

With this ticket I meant mainly, adding this functionality to the blossom if possible.
For example the wrapping of the node with the i18nContentWrapper.

I see that the template/prototype merging won't probably be applicable as there are different concept.
But the i18nContentWrapper wouldn't that be applicable?

Regards
Christian

Comment by Tobias Mattsson [ 18/Sep/14 ]

Hi,

The content is wrapped with i18nContentWrapper when rendering using Blossoms renderers. The class hierarchy is:

AbstractRenderer <- FreemarkerRenderer <- STKRenderer
AbstractRenderer <- FreemarkerRenderer <- FreemarkerTemplateViewRenderer (Blossom)
AbstractRenderer <- JspRenderer <- JspTemplateViewRenderer (Blossom)

The confusion probably comes from the fact that there's a class BlossomTemplateRenderer that indeed does not extend AbstractRenderer. This renderer only delegates into Spring Web MVC which then renders the views freemarker/jsp with the renderers detailed above.

Generated at Sun Feb 11 23:31:02 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.