[Checkins] SVN: Sandbox/jens/zmi.core/trunk/docs/thoughts.rst HTML style wish.

Charlie Clark charlie at begeistert.org
Wed Nov 16 22:53:45 UTC 2011


Log message for revision 123392:
  HTML style wish.

Changed:
  U   Sandbox/jens/zmi.core/trunk/docs/thoughts.rst

-=-
Modified: Sandbox/jens/zmi.core/trunk/docs/thoughts.rst
===================================================================
--- Sandbox/jens/zmi.core/trunk/docs/thoughts.rst	2011-11-16 22:53:28 UTC (rev 123391)
+++ Sandbox/jens/zmi.core/trunk/docs/thoughts.rst	2011-11-16 22:53:45 UTC (rev 123392)
@@ -3,25 +3,25 @@
 
 Assumptions and scope
 ---------------------
-The following points are not meant as exact definitions, they are more 
+The following points are not meant as exact definitions, they are more
 of a brain dump and starting point:
 
-* The ZMI is meant to support administering and developing Zope 
+* The ZMI is meant to support administering and developing Zope
   applications, especially server-side debugging and introspection.
 
-* The ZMI is not meant as a generic UI for administering applications 
+* The ZMI is not meant as a generic UI for administering applications
   or entering/editing data in an application.
-  
-* Request debugging by interception of application requests is not a 
+
+* Request debugging by interception of application requests is not a
   goal, but the ZMI can support integration of such tools.
 
-* Day to day application administration tasks should never be dependent 
+* Day to day application administration tasks should never be dependent
   on having the new ZMI around. Applications must remain usable without it.
 
-* The ZMI must always function when needed, even if an application's own 
+* The ZMI must always function when needed, even if an application's own
   views are broken.
 
-* The ZMI is not meant to provide full backwards compatibility with 
+* The ZMI is not meant to provide full backwards compatibility with
   the old Zope 2 ZMI.
 
 
@@ -30,7 +30,7 @@
 * ZODB (Caches, Connections, ...)
 
 * ZODB browsing (selection of attributes, readability, "broken" objects).
-  This needs UI TLC to become/stay usable, and documentation of underlying 
+  This needs UI TLC to become/stay usable, and documentation of underlying
   concepts and goals to enable future development
 
 * ZODB history
@@ -48,7 +48,7 @@
 
 * profiler
 
-* Zope 3 components without their own UI (generations, registry 
+* Zope 3 components without their own UI (generations, registry
   introspection, etc)
 
 * code browser??
@@ -64,11 +64,11 @@
 * single request debugging (request logs with complete request/response
   information, performance stats, profiling, other code logging output,
   post-mortem debugging (like WebError). This can potentially be extended
-  by application-specific debugging information. This kind of debugging 
-  should be enabled from the ZMI and singe request overlay mechanisms 
+  by application-specific debugging information. This kind of debugging
+  should be enabled from the ZMI and singe request overlay mechanisms
   should be available alongside a central UI.
 
-* content adding is application-specific. The question what support 
+* content adding is application-specific. The question what support
   to offer from the ZMI is not solved.
 
 
@@ -79,12 +79,12 @@
 
 Non-functional requirements
 ---------------------------
-* The ZMI should be resilient in the face of application issues ("broken" 
+* The ZMI should be resilient in the face of application issues ("broken"
   objects, application errors, missing filesystem code)
 
 * simple code
 
-* generic UI (like SmallTalk), but no attempt at "one size fits all" like 
+* generic UI (like SmallTalk), but no attempt at "one size fits all" like
   Plone
 
 * easy pluggability for additional ZMI views
@@ -102,14 +102,16 @@
 
 * generic object traversal independent of URL space and application code
 
-* the views should have as few dependencies (e.g. form library 
+* the views should have as few dependencies (e.g. form library
   dependencies) as possible. It should run without requiring extra
-  installation or configuration steps past installing the egg and 
+  installation or configuration steps past installing the egg and
   calling up the views.
 
-* translations are supported by wrapping user-visible messages as 
+* translations are supported by wrapping user-visible messages as
   TranslationStrings in a shard translation domain ("zmi").
 
+* HTML should be cleaned up when writing new views, preferably using HTML 5
+  semantics.
 
 Starting points
 ---------------
@@ -124,7 +126,7 @@
 
 Current ZMI views brainstorming
 -------------------------------
-* It's not clear how to convert the "Add list" in the old ZMI. The new 
+* It's not clear how to convert the "Add list" in the old ZMI. The new
   ZMI may have to provide a way to register "addable" items.
 
 * The "Contents" tab is application-specific. Its replacement is a
@@ -133,17 +135,17 @@
 * It's not clear how to handle "virtual" items that don't really exist in
   the database, such as the ''/temp_folder''
 
-* The "View" tab is useful for developers, they can jump to the public 
+* The "View" tab is useful for developers, they can jump to the public
   view for an object.
 
-* The PropertyManager "Properties" tab is an older Zope 2 API with an 
-  unclear future status. Most developers have moved to store attributes 
+* The PropertyManager "Properties" tab is an older Zope 2 API with an
+  unclear future status. Most developers have moved to store attributes
   in a different way, meaning their owbjects provide built-in views
   for them already.
 
-* The "Security" tab will continue to be available as a "read only" view 
-  to show a security profile for the given context. It should retain the 
-  current functionality of allowing user name input to show rights for 
+* The "Security" tab will continue to be available as a "read only" view
+  to show a security profile for the given context. It should retain the
+  current functionality of allowing user name input to show rights for
   specific user accounts for the given context.
 
 * The "Undo" tab will remain; having some ZODB transaction log is already
@@ -158,16 +160,16 @@
 
 * The "Find" tab should become part of the object browser.
 
-* "Edit" tabs are application-specific, they must be provided by the 
+* "Edit" tabs are application-specific, they must be provided by the
   applicaton developer.
 
 * The "Proxy" tab for setting proxy roles on an object will not be
   supported.
 
-* "History" is an application-specific tab, so it's not part of the 
+* "History" is an application-specific tab, so it's not part of the
   core package.
 
-* Nearly all views from the Control_Panel should be reimplemented as 
+* Nearly all views from the Control_Panel should be reimplemented as
   part of a new ZMI.
 
 



More information about the checkins mailing list