On Thu, 22 Jan 2004 21:06:43 +0000 Ryan Boder <icanoop@bitwiser.org> wrote:
On Thu, Jan 22, 2004 at 10:22:59AM +0000, Chris Withers wrote:
The zope-dev list for the development OF zope, not WITH it, so I'm replying to the more appropriate zope@zope.org list...
Oops. Sorry. I was thinking that products were considered zope-dev. I switched my subscription to zope.
the equivalent of a local interface in J2EE. In JBoss I would use a session bean as the remote user interface and it would manage entity beans. So in Zope if I have a non-persistent object as the XML-RPC published user interface, how can I have it access persistent objects within Zope?
This made no sense to me as a Zope developer, and it's YEARS since I did anything EJB'ish. I suggest you try and present the problem you're trying to solve, rather than trying to bash square JBoss concepts into a round Zope hole...
Ok. An example problem I have is that my zope addon will manage tasks in a schedule. There would be a Task object and each time the user wants to add a new task, a new Task object needs to be created in the ZODB.
I would suggest using the CMF (and possibly archetypes) to construct a task type. This can be prototyped as a document with properties probably. Extra methods can be added through skins. The prototype could then be baked into python classes if desired.
I like to have a seperate object that is not persistent that acts as a client interface (client programs can make XML-RPC calls to it). So the client program would make an RPC call such as createTask() and the client interface object would then do the work of creating a new persistent Task object in the ZODB. The client interface object is published via XML-RPC, but the Task objects are not (they are implementation, not interface).
In CMF terms this would be a tool. A tool is a singleton object that exposes interfaces for performing operations in the site. In zope any public method you create will be XML-RPC callable, so you will get that for free (with a couple of caveats).
So I guess the following code would do that in the createTask() method...
afolder = myobject.restrictedTraverse('/path/to/folder/that/contains/Task/objec ts') manage_addMyThing(afolder,'new_id',...any other needed parameters...)
Or you could create a "portal_tasks" tool which abstracts the storage of tasks: portal_tasks.addTask(folder, id, foo, bar) -Casey