Hi Nils, Yes, I know about the TemplateAvailability class - this mechanism is fine. I was referring to the default implementation of TemplateAvailability for STK, which is based on the template "category". We found this to be too inflexible for our needs, which is why we wrote our own subclass of TemplateAvailability.
We called it "ExplicitTemplateAvailability", and it works in combination with our subclass of STKTemplate, like so: * We can configure a node "template-availability" in our template definition. Under this node, we can explicitly configure which templates are allowed as children of this template. * We can also configure which roles/groups are allowed to use the template at this location. In this way, we can configure specific templates for use by specific roles exactly as we need them. The Singleton Paragraphs are a little weak in STK. Basically, they can generate a single node, as a direct child of whatever area they are configured in. We wanted more flexibility. Our solution extends STKTemplate and STKTemplateModel to auto-generate arbitrary paragraphs (more than one paragraph, multiple subnodes deep, etc...) and also fill them with default values (also for multi-language default values!). We do this by configuring a node "autogeneratedParagraphs" in our template definition, and provide the paragraph definitions and default values as children of this node. We auto-generate paragraphs on the author instance only, we consider this feature to be an aid for editors. Basically, it allows us to fill a page with "dummy" content paragraphs (lorem ipsum...) immediately after it is created, so that the editor sees a "pre-filled" page rather than an empty page to which he/she manually has to add paragraphs. The navigation issue is simply a case of the STK concepts not directly matching our customer's needs, which are based on pre-existing designs and websites. The navigation is "a little different", meaning we would have had to override the STK templates and models in many places (breadcrumbs, horizontal and vertical navigation). This is not so much a shortcoming of STK, it has more to do with the very specific requirements of our customer. Regards from Vienna, Richard -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Nils Breunese Gesendet: Montag, 21. März 2011 11:20 An: Magnolia User-List Betreff: RE: [magnolia-user] Setting up a site in Magnolia and usage of STK What's wrong with the template availability concept? Did you know you can specify your own template availability class in the site definition? You could even just return true if you want to allow all templates on all levels of the sites in all circumstances. We certainly don't allow this to our editors and I think the template availability concept is great. The default implementation is a bit of a long messy block of code, but that didn't keep us from writing some code to be able to specify our template availability setups a little cleaner. I'd also like to hear what your problems with autogenerated paragrahs and navigation are. Nils. ________________________________________ Van: [email protected] [[email protected]] namens Unger, Richard [[email protected]] Verzonden: maandag 21 maart 2011 10:42 Aan: Magnolia User-List Onderwerp: AW: [magnolia-user] Setting up a site in Magnolia and usage of STK Hi Tomas! We're setting up an Enterprise sized installation of Magnolia for our customer. We decided to follow a "hybrid" approach: * Our template and template-model classes inherit from STK base models, we use DAM and imaging * We use the ETK multi-site and site definitions, template definitions and template prototype * We don't directly use any of the STK templates or paragraphs * We extend the base template, template-model, site and template-availability classes with some custom functionality We chose this path because: * In this way, we feel we have all the power and flexibility of STK, but hope to avoid problems with upgrades (changes in the templates impacting our sites). * Our customer's templates only approximately match the STK concepts - we found it easier to define our own templates and paragraphs, to more directly match the customer's needs. In particular, the STK does not suit us directly in the following areas: * the template availability concept * the "Singleton-Paragraph" generation * the Navigation In terms of freemarker vs. JSP, I would strongly recommend freemarker - being able to edit the templates inline (or even better, via Webdav) is a very compelling feature. Regards from Vienna, Richard -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von [email protected] Gesendet: Donnerstag, 17. März 2011 14:58 An: [email protected] Betreff: RE: [magnolia-user] Setting up a site in Magnolia and usage of STK At this point JSP is our first choice because it is already being used while Freemarker is not. Although if it somehow came to our knowledge that we would greatly benefit by using Freemarker that could possibly change in the future. Do you have any thoughts on that? E.g. how is performance in Magnolia for JSP vs. Freemarker? ________________________________________ From: [email protected] [[email protected]] On Behalf Of Jan Haderka [[email protected]] Sent: Thursday, March 17, 2011 2:15 PM To: Magnolia User-List Subject: Re: [magnolia-user] Setting up a site in Magnolia and usage of STK On Mar 17, 2011, at 1:27 PM, <[email protected]> <[email protected]> wrote: > make of it. One issue though is that we most likely won't use Freemarker > making the pre-made templates unusable for us. Just curious, is it the corporate policy that forbids the Freemarker and forces JSP or do you have other reasons to not wanting to use it? BTW, Magnolia templates can be mixed, you can have some templates using Freemarker and others using JSPs, you can even have both types of the paragraphs on the same page. The decision to use one or the other templating language doesn't need to be site wide. At least not from the technical point, although I could understand if you don't want to have developers having to know both. HTH, Jan ---------------------------------------------------------------- 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]> ---------------------------------------------------------------- ------------------------------------------------------------------------ VPRO www.vpro.nl ------------------------------------------------------------------------ ---------------------------------------------------------------- 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]> ----------------------------------------------------------------
