Thanks Christian and Gregory for your help, i'll try it the other way around then. Actually, using a separate module with ftl files for our 'own' paragraphs and templates is something we're doing already. The include seems like an interesting experiment, i'll try it and let you know if i find anything weird.
Thanks and a happy new year too! -- Hay 2010/1/6 Grégory Joseph <[email protected]>: > > 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]> > ---------------------------------------------------------------- > > ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
