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

Describe problems

ContentMap

Templating function (info.magnolia.templating.functions.TemplatingFunction) doesn't contain method which will return ContentMap for the given path or identifier. Nowadays you need can get javax.jcr.Node by methods content(String path), content(String path, String repository), contentByIdentifier(String id) or contentByIdentifier(String repository, String id). Then you have to change the node into ContentMap with asContentMap(Node) method. Also methods called "content*" are confusing for someone. Because when methods are called "content*" than they expect it will return ContenMap.

i18n wrapper

Templating function doesn't contain method which wrap Node or ContentMap into i18nNodeWrapper. Only STK templating function (info.magnolia.module.templatingkit.functions.STKTemplatingFunctions) contain method wrap(Node) which wrap node into HTMLEscapingNodeWrapper and I18nNodeWrapper. Wrapping into HTMLEscapingNodeWrapper is exposed to templating functions by method info.magnolia.templating.functions.TemplatingFunctions.encode(Node). We should add similar method for expose I18nNodeWrapper into templating function.

ContentMap - Proposal of solution

Proposal 1

Let methods content(String path), content(String path, String repository), contentByIdentifier(String id) or contentByIdentifier(String repository, String id) like they are.

Add new methods contentMap(String path) ... which will return ContentMap.

Consequence

This solution doesn't solve problem with confusion when "contents" methods return Node, but by adding "contentMap" methods this shouldn't be so confusing. And also this solution doesn't have any consequence on existing templates.

 

Proposal 2

Change methods content(String path), content(String path, String repository), contentByIdentifier(String id) or contentByIdentifier(String repository, String id) to return ContenMap.

Add new methods node(String path) ... which will return Node.

Consequence

This solution solve problem with confusion when "contents" methods return Node, but has consequence on existing templates because ContentMap API is not fully compatible with Node API. ContenMap contains special properties map which maps property into the JCR methods. This special properties start with sign "@". contentMap.@name , but in node we can get node name by "node.name" or with node.getName(). With this solution we have to also introduce migration script for templates.

 

Propodal 3

Deprecate methods content(String path), content(String path, String repository), contentByIdentifier(String id) or contentByIdentifier(String repository, String id) and intstead of those methods add methods node(String path) ...  which will return Node.

Add new methods contentMap(String path) ... which will return ContentMap.

Consequence

This solution solve problem with confusion when "contents" methods return Node. And also this solution doesn't have any consequence on existing templates.

Proposal 4

  • Deprecate methods content(String path), content(String path, String repository), contentByIdentifier(String id) or contentByIdentifier(String repository, String id).
  • add explicit contentByPath(..) and contentById(..) which return ContentMap
  • add explicit nodeByPath(..) and nodeById(..) which return Node
Consequence
Easy transition (no code changes needed) but it might be confusing and one might use the deprecated methods why one shouldn't

Proposal 5

  • create a new templating function object (which might extend a shared parent object)
  • a template can use the old or the new render where each uses a different function object
  • add a ContentMap.asContentMap(ContentMap) which does nothing
  • if we go for this then I propose the following method names (considering that storing the id is the more common pattern than storing the path)
    • add explicit contentById(id [, workspace]) and contentByPath(path [, workspace]) which return ContentMap
    • add explicit nodeById(id [, workspace]) and nodeByPath(path [, workspace]) which return Node
    • search and simple search returns ContentMapIterator
  • TemplatingFunctions become the new one?
    • and we create a LegacyTemplatingFunctions
    • means we break the API but the templating 

Consequence

It's the cleanest solution but might require code changes (not to many actually) in our STK templates. The functions object can currently only be registered at the renderer level but we could register two legacy renderers: legacyFreemarker and legacyStk.

I18n - Proposal of solution

Proposal

Add method called i18nWrap and i18nUnwrap into template functions.

 

New Methods in template functions

public Node i18nWrap(Node)

public ContentMpa i18nWrap(ContentMap)

public Node i18nUnwrap(Node)

public ContentMpa i18nUnwrap(ContentMap)

 

  • No labels

2 Comments

  1. content():node

    contentByIdentifier():node

    search():node

    simpleSearch():node

    encode(Node)

     

  2. Added Proposal 4 and 5. I am in favour of solution 5.

    the method to wrap (if we add it at all) should just be named i18n()