#127: Move properties to Edit screen using pre-loaded fieldsets

Contents
  1. Motivation
  2. Proposal
  3. Risks
  4. Progress log
by Alex Limi last modified Jan 21, 2010 07:26 AM

Clean up the UI a bit by moving the Properties to a grouped schemata on the edit screen.

Proposed by
Alexander Limi
Seconded by
Florian Schulze
Proposal type
User interface
Assigned to release
Repository branch
plip127-fieldsets
State
completed

Motivation

Currently, the Properties view on a content object is cumbersome to get to – you almost always want to edit it along with the normal properties anyway – and has become a random mix of items that are not important enough to be on the main edit screen - but are important enough to be on the object itself.

We should consolidate these on the edit screen, and have a clickable legend area that can be used to navigate around the different schemata used to represent the item.

Proposal

  • Merge the dhtml-schemata branch, so we can have schemata without reloading the page (if this isn't already done by the time work on this starts).
  • Improve the look of the schemata selector
  • Group the Properties attributes better, maybe create 2-3 schemata of it if necessary.

Risks

  • There should be little risk involved in this, since the dhtml-schemata branch requires that you explicitly turn it on, thus the few use cases that require schemata 1 to be filled out before you can go to schemata 2 will still work.
  • There is some risk involved with Kupu if we enable it by default, though - there are reported problems since Kupu lives in an iframe. We need to make sure it works, both with editors on different pages and several editors at the same time.

Progress log

All parts of this are implemented in the plip 127 branches of Plone, ATCT and Archetypes.
The dhtml-schemata branch was not used, instead content types can be marked with the IMultiPageSchema interface to keep the old behaviour.
The properties tab was removed and the metadata schema can always be selected on the edit page for old types.
The javascript and css parts in Plone are done.

Comments (3)

Darci Hanning Feb 23, 2006 04:09 AM

I was thinking along the same lines today as created a ton of objects/pages and had to use the Edit and Properties view on each and everyone.

Along these lines, I'd also like to be able to select multiple items from the Contents view and click on a "Change Properties" button much like you can click on a "Change State" button so that the same property values can be applied to several objects at once.
Rob Oliver Mar 17, 2006 12:12 AM
+1 for enabling multiple object edits. Being able to configure effective date, keywords, etc on multiple objects I think would be a boon to Plone, especially with more and more products, etc being able to bulk import.
Martin Aspeli Apr 16, 2006 04:57 PM
Making the 'edit' tab incorporate metadata is a good thing. However, there is a question of where that metadata should come from. To enable site-wide policies for metadata, we should support portal_metadata from CMF, which will allow site admins to specify that a given metadata field should be available (possibly required) for all content types, or only for some content types. Similarly, a tagging or taxonomy solution may need to inject certain metadata into all or some content types.

I would suggest a slightly more generic solution that composes the fieldsets by looking up any number of schema providers for the current context, probably as named adapters. Thus, you could register a new schema provider that provides a certain set of metadata. We would need to integrate this with the validation and storage machinery. Most likely, this would be a generic interface, implemented primarily in Archetypes.