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

Date

Items are listed in order of how much they were discussed, and generally reflects how much interest there was in the topic.

YAML Validation

There was frustration with YAML definitions that would not work, and having a hard time getting them to work because they did not get enough information about what was wrong in the definition.

People co-miserated about the "Annoying red bar" that adminCentral shows when you have a definition error. You know something is wrong, but get no better feedback. At least since its file-based you can Ctrl-Z to go back a few steps until it works again. Someone mentioned working an hour to fix the problem.

One person explicitly mentioned cotoolz, but saying that while its handy to get the autosuggestions, her biggest frustration is simply with errors in the files. (which cotoolz does show too).

I mentioned that the definitions app will help with this a bit.

It seems the most important improvement is that the system tells them where the error is in the file. On most recent tests it appears that the logging is improved and is giving more detailed information.

A next step would be to present this information in a more comfortable and accessible way - to be determined. Possibly within the editor (atom, sublime, in a similar way to something like jslint) or within adminCentral (probably in the definitions app.)

Whitespace

One person mentioned problems with tabs instead of spaces in files. The file looks correct, but the definition cannot be imported properly. And again no helpful information.

Java developers (and many developers) are not accustomed to white-space sensitive configuration.

Extends

There was a broad interest in YAML extends feature.

People new to Magnolia even described the YAML extends feature as something that they wanted, even though they were not familiar with the feature.

A new employee at Arvato asked about something like Dependency Injection for YAML. I'd like to follow up on how he imagines that could work.

Include does not work the way they want it to

They can only use it on the node level - they want to use it on the property level too.

People use YAML for apps

Even though magnolia does not recommend it - people like it for all the same reasons they like it for templates and dialogs.

Heard several times - they can just copy the entire app definition, and modify it for the new app.

They used to use the groovyscript, now they use the YAML.

"Our Java developer hates going into the configuration tree to do something."

One should not have to configure the same thing everywhere. ie Actions for a dialog.

One person did a bunch of configurations, but nothing was working, they later realized they had forgotten the actions in the definitions.

Virtual URI's in YAML

Sentiment this would be really nice to have in YAML. Reasons:

  • If you screw up your system, you dont need the Groovy Rescue Servlet. Just change it again and save it.
    • And this can be hard because REGexps can be hard to get right, often you'd like to experiment a bit.
  • Migration to magnolia often involves setting up massive redirects. This would be great to manage in a YAML file. 
    • Its so annoying now in JCR - that they instead choose to do it in Tomcat, which is less than ideal because they would like to have that information in the magnolia project.

Project best practice

A partner is interested in how to setup a project in such a way that when it is launched and "taken over" by the client, it continues to be easy for them to develop on.

Ideally it will be easy for them to continue to revise the templates and the frontend. The Java that is developed now, and the project structure should be flexible enough to support this.

As always people are also nervous about how to develop their projects now so that they will be the most future proof and will work well with 5.5.

Migrating to Light Development

A question from a new-comer to magnolia who has taken over a large-ish 5.3 EEpro project. Is there a way to batch transform from JCR configuration to YAML configuration? What would be the recommended path? Can I mix them?

One partner said they have done that step by step, whenever working on a component, then moving it to YAML. And the answer is yes, you can mix JCR and YAML config.

TODO:

Provide a groovy script to batch export everything under specific config paths from JCR to YAML. (What about extends?)

Two people reported a problem with exporting apps to YAML. Possibly something to do with maps vs lists. Possibly to do with the roles.

Investigate how to get include (and extends) to work how people need it to work.