[Zope3-dev] Making Zope3 more (newbie) developer friendly

[Shane Hathaway]

Sidnei da Silva wrote:
> On Tue, May 31, 2005 at 09:37:32AM -0600, Shane Hathaway wrote:
> | I have only GUI code so far, because in this project, I want the UI to
> | drive the requirements.  I'm thinking about the code behind it now.
> 
> Ok. What are you using for drawing the UI? I just googled for wxGlade
> but it seems like it just generates code and doesn't save in glade's
> xml format (which would allow for sharing the UI design between
> wxpython and pygtk).

I'm using XRCed, which comes with wxPython.  I was planning to be
selfless and use all-inclusive technologies like anygui, XUL, or AJAX,
but I finally decided that I was wasting a lot of time and I needed to
selfishly use the technologies I like the most (or dislike the least.)
;-)  Also, now that wxPython 2.6 is out, I can safely depend on the
latest features.

Once I decided on a GUI, it took me hardly any time to get past the easy
GUI stuff and start to think about the real requirements for a good
software configuration browsing/editing session.  It may turn out that
you can browse/edit configuration just fine through the web, but I find
it a lot easier to discover requirements if I assume that it *won't* be
done TTW.

Here are some of the less obvious requirements I've discovered so far:

- The configuration editor should be useful for fixing a broken
configuration.  Imagine a new Zope user starts one of Stephan's
tutorials, but misspells a Python package name, and wants more help than
a traceback for fixing the problem.  The user launches the configuration
editor, which points out the problem and makes it easy to fix it.

- The configuration editor should work even if the user has written
crashy code.  Therefore, the GUI code should not directly import any
possibly unstable Python modules.  Unstable Python modules could change
stuff they shouldn't, segfault, start infinite loops, etc.  Virtually
all new code is unstable.

- Users should be able to save a broken configuration.  Imagine how
annoying a Python code editor would be if it didn't let you save your
Python module unless it passed some checks.  The same principle applies
here.  Saving broken stuff is an essential part of a normal development
workflow.

Shane