@thenexus00 Quick reply as I’ve just got back from vacation, catching up on your replies. Great shout about Liquid templating, I had totally forgotten about this - interestingly Matt Brailsford wrote an MVC View Engine with DotLiquid for Umbraco (over 10 years ago now), which was very cool. I’m quite excited on the idea of using Liquid templating in the backoffice and will prototype something using LiquidJS soon. Thanks for the discussion so far (and I’ll reply to your other points in due course). 
2 Likes
I been ill/busy myself.
Liquid JS would be a good solution.
For any native stuff being able to have that level of out of the box logic to easily expand your back office without going fully custom addon would save people heaps of time and effort.
For many just being able to have simple “if have title display that else use default” and like to help compliment their custom block grids etc would be great.
Then for anyone building more custom build solutions being able to build web components if they want but to just be able to tap into liquidJS to render out the data with logic that comes with it would be great for them as well.
It would save heaps of time having to try build out something to replace what used to be possible.
1 Like
Maybe this goes without saying, but I’d suggest allowing users to bring their own templating engine and not tying the implementation directly to LiquidJS. Then people could use Nunjucks/Handlebars/Mustache or whatever they want.
Hello, if you start looking at Liquid, I’ve had good experiences with the Fluid for liquid templates.
Just joining in with the discussion as I have been doing some custom Block Grid Views and as I am now starting to pick up more complex ones where one of the properties of the block is a MNTP which only stores a GUID/key.
I am unsure how best to resolve this problem and was curious if anyone else who is actively working with custom block previews may have encountered this problem or have thoughts,
To avoid flooding this thread - I did create a new forum post to talk about the specific use case, as I feel this thread is a good conversation between the community and the HQ core CMS team about the complexities of writing custom block previews.
I literally just created a Block Item that is a MNTP pointing to some reusable content with multiple properties.
I got the content using:
Model.Content.Value<IEnumerable<IPublishedElement>>("featureName");
I was concerned it would not display in Block Preview… but it does.
This is in 13.8.1 but I believe @rickbutterfield has it working in 15+ so a good person to ask.
I think you may have misunderstood my problem Dean.
This is for the rendering inside the backoffice of Bellissisma and not using Rick’s package.
I assumed you want to preview a block you are picking in the MNTP?
I thought the way @rickbutterfield has Block Preview working in 15+ would be useful.
So you would have to account for multiple frameworks to access the data and provide documentation implementation for all of them which would not cover things like the magic string replacements in various fields on property labels and so on…
That is a lot of work I would not ask anyone to do.
It is a legit post Warren,
I have since had various things with no support references that should work that do not but also things I did not expect to work and do.
It is a bit to wild west for me and again just feels against a lot of the ordinal ethos of Umbraco.
I mentioned that 
That would be my preference and my preference of more server side that script but the current backoffice is more scripting now so liquid JS would be the thing that would most likely be the easiest to implement.
I am personally a huge fan of liquid and the use cases I have seen or been part in to use it. Some take it a little too far but having a platform where you can go do custom solutions but also a platform that allows you to use a more consumable templating language does a lot.
I know it is old now but Kentico spent so much time developing their “K Sharp” and buggy over engineered implementations for things when Liquid Markup could have done a lot for the platform.
My thoughts here lead to Liquid because you had Angular and Umbraco was clearly looking to develop its own similar but it would take time and currently it does not have the same ability as the old back office had.
Liquid JS would allow some of that quick and easy custom output in various aspects of the back office and allow some quick output logic for things like block previews without going crazy.
I do not mind some of the people developing products and posting in here but I am a big fan of solving the problem at the root rather then having to rely on third party products to solve the problem. Such things should exist to enhance a product, not fix problems.
Sorry, bit of a rant
One of the primary aims of the new backoffice was to be framework-agnostic. People shouldn’t be forced to use a specific framework like LiquidJS in the same way they don’t have to use Lit. I’m not saying every framework needs to be accounted for up front, but it should be possible to swap out the implementation with your own.
1 Like
This.
LiquidJS templating will mean bringing another perpetually feature-incomplete Domain Specific Language to the Umbraco Backoffice.
Those of us that can bring our existing frontend components to the backoffice, or provide server-generated HTML previews, shouldn’t have to use it.
1 Like
Lots to unpack on this topic. 
I’m happy that we’re having these conversations!
This is pretty much what we have today with the blockEditorCustomView extension point.
Sure, it’s initially for a JS web-component, but could be expanded to other templating languages. Pretty much like Rick Butterfield has done with his Block Preview package for Razor templates.
With the whole Liquid conversation, I guess that’s more me wanting to explore ideas rather than decide on a CMS core feature (in a forum post).
I have started to prototype Liquid templating in Contentment, as a replacement for AngularJS templates in the Templated Label editor, so far I’m very happy with the experience/results. (Again, this shouldn’t suggest that Liquid will be a core CMS feature).
I wasn’t aware of Kentico’s K Sharp. The overengineering concerns are partly my fear with UFM. But then the intention of UFM was to be a layer on top of Markdown, rather than become it’s own DSL.
Overall, I have 2 concerns on this topic/threads:
-
The perception that a Vite/TypeScript set-up is required simple feature extensions.
As Jacob shows above, it’s entirely possible to do this with vanilla JS and package manifest file. But most feedback hear (generally from long term .NET developers), is that Vite/TypeScript (or anything npm based) is far too complex. How can we, as a community, lower the perceived barriers? -
What type of logic belongs in a user-input textbox? Specifically this textbox…
Firstly, the UI for “Label” is not very intuitive. What should a developer/implementor enter into this field? Even in v13, there was zero indication that AngularJS expressions were supported here. (You’d either need to go off and read the documentation or hear about it word-of-mouth).
We introduced UFM, with a limited feature set. So far it’s for rendering basic values, anything more then it’s roll-your-own UFM component extension… again, we’re back into the perception that Vite/TypeScript may be involved for a such a simple task.
So what should be allowed in that small textbox? After all, it’s a single-line to imply its simple usage. Would the use of JS-style conditions/ternary operators be considered advanced usage?
More questions than answers here, I appreciate the conversation!
1 Like