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

Version 1 Next »

Dear Magnolians,

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

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

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.

Use Case: Project specific processing:

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

A workaround is to have these values that need Magnolia processing to be directly in a normal component as an inline style - 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. This content could simply be included inline in the header - or actually linked to like a normal resource using Direct Component Rendering (https://documentation.magnolia-cms.com/display/DOCS/Rendering+content#Renderingcontent-Directcomponentrendering).

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 it might be hard to read! Or you could rebuild the file locally with grunt again and hotfix the whole file.

Feedback

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

Thanks for your input on the topic.

  • No labels