[Framework-Team] Re: PLIP 236: Move Display menu to edit and allow for custom properties

2008-10-09 Thread Martin Aspeli

Wichert Akkerman wrote:


First: remove the Display menu and add a field to the settings tab of
the edit form where it belongs.


-1 for 3.x.

 - This breaks existing documentation and expectations.

 - The display menu is not specific to Archetypes or any particular 
content type implementation. We shouldn't tie this to AT (or any other 
content type framework).


I think we should revisit this for 4.x, though. I agree that it belongs 
on the edit screen. In fact, we looked at doing that for 3.0, but 
decided it wasn't worth it for the reasons above.



Second: a Display view should be able to provide a custom property sheet
that is loaded into this settings form whenever you pick a display type.
These properties give the user options to set parameters for the chosen
view. A thumbnail view for instance could provide an option telling how
many thumbs are shown. The point is that you don't know this in advance
so the view should somehow provide this property sheet.


That'd be really nice. Ironically, that's easier to do if we keep it in 
the menu (or you'd need pop-ups or complex widgets on the edit screen).


Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] Re: PLIP 236: Move Display menu to edit and allow for custom properties

2008-10-09 Thread Danny Bloemendaal


On 9 okt 2008, at 11:32, Martin Aspeli wrote:


Wichert Akkerman wrote:


First: remove the Display menu and add a field to the settings tab of
the edit form where it belongs.


-1 for 3.x.

- This breaks existing documentation and expectations.


Mmm.. change the docs then ;-)




- The display menu is not specific to Archetypes or any particular  
content type implementation. We shouldn't tie this to AT (or any  
other content type framework).


Who is talking about that? An end user has no notion of AT whatsoever!  
He sees a settings tab in the edit form and there is where this option  
needs to be. (Just like wf-transitions need to be part of the form and  
they aren't related to AT either). Right now I see the display setting  
of certain folders change almost on a daily basis becuase people think  
they can use it to fit there current, temporary needs. And I can't  
blame them. That thing is wrong there.


There are a lot more attributes/properties on AT objects that control  
settings. Why not add the Display value as well to the object? You  
give it the settings schemata value and you are done. You only have to  
change the lookup code (with a fall back to the old location where  
origionally the display value was stored if it is there while the  
field is still None so you don't need any migration). Just be  
creative ;-)


Danny

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team