- Zope-Dev - Zope lists

Re: [Zope-dev] Questions about implementing object models with ZPatterns
by Itai Tavor 08 Nov '00

08 Nov '00

Phillip J. Eby wrote: >At 12:35 PM 11/1/00 +1100, Itai Tavor wrote: >>Hi, >> >>How do I implement gen-spec classes using ZPatterns and ZClasses? >>For example, I want to implement Person and Customer. Writing it in >>Python, it would be easy to subclass Person to get Customer, and >>Customer would inherit Person's properties and methods. If I instead >>create a specialist and ZClass for each class, do I use a SkinScript >>to remap Person's properties into Customer? And what about the >>methods - Customer can't inherit Person's methods, so I have to write >>methods in Customer which call the same methods in Person. This seems >>terribly complicated... am I missing something? > >If you want subclasses, just subclass ZClasses. As for the remapping, >etc., it depends on what you want to do. Keep in mind that Specialists are >created per *role* or *interface*, not per class. You can have a "People" >specialist that has a personRack and a customerRack in it, for example. >Specialists are application- and usage-driven; you don't always end up >creating specialists for every class in your object model. Ok... I think I get the "Specialist per role, not per class" part. But I still can't make the jump from a class diagram to a ZClass/Specialist setup. I can solve some of it by subclassing ZClasses. So, if I need Customers and Resellers, I'll make a Specialist for each, and a Customer and Reseller ZClasses, both subclassed from Person which stores common properties for a person. This part is ok. But it gets more complex than that. Take this example: Every OrderLineItem object can have one or more Payment objects associated with it. There are 3 possible payment types - Check, Charge and BankDeposit, so I make a ZClass for each one, all subclassed from a general Payment ZClass. I create one Payments Specialist with 3 Racks. Where do I store methods that are specific to one payment type? In the Rack? I can't store them in the Specialist - it would be a mess, and I can't store them in the ZClass, because the ZClass doesn't know about the rest of the application. Actually, writing this down makes me realize that it could work... would Payments.getItem(some_payment_id).someMethod() call someMethod in the Rack if one exists, and the one in the Specialist if not? I guess that would make it very easy... subclassing moves into the Specialist. Another problem I'm having is how to store id's for different objects in the the same field. In the Payments example above this is not a problem, because all payments are supplied by the Payments specialist. But what about another example - Customers and Resellers are two totally different roles, so they each get a Specialist. the Payment object has from_id and to_id fields, and each of those can hold the id of a customer or reseller, or some special code to indicate the store. I could add from_type and to_type fields, or I could prefix the id with a code letter, but neither seem like a good solution. Is there a recommended approach for solving this problem? >(By the way, note that if you have a personRack and customerRack in the >same specialist, they can share data plug-ins (such as SkinScript methods) >placed directly in the specialist. The ranking order of the parent >plug-ins in the child racks is determined by where you place a "Link to >Parent Data Plug-Ins" in the racks' data plug-in lists.) > > >>Another question: In Coad's examples, if a class has an 'n' order >>relationship to another class - say Order and OrderItems, Order would >>contain a list of OrderItems. Each OrderItem would contain the id of >>the Order it belongs to. It seems to me that it would be easier for >>Order to call OrderItems.getItemsForOrder(self.id), then I don't have >>to maintain a list in Orders, and if I add an OrderItem the Order >>will immediately know about it without me having to call it and tell >>it the OrderItem was added. Is there anything wrong with this > >approach? > >Nothing at all. It's the recommended approach, actually. This is how you >make frameworks work... by delegating to specialists responsible for a >role in the application. That is, instead of the Orders system having to >know anything about how order items are actually implemented, it can >delegate that function to an OrderItems specialist that could have such >things as DiscountItems, ReturnItems, and all sorts of other objects that >implement an OrderItem interface. Similarly, rather than an Order >providing its own interface for entering an order item, the UI code can be >(should be) placed in the OrderItems specialist, and called by the Order >object's add/edit forms. > >Encapsulation at its very best. :) That's the ZPatterns way; the tools >were specifically created to make it easy to do things the "right" way from >a seperation-of-powers standpoint. Thanks! I feel a little better now :) -- Itai Tavor "Je sautille, donc je suis." C3Works itai(a)c3works.com - Kermit the Frog "If you haven't got your health, you haven't got anything"

2 2

dreamWeaver encoding
by Robin Becker 08 Nov '00

08 Nov '00

A colleague and I find that the request encoding of dreamWeaver is causing us problems and we can coorect by passing the DW encoded request through urllib.unquote and quote. -- Robin Becker

1 0

Re: [Zope-dev] ZPatterns and Properties that are objects
by Willow 07 Nov '00

07 Nov '00

Thanks Philip >The way Ty and I usually handle "object" properties is to give an object >setter methods (e.g. "setAddress()") that simply set the property (e.g. >self.Address = addr). The only downside is that you have to do this in a >Python base class or an External method. Later, we expect to replace this >approach with PropertyHandlers, and we already have a primitive form of >PropertyHandler we have used with some success, but it's too crude at this >point for a product release. I presume if most of my classes are ZClasses external methods should do the job and then I can just call the setter methods when the object is created or modified? >I have created ObjectManager and Folder dataskins before and had them work, >but at the time I was testing with Zope 2.1.6, and it was an older version >of ZPatterns. I haven't done much lately with them. If people are >experiencing problems, perhaps someone could send me a bug report? If I do try out this route (in stead of using setter methods) where does the content of the ObjectManager reside - sometimes I struggle with the locality of objects when working with ZPatterns. Eg. I have a CustomerManager specialist that creates Customers (Objectmanager Dataskin) and that should contain an address dataskin. I guess a simple prodding of the namespace should do the trick but are not to clear on how this should be done? guessing (but the manage_addProduct part is probably not right): <dtml-let ni="newitem(id)"> <dtml-with ni> <dtml-with "manage_addProduct['MyProduct']"> <dtml-call "MyZClass_add(_.None, _, NoRedir=1)"> </dtml-with> </dtml-with> </dtml-let> Roché ------------- Sleep for entertaiment Willow http://www.dreamscapes.co.za

1 0

RE: [Zope-dev] calling dtml method with same name up the hierarchy.
by Dieter Maurer 07 Nov '00

07 Nov '00

Casey Duncan writes: > The following should work in your nested standard_html_footer to call the > higher level one without infinite recursion: > > <dtml-with "PARENTS[1]"> > <dtml-var standard_html_footer> > </dtml-with> I fear this solution is very unstable. "PARENTS" is defined by the URL path (loosely spoken). This means, what "PARENTS[1]" is depend on the number of path components in the URL. If there are sufficiently many components, you will get the infinite loop again. I think, there is no reliable way when "standard_html_footer" is a DTML method, as such an object has no way to access itself. With an DTML document, you may have a chance (I did not check): you would need an external (maybe Python) method def container(o): '''returns 'o's container.''' return o.aq_inner.aq_parent You could then try: <dtml-with "container(this())"> <dtml-var standard_html_footer> </dtml-with> Dieter

1 0

SiteAccess + ZCatalog Project
by Evan Simpson 07 Nov '00

07 Nov '00

Those of you who use SiteAccess, or any other virtual hosting solution, with ZCatalog (including Squishdot, ZUBB, and other ZCatalog-dependent products) should check out this new project: http://dev.zope.org/Wikis/DevSite/Projects/ZCatalogVirtualHostFix This proposes a set of changes and an upgrade path for ZCatalog to make it robust in the presence of virtual hosts. We really want to get this resolved, so this project won't be open for long. Contribute soon, if you can. Cheers, Evan @ digicool

1 0

Vote on the new name for Python Methods!
by Shane Hathaway 07 Nov '00

07 Nov '00

Being Election Day in the United States, now is a good time to vote on the new name for Python Methods. Python Methods are a relatively new concept for Zope. They give you the features of DTML, such as through-the-web editing and security, while providing a familiar, refined syntax. But before we can fold them into the Zope core, you need to help us choose the right name for them. Some have voiced the opinion that the name "Python Method" is confusing because it can just as easily refer to methods in standard Python modules. There are some interesting alternatives, so please cast your vote! http://www.zope.org/Members/hathawsh/poll

1 0

Zope Permission's Adjustment
by Keith.Larson＠Spatial.Com 07 Nov '00

07 Nov '00

Hello, Does anyone know the file that I can edit to adjust the layout of the Security Tab? I would like to be able to add the Roles Headers to the bottom of the list as well as the top. Keith Larson Web Developer

2 1

ZPatterns and Properties that are objects
by Roch'e Compaan 07 Nov '00

07 Nov '00

On the Road: I created a couple of ZClasses based on Dataskin. In the way I grok ZOPE, properties that are objects can not go onto property sheets. So if I have a Customer ZClass that has a property Address (a property that is an object) then I would create the address object as a "method" of the Customer that makes references like Customer.Address.Street possible. To achieve this without ZPatterns I would base my ZClass on a objectmanager so that I can create an instance of an Address object within Customer. So how does one do this with ZPatterns. In one posting I picked up that one does not have much joy with ZPatterns and the ObjectManger base class? Roché

2 1

Adding properties in __init__
by Chris Withers 07 Nov '00

07 Nov '00

Hi, I have a product class that subclasses SimpleItem and PropertyManager. If I try and add a property in __init__ as so: self.manage_addProperty('AProperty','1\n2\n3','lines') I get the following wonderful error: Error Type: AttributeError Error Value: aq_base I'm guessing that this is because self isn't an acquisition wrapper in __init__ (even though SimpleItem is Acquisition.Implicit) but what am I supposed to do to add a property in __init__? cheers, Chris

3 4

Bad General Try and Except
by Chris Withers 07 Nov '00

07 Nov '00

Hi Again, Management.py (around line 148) contains one of those nasty general try: except: clauses which mask real problems Anyone know why it's there? With some additions, I found out it was masking an 'index out of range' error in the product I'm developing. I wonder why this was presented as an unauthorized error? confusedly, Chris

1 0