Fat client thoughts, was: RE: [Zope] Zope + XML-RPC + native GUI

[sean.upton@uniontrib.com]

No, I haven't done this, but I plan to do something like this to create a
fat client to interact with content objects in a CMF site I am building.
I've been playing around with wxPython and Boa Constructor
(http://boa-constructor.sourceforge.net).  I'd be interest in finding out
ways in which other people might be creating apps using these tools.

Something that would really help in this arena is some stock tools for doing
this quickly using Boa Constructor, as well as some basic coding standards
(perhaps via defining component interfaces) for people creating content
types/product classes that are interface-compatible with said components.  I
imagine the Zope side of this could be accomplished with a mixin class that
implemented said interfaces for you to make it easy for product authors to
make their product work with a stock GUI toolkit.

The ideal setup would enable the drag-and-drop rapid creation of GUI apps in
a tool like Boa, and this would in turn allow for many interesting
applications - ones that wouldn't have to reinvent the wheel to create the
glue code for a GUI fat-client app that uses Zope as a data store and/or
some sort of middleware.

One thought that I had was that it would be nice to create generic
data-source and data-access components, similar to what Borland Delphi has
for relational databases, but for accessing an individual content object
within a path in Zope:
- the DataSource (called ZopeDataSource?) is the URL of the content-object,
the DataSource object would have a datasync() method, which would sync all
data components/widgets mapped to particular data write/set methods in the
Zope object by calling those methods within a single transaction.  The
DataSource would also contain an optional object for holding read-only
Dublin Core metadata for CMF content objects.  The DataSource would also
have a variety of Dialog box functions for handling server-generated
exceptions.
- a data-enabled text box widget can have a mapping to 2 method names (one
for read, other for write)
- a data-enabled combo/drop-down widget can have a mapping to read/write
methods, and also a mapping to a method for populating a dropdown list
- a data-enabled multiple selection listbox item that works generally the
same way as a combo box above
- a data-enabled radio-button group has mappings to read ("get selected
value") and write methods
- a data-enabled checkbox component that has read (isChecked) method and a
write method
- a data-enabled table widget that can be populated with a sequence of
sequences, and saved by writing a new sequence
- a data-enabled date selection / editing widget that works with Zope
DateTime objects, read/write method mappings
- a data-enabled tree widget for values of an ObjectManager derived item, so
that contained objects can be edited, uses stock objectIds() and
objectValues() methods; this could, in theory, display icon images the same
way Zope does in a browser.
- a data-enabled image widget that would read a Zope image object, and
provide an image view, and support a replacement image upload.
- a data-enabled memo widget, with support for editing both plaintext or XML
in a ParsedXML document
- Widgets would have a means of enforcing data-type for robust applications
- Eventually a table widget for browsing multiple content objects within a
ZCatalog Query result or ObjectManager item listing would be nice, as well
- In theory, these widgets could also be used (somehow?) for relational data
through Zope via ZSQL methods?

It would be nice, in the above scenario, to be able to change a bunch of
fields in an object in a single transaction, but I'm not sure how easy this
would be...  I imagine that there would be a way to marshall a bunch of
method calls (map the method names and parameters into a dictionary or
something along those lines?) into a single method call (hypothetical
ZopeDataSource.datasync() above), and encapsulate the change to a single
object within one XML-RPC based transaction.

A cross-platform fat-client toolkit would be a real help, especially for CM
sites, where there is often a need for more advanced data-entry bells and
whistles you cannot get from an HTML form (spell checking, better layout,
hotkeys, tab-order, more interactive interface, better dialog boxes).  I
really think a toolkit of this variety would be just the kind of thing that
would help Zope's use become fairly widespread for a completely different
classification of application, as well as increase Zope's appeal as a CMS
platform.

Anyway, these are my thoughts... any comments?

Sean

-----Original Message-----
From: Thomas Guettler [mailto:zopestoller@thomas-guettler.de]
Sent: Monday, January 21, 2002 8:36 AM
To: zope@zope.org
Subject: [Zope] Zope + XML-RPC + native GUI


Has anyone developed an application using a native GUI Frontend to Zope?

I had this idea some time ago and found an interessting example from 
Amos Latteier.
He uses xml-rpc and WxPython. I like it a lot, played with it this weekend.

Has someone seen other projects using Zope and a native GUI?

 thomas


_______________________________________________
Zope maillist  -  Zope@zope.org
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )