RE: [Zope-dev] Mail and zope
originated from but most e-mail clients discard custom headers but preserve a 'In-Reply-To' header with the original message-id. Don't count on it! :) I spent quite some time working on a full-text mailing list search/archive system and one of the things I wanted to do was preserve thread informtion. However it was surprising the number of MUAs that did not generate a In-Reply-To header. Mostly it was Microsoft Mail Client and quite a few similar internal mail systems with internet gateways. Also beware that many mailers use the NNTP standard of References: instead of in-reply-to. I would suggest using the Subject line instead and generate some sort of ticket number and store it in the subject line, and put a header in the message body instructing the user to not alter the subject. -Matt -- Matt Hamilton[EMAIL PROTECTED] Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Colocation | DB Integration ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Python/Zope Interfaces: ZCatalog
Ken Manheimer wrote: I'm not expert on eiffel or even interfaces, but my understanding having interface "specification very near to the implementation" is misleading, at best. The key thing is that there may be many implementations, all of which should be written to the same implementation - so you do not want Should that be 'same interface'? the interface specification tied to any one of them. This is a very good point! I'd be really interested in making something that supported the Catalog 'interface' but actually used the new MySQL full-text searching stuff to do the indexing/searching. However, until Catalog has a defined _interface_, I'm not even going to think about starting :-S Anyone know when that's likely to happen? cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] fixing security problems HOW?
How can I find out exactly what is causing my security permissioning to fail. I have put extra stuff into ZPublisher\BaseRequest.py at line 463 so I know that I'm failing on UnauthorizedYou are not authorized to access this resource. URL='http://192.168.0.4:7080/live/index_html' No Authorization header found. I am an anonymous user. Even when I make /live have the same permissions as the manager I can't make it work. index_html is a dtml method of the class of which live is an instance. How can I figure out what is blocking the anonymous access. -- Robin Becker ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] CVS down?
C:\Python\devel\Zopecvs -z9 upd -A -P -d CVS.EXE [update aborted]: connect to zope.org:2401 failed: Connection refused Am I pointing at the wrong server or something? -- Robin Becker ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Python/Zope Interfaces
Lalo Martins wrote: On Fri, Nov 24, 2000 at 08:11:48AM -0800, Michel Pelletier wrote: Python Interface Proposal I have been working on a proposal for enhancing the existing interface documentation in Zope. The Wiki for this project can be found here: As far as what's written on the proposal is concerned, I like it. Technically, I have one objection to the interface documentation system: Why must I create a new "dummy" Python file? I don't think you do need to create a dummy Python file. You *do* need to define interfaces, in whatever files you choose. Why can't the system extract the data from the Python source itself? Because the (class) source is about implementation, not interface. A class often implements multiple interfacs, and multiple classes often implement the same interface. For that reason, it makes sense to define interfaces and classes independently. Duplicating work is never good, and there are even people who like literate programming :-) There is no duplications. Interfaces and classes are two different kinds of beasts. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Python/Zope Interfaces
Michel Pelletier wrote: Lalo Martins wrote: On Fri, Nov 24, 2000 at 08:11:48AM -0800, Michel Pelletier wrote: Python Interface Proposal I have been working on a proposal for enhancing the existing interface documentation in Zope. The Wiki for this project can be found here: As far as what's written on the proposal is concerned, I like it. Technically, I have one objection to the interface documentation system: Why must I create a new "dummy" Python file? Why can't the system extract the data from the Python source itself? You can, of course, because you can just pass the Interface costructor a class. This is, in my strongly-held opinion, a bad idea. Most classes implement multiple interfaces, and trying to suck interfaces out of a class definition will tend to generate sloppy interfacesl. I added a comment on this to your Wiki page. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] fixing security problems HOW?
Robin Becker wrote: How can I find out exactly what is causing my security permissioning to fail. I have put extra stuff into ZPublisher\BaseRequest.py at line 463 so I know that I'm failing on UnauthorizedYou are not authorized to access this resource. URL='http://192.168.0.4:7080/live/index_html' No Authorization header found. I am an anonymous user. Even when I make /live have the same permissions as the manager I can't make it work. index_html is a dtml method of the class of which live is an instance. How can I figure out what is blocking the anonymous access. 1) Use the -D option to start Zope in debugging mode. 2) Install ZDebug. 3) Add a user with the essential permissions and see if *that* user can get access. Shane ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Python/Zope Interfaces
Dieter Maurer wrote: Michel Pelletier writes: Also, defining the interface seperately keep the two things apart, impementation and interface, and doesn't allow you to sneak in a new method unless you also sneak it into the interface, thus making a stronger "contract" with the user. I am a bit astonished by this statement: I know the "design by contract" concept from Bertrand Meyer, the Eiffel developper. In Eiffel, essential parts of the contract, among others method prototype, pre- and post-conditions as well as invariants are build directly into the language. A documentation tool extracts these parts from the source to generate the interface, for people that are only interested in how to use the class/method. Programms can be executed in a way, that the various (executable) contract parts can be checked at runtime. *THIS* provides for quite a strong contract. I cannot see, why the separation of interface and implementation should make the contract stronger. The interface *is* the contract. If someone builds a house for me, I don't want the house to *be* the contract. I want the house to adhere to the contract. Interface/contract and implementation are two qualitatively different things. I do see, however, that it makes it more likely to be broken by the implementation. I don't think it makes it more or less likely. Of course, if the "interface" is always derived from the implemenation then the two will be consistent, but this is not terribly useful. It is a very good thing to have the specification very near to the implementation -- as a permanent guide to the implementor. Firtunately, modern displays allow multiple side-by-side windows. ;) It is even better, when big parts of the specification becomes part of the executable code (as is the case for Eiffel's pre- and post-conditions). If you want to prevent your implementors to change the interface specification, generate the interface for the implementation and compare against your master copy. In my view, it is better to have a somewhat "weaker" contract that is met by the partners than a "stronger" contract that is violated. We disagree then. A weak interface that is satisfied by definition is nearly useless to me. Or, to say it differently, it is more essential the a system's documentation describes faithfully what is rather than what should be (but is not). I disagree alot. I'd rather have clear documentation of intended behavior, rather than have the documentation change based on implementation decisions. Note also that most classes implement multiple interfaces. Generating interfaces from classes trends to yield bloated non-cohesive interfaces. Similarly, most interesting interfaces are implemented by multiple classes, so nearness to implementation is not really meaningful. Please note that these points were argued extensively on the Python types-sig a couple of years ago. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! Technical Director (888) 344-4332http://www.python.org Digital Creationshttp://www.digicool.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] objectValues performance
Brett Carter wrote: I have a folder with greater than 5000 ZClass instances in it. It takes 5mins to do an objectValues for every object in the folder - is there a higher perfomance call I could make? -Brett Standard folder performance degrades pretty quickly once you get a lot of objects in it. There are two solutions to this: Subdivide your objects into multiple folders. Use a BTreeFolder which should be much faster. You can download the BTreeFolder product here: http://www.zope.org/Members/hathawsh/BTreeFolder/ hth, Casey Duncan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] UML reverse engineering on ZClasses - I need somehelp
On Tue, 28 Nov 2000, zope wrote: Hi! 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. I am very much interested in your work. 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] UML reverse engineering on ZClasses - I need somehelp
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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] objectValues performance
Id recommend all the above but just for reference "objectIds" is faster than "objectValues". -- Andy McKay, Developer. ActiveState. - Original Message - From: "Casey Duncan" [EMAIL PROTECTED] To: "Brett Carter" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, November 28, 2000 7:58 AM Subject: Re: [Zope-dev] objectValues performance Brett Carter wrote: I have a folder with greater than 5000 ZClass instances in it. It takes 5mins to do an objectValues for every object in the folder - is there a higher perfomance call I could make? -Brett Standard folder performance degrades pretty quickly once you get a lot of objects in it. There are two solutions to this: Subdivide your objects into multiple folders. Use a BTreeFolder which should be much faster. You can download the BTreeFolder product here: http://www.zope.org/Members/hathawsh/BTreeFolder/ hth, Casey Duncan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] objectValues performance
Ok, I'll bite. Why doesn't the standard folder scale? Seems like a design flaw to me - why doesn't the default folder use catalogs or BTrees? -Brett "Casey" == Casey Duncan [EMAIL PROTECTED] writes: Casey Brett Carter wrote: I have a folder with greater than 5000 ZClass instances in it. It takes 5mins to do an objectValues for every object in the folder - is there a higher perfomance call I could make? -Brett Casey Standard folder performance degrades pretty quickly once you get Casey a lot of objects in it. There are two solutions to this: Casey Subdivide your objects into multiple folders. Casey Use a BTreeFolder which should be much faster. Casey You can download the BTreeFolder product Casey here: http://www.zope.org/Members/hathawsh/BTreeFolder/ Casey hth, Casey Casey Duncan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] objectValues performance
Brett Carter wrote: Ok, I'll bite. Why doesn't the standard folder scale? Seems like a design flaw to me - why doesn't the default folder use catalogs or BTrees? -Brett Because massive scale is not a requirment of folders, they are meant to organize content for humans, not to be large-collection containers. A folder with 5000 elements is not very useful to a human. On a similar note, create 5000 files in a linux directory on a ext2 (standard) filesystem and then type 'ls'. You'll notice they don't scale very well either, which is why there are filesystems like ReiserFS. -Michel "Casey" == Casey Duncan [EMAIL PROTECTED] writes: Casey Brett Carter wrote: I have a folder with greater than 5000 ZClass instances in it. It takes 5mins to do an objectValues for every object in the folder - is there a higher perfomance call I could make? -Brett Casey Standard folder performance degrades pretty quickly once you get Casey a lot of objects in it. There are two solutions to this: Casey Subdivide your objects into multiple folders. Casey Use a BTreeFolder which should be much faster. Casey You can download the BTreeFolder product Casey here: http://www.zope.org/Members/hathawsh/BTreeFolder/ Casey hth, Casey Casey Duncan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: PathHandler: bug, readme.txt
To my mind it's the browser. This is a simple trick I use when egating the caching in IE for instance. Stick a space on the end of the url and IE thinks it's a new one but blindly strips them before getting the same refreshed page. This works with any server and any page on that server btw. Phil - Original Message - From: "Chris Withers" [EMAIL PROTECTED] To: "Willem Broekema" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, November 28, 2000 1:57 PM Subject: [Zope-dev] Re: PathHandler: bug, readme.txt | Willem and Zope-Dev'ers, | | Willem Broekema wrote: | | Hi Chris, | | PathHandler is a nice and really useful product! | | Thanks :-) | | A question though: is it on purpose that it ignores spaces at the end of | the url, as in: | | http://site/ph/%20d%20 -- path_to_handle == [' d'] instead of [' d '] | | (%20 is the escape code for a space) | | Although it's really a minor minor thing, letting the user decide how to | deal with spaces might be a tiny improvement. | | Well, it's not PathHandler that's stripping spaces, so either Zope is, | or maybe even your browser is. | Anyone got any ideas? | | That said, handling of spaces and %20's in URLs isn't very well defined | anyway, so I would avoid it if you can... | | And in the README.txt file, please replace | dtml-var path_to_handle with lt;dtml-var path_to_handlegt; so it | won't be ignored in the browsers. | | Well, I think this is a bug with Zope. README.TXT is a text file, | formatted so it will render nicely in structured text. | It does this in the management interface for the PathHandler product, | but the and aren't quoted properly. | I wonder why that is? | | Hmmm... anyone know what happened to StructuredTextNG? | | Anyway, README.TXT is primarily designed as a text file, and | lt;dtml-var path_to_handlegt; isn't very easy to read when viewing a | text file ;-) | So, I guess someone needs to fix Zope for at least one and maybe both of | your problems to go away. | | Any ideas? | | cheers, | | Chris | | ___ | Zope-Dev maillist - [EMAIL PROTECTED] | http://lists.zope.org/mailman/listinfo/zope-dev | ** No cross posts or HTML encoding! ** | (Related lists - | http://lists.zope.org/mailman/listinfo/zope-announce | http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] objectValues performance
Brett Carter wrote: Ok, I'll bite. Why doesn't the standard folder scale? Seems like a design flaw to me - why doesn't the default folder use catalogs or BTrees? -Brett AFAIK a standard folder uses a linear search when you request an object from it (ala Python dictionaries, someone please correct me if I'm wrong). This works great except that the search time grows linearly (by n) as you add objects. The BTreeFolder as the name implies creates a binary tree of the objects where the search time grows by only log n. For small folders the search time difference is minimal to non-existant, but as n increases the BTreeFolder search time increases minimally. B-trees are fairly complex entities to manage and for the vast majority of folders are total overkill. That is why standard folders work the way they do, the implementation is simple and efficient for 99.9% of applications. Your case is fairly atypical of most Zope folders. Perhaps a future implementation of Zope folders could automatically use a b-tree after a certain threshold is reached, for now you must explicitly select them. Andy's idea of using objectIds instead of objectValues is also a good one which will save significant amounts of memory. You can always access each object individually via id if you need to. Using a ZCatalog could also help in this because you can query the objects without loading them into memory and the returned result does not load the objects themselves, only the meta-data and only once a result item is explicitly accessed (By using so-called lazy sequences). However the catalog will not speed up your actual object access time unless you divide them up amongst several folders or use a BTreeFolder. The latter being a simpler solution from a design standpoint. Good luck! Casey Duncan ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Geeks] Interface Meta Data proposal
Is security really a part of an object's interface? I thought this was more of an implementation thing. - Original Message - From: "Michel Pelletier" [EMAIL PROTECTED] To: "Geeks Mailing List" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal
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? In Eiffel (I've never heard of Eiffle :-), pre- and post-conditions are turned into run-time checks, just like assertions. There are separate flags to turn code generation for pre- and post-conditions off. This is useful, as follows: while debugging your code, turn both on. When you've fully debugged an application, you turn both off. When you've fully debugged a library module, you create two versions: one with both turned off, for use in fully debugged applications, and one with pre-conditions on and post-conditions off, for use by other code that is still in need of debugging. I've heard that this works very well, and in Python 3000 (when we have optional static typing) I would love to add this to Python. If it's not feature bloat. --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Geeks] Interface Meta Data proposal
On 11/28/00 4:05 PM, "Michel Pelletier" [EMAIL PROTECTED] 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, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Geeks] Interface Meta Data proposal
Chris McDonough wrote: Is security really a part of an object's interface? Maybe. Are examples? Also maybe. It's documentation, so specific systems that use interfaces may want to be able to extend the kinds of information they can associate with interface elements. I thought this was more of an implementation thing. These are good questions, I think these also have a great effect on the Zope 3 story. BTW, the whole idea of extensible meta-data on an interface element came from reading the Zope 3 story so far, and seeing the examples that include security assertions in an interface. Amos and I discussed it a bit and that's where the proposal came from. -Michel ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] objectValues performance
"Michel" == Michel Pelletier [EMAIL PROTECTED] writes: Michel Because massive scale is not a requirment of folders, they Michel are meant to organize content for humans, not to be Michel large-collection containers. A folder with 5000 elements Michel is not very useful to a human. Michel On a similar note, create 5000 files in a linux directory on a ext2 Michel (standard) filesystem and then type 'ls'. You'll notice they don't Michel scale very well either, which is why there are filesystems like Michel ReiserFS. Michel -Michel Point taken, but in Zope where data and logic reside in the same place (ZODB) shouldn't we have some sort of effcient storage for large amounts of data? What happens when a site gets three or four thousand users? That won't fit well in an UserFolder. -Brett [...] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] fixing security problems HOW?
Robin Becker writes: How can I find out exactly what is causing my security permissioning to fail. I have put extra stuff into ZPublisher\BaseRequest.py at line 463 so I know that I'm failing on UnauthorizedYou are not authorized to access this resource. URL='http://192.168.0.4:7080/live/index_html' No Authorization header found. I am an anonymous user. Even when I make /live have the same permissions as the manager I can't make it work. index_html is a dtml method of the class of which live is an instance. How can I figure out what is blocking the anonymous access. The URL traversal in "ZPublisher.BaseRequest.traverse" led to a "roles" assignment with a non-"None" value. This triggers authentication checking. Annonymous did not have one of the necessary roles. I would probably check, what "roles" are determined during traversal. Apparently, your "live" is a Z instance. It is quite easy to forget the ZClass permission mapping (or get it wrong). This may lead to strange permission problems. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Python/Zope Interfaces
Michel Pelletier writes: Dieter Maurer wrote: Michel Pelletier writes: Also, defining the interface seperately keep the two things apart, impementation and interface, and doesn't allow you to sneak in a new method unless you also sneak it into the interface, thus making a stronger "contract" with the user. I am a bit astonished by this statement: I'm not sure if you are making these statement because you disagree with the current proposal or because you disagree with what I said above. I disagree with the "separating implementation and interface makes for a stronger contract". Separation by itself does not make the contract stronger. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Python/Zope Interfaces
Ken Manheimer writes: Dieter Maurer wrote: It is a very good thing to have the specification very near to the implementation -- as a permanent guide to the implementor. It is even better, when big parts of the specification becomes part of the executable code (as is the case for Eiffel's pre- and post-conditions). I'm not expert on eiffel or even interfaces, but my understanding having interface "specification very near to the implementation" is misleading, at best. The key thing is that there may be many implementations, all of which should be written to the same implementation - so you do not want the interface specification tied to any one of them. What about *ALL* of them. Source documentation is essential for high quality software. A major part of the documentation is what each programming entity is obliged to do by contract. Therefore, I would like this information to be near the implementation. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Python/Zope Interfaces
Jim Fulton writes: Dieter Maurer wrote: I cannot see, why the separation of interface and implementation should make the contract stronger. The interface *is* the contract. If someone builds a house for me, I don't want the house to *be* the contract. I want the house to adhere to the contract. Interface/contract and implementation are two qualitatively different things. But this does not imply, that the contract becomes stronger, when interface and implementation are separated. Packaging issues do not change the contract. I see however, that you usually will (should) start with a specification (the interface is part of it) and then provide an implementation (or more than one) for it. In my view, it is better to have a somewhat "weaker" contract that is met by the partners than a "stronger" contract that is violated. We disagree then. A weak interface that is satisfied by definition is nearly useless to me. If an implementation has nothing to do with its specification, then either the implementation or its specification is useless, at least in relation to one another. But, you note, that I did not speak about "a weak interface that is satisfied by definition" but about a "somewhat weaker contract that is met by the partners compared to a somewhat stronger contract but violated contract". Or, to say it differently, it is more essential the a system's documentation describes faithfully what is rather than what should be (but is not). I disagree alot. I'd rather have clear documentation of intended behavior, rather than have the documentation change based on implementation decisions. If the implementation decisions are essential: e.g. linear versus logarithmic time complexity, I would like to have that stated in the documentation. Note also that most classes implement multiple interfaces. Generating interfaces from classes trends to yield bloated non-cohesive interfaces. I may agree with this. Though some configuration for the generation process may help to reduce the danger. Similarly, most interesting interfaces are implemented by multiple classes, so nearness to implementation is not really meaningful. It helps the implementation to adhere to the contract. Please note that these points were argued extensively on the Python types-sig a couple of years ago. SIG archives tend to be non-searchable. I, probably, will not dig in to summarize the results. Even, if I do, this would be no garantee that I would be convinced. Let me stress my point of view. Maybe, we are not too far away from one another: * I like clear specifications (as you do) * The specification has more value, when its implementations adhere to it (you probably will agree). * A documentation about an existing system is more valuable, when it states what is rather than what should be (here we may disagree). I usually start by studying the documentation. If it descibes what is, then I will recognize early what does not fit my requirements and can work around it. If it describes what should be, I will determine the deficiencies much later in my projects, modifications are much more difficult and expensive. * Having the specification near the implementation helps the implementors to adhere to it, especially with long maintenance periods. (Here we may disagree). I believe in the value of well documented source, in literate programming. Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] fixing security problems HOW?
In article [EMAIL PROTECTED], Robin Becker [EMAIL PROTECTED] writes Apparently, your "live" is a Z instance. It is quite easy to forget the ZClass permission mapping (or get it wrong). This may lead to strange permission problems. Which ZClass permission mapping? Anonymous seems to be able to 'view'. The 'Manager' role can log in and do stuff, but even when I change the permissions of Anonymous to be completely the same as for Manager I don't get the same behaviour; ie anonymous is being asked to log in? The problem I suppose is that /live/index_html is really a permission of /live and I guess the permissions determining access etc are really in / the object which cannot be traversed to :) well I upgraded my CVS version and everything started working again. Mumble. If only I hadn't tried to get the new Python methods to work etc etc dribble dribble. -- Robin Becker ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] RE: [Geeks] Re: Interface Meta Data proposal
[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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] ZPetterns implementation qustions
Hi, I'm trying to figure out the right way to implement a set of classes and roles in ZPatterns. I asked some questions about this a while ago, and then went away and did some learning, but I'm stuck again and I'm afraid I need to ask more questions. I have two types of actors - Person (with properties name, phone, email, password) and Organization (with properties name, phone, fax, business_number). I also have two participants - Customer and Reseller. Each participant can be either a Person or an Organization. The participants can fill several roles, like OrderingEntities, BillableEntities, etc. Starting from the bottom, I create a Specialist for each role, each one with two virtual Racks - customerRack and ResellerRack, so I can refer to an OrderingEntity without caring if it's a Reseller or Customer. My problem is in implementing the Participant Specialists and storing Participant and Actor classes. Do I create Specialists for the Actors? It seems to me that since there is either one Person or one Organization per Customer, then the actor object should be created in the Customers Specialist. So Customers will have 3 Racks - defaultRack (using Customer object), personRack (using Person object) and organizationRack (using Organization object). Does this make sense? If this is a good way to do it, how do I handle creating and accessing the Person and Organization objects? Do I call personRack.newItem(newCustomerId) in the script that creates the customer? Or do I somehow do it in a SkinScript in defaultRack? And how do I get to the Person data? With an attribute provider? Or in the SkinScript: WITH personRack.getItem(self.id) COMPUTE name=name, phone=phone, email=email, password=password, personObject=RESULT) Also, if Actors are stored in the Specialists that implement the roles they participate as, there is no place to store methods that are common to an Actor regardless of role - for example, a method that checks if a password is secure enough and called when adding a Person object. So I either duplicate these methods in every Participant Specialist, or create more Specialists - which seems like a waste either way. Another problem is how to edit these objects - if I have a form which includes fields for a Customer properties and for the properties of the Person object linked to that Customer, can I change the Person object from the Customer SkinScript? I don't think I can do this: WHEN OBJECT CHANGED STORE name, password USING personObject.propertysheets.manage_changeProperties(name=self.name, password=self.password) Right? Because name and password are not properties on the Customer DataSkin. So I have to call person.manage_changeProperties(...) in the method that changes Customer... it seems to me that I always end up doing object connections work in methods and the SkinScript can't help with anything :( Hope this is not too convoluted...I'd really appreciate any help anyone can offer. The existing ZPatterns examples all deal with fairly straightforward situations, but it's the more complex class relationships where the bears and tigers are hiding :) Itai -- Itai Tavor"Je sautille, donc je suis." C3Works[EMAIL PROTECTED] - Kermit the Frog "If you haven't got your health, you haven't got anything" ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Geeks] Interface Meta Data proposal
Jeffrey P Shell [EMAIL PROTECTED] said: 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). It's so cool, it really chills your productivity. The moment that Python starts doing that, I'll drop the language like a hot iron. 'Nuff about thermodynamics. Making exceptions statically checked is probably the worst misfeature of Java. The idea is nice, in that it forces you to deal with exceptions, but in reality it gets in the way too soon - when you're still exploring, refactoring, stuff like that you should be able to turn the damn things off. I've got five years of full-time Java programming behind me, so I know what I'm talking about. 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. Useful documentation, especially contracts, can be useful programmatically so stuff like that should at least be setup so that it is possible to move it into the language. A bit like the @pre and @post tags in Javadoc comments - they're always nice to have as documentation, but when you run iContract over them, they are activated and start checking your code's behavior. If you don't say you implement 'Cloneable', an exception gets raised (even if you implement the proper method). Another wart in Java that is nice in theory, but sits in your way in practice. I greatly prefer the Smalltalk "protocols" approach, where implementing an interface is accomplished by implementing the right methods period. The funny thing is, hardly any Smalltalk code ever checks for the interface: the (correct) assumption is that if you hand something over to some other thing that says it wants to iterate over whatever you handed over, you'd better be sure that the thing behaves at least enough like a collection so that it can be iterated over. That's the caller's responsibility (a sort of implicit precondition), and if the caller sends over something else, you get a DoesNotUnderstand exception. Very often I have longed in Java for the possibility of an object to implement a subset of behavior of another object, but that's not possible. For example, if you have a bunch of field labels you stuff in a collection just to be able to do getText()/setText() on them (say for internationalization). Now, I want to add menu labels to that collection, they also have getText()/setText() so they would be good citizens in that collection. Java does not allow that, unless I'm prepared to jump through instanceof/type casting hoops (which is only possible if I'm the one actually calling getText()/setText()). This is similar to how we sniff things today, but we just do things like 'if hasattr(obj, "cb_isCopyable") and obj.cb_isCopyable()):' The usual answer of an OO guru here is that if statements are considered harmful, and that if statements that check object types are considered very harmful. The modern variant is "these are strong refactoring smells". -- Cees de Groot http://www.cdegroot.com [EMAIL PROTECTED] GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Geeks] Re: Interface Meta Data proposal
Guido van Rossum [EMAIL PROTECTED] said: When you've fully debugged an application, you turn both off. When you've fully debugged a library module, you create two versions: one with both turned off, for use in fully debugged applications, and one with pre-conditions on and post-conditions off, for use by other code that is still in need of debugging. I've heard that this works very well, and in Python 3000 (when we have optional static typing) I would love to add this to Python. If it's not feature bloat. It works very well in fully debugged applications. In the 99.99% other applications, advice is to leave the assertions on during production time so your app will fail fast when a bug pops up (profiling will point you to the two assertions that needs to be turned off for acceptable performance). Personally, but I'm talking without too much thinking here, I think support for assertions in Python should be based on generic support for metaprogramming - there's more than DBC that could benefit from that (aspect-oriented programming, etcetera). -- Cees de Groot http://www.cdegroot.com [EMAIL PROTECTED] GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
