Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Dear Magnolians,

Do you use the Processed Resources feature in your projects? Why? As a product manager, I would love to hear about your specific use cases.

(This is the feature where a resource file can be an processed as an ftl, and also automatically concatonated together.)

Why am I asking? - Because we have a new resources servlet - which makes working with resources much more straightforward. Its time to re-evaluate what functionality is required - balancing the benefits of a feature, vs the complexity it adds to learning Magnolia, implementing and maintaining Magnolia web projects - as well as the complexity of the Magnolia codebase.

A lot has changed in the web world since we first introduced that feature. Now many teams do their less, sass, concatination, minification, etc processing beforehand - using tools like grunt, gulp, browserify etc. And they add these pre-processed resources to Magnolia. And of course this frontend world will continue to evolve rapidly. There are two use-cases that I know of that the pre-processing does not exactly cover. (Also there are some nice Maven plugins that make adding the preprocessing to your build chain easy.)

Use Case: Project specific processing

One use case that this "offline" preprocessing cannot help with - is where you want to do project-specific processing - such as grabbing a color value from each site configuration to use in the css of that site.

A replacement is to compute these values in a normal component and render them in the template: as an inline style in the case of css - or as a parameter to a javascript function. So the javascript resource can be static - but use the value provided in the processed template.

Another possible approach - if you have a resource that you want to be highly processed, just like a Magnolia component - with a custom renderer, model class, etc... Is to simply really use an actual component template or page template that outputs css or js code. This content could simply be included inline in the page header - or actually linked to like a normal resource using Direct Component Rendering (

Use Case: Hotfix originals

Another use case is that you like the ability to hotfix a css or js resource directly on your server. It is convenient to hotfix the clean unprocessed file in adminCentral - and then Magnolia processes it again for you.

This is true - but if you did pre-process your resources with grunt and include that file with Magnolia - you would still be able to hotfix manually via adminCentral - though the file will probably be harder to read! Or you could rebuild the file locally with grunt again and hotfix the whole file.


Are one of these use cases important on your project? Would the alternative approaches work for your case? Why not? Do you have other important use cases?

Please add comments to this wiki document. (Create an account. Or to the forum if you dont have an account here).

Thanks for your input on the topic!

  • No labels