Hi Ryan, The zope-dev list for the development OF zope, not WITH it, so I'm replying to the more appropriate zope@zope.org list... Ryan Boder wrote:
I would like to stop developing with JBoss and convert to Zope.
Good for you ;-)
The majority of my code was in EJB's. So I am trying to create Zope products to replace them.
That might not be necessary, but there's nothing wrong with it ;-)
What kind of naming service is available within Zope? For example, how can I get a reference to one object from another object within Zope?
All objects are refered to by their paths in the ZODB. To get from one object to another, you may want to try: myobject.restrictedTraverse('/path/to/another/object')
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...
How can I create new objects programmatically in Zope?
Depends on what type of code you want to create these objects in, what you want them to do, and what type of objects they are...
In J2EE I would get get a home interface to a bean and then call a create method on it to create the bean. I know how to create new objects using ZMI in Zope, but I need objects to be created through remote calls from clients. For example if I had objects that represent tasks in Zope, I need the clients to be able to create and delete tasks. How do I do that?
If you're doing everything as Python Products, then you write a construction method, usually called manage_addMyThing, import that where you want to create your object, and then use it: from MyProduct import manage_addMyThing ... manage_addMyThing(afolder,'new_id',...any other needed parameters...)
Are there any other gotchas that ex J2EE developers can tell me about switching to Zope?
Yeah, Zope is not J2EE. Trying to think in J2EE terms and make those concepts work in Zope will only lead to pain and suffering for you and anyone who tries to help you ;-)
I've read all the documentation I can find on the web site,
I doubt that ;-) Zope Book? Zope Developers Guide? ALL the How-To's and examples? The website is difficult to navigate, and I apologise for that, but the stuff is on there... cheers, Chris
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 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). So I guess the following code would do that in the createTask() method... afolder = myobject.restrictedTraverse('/path/to/folder/that/contains/Task/objects') manage_addMyThing(afolder,'new_id',...any other needed parameters...) Is this a sane design in Zope or am I thinking in J2EE?
I've read all the documentation I can find on the web site,
I doubt that ;-)
Zope Book? Zope Developers Guide? ALL the How-To's and examples?
The website is difficult to navigate, and I apologise for that, but the stuff is on there...
Yes, yes, and quite a few. -- Ryan Boder http://www.bitwiser.org/icanoop
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
participants (3)
-
Casey Duncan -
Chris Withers -
Ryan Boder