Enonic version: 6.6.2-SNAPSHOT
I have an existing app for a site, where this app also contains a “corporate design framework” with CSS and markup examples which is a node.js project that the designers want to re-use for all future sites/apps. Currently these two projects have been built and deployed as part of the same app, where the CSS files are built with SASS into the app’s assets folder using some intricate relative paths.
Now I am tasked with making a new app for another site that is supposed to re-use the same design framework CSS that was used in the original app. I see a few options:
- Do not make a new app for the new site, instead just expanding the old mega-app. Nope.
- Compile the CSS from the node.js project into the assets folder of the new project, using the same intricate relative paths across project directories. Building could fail if for instance both projects don’t reside in the same parent directory… :-S
- Reference the assets from the other site directly, using filters. Similar to how the Favicon-app currently on the Market modifies the document head.
- Make a lib out of the node.js project, that contains the CSS and other assets that I need. But that leaves me with a question: How could I include these assets from another lib in the page controller of my app? Page Contributions would have been wonderful, but according to the docs it seems that this is only possible for parts, layouts and macros. Not for actual pages. It seems risky to have my pages not show properly until a mandatory part/layout has been added to the page…
- Let the page controller(s) be part of the design framework lib described above, while other stuff like content types and parts are part of the new separate app.
Any thoughts on what would be the best approach?
One goal at least would be to avoid serving duplicate code in multiple app assets.
I don’t know why page contributions are not available in all controllers. But I would definitely like to see it in page and content-type too.
- I would put the assets in a lib.
- I would use sass variables and mixins in different apps assets
- I would have a filter in the lib that adds the prebuilt css, fonts, etc directly via page contribution
- I would make it possible to disable the filter on special pages via serverside headers in the response object.
Page contribution via filter example:
We are working on a extranet site that contains multiple APPs. An APP in this context is FAQ, files, blogs … So we tried some different approaches how to set this up that worked for multiple devs and was easy to deploy.
The short answer is that we created a THEME app , A FAQ APP and so on and added it on the same SITE. This gives us flexibility to change any component in the apps, but the APP must follow the Theme for look & feel. So when we create an APP we add the Theme APP and the PROJECT APP.
I know there have been some discussion on having multiple apps in a site or not. But from where we sit, this works when you want to create multiple app that uses the same functionaliity, UI … multiple times
So from what I have read. I would create a “corporate design framework” APP with everything UI in it. And if you need some additions you could use contributions from you’re other APP.
4. You can use page contributions from a page controller also. I see the documentation is confusing. I guess we did not see the use of adding contributions from the page. I will update it.
Also I think when you include a lib in your app, then you can just reference the lib assets as if they are local assets. If I’m not mistaken.
Thanks for your answers, I think I have a path forward from here.
I suggest making a lib of the css-project and then building it into your various apps make perfect sense. When compiled, all the assests appear as if they were local resources and can be referenced directly.
If you have a css project that you want to include in another project, I suggest you create a npm package for it, and just include it as a dependency in your application’s local build. This way, you can have access to uncompiled assets (less, sass, whatever you feel like), and each app is responsible for the paths they set.
Putting assets in a library seems like an unnecessary step to me.