What Christian said, plus a few additional notes: "variations" can also be
driven by your model classes, and/or the site configuration (this is maybe
far-fetched, but you can do stuff like ${stk.site.name}, or STKUtil.getSite()),
for instance. (which would mean you could also reuse the same paragraph
definition)
And yet another approach is to use "specialized" includes, such as [#include
"includes/${stk.site.name}/myInclude.ftl"]. To be tested, but this might even
work with acquisition[1] [#include
"includes/${stk.site.name}/*/myInclude.ftl"], which would (hopefully, if I'm
getting this right), first try to include includes/mySite/myInclude.ftl, or
includes/myInclude.ftl if the specialized version does not exist. (I've never
tried this, let me know if you do!;))
Hope this helps + gelukkig nieuwjaar !
-greg
[1]
http://freemarker.org/docs/ref_directive_include.html#ref_directive_include_acquisition
On Jan 6, 2010, at 2:47 PM, Christian Ringele wrote:
> Hi Hay,
>
> On Jan 6, 2010, at 1:13 PM, Hay (Husky) wrote:
>
>>
>> Hi everyone,
>> here's a common scenario: you want to use one of the STK paragraphs
>> (e.g. the stkTeaser one) in one of your sites. Unfortunately, the
>> template file of the teaser lacks some stuff for the specific design
>> so you copy the paragraph definition to a new node (let's say you call
>> it myTeaser), make a new ftl file that has your specific HTML and use
>> that for the paragraph definition. In the process you copy all of the
>> settings and parameters.
>
> If you need additional html in the ftl, you should try to define the
> diverging html-element names in the paragraph definition/parameters.
> For example as we do it with the heading level of titles and for div id's and
> classes. Also you can define in the ftl that when the parameter is empty, the
> html element is not rendered at all [#if def.property?has_content]...use my
> ${def.property} [/#if].
> The goal would be, that you can always use the same ftl, but only by
> parameters of the paragraph definition having it rendered different.
> But this makes only sense, if these 'myTeasers' have a similar html
> structure, but varies html element naming and/or not having some of the
> elements.
>
>>
>> Then, for another site you have another design, you copy your
>> paragraph definition to myTeaserNew, make a new ftl file, link it,
>> etcetera. After a year you have around 100 'myTeaser' definitions, all
>> exactly the same but for one thing: the ftl file.
>
> It makes more sense to look at it the other way around:
> Having always the same ftl file, rendered different driven by parameters of
> the paragraph definition.
> So when you need it in a new project, only a copy of the paragraph def is
> needed with different parameters.
>
> For not having to copy always the same ftl files again, you could provide
> your adapted ftl files & paragraph definitions with an own module, for
> example 'my-paragraphs-module'.
> It would contain all ftl's you want to reuse in different projects. You could
> say this would be your customized template/paragraphs module.
> If the paragraph definitions would not varies for the different projects, you
> even could use the origin paragraph definition directly out of that module.
>
>
> I hope I understood your question correctly.
>
> Best regards,
> Christian
>>
>> To me, it would make more sense to have one single paragraph
>> definition, but multiple ftl files, specific for a certain site. Is
>> there something you can do to accomplish this? E.g, an extra property
>> in the 'paragraphs' node of your site definition that enables a
>> specific custom ftl file for that site?
>>
>> Kind regards,
>> -- Hay Kranen
>> Frontend developer VPRO Netherlands
>>
>> ----------------------------------------------------------------
>> For list details see
>> http://www.magnolia-cms.com/home/community/mailing-lists.html
>> To unsubscribe, E-mail to: <[email protected]>
>> ----------------------------------------------------------------
>
> Best regards,
>
> Christian Ringele
> Magnolia International Ltd.
>
> Meet us at the Magnolia Conference
> http://www.magnolia-cms.com/conference
>
> Magnolia® - Simple Open Source Content Management
>
>
>
> ----------------------------------------------------------------
> For list details see
> http://www.magnolia-cms.com/home/community/mailing-lists.html
> To unsubscribe, E-mail to: <[email protected]>
> ----------------------------------------------------------------
----------------------------------------------------------------
For list details see
http://www.magnolia-cms.com/home/community/mailing-lists.html
To unsubscribe, E-mail to: <[email protected]>
----------------------------------------------------------------
