[MGNLSTK-780] Ability to define parameters on an Area Created: 08/Jun/11  Updated: 22/Feb/12  Resolved: 19/Jul/11

Status: Closed
Project: Magnolia Standard Templating Kit (closed)
Component/s: templates
Affects Version/s: 1.4.4
Fix Version/s: 2.0

Type: Improvement Priority: Neutral
Reporter: Matt Dertinger Assignee: Philipp Bärfuss
Resolution: Won't Fix Votes: 0
Labels: stk
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File Area.java.patch    
Issue Links:
relation
is related to MGNLSTK-575 Add a parameters map to the Site class Closed
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Date of First Response:

 Description   

Hi,

Sometimes it would be useful to configure generic parameters into the config for an Area, similar to the current ability to do this at the Paragraph level. Example use case would be able to apply different values to a divClass parameter to populate the class attribute in mainArea.ftl. One template definition could define this value as simply text, while another, (say a News Template that supports the hNews microformat), could define it as text hnews hentry item.

Example mainArea.ftl
[#assign divClass = def.mainArea.parameters.divClass]

<div class="${divClass}">
    [#include "/templating-kit/templates/global/mainArea.ftl"]
</div><!-- end text -->

[#-- commenting --]
[#if content[def.mainArea.comments.paragraph]?has_content]
    [@cms.includeTemplate contentNodeName="${def.mainArea.comments.paragraph}" /]
[#else]
    [#if mgnl.editMode]
        <div style="padding-top: 20px;">
            [@cms.newBar contentNodeName="${def.mainArea.comments.paragraph}" paragraph="${def.mainArea.comments.paragraph}" newLabel="${i18n['comments.newLabel']}" /]
        </div>
    [/#if]
[/#if]

Possible patch is attached. Needs to be tested before applying.

Please let me know if you have any questions.

Cheers,
Matt



 Comments   
Comment by Magnolia International [ 15/Jun/11 ]

Fair enough. If we wanted to be consistent (don't we ?), we'd need a freemarker model similar to info.magnolia.module.templating.freemarker.RenderableDefinitionModel to "hide" the "parameters" node. Some refactoring might be needed to avoid duplicating the whole thing. We'd then need to register that model's factory too.

Templating changes in Magnolia 5 should cover this "natively" (i.e areas become first class citizens)

MGNLSTK-575 has a very similar patch for Site definitions. I'd suggest we apply both simultaneously.

Comment by Matt Dertinger [ 15/Jun/11 ]

Hi Greg,

Regarding being consistent, yes, hiding the parameters node with a freemarker model would indeed be nice

Thanks,
Matt

Comment by Jan Haderka [ 19/Jul/11 ]

This feature is part of the the feature set of Magnolia 5.0 and is implemented there in more central way. In case of need, please use the attached patch, but the patch will not be applied on 4.4 branch in order to prevent conflicts between this implementation and one coming with 5.0.

Generated at Mon Feb 12 07:30:20 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.