[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: |
|
||||||||
| Issue Links: |
|
||||||||
| 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, |
| 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)
|
| 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, |
| 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. |