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 )