Hey Richard, your solution to auto-generating any kind of arbitrary structure sounds very interesting. Have you thought of maybe contributing this to the community as a separate forge module?
Cheers, Jan On Mar 21, 2011, at 12:15 PM, Unger, Richard wrote: > > 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]> ----------------------------------------------------------------
