Tabbed separation of content in backend and UI for 1.7

Topics: Core, General
Oct 19, 2012 at 9:07 AM
Edited Oct 19, 2012 at 9:33 AM

A few missing things which we hopefully can implement in V1.7 and a futher disccusion of issue: http://orchard.codeplex.com/workitem/18746

Currently we're are still using Umbraco for 99% of our sites (unfortunately, because I really don't like it. I'm preferring Orchard way more in almost every way!

I'm using Orchard since the beginning (a few years now) but I still can't convince our 'bosses' to make a move to Orchard because of the following points. Pure by features and archtitecture it's a piece of cake to convince them though. 

Hereby the 2 main issues for them with Orchard:

- We have sites with contenttypes/ documenttypes with a lot properties/fields and parts. In Orchard it's not yet possible to split fields and parts/shapes between tabs. (only from controller actions)

- The tree module of bertrandleroy is a good start bug not nicely integrated like we talked about in the last meeting. I don't say a tree is the right solution but it would be nice if you can create sub folders and view the in a integrated way (taxonomies?).

An example which currently can't be done nice for content editors (non technical people) of one of our customers:

http://tweakers.net/ext/f/V2Xh391itxtAVsTXk0TNb9LN/full.png

Every tabs in the screenshot has a about the amount of properties as the first tab

I would really like to help with these points so maybe would could discuss this topic also at the next meeting.

Oct 19, 2012 at 11:15 AM

What does "bedrijfsonroerendgoed" mean? Is that an actual word? :p

I really like the idea of extending the admin placement to include tab support. Maybe placement.info should be able to send stuff into a specific tab as well so modules can have some fields in a tab by default if necessary?

Coordinator
Oct 19, 2012 at 5:27 PM

Totally agree on tabs, and there are bugs open for that: http://orchard.codeplex.com/workitem/18746 and http://orchard.codeplex.com/workitem/18216

I'd also like to see taxonomies replace the current tags as the default structuring mechanism and make it into Core. I'm not sure about the tree however, I think it's fine as a module, but the module could be better integrated, yes.

Developer
Oct 19, 2012 at 6:04 PM
Edited Oct 19, 2012 at 6:04 PM

I too agree on tabs, but the tree in admin is a different thing.

Tabs should be done on CSS/JS level, so the server-side rendering wouldn't need to be touched at all. Eg. we could, by convention, separate top-level fieldsets (or by using attributes, like we currently do with data-controllerid for hiding/showing elements) into tabs automatically.

By how the editor form rendering works, there is no other, easy way to achieve the desired behavior.

Oct 19, 2012 at 7:56 PM

I have been using tabs in my own custom modules for awhile now to alleviate long pages, so I would love this feature as well.

The idea of doing this on a CSS/JS level is a good idea and the least difficult, but it may not give us the flexibility we need in terms of parts being able to participate in existing tabs as well as developers and users being able to override tabs via Placement.info, Admin Placement, or some other mechanism. I'm not saying we need that level of sophistication, but just as I can target parts and fields to new zones via the Layout Placement or Admin Placement, I can see myself attempting to organize fields and parts within tabs independent of what the original developer had in mind. If we can pull that off via CSS and JS great, but I suspect that will require rendering on the server.

Developer
Oct 19, 2012 at 8:17 PM
Edited Oct 19, 2012 at 8:20 PM

Hmmm. I guess it gives as a fair amount of flexibility. If tabs are declared in HTML (using data-* attributes and some JS processing it), then shape alternates will allow you to change almost everything. 

David, I understand what you mean and frankly it's a very good idea too. If we treat tabs as configurable local zones within the editor shape, we could then be able to utilize Placement.info to dispatch certain shapes to those tabs. I.e. doing sth like this :

<Place Parts_EditorShape="Tabs-MySuperTab:1"/>
<Place Parts_OtherShape="Tabs-MyOtherTab:1"/>

That would be super cool and quite easy to implement. The only problem is how and where to define the text displayed inside each tab? We could eg. loop over the shapes inside a given zone (tab) and look for the first shape containing eg. TabText property defined and use that value. What'd you think?

Coordinator
Oct 19, 2012 at 8:19 PM

I concur, very needed, on the front end as well.

The rendering could be done using a new shape, like we did for Zone. Thus it could be themed using different techniques (jquery, html, server side, ...).

Open question is how to handle it on the admin, as parts might be required for the content item, should we render everything and hide the parts using ajax, or render only the current tab but then what would happen in drivers ... I'd rather render everything and use javascript to show/hide the parts editors, as it would break nothing. The front end is a different story and would be customizable as I explained.

Developer
Oct 19, 2012 at 8:25 PM
Edited Oct 19, 2012 at 8:36 PM

@Sebastien Yeah, exactly - the whole editor needs to be a single page with everything rendered upfront. Tabs should be then created from the generated markup, using CSS and JS. Postbacks between tabs are totally out of scope right now, I agree.

Oct 19, 2012 at 9:28 PM

@pszmyd @sebastienros

Local zones within a new "tab" shape sounds perfect. This gives us the flexibility around placement. I am not sure how to best derive the name for each tab, but we have a lot of practice defining metadata (via handlers, interfaces, etc. ) that we can come up with some configurable solution that leverages today's techniques.

Definitely just render everything on the page and show/hide the tabs so we can leverage the drivers like they work today. The only minor issue I have run up against is validation errors popping up on tabs not being displayed. Ideally if postback fails it would be nice if it was obvious which tabs had errors. This may be as simple as adding an "*" to the tab name to indicate an error occurred on it or some other visual indication of where to look for validation errors.

Sebastien will probably have this completed this evening :)

Coordinator
Oct 19, 2012 at 9:41 PM

"Sebastien will probably have this completed this evening :)"

Don't bet on this one

Dec 1, 2013 at 8:15 PM
Has anything happened with this? I've done some googling, and have seen a couple of indirect references to the idea, but nothing that specifically spells this out for 1.7. I have, for example, an "About Us" page that would be really nice if laid out in a tab format. I'd have the general About Us text in the first tab, then three more tabs: "Course Leaders", "Management" and "Contact Us".

It looks like a combination of LocalNav() (from AdminMenu) and Taxonomies could be the way to go, but I've found nothing that really addresses it. Any pointers?