i enter content into the three tabs: Default, Intro, Monthly care. Again, all works and dispalys as would be expected. going back and forth between the three tabs as a test, the text is always displayed properly.
when i save the page, the tabs go away completely and all text shown on one page. The text that should be tabs are shown as Headings of some kind :
I think what you see is the difference between the "edit" and the "display" view:
the edit view presents the fieldsets as tabs, the display view as sections.
Fieldsets in "view" mode are being rendered on the same page and not as tabs in the "edit" mode.
If you need something different then you have to override the view or rewrite the DOM with Javascript.
In my opinion tabs are a bad UI (whether on the edit form or not) because if the contents of a tab is long enough, the user gets to the bottom and doesn't remember there are more tabs (have you ever clicked save and gotten a validation error because there was a required field on a different tab?). And on mobile you can't fit very many tabs horizontally. On one site we replaced the tabs on the edit form with an accordion:
@dieter
Showing tabs to the person editing is great - makes editing easy and won't see and thus can't mess up any code. However, not showing the tabs to the reader I think that is a bug (or a least a bad design decision). what do you think?
When I create a content type with tabs, the expectation is the user will see them.
This is in general nonsense. Editor and site visitors are usually distinct groups and editing a bunch a fields is usually a different problem from rendering a bunch of fields in a nice and consistent and meaningful way.
So then the answer is that it should be developer selectable. Either to show tabs or accordions in both edit and view, or perhaps have another "view" grouping concept so fields can be displayed differently from how they are edited.
When I created the Dex CT, I chose tabs for a reason. For Plone to decide to show them to editors but not viewers isn't a design decision that I support. However, that's what we have.
So, I will have to create a modified user view for this Dex CT to show the tabs.
What should have been a 10 minutes job for an semi-experienced site admin (create this simple CT) in Dex is impossible for a typical Site Admin for two reasons: 1) I had to know the need to edit the code because Dex can't handle fieldsets properly (after creating a fieldset any fields added to the fieldset go into the main page because the xml isn't correct). Also, knowing the quirk, I needed to be able to edit the xml. 2) after creating a tabbed CT, it doesn't work because the view for editor and viewer are different.
This simply makes the Site Admin look foolish. User asks: "why can't I have this simple page with tabs". Site Admin: "Oh you can, if I can get budget to hire a Plone programmer to make it work". Remember, no one likes to be made to look stupid or incompetent.
If anything here is 'general nonsense' , I'm not sure it's my expectations.
If you need a different view and a different look and feel then you need to create different view. The standard field-below-field is a generic approach. Even more complex views like the Event type uses a different made-made layout. Why? Because every content-types needs its own representation. Simple example: addresses with zipcode and city fields. In the edit view you want both fields to be editable separately. Inside you want both informations rendered side-by-side instead of city below zipcode...generic vs. nice representation. In general: Dexterity supports only group by fieldset. In reality you need group down to three level:
fieldsets
grouping of fields within a fieldset (e.g. 'addresses' fieldsets with subsets for private and business address)
"horizontal" grouping of fields (e.g. zipcode + city)
You can not implement this with Dexterity. That's why I went with VueJS and Vue Form Generator:
Not the solution for all and everything...but for the rendering part (view mode) I will be using client-side JS rendering where each fieldset can have a configurable template (likely based on Nunjucks).
You have valid points but you are complaining that you don't get what you want just because a generic rendering is only half of the solution. If you need something fancy then you have to write it or find some to implement it for your...this is not much different from other CMS...or take Wordpress and have fun with the administrator fiddling in some templates...
Andreas is correct but you are right in saying that it should be made clearer in the documentation that schemas don't give you much control over view layout and you will need to switch to code for that. Note however
Mosaic is designed to make this step easier (but not sure it has a solution for fieldsets actually)
themefragments or rapido is designed to make this step easier (still have to code but amount of code is less).
But our documetation should catch up. If you can find where in the documentation you would have expected to find this out, please submit a bug report.
Mosaic does not give you control over fine-grained layout of a content block...this is either up to a custom implementation or perhaps a ruleset in Diazo or using client-side rendering.
I am not aware of such a bug...I fiddled a lot with fieldsets lately - both on the FS and through the Plone UI..XML is at any point validated correctly from the syntactically point of view (not from the semantic point of view). There should be really schemas or DTDs for all XML configuration in Zope and Plone in order to validate the configurations semantically which would reduce some error sources.
What you see is the behaviour considered adequate for the built in Plone content types. Those content types have a lot of fields: beside the typically used fields there are rarely used control fields and fields for classification. The tabs in the edit views primarily hide the mass of fields relevant only for special purposes. A display view can reduce complexity in a different way: it can suppress fields which do not have a value; it can suppress control fields.
Apparently, this reasoning is not applicable in your case. Sadly, this may mean that you need a special display template. I may not be difficult to achieve what you need (look at Espen's answer to your problem).
I don't think I'm complaining - I tried to make clear that my issue was I didn't expect the behavior I got from view. And yes, I disagree - doesn't mean I'm right.
I've been part of UI groups on many different software and I realize you can't please everyone. One path is chosen that in the judgment of experienced people works best. Plone UI represents a lot of hard work and I think they've done a great job. Thanks. Period.
Thanks to you folks for pointing me to solutions - I appreciate that. Let's let this rest is peace.
I'd only like now to focus on what I think is a bug in Dex. Note: as I remember this was confirmed a long time ago when I spoke with @cewing
What I did: in dex: create new CT; create fieldset; click on tab for this new FS and add field. Repeat for second FS. This is the schema: Note both FS are empty. Please let me know if I am missing something or if this is a bug and confirm the above link is proper place to put bug report.
Also, attached is what a new instance of the CT looks like
I agree and you've nailed the problem. However, this is the xml produced by Dexterity - unaltered by me.
Knowing this, do you think this is a Dex bug I should report? I'm asking because you and the others on this thread a more experienced than me. Before I report what I think is a bug, I like to get confirmation. (Had I reported the issue of the tabs as a bug, I would have created extra work for the volunteer maintaining Dexterity. I don't want to do that)
You're deep enough into hunting the source it'd not hurt to just post the issue and see if it sticks. If it's a classic user error - wontfix, at least you'll know what it was.
