This subject has been discussed earlier but it always ends upp with someone linking to a solution from the past 80's telling me i need to manipulate the dojoscript for the displayoptions menu. Well i was inspired by the way they handle the tinyMCE component where i could just create some code behind calls with parameters and voila, it renders as i want it. I want this for the DisplayOptions menu to thus making it how it really should work in the first place. No you are wrong EPiServer. It doesnt work as people really want it to. I said NO. Quit it, you can argue if you want but you are WRONG.
The DisplayOption should clearly work in the same way tinyMCE work. I got a block with a default DisplayOption. I can now enable DisplayOptions i want to be able to choose from by filtering. The ones not in the filter shouldn't render in the DisplayOptions menu. And i don't want to do this by editing in some dojoscript. Every time there are EPiServer updates making the edited file be overwritten and BS like that.
So, are there any real solutions to the issue? Not from the 80's...
Thank you for making the time reading this rant over a simple thing like wanting a filtering function for DisplayOptions visible in the menu depending if the block has like a allowedDisplayOptionsAttribute...
Image is to illustrate the current solutions available for the issue. It's outdated...
I've posted my solution as a blog which uses attributes to control block size support. It does use some custom Dojo changes but atm I think that's needed
Yes indeed. It's another great job in order to filter the displayoptions but as you point out it's using script in order to manipulate episerver frontend and may cause problems if they choose to change the frontend etc. Specially when there is so poor documentation around it making me wanna "flip the keyboard". In other words I really want to avoid it and perhaps the only way to do it the right way is to force EPiServer to change the implementation of DisplayOptions!?
I mean how they implemented the new TinyMCE isn't bad at all. In fact it's a great way to make it more dynamic and letting the coder get more control over it.
Although i really want to mark your reply as the answer i really can't since this is a issue with the product itself and we shouldn't have to manipulate it ourselfs. However im giving it thumbs up and a vote. I will recommend your solution to others and perhaps you could extend your solution towards evan more SOLID, unit testing and factory pattern since it seems to be the bomb right now. Not for me but for others wanting a crisp code to yearn for.
Yeah I understand where you're coming from, as I said it's something I've wanted in the framework for a long time around controlling this but it's a standard Episerver pattern at the moment that if you want to extend the Dojo UI you need to touch the Dojo script. However their roadmap is to fully replace Dojo with react this year so it's using a more modern framework so hopefully it will more to be mor extensible from C#.
I wanted to at least post an example that works with the current versions and is easy to follow so for now people can do it the only way you can, ff I release the package as a Nuget package I will add some unit testing and possibly extend it a bit more. I'll get it at least on github via Alloy at some point.
Thanks for the feedback :-)