or maybe allowing an option that turns on advanced panels(or at least a
way for addon developer create some sort of navigation to advanced
options they may add).
re: zmi. lets talk about being painfully modal. The fact we are having
this conversation seems to indicate a different and wider issue to me.
the argument that we are now using the zmi by design really rings hollow
for me. Though I strongly support generalizes ui that works with or
without plone, I'm not sure designing in any more context switches into
plone is at all a good idea. Let's keep people in the application or on
filesystem, not rummaging though our hot nineties legacy layer.
Context switching has almost always been an unfortunate bump on our
learning curve for Plone. Just having to explain navigating the zmi
increase our support burden. People should design good configuration
uis, not just stick badly drawn ones in the zmi.
There are options that make more sense in a plone setting even if not
for the more general day to day site admin tweaks. addon authors will
add their own control panel regardless of what we say the right way is,
so I would vote for giving them a more appropriate place to do this
(with wicked, I see plenty of fertile options that I'm not at all
interested in building zmi pages for but are definitely not basic
configuration options).
we are also moving into a time where control panel style UIs make sense
at any container level, not just the portal.
with these things in mind, we may need to rethink the application of the
pattern we use in plone.app.controlpanels so it can be easily reused for
things like advanced options or container level configuration. This
seems like the right direction, rather than claiming the inevitable use
of better technology as wrong by decree and advocating a return to the
bonny days of 1999.
long live frames!
-w
--
------ d. whit morriss ------
- senior engineer, opencore -
- http://www.openplans.org -
- m: 415-710-8975 -
"If you don't know where you are,
you don't know anything at all"
Dr. Edgar Spencer, Ph.D., 1995
_______________________________________________
Framework-Team mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/framework-team
