[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