Re: [Zope-dev] Put an adapted object in context
Santi Camps wrote: Thats very interesting !! I was rewriting __getattr__ to allow the adapter access adapted object attributes, but doing this way its clear and easier. Inheriting from Acquisition Implicit and applying the adapter using __of__ I obtain the same result and have less problems. Okay, though Acquisition.Implicit is actually going to make your namespace issues worse; better use Acquisition.Explicit and enjoy another benefit of adapters -- namespace separation. I suspect though that your application's goals/design are different than mine. I appreciate adapters in part because they can support a much cleaner partioning of code, while you're interested in them primarily for the added dynamism, which is of course another major benefit of them. P.S. In the course of the coming weeks I'll be backporting parts of Zope 3's component architecture, especially adapters, into Zope 2. Contact me if you're interested. I also expect I'll be making more noise about this in a few weeks. Sure. Now my little adapters systems is beginning to work fine, and I will move my application this way. I'm using a simple engine, a method to define which adapters should be applied to each meta_type (this info is stored in SESSION) and then this adapters are transparently applied when accessing this kind of objects (writing some code in __bobo_traverse__). Sounds a bit like views (which is a special kind of adapter in a way); what're the adapters doing? A registry that maps meta_type to views is what we've been using inside Silva for a long time, but we're going to move away from this towards mapping interface to views/adapters, like in Zope 3, hopefully soon. One important idea is that an object can have multiple views simultaneously, instead of one big view standing in for all aspects of looking at the object. Associating views with interfaces makes it possible to associate some views for the 'base interfaces' of an object (and thus for a large class of objects) while others only apply to very particular interfaces (and thus a much smaller class of objects). Regards, Martijn ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Put an adapted object in context
Okay, though Acquisition.Implicit is actually going to make your namespace issues worse; better use Acquisition.Explicit and enjoy another benefit of adapters -- namespace separation. I suspect though that your application's goals/design are different than mine. I appreciate adapters in part because they can support a much cleaner partioning of code, while you're interested in them primarily for the added dynamism, which is of course another major benefit of them. That's it. Sure. Now my little adapters systems is beginning to work fine, and I will move my application this way. I'm using a simple engine, a method to define which adapters should be applied to each meta_type (this info is stored in SESSION) and then this adapters are transparently applied when accessing this kind of objects (writing some code in __bobo_traverse__). Sounds a bit like views (which is a special kind of adapter in a way); what're the adapters doing? A registry that maps meta_type to views is what we've been using inside Silva for a long time, but we're going to move away from this towards mapping interface to views/adapters, like in Zope 3, hopefully soon. One important idea is that an object can have multiple views simultaneously, instead of one big view standing in for all aspects of looking at the object. Associating views with interfaces makes it possible to associate some views for the 'base interfaces' of an object (and thus for a large class of objects) while others only apply to very particular interfaces (and thus a much smaller class of objects). Yes, the most important difference is that CMF and Silva are content management systems, and I'm focussing my efforts in to use Zope as a bussiness applications development framework. I use adapters to apply a Model View Controler pattern. I've diveded my development into: 1) Types. Basic objects with its model methods and its unitary views. For instance, a Folder with its creation and modification methods and forms, but without any logic (neither navigation between methods, REQUEST doesn't appear here). 2) Applications. Each application acts as a controller of used Types, and also can add some custom views. This functionallity is added throught adapters. So, the application can decide in which framework should appear the add_folder_view, where its submit should be sended, and what should be done after adding. This way, same object could be used from various applications with no problems. All the logic and navigation is decided in each application. Regards -- Santi Camps http://zetadb.sourceforge.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Put an adapted object in context
Santi Camps wrote: My problem is that the adapter object, and also the adapted object contained in it, are out of publisher context or something like this. For instance, absolute_url() methods doesn't work becouse REQUEST is not defined. I'm not sure I understand what you mean; I don't understand why your adapted object would become detached from the original context. It looks like you're losing acquisition context. You put an object into acquisition context explicitly. Something along these lines: import Acquisition class MyAdapter(Acquisition.Explicit): def __init__(self, context): self.context = context def getAdapter(context): # create adapter for context, and wrap it explicitly in the acquisition # context return MyAdapter(context).__of__(context) This works to give the adapter among other things a security context, so you can call methods on the adapter from a page template, for instance. You can also get to REQUEST and such, though in this case I used explicit acquisition so you'll have to use self.aq_acquire.REQUEST, if I recall the syntax correctly. Regards, Martijn P.S. In the course of the coming weeks I'll be backporting parts of Zope 3's component architecture, especially adapters, into Zope 2. Contact me if you're interested. I also expect I'll be making more noise about this in a few weeks. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Put an adapted object in context
Santi Camps wrote: My problem is that the adapter object, and also the adapted object contained in it, are out of publisher context or something like this. For instance, absolute_url() methods doesn't work becouse REQUEST is not defined. I'm not sure I understand what you mean; I don't understand why your adapted object would become detached from the original context. It was a stupid question, I was applying the adapter before publishing the object. Now I apply the adapter in __bobo_traverse__ and its beginning to run OK. It looks like you're losing acquisition context. You put an object into acquisition context explicitly. Something along these lines: import Acquisition class MyAdapter(Acquisition.Explicit): def __init__(self, context): self.context = context def getAdapter(context): # create adapter for context, and wrap it explicitly in the acquisition # context return MyAdapter(context).__of__(context) This works to give the adapter among other things a security context, so you can call methods on the adapter from a page template, for instance. You can also get to REQUEST and such, though in this case I used explicit acquisition so you'll have to use self.aq_acquire.REQUEST, if I recall the syntax correctly. Thats very interesting !! I was rewriting __getattr__ to allow the adapter access adapted object attributes, but doing this way its clear and easier. Inheriting from Acquisition Implicit and applying the adapter using __of__ I obtain the same result and have less problems. Regards, Martijn P.S. In the course of the coming weeks I'll be backporting parts of Zope 3's component architecture, especially adapters, into Zope 2. Contact me if you're interested. I also expect I'll be making more noise about this in a few weeks. Sure. Now my little adapters systems is beginning to work fine, and I will move my application this way. I'm using a simple engine, a method to define which adapters should be applied to each meta_type (this info is stored in SESSION) and then this adapters are transparently applied when accessing this kind of objects (writing some code in __bobo_traverse__). -- Santi Camps http://zetadb.sourceforge.net ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
