Hi Peter,
> Hmm no reply yet, let me clear up my questions: > > 1. It doesn't seem possible to extend STK by supplying all code and config in > a new module. So without modifying STK config. Is that right or am I missing > something? > I'm not sure why you're saying that? You can supply code, templates and config in your own module. You can write a module-version-handler to update magnolia when your module gets installed. If you are actually overwriting STK settings, then you will need to see how future STK releases affect those changes. If a new version of STK comes out that interferes with your setting, you will have to make a new version of your module, with a Delta-Update in the module-version-handler which 'recreates' your setting. It can't be 100%-proof (for example, you won't be able to tell if the setting was customized, you can only restore a "default" value), but it's pretty good. At the very least your module can warn the user which settings need checking after an update. Remember also that upgrading STK isn't something you do often in a real installation - once in a while. And most STK Updates won't affect your settings, so it should really be a rare event that manual correction is needed. > 2. TemplateAvailability config and server config can not be extended from a > module it seems, is that right? > > For template availability you would have to change stk config and plug in > your own class or add entries to the availability list itself. For server > config I tried all > kinds of extensions from my module config, but so far no luck. > You can configure the class that handles TemplateAvailability in your site definition, under: config --> node: /modules/standard-templating-kit/config/site/templates/availability property: class standard value: info.magnolia.module.templatingkit.sites.TemplateAvailability for a Community Edition. You can supply this class in your own module, and configure the value in your module-version-handler. I don't think any of Magnolia's modules will ever overwrite this value once it is present. For example, we have an implementation we call "ExplicitTemplateAvailability" à basically we configure which templates are allowed as the children of a given template explicitly in the template definition. This gives us fine control over what type of page is allowed to go where. Our template-availability implementation simply reads this config information from the parent page's template definition, and uses it to filter the site's available templates. The template-categories are ignored. It works nicely. > My suggestion to magnolia dev team is to remove all instanceof STKPage code > in the category / root resolving part so that an implementer can create his > own > page type based on STKPage. I also found the code for finding rootnode > scattered around a bit. Lastly it would be handy if the > stktemplatingfunctions and > other helpers could be easily overriden since they contain parts that could > conflict with ones custom implementation. I don't really understand what you are missing here. I find that Magnolia is quite unique in that really EVERY little part can be replaced by your own implementation, usually quite easily, just by changing a value in the config workspace, and usually on the fly (without restarting the server!). Certainly this is true of all the templating and template related code. When I work with Magnolia I like to extend the STKTemplateModel and STKParagraph, but I don't use any of the STK template-scripts or template-definitions. I create my own templates and definitions, as I find it much easier to implement the designs in this way (bottom up) rather than modifying STK templates to try to make them look like what the design agency supplied. I've had no trouble working in this way so far. It's been possible to extend and replace vast amounts of functionality with surprisingly little code - for example we have our own "Templating Components" (edit bars, page bar, support functions, etc...). Give us a description of what you're trying to achieve, and someone will be able to help with pointers about how best to get there... Regards from Vienna, Richard ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
