The script catches all responses to Umbracos own editor view, and by string manipulation substitutes Umbracos umb-tabbed-content directive with my own directive, called matryoshka-tabbed-content.
TRACK ACTIVE TAB PRIMEFACES TABVIEW HOW TO
There is an article here, describing how to do that. To do something like this, the first thing you do, is to inject an interceptor script into Umbraco using a package.manifest. In the process, I made it into my own thing. I tweaked it here and there, to make it look more like the tabs used on dashboards - and made the tab bar disappear if the document type only had one tab. Since I wanted groups inside my tabs, I couldn't have the tabs visually sticking to the property panes, so the first part was some CSS changes to Tabify. So I set out to make the best of both worlds. Then make it better (at least in my opinion) The description even suggests the ability to kill of tabs with limited number of properties. I then remembered how I previously made faux groups of properties in v7 using a package called CM.Seperator by Rasmus Fjord. This time it felt better, but I still missed my super focused groups of properties. And Tabify had gained popularity, and I tried it out again. It got turned down, with the suggestion to clone the project and maybe release something brand new.Īfter the first few builds on Umbraco 8, without using Tabify, the groups started to annoy me. I suggested a way to control the tabs in another way, so I could have both. And I was reluctant to replace such a crucial part of the CMS with a third party package.
It has since evolved, to completely substitute the editor view in the backoffice, for a tabbed interface.Īt first I wasn't sold, I still liked the new possibilities groups gave me. Originally a content app with the sole purpose of manipulating the HTML in the backoffice to get our beloved tabs back. Sebastiaan Janssen came to the rescue with his Cultiv.Tabify package.
That way the user had a quick way of navigating to specific parts of the document. Right before the 8.0 release, HQ was kind to put a band-aid on the problem, by adding a dropdown navigation to the Content app. And since Content Apps can't edit the content (parts of the community call them Context App for the very same reason), they are really not a good fit for that use case. Usually the content inside those properties are needed when rendering eg. The first two is right - they really should just be content apps.
Analytics graphs, static content information, SEO properties and settings were mentioned. Where I previously had a Settings tab for things like URL naming, visibility and other stuff, I could now have a group for each thing.Īnother argument for the groups, was that a lot of the properties we were used to create in earlier versions, didn't belong in the document type anyway, but in a Content App. The thing I liked the most about the groups, is that you could create more focused groups of properties, without sacrificing horizontal real estate on the screen. In addition to that, you were almost certain to get arm injuries resulting from extra vertical scrolling through the properties you need to edit. The groups were especially supposed to aid the new split view feature, for editing multiple languages at once, and while it probably does that, you still end up with two editor panes out of sync, as the scrolling isn't synchronized, and the onscreen height of the different properties could still differ between languages. And of course, the argument to rule them all, tabs was what "we" were used to. But the were equally good when it came to the overview of the structure the document, and easier navigation to the different parts. Tabs might have been flawed in the potential tab overflow, where you have more tabs than your viewport width can contain, or when you have validation errors buried inside of "unused" tabs. After all most document types I build are simple in terms of the amount of properties, and I didn't want to let edge cases decide the design. A huge thread on Our was started, in which community members giving their input on pros and cons about the new and the previous document type navigation.įor my own sake, I was unsure about the change, but willing to give it a chance. Long before the official release, discussions on this change started. A decision probably made with all the best intentions. Instead Umbraco opted for a single view of properties separated into distinct groups. With Umbraco 8, the notion of separating document properties into tabs were no longer. But another big change has since kept the community discussing.
Language variants, infinite editing and content apps. With that release, 3 new features were key the selling points. It has been almost a year since Umbraco 8 got released.
0 kommentar(er)
