November 2000 - Zope-Dev

Re: [Geeks] Re: Interface Meta Data proposal
by Jim Fulton 30 Nov '00

30 Nov '00

Guido van Rossum wrote: > > > Is security really a part of an object's interface? I thought this was more > > of an implementation thing. > > Good point. Certainly in Unix I can have two things implementing the > same interface (e.g. two named pipes) with different security > settings (i.e. modes). > > However some security stuff can be part of the interface too: e.g. the > fact that a Foo object has Read, Write and Execute permissions is > usefully specified as part of its interface. Whether a particular Foo > instance has a given permission for a certain user is up to the > instance. I think we're talking about a different level of security setting here. In unix, you have certain fixed permissions (e.g. read, write, execute). The OS maps these permissions onto certain low-level operations for the few objects it knows about. This is about mapping permissions onto objects, rather than deciding what users or groups have what permissions on an object. In Zope, the programmer defines abstract permissions and decides how to map the abstract permissions to object operations. It is this mapping that makes sense for interfaces. Like Unix, Zope has a separate mechanism for deciding what users/roles have what permissions on objects. This should not be part of the object interface. These settings are done by users/administrators. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org

1 0

Re: [Geeks] Interface Meta Data proposal
by Chris McDonough 30 Nov '00

30 Nov '00

Is security really a part of an object's interface? I thought this was more of an implementation thing. ----- Original Message ----- From: "Michel Pelletier" <michel(a)digicool.com> To: "Geeks Mailing List" <geeks(a)digicool.com> Cc: <zope-dev(a)zope.org> Sent: Tuesday, November 28, 2000 4:05 PM Subject: [Geeks] Interface Meta Data proposal > > I've added a sub-proposal to the Interface proposal for describing > additional meta-data with Interface objects: > > http://www.zope.org/Wikis/Interfaces/ExtesableMetaData > > Please comment about this interesting possibility. > > -Michel >

3 2

ZPatterns: Still Properties that are objects
by Roch'e Compaan 30 Nov '00

30 Nov '00

I use external methods to set properties that are objects for my Dataskins. I have a Customer Dataskin with a property Address. Address is another Dataskin. In my editInstance for Customer I change the properties of Address directly: <dtml-call "propertysheets.basic.manage_changeProperties(REQUEST=REQUEST)"> <dtml-call "Address.propertysheets.basic.manage_changeProperties(REQUEST=REQUEST)"> but this results into a keyError afters a couple of edits ie. it works SOMETIMES but not all the time. Roché

1 0

time stamp - concurrent editing
by Nai A. Tzeo 30 Nov '00

30 Nov '00

Hello, I'm a zope newbie and was wondering if anyone on the list know how to solve the problem of concurrent editing. I'm using zope as a front end and SQL server as a back end. Basically, I want to be able to edit a record with out having to lock the record so that others can use it but I want to make sure that when I update and save my changes that I don't overwrite someone elses changes. I was thinking about time stamping the record every time a person grabs the records in update view. Before the changes are written to the database, the timestamps on both the record that's checked out and the record that was modified should be compare. If the timestamp in the database is more recent, meaning someone has updated the record, then I can't update the record with my changes. I would need to grab the latest copy from the database and add in my changes. I know this sounds really inefficient but I can't think of another way. If anyone have other ideas or thoughts, pass it along. It will be greatly appreciated. TIA, Nai

2 1

Zope.org done broke
by Michel Pelletier 29 Nov '00

29 Nov '00

Editing a Wiki page results in: Error type: TypeError Error value: loop over non-sequence

1 1

Meta-data clarification and Interface interfaces
by Michel Pelletier 29 Nov '00

29 Nov '00

In my proposal: http://www.zope.org/Wikis/Interfaces/ExtensibleMetaData I mention interface object meta-data like pre/post conditions. This spurned a lot of interesting conversation, and I wanted to clarify some bits that I picked up from the thread. The proposal is not in any way trying to define what types of meta-data are interesting, this is, rightly, application dependent (for example, Zope would find security assertions interesting, other applications may not). The proposal is just proposing a mechanism for associating any kind of meta-data with an interface object. Dont get me wrong, the information on pre and post conditions was really interesting, especially Tim's description of Eiffel's particularly strong methedology that made me glad I don't work for the government. In the interest of clarifying what these interface objects are, I have created an Interface interface description: http://www.zope.org/Wikis/Interfaces/InterfaceInterface This describes interfaces, attributes and method objects and how they are used. I can forsee creating interface objects for these interface objects. The ones marked **Proposed** are the ones I am most interested in getting feedback on. Thanks! -Michel

1 0

how to add new propertys programmatically ?
by Joachim Schmitz 29 Nov '00

29 Nov '00

Hi, I tried to add a new property to an existing zclass-dataskin-propertysheet programmatically with <dtml-call "item.propertysheets.Basic.manage_addProperty(id,0,type)"> but that gives me Zope Error Zope has encountered an error while publishing this resource. Error Type: Bad Request Error Value: Properties cannot be added to this property sheet The reason that I want to add a new property is: I have a folder Adress with FieldObjects (Folders) Firstname Lastname Street and so on... Each FieldObject has the attributes: type, sortorder, required and others That way I can easely add or remove FieldObjects to my Adressfolder. Now I want to do all my processing based on the FieldObjects in the folder and store the values in a ZPatternRack, I defined a Zclass for storage with a propertysheet Basic defined but empty, cause I lazy I only want to define my properties only once, by putting a FieldObject in my folder. Than at runtime I wanted to check if a property with the name of my FieldObject exists, and if not I want to addit, but that does not work see above. Is this a good idea at all ? or are there better ways to achieve this ? Mit freundlichen Grüßen Joachim Schmitz AixtraWare, Ing. Büro für Internetanwendungen Hüsgenstr. 33a, D-52457 Aldenhoven Telefon: +49-2464-8851, FAX: +49-2464-905163

1 0

Re: [Zope-dev] UML reverse engineering on ZClasses - I need somehelp
by Philipp Auersperg 29 Nov '00

29 Nov '00

generating zclasses out of an UML model should be possible and I want to implement it, but it has to be checked if all features of ZClasses have a match in UML and vice versa. For example a method in UML can be generated as a DTML Method,PythonMethod,PythonScript,ZSQLMethod,PHPMethod,[otherLanguage] Method... and lots of other questions. this could be defined through stereotypes on the UML side, but that is still a big bunch of work. Before I go into generating zclasses I want to complete and publish the reverse engineering, therefor I want to clear some questions (see my original mail). another question: What's up with ObjectDomain, I haven't seen any change on their website since months, the currend release is still R3 Beta. Are they dead at objectdomain.com? But its JPython scripting feature makes it my favorite tool for this task.... phil ---------- Original Message ---------------------------------- From: Maik Röder <roeder(a)berg.net> Date: Tue, 28 Nov 2000 16:11:57 +0100 >Hi Joachim ! > >Joachim Schmitz wrote: >> > I am currently developing a tool for reverse engineering >> > ZClasses into UML using ObjectDomain and JPython. >> > >> > this tool connects directly to a Zope instance and queries >> > the ZClass entities, methods and inheritance relations by >> > calling a set of utility methods that I implemented as External methods. >> > >> > it works fine when reverse engineering ZClasses, their methods and inheritance relations. >> > >> > you can check out a sample result where I reversed a part of Maik Roeder's ZDP tools under >> > http://zwork.bluedynamics.com/Tests/zdp/index.html >> > >> > If there is interest and time I'll document the reverse engineering tool and publish it on zope.org >> > >> >> this is absolutly fantastic, great job Phil. >> If reverse engeneering is possible, also ZClass generation should be possible, >> or even better generate a python-product. > >Generating ZClasses out of a model description is what I wanted to do >for a long >time, but I couldn't find someone to fund this. Generating a Python >product is >something that Eric Enge has done with his mkzproduct. > >I haven't been using "SubObjects" in my ZDP-Tools, so Aggregation is >nowhere >defined, except implicitely. > >Best regards, > >Maik Röder >

4 3

Re: [Geeks] Interface Meta Data proposal
by Jeffrey P Shell 29 Nov '00

29 Nov '00

On 11/28/00 4:05 PM, "Michel Pelletier" <michel(a)digicool.com> wrote: > > I've added a sub-proposal to the Interface proposal for describing > additional meta-data with Interface objects: > > http://www.zope.org/Wikis/Interfaces/ExtesableMetaData > > Please comment about this interesting possibility. > > -Michel > Without these things being supported more in the core language, it seems quite awkward. Being able to do the followng is nice: class ILockToken(Interface.Base): def frame(self, width, height): "a frame" class LockToken: __implements__ = ILocktoken, ... The following would (will?) be better: interface ILockToken: def frame(...): class LockToken implements(ILockToken): ... But I'm not sure how one would go about setting your meta-data in a way that is at all natural to Python. I think that exceptions that a method must\should raise *should* be part of a signature\contract. This is one of the really cool things about Java. If you use a method, 'readFile' that says it raises IOError, you *HAVE* to catch that exception (I believe in order to compile). But it looks like what you're really wanting is to use interfaces for documentation purposes, not for contract purposes. Not for interfaces at this level of the language. I'm guessing along your proposal, to state that a method raises ValueError or Attribute I'd have to do the following?: class ILockToken(Interface.Base): def frame(self, width, height): "a frame" frame.setMetaData('exceptions', (ValueError, AttributeError)) ... Meta Data is a deadly term. Be careful with it. Anyways, I doubt we want to invent our own IDL (no!) or reinvent Eiffel (specifying pre and post conditions are only truely useful if they're enforced, and without this enforcement in the core language I imagine that could be expensive. They're a good thing for large systems, but Python doesn't support them automatically), so it seems that this information seems to be best put in the documentation (since doc strings in an Interface don't also mean "Publish Me!", they can be used to document!). Interfaces are contracts and pretty darn good ways of specifying parts of the system, but don't confuse them with headers in C\C++\Objective C. 'IObjectManager' is a critical interface for Zope (so instead of having attributes like 'isPrincpiaFolderish', we can ask 'IObjectManager.implementedBy(fooObject)'. Folder, on the other hand, is an important class in Zope, but is primarily an amalgam of classes implementing important Interfaces (ICopyable, IPropertyManager). It's unlikely that we'll really have a need for a Folder Interface, because what's important about Folder's is that they implement ObjectManager behaviors and CopySupport behaviors. To bring Java back into play here for a moment, a simple example is the interface 'Cloneable'. By implementing 'Cloneable', well then.. when it's time to clone, you can be cloned. If you don't say you implement 'Cloneable', an exception gets raised (even if you implement the proper method). This is similar to how we sniff things today, but we just do things like 'if hasattr(obj, "cb_isCopyable") and obj.cb_isCopyable()):' I get the feeling sometimes that what you want with interfaces is actually a bit closer to what Objective C does with the word Interface. And that is that in Foo.h, you have the interface for class Foo: @interface Foo { ... And in Foo.m, you have the implementation: @implementation Foo { ... These interfaces are header files, and they're damn nice to use for documentation since the specification of the class is separate from the implementation. But they don't imply contracts in the way that Java's use of the word Interface does. (Some implementations of Objective C call those things Protocols). Both needs are valid, but I think we'll benefit most from the first (contracts). In order to make those work, we probably shouldn't make them too foreign to specify, or the incentives to write them go way down (as is evidenced by the amount of doc strings that go """ """ or "XXX: Fill in later", getting developers to fill in too much 'meta data' is hard). But if we can get some of the information in your proposal more integrated with the language, I think it would be beneficial. Jeffrey P Shell, jeffrey(a)Digicool.com http://www.digicool.com/ | http://www.zope.org

2 1

RE: [Geeks] Re: Interface Meta Data proposal
by Tim Peters 29 Nov '00

29 Nov '00

[Christopher Petrilli] > I notice you mention post/pre conditions (something that UML > obviously talks about). I wonder if we want to do a bit of > research on Eiffle and it's contractual description. The only > thing I wonder is if some of this is actually useful > programatically, if that makes sense? It's great info, but is > it useful at runtime? Eiffel takes this all very seriously, and supplies several variants of assertions that are individually togglable. Preconditions verify a method is called according to its docs; postconditions verify a method does what it's advertised to do; anyone who takes debugging seriously is writing verification code of that kind anyway, and Eiffel automates it to an extraordinary degree. Note that's only the tip of "the contract" part: inherent in any contracting scheme is the ability to sub-contract. A subcontractor cannot require more, nor deliver less, than the original contract specifies. So, in Eiffel, for a subclass S that overrides a base class B's method M, the preconditions for S.M are magically OR'ed with the preconditions for B.M (S.M can't require more than B.M, but it may require less), and the postconditions for S.M are magically AND'ed with the postconditions for B.M (S.M can't deliver less than B.M, but it may deliver more). The language guarantees to keep all this stuff straight for you, and the doc-generation system for Eiffel knows all about it too. This isn't a collection of random debugging features in Eiffel: it's all in support of a particular formal theory of program design. if-you-can't-check-a-thing-at-runtime-you-can't-know-whether- it's-been-satisfied-ly y'rs - tim

1 0