Closed lars-erik closed 1 year ago
@lars-erik Small tangent question, you mention the Superpower dependency - is that this library? If so, it's not clear to me how it'd be used (in the context of your idea).
Back to the idea, slightly related, I'd previously made an editor called Shadow Content Picker, which would let you pick content, then use an element type to override property values. The resulting IPublishedContent
would let you fallback to the original values. I ended up never releasing it.
I think we would be more than happy for both our Text Fallback and Image Fallback to be merged into contentment. It's something we have thought about asking @leekelleher for a while. The idea came from our old Classic ASP CMS where we have had fallback options for 15+ years. So it would be even better if 'user visible / configurable' fallbacks were in core. We also have a image fallback, predominantly used for meta thumbnails as well.
@leekelleher To quote the Superpower readme:
Just like other kinds of functions, parsers can be built by hand, from scratch. This is-or-isn't a lot of fun, depending on the complexity of the parser you need to build (and how you plan to spend your next few dozen nights and weekends).
Then point to code in the Wholething repo:
It's a library to avoid parsing stuff with regex. That said, big H5s and all to the Wholething gang. It works and it's useful.
In our V7 package I had dropdowns of pre-defined stuff with params, so kind of the same and as non-scalable.
OFC. having a proper AST and super flexible code might not be needed. The primary goal is to be able to configure fallbacks for any property editor type using Admin Only's "shadowing" mechanism, as well as a flexible way like Wholething's mustache/functionish language for specifying fallbacks.
🤦♂️
At least a bit...
I dug further through the Wholething thing and discover Handlebars.net, which is pretty much the same alley as Superpower. Tho' I'd prefer to keep to one dependency ofc. :)
I got the idea for using mustache syntax e.g. {{myPropertyAlias}} from angular filters for block list and grid labels. I just thought path of least resistance etc… We have been waiting for the new UUI before deciding what to do with the code. However, with the delays it may be worth progressing it.
Ka-blam!
https://github.com/lars-erik/umbraco.community.fallback
@deanleigh: Your text fallback package still has competitive edge for text (the DSL), so please leave it around. I only made fallbacks to current content, and have no idea about blocks or variants yet.
Guess we can close this thread. 🙃
Idea summary
In 7 we had a proprietary editor we didn't share that made SEO and listview properties "fall back" to each other, then content, then name. So for instance the SEO title would fall back to the listing title, which would fall back to the "heading" if any, which would fall back to the name of the document.
Same goes for SEO-description, which falls back to listing text, which falls back to first 160 chars of any body text.
Sharing image etc...
I know Wholething has made a couple of packages for text over here. The features they made for defining fallback is quite nice, and might even be improved by exploiting Superpower which is already a dependency.
But it suffers from being individual property editors per textbox, textarea, image etc., as well as showing both the default and "overridden" value as radioboxes.
IMO the default should be kind of dimmed until you toggle some mechanism, which opens a "blank" editor of the same type. There should be some way to revert to the default as well.
The way to do that would be to use the same mechanism as Admin Only Property Editor such that any property editor could be wrapped with a fallback rule.
Incidentally, this could also help solving all the issues with ModelsBuilder having just "one" fallback for the typed properties.
When this is done, it should really just be a property editor in Contentment, no? 🙈
Which categories would the idea fit?
Code of Conduct