There were two topics proposed for the unconference "Ideas for NPM CLI" and "How to develop frontend and backend in parallel", but since they occupied the same time-slot, it was decided to merge them.
To summarize, the meeting did not delve too deeply into the topics as proposed, and I did not sense any conclusions or progress on these topics. However there was a useful survey of many of the topics and questions concerning how to work with frontend techniques in Magnolia - and also a few of the useful approaches and code that can address them. It would be great to have more focussed discussion in the future on some of these topics.
How to automate? How to bring a frontend build process (gulp, grunt) into the existing maven based continous integration system?
There is a consensus on the benefit of the maven-frontend-plugin to ensure that everyone has the same build, and that the CI system can handle changes to front-end resources. (Rather than the risk of only one Frontend developer being able to build the FE resources.)
Some devs complained that this worked but took 20 minutes to build, Marvin thought there might be something wrong with the build because his only takes a few seconds. (Obviously could just be differences in project size.)
This is typically about building css from less and sass and building a js bundle for the project.
How to incorporate frontend projects like React and Angular into Magnolia?
Render React, Angular, etc on the server? Isomorphic apps.
A few people are wondering how to follow the new-ish best practice of rendering FE SPA on the server to improve initial load times and SEO.
TODO: Research. Form a discussion group. Seems doable (http://niondir.de/blog/isomorphic-web-application-using-java-8-nashorn-and-react/)
How to feed frontend apps with Magnolia content?
Two main approaches.
- Render JSON directly in the template, so the app does not need to make another request to the server. This is more appropriate for simpler smaller apps sitting on a page.
- App hits a REST endpoint to pull the information.
Templates can render JSON as easily as HTML, and this approach can be used in both of the above cases.
TIP: There is a very slick (unofficial) magnolia module which supplies jsonfn templating functions to do this. See https://www.magnolia-cms.com/blogs/jan-haderka/detail~@json--rest--magnolia-and-the-creation-of-end-points-without-writing-a-single-line-of-java~.html
You can also use the Magnolia out-of-the-box rest endpoints, or create your own endpoints with Java. Here is a tutorial: https://documentation.magnolia-cms.com/display/DOCS/Accessing+content+on+the+client+side
Ideas for the NPM CLI
One person suggested that the CLI could analyze project files and create the i18n property files automatically.
Someone suggested that if your apps were in YAML you could use it to change app behaviours such as changing role access, or changing the publishing method.
How to improve the workflow between Frontend and Backend developers working on Templates?
Common annoyance - keeping the "static HTML prototype" aka "click dummy" from the designers/fe developers in sync with the Magnolia templates. Some approaches:
Generate templates from HTML prototype
...based on annotation in the HTML
This was demonstrated and explored by the lemonize kickstart.io project. This sounds very attractive, but there does not appear to be a truly successful implementation of this yet. Some issues:
- The HTML prototype gets crowded with meta-information that makes it unwieldy.
- Meta information gets hard to maintain, and have an overview. (Do you want to maintain your dialogs in separate files, or as annotations sprinkled in an HTML file?)
- At some point your team probably transition to the generated templates, and then the benefit is gone.
Personally, i still think the idea "has legs" and should be researched, but possibly we have not yet discovered the proper balance between annotation and explicit configuration.
Universal templates. Same template used in FE prototype and Magnoila
Use the same templating language in your FE build system (probably based on node) and in Magnolia. Then the templates developed by the frontend teamcan be used in Magnoila. Frontend devs then typically "own" the templates - but Java devs can still edit them. Any changes in the FE prototype are automatically integrated in the Magnoila project since they are the same files. There are several different implementations of this approach.
- Namics uses Java based handlebars renderer (Jknack) in Magnoila. And custom opensource handlebars build system, nitro.
- T8Y has experimented with Java based handlebars renderer (Jknack) in Magnolia.
- Netcetera has Mustache "meta-templates", that are used to generate both the "static" design templates for a "living styleguide" (based on patternlab), and Magnolia templates.
- Moo also generates a living styleguide, but they created a custom one (not patternlab) and they have developed a front-end build process based on FTL.
- I think there is an FTL renderer for node, and theyve mocked the magnoila specific things.
- Other teams simply have their FE developers learn FTL and work directly with Magnolia from the start.
- Pair programming. One person said they simply have their Backend and Frontend developers working together, and this saves a lot of time. But he acknoledged that this is not exactly a system.
How to include FE resources in Magnolia Projects?
Several factors to consider when deciding on an approach: Ease of development and maintenance, performance on the website. Can npm components automatically include their resources in a project, or do you have to manually wire them up?
- Manually "wire-up" all resources with a Magnolia theme, or simply in the head of the templates.
- Use the handy un-official Magnolia module neat-resources which includes templating functions which automatically include all resources under paths that are specified with wildcards.
- Use fe build process (gulp, grunt...) to generate bundled resources - Magnolia then just includes two files all.css, all.js
- Require.js can be used to only load the JS that is needed on that particular page, rather than loading a single all.js that might be too heavy.