@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
As someone who is doing stuff like this in labels:
{{$settings.featureSettingsPropertyHideDisplay == '0' ? '🚫 ' : "🟢 "}}{{ $index }} - {{$contentTypeName}}{{featurePropertyFeatureTitle? ' - ' + featurePropertyFeatureTitle : ''}}
I would like to see a low code / no code solution (rubbish example below but you get the idea):
Fairly certain we could use the new UI to add decision points
If has content display [a] else fallback to [b]
We created a manifest file that let us use the angular syntax (well a version of it) to create Wholething Text Fallback for inputs and text fields.
But this could have been built by ‘picking’ and ‘choosing’ in an interface.
I’d be happy to be involved if anyone thinks this is a good idea?
I like the idea. The same way how dynamic root replaced writing xpath queries. You can do this two ways: just have a UI and do everything there. Or have a UI that acts as a helper to build and update the UFM where you see the changes to the code happening real time. This latter gives more control in changing and updating the code if you know what you are doing.
1 Like
Absolutely - all low code / no code solutions are of course writing code under the hood e.g. We are already using things like @leekelleher’s Contentment for data lists with a UI or paste raw json option
I personally don’t mind writing some ‘code’ and for some things you just need to read the documentation. BUT I find it annoying to need to lookup the aliasses of the fields and what type they are. So what would help me:
- Maybe have a few templates for things you do often
- Have an easy way to access the list of aliasses and their types
- Link to the documentation.
Neither do I but I think the thing that attracted me to Umbraco is the level of entry. What you can get out of things and what you can do with little effort. Especially when compared to other .Net based CMS solutions which are all far to bloated and overly complex.
Umbraco has lost that a bit and needs to bring it back in. The discussions I seen of having views compiled by default as well is an example of that movement away and I do not agree with it.
To have to struggle, debug and know what properties you get our of things is one my gripes across multiple platforms as well. I wish you could more easily have a tool or documentation that easily told you.
The suggestions I made with Liquid and leading to JS again is simply…
- You can do what you want with web components and JS
- Angular had the magic strings which is lost. Umbraco to cover some missing features have started to replace them with their own but it is very limited. Time to develop would take time on other aspects of the platform. If you used liquid JS to get that in place is far easier and helps with the other point as well..
- The barrier of entry is increasing and I think things like liquid JS on top of the core nature of things allows people to create sites and solutions with the platform at a better pace, get into it and then expand and learn. That is what original attracted me and many to Umbraco. I do not want them to loose this.
3 Likes
Thanks for the working example @jacob . This made the process much easier 
2 Likes