[Zope3-Users] How to resolve bi-directionally navigable association?
As the subject sais, how can I resolve bi-directionally navigable association in Z3? Both objects have to have references of each other, that means that also the schemas have to have references. class IItem(interface): unit = Object( title=u"Unit", description=u"Unit", required = False, schema=IUnit) class IUnit(interface): item = Object( title=u"Item", description=u"Item", required = False, schema=IItem) but obviously that does not work, I cannot define one before the other. The only way I found is defining a dummy interface before the other: class IUnit(interface): pass class IItem(interface): unit = Object( title=u"Unit", description=u"Unit", required = False, schema=IUnit) class IUnit(interface): item = Object( title=u"Item", description=u"Item", required = False, schema=IItem) Is there any better solution? -- Best regards, Adam mailto:[EMAIL PROTECTED] ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] How to resolve bi-directionally navigable association? (Corrections)
Corrections: Monday, August 8, 2005, 11:45:56 AM, I wrote: > The only way I found is defining a dummy interface before the other: Actually that does not work, because the dummy IUnit and the real IUnit is not the same and IItem stores the wrong one. This failes on validations. Now I don't have any more ideas, please help. -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] practical example of migrating from services to utilities
Hey all, I just wanted to check to make sure I was doing this right, and if so, provide a resource that would turn up on subsequent googling. This example involves the getting menus items with the getService/getUtility functions and is taken from Philip's worldcookery example code. Here's the pertinent zcml (worldcookery/browser/configure.zcml): Here's the original code (worldcookery/browser/recipe.py): def alternateViews(self): menu_service = zapi.getService(servicenames.BrowserMenu) menu_id = 'alternate_views' return menu_service.getMenu(menu_id, self.context, self.request) Here's the modified example that I'd want to check if I am doing correctly: def alternateViews(self): browser_menu = zapi.getUtility(IBrowserMenu, 'alternate_views') return browser_menu.getMenuItems(self.context, self.request) Am I doing this properly? Thanks! d ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re[2]: [Zope3-Users] How to resolve bi-directionally navigable association?
Hello Douglas, Monday, August 8, 2005, 5:53:54 PM, you wrote: > Adam: > You should look at the Zope 3 Developer's Handbook. Maybe this part: > 13.3 Step III: Writing the interfaces > http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Book/contentobject.html > could help you. As you can see there: > # Line 45-49: This interface describes via field constraint which other > content > types can contain a message. Clearly message boards can contain messages, but > also messages can contain other messages - known as responses. We usually > specify this constraint on the parent on the main content type interface (i.e. > IMessage) directly, but since this constraint refers explicitely to IMessage > we > have to wait till the interface is defined. > # Line 52-59: We also want the message to be container, so it can contain > responses and attachments. However, we do not want any object to be able to be > added to messages, so we add a precondition as we did for the IMessageBoard > interface. Again, we have to do this in a separate interface here, since we > reference IMessage in the condition. > Hope this helps. > Regards, Douglas. > > Start your day with Yahoo! - make it your home page > http://www.yahoo.com/r/hs Sorry, this is not really my problem: The book speaks about a containment association. My problem is a "simple" bi-directional association, which I cannot break up into a contained and container class. -- Best regards, Adammailto:[EMAIL PROTECTED] ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: [Zope3-Users] practical example of migrating from services to utilities
On Mon, Aug 08, 2005 at 01:57:21PM -0600, Duncan McGreggor wrote: > Hey all, > > I just wanted to check to make sure I was doing this right, and if so, > provide a resource that would turn up on subsequent googling. This > example involves the getting menus items with the getService/getUtility > functions and is taken from Philip's worldcookery example code. > > Here's the pertinent zcml (worldcookery/browser/configure.zcml): > > id="alternate_views" > title="Menu containing a list of alternative views for an object" > /> > > title="[label-recipe] Recipe" > class="worldcookery.recipe.Recipe" > permission="worldcookery.EditRecipes" > view="AddRecipe.html" > /> > > Here's the original code (worldcookery/browser/recipe.py): > > def alternateViews(self): > menu_service = zapi.getService(servicenames.BrowserMenu) > menu_id = 'alternate_views' > return menu_service.getMenu(menu_id, self.context, self.request) > > Here's the modified example that I'd want to check if I am doing > correctly: > > def alternateViews(self): > browser_menu = zapi.getUtility(IBrowserMenu, 'alternate_views') > return browser_menu.getMenuItems(self.context, self.request) > > Am I doing this properly? > ... I haven't tried your solution zapi.getUtility(IBrowserMenu, 'alternate_views') (I doubt it works) but I had the same problem some time ago, and Philipp had pointed out to me that there are simpler solutions now - both of them worked fine for me (his original e-mail to me in German below, the English translation is mine): There is no global browser menu service available any more. And there is no corresponding utility, as for most of the other services. Menu items are simply adapters in Zope 3.1. The helper function getMenu from zope.app.publisher.browser.menu is handy for the lookup. The method alternateViews() from example 12.3.3 can now be written as def alternateViews(self): menu_id = 'alternate_views' return getMenu(menu_id, self.context, self.request) Besides that there is an even easier to use view "view_get_menu" (that Philip regrets to not have mentioned in his book). Example 12.3.4 could be written as ... This worked in Zope 3.0 already (and has not changed in Zope 3.1) It can also be recommended as there is no requirement for an additional method in a view class. Regards, Andreas (from Philips E-mail:) Der Global Browser Menu Service ist komplett weggefallen. Eine Entsprechung als Utility, wie das mit den meisten anderen Services der Fall ist, gibt ebenfalls nicht. Menü-Einträge sind unter Zope 3.1 einfache Adapter. Die Hilfsfunktion getMenu aus dem zope.app.publisher.browser.menu Modul erleichtert das Lookup. Die Methode alternateViews() in Beispiel 12.3.3 könnte nun folgendermaßen implementiert werden: def alternateViews(self): menu_id = 'alternate_views' return getMenu(menu_id, self.context, self.request) Es gibt übrigens auch den etwas leichter zu bedienden View "view_get_menu", den ich leider vergessen habe zu behandeln. So könnte Beispiel 12.3.4 ab Zeile 20 auch heißen: ... Diese Methode ist transparent gegenüber den Änderungen von X3.0 zu 3.1 und insofern auch empfehlenswert, allein schon weil eine zusätzliche Methode in der View-Klasse entfällt. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: How to resolve bi-directionally navigable association? (Corrections)
On Mon, Aug 08, 2005 at 02:36:46PM +0200, Adam Groszer wrote: | Corrections: | | Monday, August 8, 2005, 11:45:56 AM, I wrote: | | > The only way I found is defining a dummy interface before the other: | | Actually that does not work, because the dummy IUnit and the real | IUnit is not the same and IItem stores the wrong one. This failes on | validations. | | Now I don't have any more ideas, please help. I don't think the schema you posted actually does what you want. When you create an IItem object, the form will embed a form to create a new IUnit object (which will embed a form to create a new IItem and so on). Even apart from the infinite recursion in the form, I don't think you are intending to create a new IUnit every time you create an IItem. I think you are intending to initialize a -reference- to an existing IUnit when you create the IItem and vice-versa. In X3.0, you use a vocabulary to do this. See if the available documentation and examples for those meets your needs. HTH, -D -- How great is the love the Father has lavished on us, that we should be called children of God! 1 John 3:1 www: http://dman13.dyndns.org/~dman/jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
