[Zope] Prerequisites for a desktop IDE, or any desktop app w/ Zope

[sean.upton@uniontrib.com]

The recent IDE thread has sort of got me thinking about my ideal vision of
what Zope could do for and be to developers in the future, so perhaps my
quirky visions here seem a bit ambitious, so take what I'm saying with a
grain of salt (or a Tablespoon if you prefer)...  So perhaps this message's
subject might be best written as: Sean's Crazy Zope Wishlist...

here are some random thoughts re: IDE for Zope... this message is long, so
here is a summary:

1. create generalized toolkit/class library for desktop access to Zope; use
wxPython... Work should be used for basis for IDE and a whole new generation
of cross-platform desktop applications using Zope as a middleware core,
expanding what Zope is used for, and the market opportunities associated
with it for developers and vendors...
2. IDE should have ability to checkin/out stuff from server Products dir via
FTP, as well as ODB; code should be synced from IDE/workstation to CVS, and
also to Zope server for testing snapshots.
3. IDE should allow for unit testing of python classes using local python
installation, and also facilitate debugging using python on server after a
sync of code.
4. I'm not sure I would pay for an IDE versus using traditional tools, but I
WOULD PAY FOR CASE TOOL INTEGRATION.  I want forward/reverse engineering
from UML; this would require the ability to have the CASE tool plugin
cooperate with changes/evolution in Zope and any "standard" IDE, which means
there is a sale-plus-subscription business model for this (for DC or another
vendor to sell to ISVs?). Do this, and watch to "Enterprise Java" folks be
converted - they really want to code in python, they just don't know it yet.
;)

Anyways, if you aren't already bored to tears, read on...
------

Zope, via XML-RPC, could be a very good platform for creating an extensible
toolkit for desktop access to Zope, wrapping XML-RPC calls to Zope machinery
to do certain tasks.  Such an abstract toolkit might provide a decent
foundation for an IDE, but would also serve the purpose of allowing folks to
write "desktop" (really: client/server) programs that interface with the
Zope/ODB rather transparently by using the some prebuilt toolkit classes and
basic-auth-wrapped python XML-RPC library.  I could imagine having prebuilt
library functions for Zope access (a desktop application that has a concept
of a user-login and session, a URL, etc), admin (pack db, restart,
backup/export object hierarchies to a local file), development (ftp
checkin/checkout of code from Products directory on server, source/property
editing of TTW objects), and general use (bound data controls - widgets like
text boxes that are bound to a particular class definition, and represent
members of instances of those classes, for example a widget has an
associated get and set method within a class that it gets its text from and
sets upon changes).  Perhaps I'm dreaming here, but I really want to extend
what I am doing in Zope in the future into cross-platform desktop
development efforts.

The rationale for desktop apps to be built with Zope is exists because:
1 - Data Entry: TTW editing is not always ideal; if I was building a
content-system, for example, like a newspaper library system, Zope is an
ideal platform for an asset-management system/content repository. But that
task also involves a lot of editing, and the librarian will want to have
hot-keys to modify content and navigate an entry-screen, it would make sense
to make this a desktop app, as that kind of flexibility is not afforded by a
browser and html forms.
2 - Current Desktop Client/Server apps are stale: Isn't the idea of ODB
integration with desktop apps more exciting than standard 2-tier RDB apps?
Wouldn't middleware based on lightweight, commodity technologies (http,
xml-rpc, open source server software) like Zope make sense for the new "web
services" paradigm?
3 - Zope has potential as an enterprise data-center mainstay, not just as a
web-only application.  This expands the market for Zope and vendors working
with Zope, as well as expands the Zope community.
4 - Commodity internet technologies, especially with open-source cores,
provide what might just be the core for the next generation of enterprise
applications (both web-based and desktop c/s), especially in heterogeneous
content environments (like publishing/media companies using something like
this for the database core for print and online production systems).
5 - There is a market justification for vendors to sell more integration
services to 2 market vectors (enterprise and web development), in both
content-management and other verticals for which Zope might excel as a good
development platform for a back end.  In the newspaper editorial and
asset-management systems business (I used to work for a vendor in this
industry), for example, there is a great deal of talk about convergence and
formatting-neutral content storage databases at the center of web and
desktop apps; a lot of app & services sales within these markets are 6 to 7
figure sales to media companies, so there is opportunity, not in just this
industry, but other content-heavy industries (medical, legal, etc) as well -
for the same types of "integrated" solutions with a single
commidity-web-based core, with desktop and web apps surrounding it.

I'm currently doing a bit of playing around with wxPython, which reminds me
a lot of my days programming with the Borland OWL class libraries, so I
might be partial to such a solution using wxPython instead of tkinter (tcl
interpreter - blech!  motif-style widgets - yuck!).  An IDE built with a
decent (modern) widget set / UI class library, with extended toolkit
functions, like data-bound controls, might make for an interesting
user-extensible means of creating custom-tweaked IDEs, not to mention other
desktop software that accesses Zope...

I guess what I am saying is that we might as well have a toolkit for
building desktop apps and kill two birds with one stone here if there ends
up being any sort of IDE project.  I also think that choosing to use a
modern cross-platform desktop class library like wxWindows with wxPython
might be a better choice than mozilla/XPCOM or tkinter...

In addition to remote object/method calls, ability to sync local code done
in the IDE with both a CVS server (whenever), and with the Zope server (on
production/snapshot releases) via FTP would be good. 

The IDE should allow unit-testing and debugging using a python shell and a
local python.  The IDE should also automate the ability to telnet to the
Zope server to do integration testing and verification using the python on
the Zope server.  I do this now with Idle on the Zope server via a remote
X-Session (not entirely graceful, but it works).

In addition to an IDE, I want to be able to have some good guidelines and
documentation for standardized UML in Zope, so that when I share designs
with colleagues, I don't have to use a ridiculous amount of my own flavor of
stereotypes, just because I don't know any better.  Once I have that, I want
CASE->CODE->CASE tools with an existing tool (even if it is a Visio
extension hacked with VBscript), but perhaps I am pushing my luck there.  I
just think that provided the ability to use standard editing tools, I would
feel good to have the ability to do forward/reverse engineering from UML
models.  Such a tool might get some Java developers to jump ship.  I might
not pay for an IDE, but I WOULD PAY $$$ for a plugin that does
forward/reverse engineering with an existing CASE tools (ObjectDomain,
Rational Rose, Visio2k, etc).  These are high-end tools that would likely
only be used by a smaller group of folks than Zope's general audience,
which, I assume makes this more ideal for a standard commercial software
paradigm.  Such a product would need to be able to change with
changes/evolution in Zope, which means that a buy-once, buy a support
contract for free updates would be a good model for anyone creating such a
tool.  Also, you keep the barrier to entry low for development in
open-source projects built on Zope because you can always have folks without
these tools submit patches, participate in development, and view a PDF or
JPG of the UML diagrams if they so please...

Sean

=========================
Sean Upton
Senior Programmer/Analyst
SignOnSanDiego.com
The San Diego Union-Tribune
619.718.5241
sean.upton@uniontrib.com
=========================