Re: [Zope3-Users] searching and relations
Gary Poster wrote: If the relationship is intrinsic to one object's data model but not to the other's, then it makes sense to have a Python pointer on the first object. Hi Gary, Am I right that 'a Python pointer on the first object' is defined by simply defining the schema field, eg:: mypointer = Object( title=Pointer to object, schema=IInterfaceOfTheTarget) Then everything else will fall into place. I could even use formlib to edit the object being pointed to from within a form editing the 'first object'. The second object would not even know it is pointed to. For it to know I would need to use a relationship as you go on to discuss. Have a correctly understood? Regards, Darryl ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Debugging Zope3 with Winpdb
Hi, I try to debug zope 3 with winpdb, but without success. Was anybody able to let zope 3 run within winpdb. Winpdb seems to start my z3.py script but the looses the connection to the process. I see no error messages and I'm quite new to winpdb. Any help would be very appreciated! regards, Achim ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] searching and relations
On Jul 23, 2006, at 4:12 AM, Darryl Cousins wrote: Gary Poster wrote: If the relationship is intrinsic to one object's data model but not to the other's, then it makes sense to have a Python pointer on the first object. Hi Gary, Am I right that 'a Python pointer on the first object' is defined by simply defining the schema field, eg:: mypointer = Object( title=Pointer to object, schema=IInterfaceOfTheTarget) Then everything else will fall into place. I could even use formlib to edit the object being pointed to from within a form editing the 'first object'. The second object would not even know it is pointed to. For it to know I would need to use a relationship as you go on to discuss. Have a correctly understood? Yes, precisely; and for what it is worth, the Object schema value lets formlib work, and specifies part of your software's contract, but is not necessary for the most basic story. The simplest clear case (Where `app` represents some ZODB folder, like the application root): class DemoSubject(persistent.Persistent): pass class DemoObject(persistent.Persistent): pass app['demo'] = DemoSubject() app['demo'].mypointer = DemoObject() By the way, a small but possibly important subtlety about the object widgets that are associated with the schema object fields is that (unless you manage your form pretty carefully) they change value by creating new instances of the sub-object and replacing it on the main object, not by modifying an old sub-object instance, IIRC. Sometimes Choice fields with a custom vocabulary or source are what you want, if you want to make a pointer to an object that already exists somewhere in the database. Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Laying out a Site
I am setting up a site, and have been reading through a couple of Zope3 books and I just want to make sure I have the right general idea with how to set up the site visually. My understanding is the following 1) I create a skin and in that skin a new layer plus the default and rotterdam layers. Then each view I have in the future, I put on the layer for my skin. 2) I create a macro that holds the basic markup for all of the pages. In this macro I have slots for the different parts of the page. I would have slots for the title, meta, style in the header. Then in the rest of the doc I put slots where dynamic content will be going. So for example I would have a main content area, a side bar area and so on. 3) Once I have all these slots set up then I make templates for the different content types I have. So for example in my task there is a Project that has a bunch of attributes. I would create template for a user to view the project. When the user goes to the template for that Project, they see the attributes from the Project displayed per how the template is set up. Is that the right general idea? I have recently heard of viewlets also, does anyone have any experiences good or bad with them? Gabe ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Persistent subclasses in tests
Hi, I've have a problem with the following and I hope someone can shed some light for me, I can't figure out what I am missing:: from ZODB.tests.util import DB import transaction db = DB() conn = db.open() root = conn.root() from persistent import Persistent p = Persistent() root['p'] = p Thats fine, but:: class TestItem(Persistent): ... pass item = TestItem() root['item'] = item transaction.commit() Traceback (most recent call last): File /opt/zope/zope3/src/zope/testing/doctest.py, line 1361, in __run compileflags, 1) in test.globs File doctest README.txt[28], line 1, in ? transaction.commit() File /opt/zope/zope3/src/transaction/_manager.py, line 96, in commit return self.get().commit(sub, deprecation_wng=False) File /opt/zope/zope3/src/transaction/_transaction.py, line 395, in commit self._commitResources() File /opt/zope/zope3/src/transaction/_transaction.py, line 495, in _commitResources rm.commit(self) File /opt/zope/zope3/src/ZODB/Connection.py, line 484, in commit self._commit(transaction) File /opt/zope/zope3/src/ZODB/Connection.py, line 526, in _commit self._store_objects(ObjectWriter(obj), transaction) File /opt/zope/zope3/src/ZODB/Connection.py, line 553, in _store_objects p = writer.serialize(obj) # This calls __getstate__ of obj File /opt/zope/zope3/src/ZODB/serialize.py, line 407, in serialize return self._dump(meta, obj.__getstate__()) File /opt/zope/zope3/src/ZODB/serialize.py, line 416, in _dump self._p.dump(state) PicklingError: Can't pickle class 'TestItem': attribute lookup __builtin__.TestItem failed ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Persistent subclasses in tests
On Jul 23, 2006, at 6:59 PM, Darryl Cousins wrote: Hi, I've have a problem with the following and I hope someone can shed some light for me ... Yup, you need to handle a case like that specially. See zope.testing.module Gary ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] Persistent subclasses in tests
Hi Gary,
Thanks for that. For those who follow
tests.py::
import unittest
from zope.testing import doctest
from zope.testing import module
name = 'tfws.cart.README'
def setUp(test):
module.setUp(test, name)
def tearDown(test):
module.tearDown(test, name)
def test_suite():
return unittest.TestSuite((
doctest.DocFileSuite('README.txt',
setUp=setUp, tearDown=tearDown,
optionflags=doctest.ELLIPSIS
),
))
if __name__ == '__main__':
unittest.main(defaultTest='test_suite')
On Sun, 2006-07-23 at 20:59 -0400, Gary Poster wrote:
On Jul 23, 2006, at 6:59 PM, Darryl Cousins wrote:
Hi,
I've have a problem with the following and I hope someone can shed
some
light for me
...
Yup, you need to handle a case like that specially.
See zope.testing.module
Gary
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users
