Re: [Zope-dev] Patch to fix problem
Chris Withers wrote:
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 made this go away with a patch to PropertyManager.py:
===
RCS file: /cvs-repository/Zope2/lib/python/OFS/PropertyManager.py,v
retrieving revision 1.30
diff -r1.30 PropertyManager.py
199c199
or hasattr(self.aq_base, id):
---
or hasattr(getattr(self,'aq_base',self), id):
I'm sticking this in the collector so please tell me if my patch is
wrong ;-)
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] Bad General Try and Except
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 ___ 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] Adding properties in __init__
Toby Dickenson wrote: Your object must have a factory method somewhere I suggest adding an extra method to your object (I always name it '_after_create') and arrange for it to be called by your factory once the new object is installed in its container. ...yurch! ;-) 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] ZPatterns, MySQL, Full Text Searching
Hello, I've read that ZPatterns and ZCatalog don't interact too well and I was wondering if this is also true of the new ZPatterns release. I might be looking to move something to ZPatterns so that it can get all benefits of Zope's security system and things like the Catalog, obviously if the Catalog doesn't work with ZPatterns, that's a bit of a problem :-S On a related note, has anyone thought of using MySQL's new full text searching to implement the Catalog interface? Has anyone thought of or actually made the Catalog stuff into an interface so people can implement other options to ZCatalog? cheers, Chris PS: Is there a ZPatterns demo/tutorial around anywhere? How should I start getting into ZPatterns? What should I read? Where should I start? (The four most common ZPatterns FAQ's if I'm not mistaken ;-) ___ 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] DynPersist for Windows, ZPatterns 0.4.3b1 and Zope 2.2.x
Hi, Just went through the fun of compiling this so thought I'd mail it to the list in case anyone else wants it... Also noticed the Pluggin product is missing a /help folder in the distribution which makes registerHelp() barf unpleasantly. Adding an empty directory of that name makes the problem go away. cheers, Chris PS: Rename the file back to DynPersist.dll and stick it in the ZPatterns directory. DynPersist-0.4.3b1.dll
Re: [Zope-dev] Observable Interface?
Tres Seaver wrote: Chris Withers [EMAIL PROTECTED] asked: Does anyone know what happened to it and how far its implementation got? The preliminary implementaion, DefaultObservabale, landed as a mix-in class in Zope 2.2: $ZOPE_HOME/lib/python/OFS/DefaultObservable.py Mix it in to one of your Python base classes (be sure to get it's '__init__()' called!) and fire away. Where are the docs? Hwo does it work? I am currenly working on the more ambitious notion of adding an event channel, which addresses some of the "MxN" problems which plague the classic Observer. See the Zope-PTK archives for August for the latest on that. Looked... any further progress? 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 )
Re: [Zope-dev] Re: Discussion Story Building Mediums
Michael Bernstein wrote: After some more thought, I realized that this really needs to be a three-way gateway betrween a mailing list, a 'blog, and a newsgroup. I'm all up for doing the mailing list/weblog type bits but I have no idea how news _works_ and how it could be integrated into the Zope environment... 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 )
Re: [Zope-dev] RFClarification: Security on Product Attributes
Okay, apologies in advance for picking up a thread that's been dorman for so long ;-) Jim Fulton wrote: Chris Withers wrote: self.id = id self.title = 'Title!' self.anInt = 0 self.aString = 'testing' None of the values above can have a __roles__ attribute, so they are covered by assertions made in their containers. That's what I thought Note that if you can't adequately control something that can't have __roles__, you can provide an access function (e.g. getAnInt), which you can control Can I read them? I think the answer is yes for anInt and no for aString. Probably, if you can get at one, you can get at the other. That's not my experience. If you try and use strings, you get dialog boxes popping up. If you use ints, it works fine. So, the problem is how to protect ints when you don't want people to get at them... Adding accessors mean you have protected accessors bu there's nothing to stop you just going and using the freely available original attribute. Strings; fine, at least they're secure, and when they become proper objects in Python 2.0, the problem should go away? 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 )
Re: [Zope-dev] Observable Interface?
Tres Seaver wrote: The docs are in the interfaces wiki: http://www.zope.org/Members/michel/Interfaces/ObserverAndNotification (Note that this actually predates the fishbowl process -- this has been in Zope for a lng time). Actually at: http://www.zope.org/Members/michel/Projects/Interfaces/ObserverAndNotification /pedant ;-) Does this mean all of the classes in the diagram at that URL have been implemented? How come the Catalog doesn't use it so CatalogAware (bleugh!) isn't needed anymore? Also, is there any documentation about how to actually use the Observable interface? (excuse my ignorance if I've missed it...) Nope, the PTK work I have been able to do lately is all stabilization. I am working an a new "PTK Fishbowl" site, where such proposals can be tracked more cleanly. Cool :-) 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 )
Re: [Zope-dev] Exceptions
Oh if only!!! I love this idea, and comments haev coem from DC along those same lines, btu nothing ever really happened about it... cheers, Chris seb bacon wrote: I was just building in some error handling into some UI code, and wanted to catch errors relating to duplicate ids. The problem is that just about every client-side error raises the same kind of Exception, a 'Bad Request'. A quick grep counted 41 different types of 'Bad Request' in my Zope source. Wouldn't it be *much* nicer to have a hierarchy of exception types, so that applications can deal with them at an arbitrarily granular level? e.g. ZopeException | `RequestException | | | `XMLException | `IdException | | | `ReservedWordException | `DuplicateException Has this discussion taken place before? Would it be useful? Would its effort:benfits ratio be too great to justify doing? seb ___ 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] [Fwd: [Zope] DataSkin Supplier?]
Erk... meant this for zope-dev :-S Chris Withers wrote: Hello... Okay, I'm still staring up at the ZPatterns learning cliff as I write this so forgive my ignorance. I'm looking at ZPatterns WRT to 'dynamically generated dataskins'. You what? Well, okay, I'll try and explain... Firstly, I'm assuming that DataSkins (or their subclasses?) are first-class zope objects, can be 'added', copied, pasted, have security tabs, can be catalogued, URL traversed, etc, etc. Is that assumption correct? I hope so :-S If it is, is there something which can generate DataSkins on the fly? ie: in the same way an AttributeProvider supplier attributes to an object, is there something like a 'DataSkin provider' which provides whole dataskins to a folderish object? Finally, and this is the important bit. Can one of these folderish objects also _be_ a DataSkin? So, to word it differently, there is a root 'DataSkin provider'. This provides DataSkins which are folderish and are also 'DataSkin providers' themselves. Why do I want this? Well, think objects in a tree where the parents/children are stored as a list of names refering to other objects. In addition, objects may have multiple parents, etc... Any ideas? Where should I start reading? cheers, Chris ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) ___ 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] searching for __call__
Stephen Simmons wrote: P.S. ChrisW, searching NIP for "__call__" returns every message with 'call' in it, which is not quite the same thing! That's not my experience :-S 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] CatalogTNG
Christopher Petrilli wrote: Chris Petrilli is working on a fishbowl proposal for CatalogNG; I'm pretty sure he intends to adopt some kind of observer/event scheme to make it work. CatalogTNG is definately going to be top down, rather than bottom up (its current design). I'm trying to collect a set of requirements currently, which will be used to drive the architecture. I have some ideas on that, but would rather not publicize them until all the requirements are gathered. Where are the requirements being gathered? 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 )
Re: [Zope-dev] ZCatalog + ZCatalog
Casey Duncan wrote: OK, what this patch does is allow you to concatenate ZCatalog result sequences (Lazy sequences) without loading the whole enchilada into memory. It also dispenses with the funky workaround/hack notation that currently exists (although it still works AFAIK). Once this patch is in place, you will be able to write code as follows: snip This looks great. Have you put it in the collector yet? (http://classic.zope.org:8080/Collector/ as a 'Feature w/patch') You should chat to Chris Petrilli as he too seems to be on a Catalog mission, ATM :-) 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] Re: [Zope] FIX for the infamous __call__ bug - testers needed!
Brian Lloyd wrote: Hi all - One of the things I _really_ _really_ wanted to fix for the upcoming 2.2.3 release is the infamous "__call__" bug. I have a fix that works according to my limited testing - what I really need is for a few volunteers familiar with the problem to take a few minutes to verify the fix and let me know if the problem goes away for them as well. Attached is an updated version of cDocumentTemplate.c. You can drop this into the lib/python/DocumentTemplate directory of your installation and rebuild it - after restarting the Zope site, the __call__ problem should be gone. I'd really like to hear from some folks on this so I can get the 2.2.3 release wrapped up - thanks! What was the manifestation of this problem again? 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 )
Re: [Zope-dev] License issues
Juan David IbXXez Palomar wrote: software, but I know there's people that don't use Zope because of this incompatibility. their loss... 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 )
Re: [Zope-dev] License issues
Juan David IbXXez Palomar wrote: And more, there's already zope software with the GPL license, for example ZWiki. ZWiki is included in Debian, probably the Debian developer that maintains the package is not aware of these license issues. Has any open source license issue actually come to court yet? How many people really care about this compared to the number of people who just want to get on, develop and use software in an open source community fashion and don't want to get involved in religious flame wars? My $0.02 Chris (who doesn't really bother about license issues and hasn't been hurt by it yet...) ___ 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] ZClasses - Two glaring omissions
There was lots of talk a while back about redoing ZClasses. I wonder what ever happened to that? cheers, Chris Andy McKay wrote: Of course all those points can be done in python, im assuming you are talking about ZClasses. -- Andy McKay, Developer. ActiveState. - Original Message - From: "Alexander Limi" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, November 14, 2000 11:35 AM Subject: [Zope-dev] Two glaring omissions Hi, I've been working with Zope for almost two years now, and there are two things that I feel is missing in the interface: 1. The ability to add a Base class after the class is created 2. The ability to rename properties after instances of the classes have been created (and have the data in those fields preserved) Are there any technical reasons why these are not present? I know it is possible to add base classes in retrospect via the hack described in http://www.zope.org/Members/AlexR/ChangingBaseClasses but are there plans for making this easier? As for #2, it is quite annoying and counter-productive not being able to change a variable name that was decided a long time ago, or maybe by others simply because there exist instantiated objects of that type. Both of the above are pretty essential OO techniques (for me, at least), and hinder my work quite a lot by not being there. Any chance of these being fixed at all? Or are there reasons that I do not know about that makes this impossible? Regards, -- Alexander Limi [EMAIL PROTECTED] ___ 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 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] large PersistentMapping
Talk to Tres Seaver about the observer interface and the event channel stuff. He has lots of ideas about this and I think it does pretty much what you want... cheers, Chris Robin Becker wrote: I'm trying to build a Reverse Cross Referencing Product. The idea is to enable documents to know which other documents in the Zope data base are pointing at them. I would like to use a persistent mapping to store the link information, but since eventually the object might be quite large will I get a performance hit when accessing only a small part of the object. It certainly seems to work for small instances, but I'm worried about what happens as my structure gets larger. Is there an alternate way to do this? The heart of the object are the methods def __init__(self, id, title): '''Initialise a new instance of RXRef''' self.id=str(id) self.title = str(title) self.title = title self._N = PersistentMapping() def addNode(self,n): '''Add a new node if not known''' N = self._N if not N.has_key(n): N[n]=[] def addLinks(self,src,DST): '''We have a single src and multiple destinations''' if type(DST) not in SEQTYPES: DST = [DST] N = self._N for dst in DST: self.addNode(dst) if src not in N[dst]: N[dst].append(src) def delLinks(self,src,DST): '''We have a single src and multiple destinations''' if type(DST) not in SEQTYPES: DST = [DST] N = self._N for dst in DST: if N.has_key(dst): if src in N[dst]: N[dst].remove(src) if N[dst]==[]: del N[dst] def getRLinks(self,dst): '''get links pointing to dst''' N = self._N return N.has_key(dst) and N[dst][:] or [] -- 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 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] TTW Product distribution
jimbo wrote: Hi, If I try to distribute it and leave it set for "Allow redistribution". Its not showing up in the Zope products directory tree after I untar the 3 files into the file system products directory and restarting Zope. I have a Dataskin based ZClass, 2 Specialist, the default constructor forms. I'm using Zope 2.2.2 on win98 ZPatterns 4.3b2. Is this expected behaviour for a ttw product? It works if I export/import it. This used to be really buggy and maybe it still is. The DC guys working on the PTK found and fixed some of the bugs but I don't know if they've landed in a Zope release yet. Maybe 2.2.3? Anyone got any definite knowledge? 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 )
Re: [Zope-dev] __replaceable__ or whatever it is ;-)
Shane Hathaway wrote: FYI I actually added the docs in two places, but they were promptly removed from the place they did not belong: the help system. Unfortunately the InterfacesWiki is currently the only good place. Guess we'll have to wait for 2.3 :-) Could whoever did the coding please put something in the Interfaces Wiki or point us to where the official documentation lives? http://www.zope.org/Members/michel/Projects/Interfaces/ObjectManagerItem (See the bottom.) Thanks... I guess the behavior that was associated with ObjectManager.NOT_REPLACEABLE is obtained by just not havign a __replaceable__ attribute? ...or does ObjectManager.NOT_REPLACEABLE exist, just in an undocumented fashion ;-) Also, when is it going to land in a erleased Zoep version? 2.3 I guess... That's the plan. Bad question, I know, but any idea when that'll be? 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] Folders w/Customizer Support
If a FwCS, supports a meta_type, does that mean it has to provide everything for DataSkins of that meta_type? To put it another way, could you have a FwCS that provided soem properties and let another FwCS further up the acquisition tree supply the rest? 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] Conflict Errors
Hi, Whenever there's a lot of writes and the occasional read going on, we get the following error: 2000-11-19T16:03:44 INFO(0) Z2 CONFLICT Competing writes at, /aFolder/anObject Traceback (innermost last): File D:\Program Files\Zope\lib\python\ZPublisher\Publish.py, line 175, in publ ish File D:\Program Files\Zope\lib\python\Zope\__init__.py, line 235, in commit File D:\Program Files\Zope\lib\python\ZODB\Transaction.py, line 251, in commit File D:\Program Files\Zope\lib\python\ZODB\Connection.py, line 267, in commit ConflictError:y Can anyone shed any light on: -what this means -how bad it is -how we can make it stop happening 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 )
Re: [Zope-dev] ANNOUNCE: PartitionedFileStorage
Shane Hathaway wrote: What couldn't be tested by my limited resources: - Platforms other than Linux. I'm running this on my NT4 Workstation, not high load but I'll let you know if anything weird happens (that isn't caused by me ;-) I wonder if this will help with the conflict errors I've been getting? 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] ZPatterns Mailing List?
Hi, Just noticed there are loads of ZPatterns posts on [EMAIL PROTECTED] Would it help to have a ZPatterns list? Is there one? Could Ethan set one up? 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] ZPatterns getPersistentItemIDs() bug?
Steve Spicklemire wrote: This is a known problem. Use: dtml-let itemIDs="[]" dtml-in "addressRack.getPersistentItemIDs()" sort dmtl-call "itemIDs.append(_['sequence-item'])" /dtml-in Hmmm... that's not very nice, has the bug in getPersistentItemIDs() been fixed? 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 )
Re: [Zope-dev] Mail and zope
Roch'e Compaan wrote: Is there anyway to get a hold off the message-id of e-mail sent through the sendmail tag? I would have thought the message-id would only get generated by the MTA once the sendmail tag has finished doing its thing :-( 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 )
Re: [Zope-dev] ANNOUNCE: PartitionedFileStorage
Phil Harris wrote: Chris, Any hints/tips on how you did this (just to save me from having to do any work of course ;)) I just used WinZip to extract the tarball in the /ZODB directory. Sadly, it didn't work, and won't do until the next version fo Zope is released :-( 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] Non-TTW ZPatterns
Hi, I think (shock, horror) I'm finally starting to understand ZPatterns ;-) (well, okay, just a little bit then...) Anyway, I'm wondering how I'd go about making a ZPatterns-based project that is totally file system based. The reasons for this are CVS-ability, the ability to update the 'product' without trashing the data, the ability to easily duplicate the 'system' without copying the data, better editing environment, etc, but I'm not sure how I'd go about it. It seems as though all the cool bits (like SkinScript methods, order of racks and the like) are in Zope's 'instance space' with ZPatterns. Does this have to be so or could all the 'setting up' be stored/changed in Python or other filesystem-based stuff? If so, how so? I guess I'm talking about HTMLFile-like things for SkinScript and ZSQL methods, amongst others. Possible, or am I off my rocker (again ;-) 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 )
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 )
Re: [Zope-dev] RFC: Python/Zope Interfaces - More ZCatalog ;-)
Jim Fulton wrote: 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. ;) G400, two displays :-) 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'd much prefer smaller lightweight interfaces with as little 'code' in them as possible... 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. Yeah! ZSearch (thanks Michel, I did know about it but didn't express my point very well ;-) seems like a good example of this to me. The _interface_ deosn't seem to exist, just several implementations and no actual documentation. I wonder if the implementations all have the same functionality? They would if the interface was a contract... Please note that these points were argued extensively on the Python types-sig a couple of years ago. What was the outcome? Michel wrote: 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? A couple of years ago. (hehe - sorry, had to). Well, sorry to correct you, but there isn't an _interface_, or at least one that's published. The Z Search Interface is well defined (not well documented) ie: there isn't an interface, there's just similar (I bet they're not identical) implementations in ZSearch, Catalog, ZSQL and ZNetwork (whatever that is ;-) The 'Z Search Inteface' object is one tool in particular that uses it, perhaps you can in imply the interface from that since it is not documented. As I said earlier, I totally agree with Jim that a weak interface like this isn't a lot of use. What happens next time someone tweaks the catalog and changes the functionality? Does that mean the interface has changed? How can all the seperate implementations keep up? I actually tried to make Squishdot implement the Z Search Interface when I moved to using the catalog, but it appeared at the time that ZCatalog didn't actually work properly with Z Search anyway. All of which kindof illustrates my point :-S The main thing for me is that the implementation is documented somewhere, which it isn't. Of course, it'd be much better if it was a proper interface as is being discussed here. Mindyou, it'd also be great if python had native interface support. What does Guido think about that? 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 )
Re: [Zope-dev] Interfaces: Specify, then implement!
Dieter Maurer wrote: If you do change the implementation, then the specification can probably be changed at the same time. IMHO, this is the wrong way round. If the interface doesn't cover what it needs to, update the interface and then make sure all the implementations are updated afterwards. 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 )
Re: [Zope-dev] Suggestion: All wiki pages have the last modified date in the footer.ter.
"Jay, Dylan" wrote: There is getting to be some out of date content and it would be great to see which is which. Now there's a great idea :-) 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 )
Re: [Zope-dev] ZCatalog scalability...
John Eikenberry wrote: the potential of up to 50,000 entries. Using a ZCatalog for listings This may cause you real problems, especially if there's a 'bulk data load' at any point. Cheers, Chris PS: How's the catalog revamp coming along? Any published ZSearch interface yet? ___ 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] Turning acquisition off selectively.
[EMAIL PROTECTED] wrote:
That is, with a simple method, and not disabling the Acqusition class,
something like self.aq_disabled('attribute') .
So kindof the inverse of using Aquisition.Explicit and using the
aq_acquire method?
What you describe would be really cool...
The only workaround for now is to use calls to ac_acquire() and provide
a filter function, but this doesn't help when other code that you have
no control over accesses an attribute that you'd rather not have
acquired :-(
cheers,
Chris
PS:
http://www.zope.org/Members/michel/Projects/Interfaces/AcquisitionWrappedObject
___
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] Turning acquisition off
Ken Manheimer wrote:
On Wed, 6 Dec 2000 [EMAIL PROTECTED] wrote:
Does anyone know how to disable acqusition ?
That is, with a simple method, and not disabling the Acqusition class,
something like self.aq_disabled('attribute') .
I believe one way is self.aq_base['attribute']. aq_base gets the
unwrapped object (what got __of__'ed).
What if the base object's not a dictionary?
If you're not sure the thing
is acquisition-wrapped in the first place, you'd probably want to check
for the existing of the 'aq_base' attribute before using it...
Am I imagining things of did Jim F say he might make ac_base present in
all the acquisition classes so that kind of checking isn't necessary?
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 )
Re: [Zope-dev] case insensitive sorts
Dieter Maurer wrote:
Andy McKay writes:
what does anyone else think
I would not like it.
Why not? ;-)
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 )
Re: [Zope-dev] Search Interface [was 'case insensitive sorts']
Rik Hoekstra wrote: Hm, reading this... just a loose comment. In light of the awkward search interface of ZCatalogs, would it be a good idea to make a search interface for ZCatalog ZPatterns based? T I'm starting to feel like a stuck record on this, but lots of people seem to be asking for it in their own way... ;-) If the ZSearch Interface was properly documented and fully featured (ie defined how you search an object that supports the interface, and how you would index objects using that interface) then we wouldn't be stuck with the ZCatalog. It would enable people to write SQLIndexers, ZPatterns-based Catalogs and anything else they want, all of which would be freely interchangeable with the ZCatalog. Comments? 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 )
Re: [Zope-dev] virtual domains
Josh Zeidner wrote: Hello, Is it possible to configure zope for "virtual domains"? For instance, can I have one zope installation serve several domains? How do I configure this? http://www.zope.org/Members/4am/SiteAccess2 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 )
Re: [Zope-dev] Validation
Brad Clements wrote: I keep making this patch to each Zope release, but would like to talk about a more permanant and "correct" solution. What do others think? Validation as a whole could do with looking at, it's be great if there were hooks to catch validation problems rather than just raising exceptions... 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] Re: [squishdot] Squishdot site did not setup Tiny Tables
the three Tiny Tables for the left,right, and bottom box. I have Tiny Table installed and can add a Tiny Table to a directory, but can't seem to get a Squishdot site to create the tables. What am I doing wrong? This is a bug which will get fixed soon. However, it's partly due to the fact that there's no nice reliable way to check whether a product is installed, what version of a product is installed and whether the current user has the permissions needed to add objects of that product's type that I know of. If anyone knows different, please let me know :-) 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 )
Re: [Zope-dev] IMPORTANT! Zcatalog path handling changes in 2.3
Christopher Petrilli wrote: On 12/18/00 4:24 PM, "Steve Alexander" [EMAIL PROTECTED] wrote: Doesn't work with 2.3 from CVS, 2000-12-18 21:21 UTC I had the same problems with 2.2.5b1... ACK, I forgot that I also revealed afew bugs in other systems :/ I thought that I could just package up Zcatalog, but apparantly not Let me work on coming up with something new. Has any progress been made on this yet? 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 )
Re: [Zope-dev] Updating a ZCatalog when objects in it change their path
cheers :-) if people start bitching that it's too slow, I'll give this a go... Chris Steve Alexander wrote: Chris Withers wrote: However, the only way I could find to solve it was to add a manage_afterAdd method to Squishdot Sites which recatalogued all postings. This is a _lot_ more resource intensive than it needs to be, since I don't actually want to recatalog all postings (quite expensive when there are 3000+ of them ;-), I just want to modify the paths that ZCatalog has stored. Is there any way to do this? There probably should be ;-) Look in the new ZCatalog product (released for testing a few weeks ago), in the manage_normalize_paths method of ZCatalog.py (line 603). This method goes through every item in the Catalog, and checks to see if its path needs to be changed to the new convention of using the physical path to the object. You could use a modified version of this method to do what you want, calling it from manage_afterAdd. You may need to store the old path to the ZCatalog instance in an attribute, so you'll know how to change the paths. The following code should help, although I haven't tested it. It is shamelessly cribbed from Chris P's manage_normalize_paths method. paths = self._catalog.paths uids = self._catalog.uids for path, rid in uids.items(): new_path=_method_to_return_new_path_after_add(path) del uids[path] paths[rid] = new_path uids[ppath] = rid -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] ZCatalog reindex_object
Michael Bernstein wrote: reindex_object - should be called when an object is edited Hmmm... didn't see this method listed in the interfaces wiki. Where did you find it? I just inserted a call to catalog_object which did the job but I wonder what the difference between index_object abd reindex_object and catalog_object is? 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 )
Re: [Zope-dev] ZCatalog reindex_object
Steve Alexander wrote: reindex_object is a method of the mix-in class CatalogAwareness. Ah, that's okay then, since Squishdot doesn't have anything to do with CatalogAwareness. I think calling index_object should work, as a well-implemented catalog will do the right thing. However, calling reindex_object makes your intentions more explicit. AFAICT, the catalog doesn't have a recatalog_object method and the comments for catalog_object in ZCatalog.py suggest it can be used to re-cataloging and well as cataloging. ...in which case, I wonder why CatalogAwareness goes to the trouble of unindexing and then re-indexing? answers on a postcard, or email ;-) 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 )
Re: [Zope-dev] ZCatalog catalog_object
Itamar Shtull-Trauring wrote: Chris Withers wrote: ...in which case, I wonder why CatalogAwareness goes to the trouble of unindexing and then re-indexing? Because in older ZCatalog (before 2.3 and maybe before 2.2.4), catalog_object did not uncatalog automatically. When in doubt, assume ZCatalog is broken :p Hmmm... I wonder if Chris P or anyone else in the know could confirm the recommended steps to recatalog an object? 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 )
Re: [Zope-dev] Local Factories in Products
Johan Carlsson wrote: In ZClasses it is possible to control where a ZClass instance should be permitted to be added, in other words show up in the factory listing in a ObjectManagers manage_main view. Didn't Itamar have a proposal/project on this? How did it work out? 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 )
Re: [Zope-dev] Conflict Errors
Chris McDonough wrote: The ZODB tries hard to avoid error conditions for you by retrying conflicting writes, but if you really pound the snot out of a particular object, it'll let you know. That's gotta be one for the Zope quotes board, if I could onyl remember the URL :-) and step through a real-world ConflictError situation. Neither of which I have time to do right now... sorry, Chris. this one by saying "I don't know" because it's one of those things where learning exactly what is going on can chew up time like nobody's business, because I'd need to step through the code line-by-line. I shouldn't even be in here. :-( Hey, no problem, the help was much appreciated :-) However, if anyone does know what constitutes a 'seperate object' in ZODB terms, it be really useful to know. I'm guessing a class which inherits from Persistent? Dictionaries don't, 'cos they're python builtins, which I'm pretty certain was the problem in my case... 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 )
Re: [Zope-dev] How to confuse the publishing process
Steve Spicklemire wrote: Hi Chris, OK... you need to tell us where the index_html's are and what they have in them! ;-) Doesn't seem to matter what's in them... Say there's one in folder1 and one in folder2, which one should be used? Why are neither of them being used? cheers, Chris Do you have a dtml-var folderx somewhere? don't think so... Chris If you go to a URL that ends in a folder, you get the Chris index_html in that folder, right? Chris Well, yes and no... Chris If you go to: http://server.com/folder1/folder2/folder1 Chris ...where folder1 is a folder in your Zope's root, folder2 Chris is contained in folder1, but doesn't itself contain a Chris folder1 (so the last folder1 in the url is also the first Chris one, just acquired), Zope returns the following: Chris htmlhead base Chris href="http://localhost:8080/testnav/normaltest/testnav/" Chris /head Chris body Folder instance at 014B3D80 /body /html ___ 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] PartitionedFileStorage - Eek!
Shane Hathaway wrote: BTW, Evan helped me find and correct a bug. You'll only run into it if you set your partition size to less than the size of the largest ZODB objects. That's fixed in 0.0.2, right? Well, anyway, I changed the line in FileStorage.py as follows: # Use 0.5 GB partitions because that's what fits on a CD. defaultOps = PartitionedFileOperations( DefaultPartitionNamingStrategy(partlen=4)) #DefaultPartitionNamingStrategy(partlen=2L**29)) ...so I could try and provoke a split, but, now, when I try to add objects, I get: Error Type: CorruptedDataError Error Value: 41904222L Traceback (innermost last): File E:\Zope\22C38D~1.5B1\lib\python\ZPublisher\Publish.py, line 222, in publish_module File E:\Zope\22C38D~1.5B1\lib\python\ZPublisher\Publish.py, line 187, in publish File E:\Zope\22C38D~1.5B1\lib\python\Zope\__init__.py, line 221, in zpublisher_exception_hook (Object: ApplicationDefaultPermissions) File E:\Zope\22C38D~1.5B1\lib\python\ZPublisher\Publish.py, line 171, in publish File E:\Zope\22C38D~1.5B1\lib\python\ZPublisher\mapply.py, line 160, in mapply (Object: manage_main) File E:\Zope\22C38D~1.5B1\lib\python\ZPublisher\Publish.py, line 112, in call_object (Object: manage_main) File E:\Zope\22C38D~1.5B1\lib\python\App\special_dtml.py, line 120, in __call__ (Object: manage_main) (Info: E:\Zope\2.2.5b1\lib\python\OFS\main.dtml) File E:\Zope\22C38D~1.5B1\lib\python\DocumentTemplate\DT_String.py, line 528, in __call__ (Object: manage_main) File E:\Zope\22C38D~1.5B1\lib\python\App\special_dtml.py, line 120, in __call__ (Object: manage_tabs) (Info: E:\Zope\2.2.5b1\lib\python\App\manage_tabs.dtml) File E:\Zope\22C38D~1.5B1\lib\python\DocumentTemplate\DT_String.py, line 528, in __call__ (Object: manage_tabs) File E:\Zope\22C38D~1.5B1\lib\python\DocumentTemplate\DT_With.py, line 146, in render (Object: _(manage_options=filtered_manage_options())) File E:\Zope\22C38D~1.5B1\lib\python\App\PersistentExtra.py, line 114, in locked_in_version (Object: ApplicationDefaultPermissions) File E:\Zope\22C38D~1.5B1\lib\python\ZODB\Connection.py, line 432, in modifiedInVersion File E:\Zope\22C38D~1.5B1\lib\python\ZODB\DB.py, line 364, in modifiedInVersion File E:\Zope\2.2.5b1\lib\python\ZODB\FileStorage.py, line 679, in modifiedInVersion (Object: E:\Zope\2.2.5b1/var/Data.fs) CorruptedDataError: (see above) 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 )
Re: [Zope-dev] OracleStorage, and possibly others
Jim Fulton wrote: - Policies to control whether multiple revisions are stored or whether revisions are removed by packing on a object-by-object or transaction-by-transaction basis. You could keep significant historical revisions for important objects, such as Wiki pages, templates, scripts, etc., with a policy to decide which revisions are significant. - The ability to set policies to implement quotas. We are also working on ZEO storage replication. This may have a big impact on the storage API, or lead to specialized APIs for replicated storages. very cool :-) Any idea when these will be around to play with? Please help stamp out Data.fs! :-) Nah... we like it, especially once Shane's PartionedFile storage makes it into production... 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 )
Re: [Zope-dev] case insensitive sorts
Shane Hathaway wrote: Python's sort() lets you sort based on not only strings but also tuples, lists, and numbers, which is a very useful feature. Thus sort() is intended to be a highly generalized method. It is useful but not ideal for sorting text strings. What you *really* want is a second method, perhaps in a new module (called "textops" or something similar) that would also include multilingual text splitters and other utilities for working with human-readable text. I agree that's a good idea, but all I'm talking about is the simple case of sorting strings, in which python's current implementation isn't very helpful and I don't see any situation where sorting: Andrew David Wayne bart sophie is better than sorting: Andrew bart David sophie Wayne 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 )
Re: [Zope-dev] case insensitive sorts
Dieter Maurer wrote: Chris Withers writes: Dieter Maurer wrote: Andy McKay writes: what does anyone else think I would not like it. Why not? ;-) I would not like to see this sort order in the management screens, because I use capitalization to ensure that essential objects are at the top of the object list. Hmmm... that's like saying you'd rather not have a memory leak fixed because it gives you an excuse to buy more RAM ;-) *grinz* 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 )
Re: [Zope-dev] case insensitive sorts
Toby Dickenson wrote: (reasons of course would be helpful, particularly if you want it to stay like it is ;-) I noticed the smiley, so Im not sure how serious the suggestion is. It was serious, the smiley was 'cos I couldn't understand why anyone would want it to stay like it is :-) 1. Python doesnt distinguish between 8-bit-strings and byte arrays. (for example, ZODB uses 8-byte-long 'strings' as oids). Do you want a casewise sort for byte arrays too? I don't know. Show me why this is bad :-) 2. 'sort' uses 'cmp'; so effectively you are asking for string's cmp to be case insensitve. Can you demonstrate a case-sensitive collation function that is as simple as your case-insensitive one: def _default_sort(x,y): return cmp(string.lower(x),string.lower(y)) I see your point. I guess cmp is implemented in C? How about a third optional argument? def _case_sensitive_sort(x,y): return cmp(x,y,string.CASE_SENSITIVE) def _default_sort(x,y): return cmp(x,y) 3. ZCatalog stores objects in a pre-sorted order. Changing the sort order of any object (not just strings) would break *all* existing ZCatalog instances that store mixed case strings. (and other applications too - the python language reference documents that this assmption is safe at least until python3k) Sorry, don't qutie follow this... explanation for a simpleton? ;-) 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 )
Re: [Zope-dev] Acquisition wishlist :-)
Jim Fulton wrote:
I'm inclined to think that in some future version of Zope, we
should switch to making explicit acquisition the norm.
Well, implicit is good when you're starting, but can cause fun with
security later.
Hmmm, I guess I like the way it is but my wishlist (damn, Christmas just
gone ;-) would be:
for Acquisiton.Implicit, be able to do something like:
class MyClass (Acquisition.Implicit):
acquisition = ClassAcquisitionInfo()
acquisition.donotacquire('index_html')
and, likewise, for Acquisition.Explicit, to be able to to something
like:
class MyClass (Acquisition.Explicit):
acquisition = ClassAcquisitionInfo()
acquisition.acquire('index_html')
acquisition.acquire('fred')
...of course, you may be able to do this already in some way.
What do people think?
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 )
Re: [Zope-dev] [ZPatterns] DataSkin and Zope Security
"Phillip J. Eby" wrote: DataSkins stored in Racks do not participate in the Zope ownership mechanism, nor the creation of the 'Owner' role. This is because they are not being stored via the normal ObjectManager protocols. Hurm... to what extent do they participate in Zope's Security Mechanisms? 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] AppTabs
Ty Sarna wrote: AppTabs[4] [4] Unreleased product, still in some flux. It mainly provides fancier, more flexible version of Zope's management tabs, suitable for use in an application (that is, suitable for exposing to users, not just developers). It also has some local roles hooks as mentioned. Ooo sounds very cool... any chance of a release? I had a proposal on dev.zope.org for something similar (Multi-Row Manage Tabs, I think, but it was a while back :-S) 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 )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
Steve Alexander wrote: On a related issue, what about other dtml snippets that people generally don't want as web accessible, such as standard_html_header ? On my pie-in-the-sky zope wishlist: snip wishlist I did have a proposal for just this on dev.zope.org, but I see someone has deleted it :-( 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 )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
Dieter Maurer wrote: There are objects, that should be usable by Anonymous inside DTML but should not be viewable over the web (as they will only confuse). All page components (such as "standard_html_header/footer") fall into this category. Totally agree... this has bugged em right since I started usign Zope! :-S 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 )
Re: [Zope-dev] case insensitive sorts
Andy McKay wrote: They want information fast and most users expect case insensitive sorts. Its simpler and easy. I think having the ignore_case option for a -tree and -in helps Zope by increasing the ease of development and friendliness to the user. And my point was that this is so universally true that the _pthyon_ sort function (which is at fault here) should be fixed :-) 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] Objects with multiple parents and storage flexibility, ZPatterns?
Hi, Once again I'm back at trying to solve this problem, hopefully with a little more knowledge this time ;-) What I'd like: 'Zope' objects of type 'X', which can have multiple parents and can contain other objects of type 'X', where storage isn't necessarily tied to the ZODB but where the objects have a normal properties page (in terms of use, again, it'd be nice if it could be stored anywhere) and participate in all the normal Zope security and management interface processes, and they need to be catalogable. This sounds like ZPatterns to me, am I right? If so, it appears there are two choices: 1. Folder w/Customiser Support (FwCS ;-) and DataSkins 2. Specialist with one or more Racks and DataSkins Which one of these would be most appropriate? FwCS containg DataSkins that also mix in the Folder class sound like they'd give a closer approximation to 'real Zope objects', but Racks sound like the only way that objects of the same metatype can come from different sources (eg, some objects of type 'X' from ZODB, some from SQL, some from LDAP ,etc) and seem to be more flexible in general, but can I have DataSkins that nest stored in a specialists' rack, eg: http://server:8080/specialist/dataskin1/dataskin2 How about doing something like: http://server:8080/specialist/dataskin1/dataskin2/manage ? Any help is good help, sorry this is a bit rambling, if you need mroe info, I'll be happy to supply it :-S 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 )
Re: [Zope-dev] case insensitive sorts
Andy McKay wrote: Hmm im actually not so sure on that. Currently you can do a sort either way, if you fix it so its only case sensitive we'll end up like Visual Basic :) Actually, I'd like to see it 'fixed' so it's only case insensitive: Alan betty Carl Wilbur Fixing python is a question for the python list and I'd be scared to ask it there... I'm sure I copied one of these messages to the python list for that very reason but it didn't get any response. Ah well, I'll copy this one there as well and see what happens ;-) 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 )
Re: [Zope-dev] How to confuse the publishing process
Steve Spicklemire wrote: I don't see the behavior you describe.. What did I misunderstand? Prolly nothing. I was more than likely just doing something stupid :-) 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 )
Re: [Zope-dev] case insensitive sorts
Dieter Maurer wrote: Chris Withers writes: Andrew bart David sophie Wayne Why in hell do you switch caseness for similar objects? Who said anything about objects? I was just talking about lists of strings and in general, people prefer sorting based on the character to take precedence over sorting based on the case of that character. Sadly, python's default sort does it the other way round :-( 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 )
Re: [Zope-dev] Acquisition wishlist :-)
Dieter Maurer wrote:
acquisition.donotacquire('index_html')
This would be great.
Indeed :-)
class MyClass (Acquisition.Explicit):
acquisition = ClassAcquisitionInfo()
acquisition.acquire('index_html')
acquisition.acquire('fred')
You already can do that, though with a different syntax
(I would need to search for in the documentation).
You may mean that if x is an Acquisition.Explicit object, you can do:
x.aq_acquire('your_attribute') (syntax may be wrong ;-)
What I meant is that through a declaration in the class you could saying
acquire the 'your_attribute' attribute but nothing else. So, you could
still do:
x.your_attribute ...which would be acquired, but...
x.index_html ...which wouldn't be acquired.
cheers,
Chris
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 )
___
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] ZPatterns question
Christian Scholz wrote: Well, virtual in the sense as a specialist is no real folder but can provide content from different sources. Thus what I mean is some mechanism which emulates objectIds() etc. so it looks to the user (and the ones using it via dtml) like a normal folder object. Somehow like the Customizer but without the need for actually creating Zope objects. Something inbetween Specialist and Customizer this would be I guess. yeah, this is exactly what I'm after too. I'd like the virtual objects the specialist is responsible for to have normal Zope management screens. Also, much mroe trickily, I'd like them to be able to contain each other, although Steve A's __bobo_traverse__ trick might help with this bit... 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 )
Re: [Zope-dev] CatalogAware
Erik Enge wrote: Are you saying that, as a general rule, inheriting from CatalogAware and using index_object, reindex_object and unindex_object does not work? It probably does, but if you're a catalog yourself anyway, as Squishdot is, it just more overhead rather than calling your own catalog_object and uncatalog_object methods ;-) 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 )
Re: [Zope-dev] Objects with multiple parents and storage flexibility, ZPatterns?
Thanks... this sounds a lot like what I'm after :-) Steve Spicklemire wrote: I think that if you make your DataSkins folderish it will be hard to make the storage anything other than ZODB. Well, I don't mind the 'skins' being stored in the ZODB, but, as Steve A mentioned, I _would_ like stuff created in the RDBMS to 'magically appear' in the Zope side of things. I guess that means FwCS and folder-subclassing DataSkins are a no-no? Let's say your objects have an attribute that defines them in the context of their parent (e.g., dataskin2 in your example URL), their id in Zope parlance, right? let's call it 'context_id'. You may have six objects with the same context_id, but they would all have different parents. They may each have mutliple parents too ;-) The point for me is that the id (context_id in your example) is unique in terms of _only_ the following constraint: No parent may have more than one child with the same id. This is actually how the ZODB works except that it objects in the ZODB may only have one parent (well, at least ZODBs managed with Zope ;-) Now.. you could implement a search interface that finds an object in context. GetObjectInContextOfParent( context_id, parent_id ) might be better if it resolved a path into an object, like Zope does, hence my keenness to see if there isn't a simple way I can make Zope and Zpatterns do the bulk of the work, just with the tweaks I need... Now for the traversal interface: def __bobo_traverse__(self, REQUEST, name): ob = getattr(self, name, _marker) if ob is _marker: ob = self.GetObjectInContextOfParent( context_id = name, parent_id = self.id) if ob is not None: return ob raise 'NotFound' return ob looks good... Totally untested of course. ;-) Anyway the idea would be to *not* use folderish DataSkins, but to build a hierarchy out of them that could be traversed. Hurm... I'd love them to have a UI identical to normal Zope folders/objectmanagers, though, with properties, a security tab, and, in a dream world, the ability to drop normal DTML methods, python Scripts and the like into the foldersish objects. Is this asking for too much? ;-) 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 )
Re: [Zope-dev] Re: Objects with multiple parents and storage flexibility, ZPatterns?
Steve Alexander wrote: If you use a Folder w/ Customizer Support, you'll need to create all the DataSkin instances in the ZODB, just as if they were normal ZClass (or whatever) instances. Thus, the instances all need to be "in there" to start with. Shame, although if I'm really brutal and XP about this, that might not matter... You can't add data to your external database, and expect a new Dataskin instance to pop up in the ZODB. This is what is meant by "When using Folder with Customizer Support, DataSkins are anchored in the ZODB". Is this always going to be the case or just the current implementation? You can get the data for your dataskins from a variety of sources, whether you choose to use Specialists or Folder w/ Customizer Support. Cool... would creating a folder objects that subclasses FwCS _and_ DataSkin be a very bad thing, or could I maybe get what I want doing that and supplying things like objectIds with an attribute provider? However, if you use Specialists, you can have the DataSkin instances appear only when requested. Thus, you can add records to your external database, and thereby have new Dataskins available from your application. Hurm... could this not be achvieved if, like I mentioned earlier, objectIds, and whatever else is neeeded, is supplied by something ZPatterns-ish? I briefly described this on zope-dev a couple of days ago. Yup, I saw :-) Many thanks for all the help, 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 )
Re: [Zope-dev] Objects with multiple parents and storageflexibility, ZPatterns?
"Phillip J. Eby" wrote: You can't really "nest" DataSkins inside each other in a rack, and you really don't want to, anyway. I kindof agree, I guess nesting doesn't mean a lot in RDBMS terms? ;-) But there's nothing that says you can't create a DataSkin subclass whose __bobo_traverse__ looks up related objects. Hurm, could something similar be doen so a DataSkin could implement the objectmanager interface? You just can't "really" store the DataSkins inside each other. I don't want to, I only want it to appear to Zope, ZPublisher and the Management Interface as if that was the case. The only difference being that 'objects' can appear under more than one parent. Note that if your __bobo_traverse__ uses a specialist "getXforY()" call, you can "store" objects from different databases (racks) "inside" each other. :) I like the sound of that :-) Well, thanks for the help so far, I'm going to have to bite the bullet and start implementing tomorrow :-S 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 )
Re: [Zope-dev] Product dev
Shane Hathaway wrote: when a product has syntax errors. One of the first things I did at Digital Creations was make sure that got fixed. :-) Does this mean this bit from your average product's __init__.py isn't neeeded anymore? except: # If we can't register, complain! import sys, traceback, string type, val, tb = sys.exc_info() sys.stderr.write(string.join(traceback.format_exception(type, val, tb), '')) del type, val, tb 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 )
Re: [Zope-dev] case insensitive sorts
Shane Hathaway wrote: Shane Hathaway wrote: def sort_strings(data): sortable_data = list(map(lambda s: (lower(s), s), data)) sortable_data.sort() return map(lambda s: s[1], sortable_data) ... Or better, you could pass a comparison function to sort() like Tres suggested. :-) This is where this whole thread started ;-) We end up using a comparision function every time we call sort, which is messy and results in a lot of duplicated code... My suggestion was for the default sort function to change so that when you want the sorting that makes sense to humans, you'd just have to do: list.sort() ...and when you wanted sort as it is now, then you could something like: list.sort(lambda x, y: old_cmp(y,x)) But this thread has lost noth its ends, so to speak, so I shall duck out ;-) 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 )
Re: [Zope-dev] CatalogAware
Michael Bernstein wrote: Your example is correct as far as it goes, but as I understand it, you are not really specifying the default catalog per se, but the default catalog *name*. snip This is true, and one of the reasons why I (and maybe only I ;-) consider CatalogAware somewhat less useful than it could be. 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 )
Re: [Zope-dev] CatalogAware
Michael Bernstein wrote: Aha! You're saying that catalog_object and uncatalog_object are methods of the catalog, so when the catalog contains the objects directly, it's all that's neccessary, correct? Yes :-) uncatalog_object to be called on it (I'm not sure what method reindex_object causes to be called). unindex_object followed by index_object. I'm not convinced it's necessary, as no-one has said that uncataloging is a necessary step before catalogng something that's already in the catalog. So, postings would only need to be CatalogAware if you wanted them to be able to 'live' anywhere within the Zope heirarchy, instead of being contained directly within the Squishdot object (which inherits from ZCatalog). Yes, but Squishdot postings are intimately tied to the Squishdot folderish object anyway, so that's not going 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 )
Re: [Zope-dev] RE: objectIds accessiblilty and a proposal
Brian Lloyd wrote: Are you talking about 'ProtocolAccessibility'? It's still there (though Jim has done some rearranging of things there lately)... http://www.zope.org//Wikis/DevSite/Proposals/ProtocolAccessibility So it is :-) Comments are still welcome... 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 )
Re: [Zope-dev] protocol accesibility
Toby Dickenson wrote: On Fri, 05 Jan 2001 12:18:07 +, Chris Withers [EMAIL PROTECTED] wrote: http://www.zope.org//Wikis/DevSite/Proposals/ProtocolAccessibility So it is :-) Comments are still welcome... Comments provided as requested With sensible defaults, what I was proposing would be just as simple as things are now, but explicit and flexible. For example, if you start a method name with _, it's not URL traversable, or available in DTML. I have no idea about FTP but it probabyl won't be accessible through DAV. Alternatively, if you give a method in a python a doc string, it will be URL traversable. Take that doc string away and it won't be url traversable but will be accessible in DTML. Again, don't know about FTP or DAV. I agree the wording might be bad (that proposal is very old now), but how can something that seeks to clearly define and document something that has already been partially and accidentally implemented (as was often the Zope way ;-) be a bad thing? cheers, Chris PS: How would you hide things like standard_html_header and _footer from users? Access Contents Information is needed by a lot of methods (some of which aren't available to give proxy roles to) that using it to prevent peole from sniffing around in your site isn't feasible. ___ 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] RFE: Make PythonScripts.standard available from DTML _.standard
Steve Alexander wrote: eg: dtml-if "mysomething(_['title_or_id'],_.standard.html_quote(absolute_url()+_[id]))" You are being deliberately Byzantine there! I provided a good example for my case, don't know what Byzantine means, erk :-S However, I agree with you in principle. I've had other, much simpler, cases where I want to html_quote just a part of something. I can't put my finger on an example right now, so that does weaken my case a little :-) *grinz* 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 )
Re: [Zope-dev] ZPatterns question
Christian Scholz wrote: yeah, this is exactly what I'm after too. I'd like the virtual objects the specialist is responsible for to have normal Zope management screens. Well, I think this shouldn't be too difficult to create. Just a subclass of Specialist and add some Contents-Tab, define objectIds() etc. in the Methods tab and call it in the management screen of "Contents". Though the more advanced things like Copy/Paste/Rename might then not be available.. But for me actually it would be sufficient to get the contents. :-S I was hoping for something along the lines of subclass from Specialist and Folder, and override objectIds (+ whatver else?) in my new class to do 'the right thing' I wonder how that would pan out? Also, much mroe trickily, I'd like them to be able to contain each other, although Steve A's __bobo_traverse__ trick might help with this bit... What do you mean? Nesting Specialists (or these virtual folder specialists)? The DataSkins stored in the specialist ;-) 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 )
Re: [Zope-dev] Product dev
Shane Hathaway wrote: when a product has syntax errors. One of the first things I did at Digital Creations was make sure that got fixed. :-) Does this mean this bit from your average product's __init__.py isn't neeeded anymore? except: # If we can't register, complain! import sys, traceback, string type, val, tb = sys.exc_info() sys.stderr.write(string.join(traceback.format_exception(type, val, tb), '')) del type, val, tb That's right. As long as you're in -D mode or you have the event log going somewhere, you'll see these kind of exceptions. Cool, what version was it fixed in? I'll chop the code out of Squishdot et al as soon as I get the chance :-) 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 )
Re: [Zope-dev] Objects with multiple parents and storage flexibility, ZPatterns?
Steve Spicklemire wrote: No... I don't think so! If you don't mind keeping stuff in ZODB then you *could* have a traversal interface that made stuff 'appear' wherever you want it to, though its persistent storage would 'really' be in a Rack or FwCS. Cool... how would I go about doing that? Hmm. not really... the Zope 'id' is used by the Rack to keep track of all the objects of a single type. If all your 'X's are kept in one Rack, they all need a unique 'id'. Ah, yes, now I see, in my case, as with the ZODB, the unique id would be the path from the specialist/FwCS to the DataSkin in question, ending in the dataskin's ID, I think :-S The difference is that, because of the multiple parents thing, unique id - dataskin isn't a one to one mapping. many unique id's map onto one dataskin. I suppose that means the _actual_ unique id for the dataskin needs to be a unique integer number or some such. But I guess the user would never need to be exposed to that? Does strike me that this is all redo-ing Zope's traversal stuff, which is why I'm trying to find a better way... wagh! My head hurts :-S The idea context_id is an id-like attribute that 'plays the role of id' in the context of a particular parent. It's probably a bad name... but all I could think of in 5 minutes... I think id would be better, because it's closest to Zope's notion of id, the bit that goesi nto the Rack probably wants to be called 'unique idenitifier' or maybe even 'path' depending on what gets used :-S Wow... multiple parents, multiple children.. it's almost incestuous! inbred objects, now there's a concept ;-) So long as you can write queries for 'find parents for child x' and 'find children for parent y' it shouldn't matter. cool... Chris Hurm... I'd love them to have a UI identical to normal Zope Chris folders/objectmanagers, though, with properties, a security Chris tab, and, in a dream world, the ability to drop normal DTML Chris methods, python Scripts and the like into the foldersish Chris objects. Chris Is this asking for too much? ;-) You can never *ask* for too much. ;-) But then what happens if I ask how to do it? Seriously though... for this you'll probably need to store the objects persistently in the Rack(s), Why? though you could farm some of their attributes out to other data storage systems with SkinScript. Nothing will prevent you from making your DataSkins inherit from ObjectManager or Folder, but you won't be able to completely 'virtualize' them. Well, that may not be a problem. The important thing is that if someone creates a record in a.n.other system, then one of these 'virtual' objects automatically appears in the Zope side of things... reckon that's not too hard? The only way I *think* you could make this work with completely virtual data-skins is to create 'sister' classes to everything you wanted to add (e.g. 'SkinDTML Method' and 'SkinPython Script' which would be new classes that inherit from DataSkin *and* the class you want to emulate (and probably yet another class that hanldles the interconnection glue parents/context and all that). Then you'd need to add whatever attribute providers were necessary to keep all the attributes of the original classes (e.g., DTML Method) in your external storage. But it sounds like you just want to keep 'some' of the associated data in the external source... so I don't think any of that will be necessary. Why would the sister classes be needed? Anyway, how do I break this down into small beginner sized steps and start doing it? thanks for all your help, 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 )
Re: [Zope-dev] protocol accesibility
Toby Dickenson wrote: IMO their goals are achieved better, and simpler, with a HOWTO that explains how to configure the 'access contents information' permission. That's not been my experience, but maybe that How-To would help :-) Care to write it? ;-) I think perhaps you havent appreciated the simplicity of the current arrangement - all protocols work the same. That remains to be proved, even given the DTML wart you mentioned ;-) Your word 'accidentally' is a good hint as to the reason. A better (IMO) principal is 'protocol independance' - a method should behave the same no matter how it is called. Protocol independence is not necessarily a good thing in this case. Different protocols have different capabilities. For example, you might trust someone a lot more if they were using HTTPS rather HTTP. So, there is a disagreement here. What I proposed would enable us both to be happy, without anymore work on your part thanks to defaults that leave things as they are now. Your point of view leaves only you happy ;-) How would you hide things like standard_html_header and _footer from users? Im not sure why they need to be, please explain. I dont think 'tidyness' is a sufficient reason. I do, and I'm sure others do to. It's doesn't look very professional when things like http://www.zope.org/standard_html_header and http://www.cbsnewyork.com/objectIds are left hanging out. http://www.cbsnewyork.com/rubbish ain't none too nice either, likewise http://www.cbsnewyork.com/manage... 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 )
Re: [Zope-dev] protocol accesibility
Toby Dickenson wrote: That's not been my experience, but maybe that How-To would help :-) Care to write it? ;-) It is on my todo list cool :-) Protocol independence is not necessarily a good thing in this case. Different protocols have different capabilities. The zope way of modelling different capabilities is through roles. The right way to achieve this is to allocate different roles based on protocol. how do you do that? (refs to how-to's, docs, etc all good, just that I never knew you could do that :-) You could do this today using LoginManager, which allows for roles to be *computed* during authentication. Give your users different roles depending on whether they use http or https. ( or ftp? Indeed, I would be keen to see this feature in the standard user folder) Maybe that's what I should haev said in my proposal ;-) Note that protocol is not a key factor here: you might also trust them more if the socket connection comes from localhost. very true http://www.zope.org/standard_html_header Can you explain *why* this is a problem? While I agree it's untidy, its only an untidyness seen by people who go looking for it. Some people (or am I the only one ;-) don't really find that acceptable. The paranoid part of me also wants to know that it isn't possible to find this, as it should only be used by other stuff inside zope, why should stuff outside of zope get to play with it? http://www.cbsnewyork.com/objectIds are left hanging out. I propose securing the 'access contents information' permission, and you havent explained why this is flawed. Securing the permission? perhaps you could explain that a bit more :-S http://www.cbsnewyork.com/rubbish ain't none too nice either, likewise That document has since been removed. Nope, that's the point, it give a yucking Zope Error which lowers user confidence, rather than saying 'that page wasn't found, perhaps you'd like to look here or here', but, to be fair, that's because whoever built that site didn't bother to make standard_error_message useful (don't get me started on tacking tracebacks on the end of html generated by that page ;-) http://www.cbsnewyork.com/manage... I get an authentication dialog so? Hit cancel. Again, a yucky Zope error rather than saying 'sorry, your username or password were wrong', or, in reference to this thread, not actually being _visible_ to this protocol at all. eg: should raise a 404, as standard_html_header should ;-) 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 )
Re: [Zope-dev] CatalogAware
Michael Bernstein wrote: Now I'm wondering how to duplicate the behaviour of Postings being contained within Squishdot, but not appearing in the 'Contents' tab. that's definitely a 'bad' thing :-( Why duplicate anyway? You writing a replacement? ;-) 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 )
Re: [Zope-dev] Acquisition wishlist :-)
Shane Hathaway wrote: There's a (much) simpler way: class MyClass(Acquisition.Explicit): your_attribute = Acquisition.Acquired # index_html isn't index_html = None Cool :-) And I suppose the other part of my wishlist: class MyClass(Acquisition.Implicit): # your_attribute will be acquied # index_html won't index_html = None Sorry for wasting the lists' time :-S 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] BTree Folders
Hi, There was talk a while back of re-doing BTree's in Zope so they were more efficient. Is that still going ahead? If I start using BTree folders now, will there be any nasties when the changes happen? Right, BTree folders wise, what I'm looking for is to have, in effect two Contents tabs for one BTree folder object, one showing all contained items of a particular meta_type (with the BTree Folder's interface to deal with lots of objects), and the other containing all other items in the folder (DTML Methods, Gifs, etc, with a normal folder's interface). What's the best way to do this? I was going going to subclass BTreeFolder, and overide the contents tab and provide an extra one, copying and hacking the DTML as appropriate to filter on meta_type. this strikes me as not very robust as I won't benefit from any improvements to either GUI that are made in the future. Is there perhaps a better way? Also, what's the difference between a 'Full' and a 'Basic' BTreeFolder, which one should I use? 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 )
Re: [Zope-dev] ZPaterns, Pluggins
Steve Alexander wrote: If you're using ZPatterns anyway, After looking at ZPatterns for a few more days again, I still can't justify introducing that ammount of complexity to the project concerned. Also, ZPatterns seems very skewed towards TTW development now and, for CVS and distributability reasons, that's also innappropriate for this project. you might like to look at PlugIns. The idea with PlugIns is that a PlugIn manager delegates the handling of objects it contains to its various PlugIns. Typically, a PlugIn will claim objects based on the object's meta-type. As I understand it, the pluggins archicture is now wholey seperated from the ZPatterns one, so I might still take a look at that. Are there any docs about the pluggin architecture anywhere? PlugIns appear in the user-interface as separate tabs. See the Customizers and Data Plug-ins tabs in a Folder w/ Customizer Support instance for an example. Thanks, I'll take a look :-) 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 )
Re: [Zope-dev] Zope from CVS for Windows
Steve Alexander wrote: Is anyone regularly building Zope from CVS for Windows? I want to try something out on a Zope 2.3 build on windows, but I don't have easy access to windows development tools. Is there a How-To on this? I'd love to run off CVS Zope at least some of the time, but I don't know where I'd need to start... cheers, Chris (NT on Desktop, not server, don't worry ;-) ___ 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] Documentation
Dieter Maurer wrote: You can control for an explicit acquiring object that some attributes are acquired implicitly Ooo... cool :-) Where can I find out about it? Guess! ... in the Acquisition documentation. Each Zope installation has one (though on a place where one would probably not look for it): I have to be honest and say I've never found the online help system docs very user friendly. They're difficult to navigate and the presentation isn't terribly readable. Thanks for the pointer though :-) 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 )
Re: [Zope-dev] CatalogAware
Michael Bernstein wrote:
that's definitely a 'bad' thing :-(
Why is that bad? A custom object management UI ('Postings'
and 'Moderation' tabs) seems appropriate for Squishdot. I
wouldn't want to manage postings from the standard
management interface.
Hmmm... it does mean you can't cut, copy or paste postings though, which
can be a pain sometimes :-S
No, I'm creating two different applications, an image
archive and a book catalog. Both need to handle large
numbers of items. The standard management interface does not
scale to the number of objects involved from a usability
perspective.
Look at Shane Hathaway's BTree Folder :-)
I'd like to know how to prevent the objects being listed in
the 'Contents' tab, while still allowing other objects (like
DTML methods) to be added there.
Well, all the postings are actually stored in SquishSite.data, so
they're not actually 'contained' in the SquishSite object, hence they
don't show up in the contents tab. A bit of magic in
SquishSite.__getitem__ makes the postings URL traversable.
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 )
Re: [Zope-dev] Acquisition wishlist :-)
Dieter Maurer wrote: Chris Withers writes: And I suppose the other part of my wishlist: class MyClass(Acquisition.Implicit): # your_attribute will be acquied # index_html won't index_html = None No, that is not enough! As a side effect to turn off acquisition, you defined the attribute. This will not play well with inheritance: You will not only prevent acquisition of "index_html" but also prevent inheritance of it (which may be really necessary in some contexts). I'm pretty sure inheritence takes precedence over Acquisition. You wouldn't need to have index_html = None if it is inherited, since the inherited idnex_html would be used before one is acquired, surely? 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] ZCatalog Docs
Where is/are the most accurate and up-to-date documentation source(s) for ZCatalog in terms of search syntax and the different indexing types? 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 )
Re: [Zope-dev] python script
Zope mailing lists wrote: I recently released 'zopectl', a python script ...gak... now is that a 'python script' or a 'Python Script'? ;-) *grinz* 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 )
Re: [Zope-dev] index_html = None is bad...
Dieter Maurer wrote: snip example It would be much clearer, when "Item" could declare, it does not want to acquire the methods without providing a definition. Having seen the example, I think you're right :-) 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 )
Re: [Zope-dev] Re: ComputedAttribute
Martijn Pieters wrote: Erm. The ExtensionClass.stx documentation hints at a ComputedAttribute class (but as an example of how you could use an ExtensionClass). The current C implementation of ComputedAttribute is not, as far as I can see, documented. Now I think I know the answer to this one, but I'll ask just to be sure: class MyClass(Persistent Acquisition.Explicit): def _set_your_attribute (self,value): self._v_your_attribute = value def _get_your_attribute (self): return self._v_your_attribute your_attribute = ComputedAttribute(_get_your_attribute) ...with this class, your_attribute isn't going to play in Persistence, is it? (so I can update it lots without worrying about ZODB size growing... :-) Hmm... more questions: If I do: x = MyClass() x.your_attribute = 1 ...what happens? Where do you import the ComputedAttribute module from? 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 )
Re: [Zope-dev] Re: ComputedAttribute
Martijn Pieters wrote: ...with this class, your_attribute isn't going to play in Persistence, is it? (so I can update it lots without worrying about ZODB size growing... :-) Yup, this allows you to alias your_attribute to _v_your_attribute without creating an attribute that *will* persist in the process. yay! :-) your_attribute is set to one instead of the ComputedAttribute instance and concequently persisted. d'Oh... of course... If you want _set_your_attribute to be called, you need to override __setattr__: def __setattr__(self, name, value): setter = getattr(self, '_set_' + name, None) if setter: setter(value) else: raise AttributeError, "no such attribute: " + `name` Hmmm... how would you change this to call the __setattr__ that was there before you overrode it, if a setter could not be found? cheers for all the help, this thread might make quite god docs for ComputedAttribute ;-) 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] Security Machinery doesn't work on some objects?
Hi there, I'm slightly confused by a class I have: class X(Persistent, Acquisition.Explicit): This class has no __roles__, no __ac_permissions__, no nothing... Instances of this class are stored within a special folderish class, Y. This folderish class has a __bobo_traverse__ which returns X objects, wrapped in context, from it's self._xs BTree using something along the lines of: def __bobo_traverse__(self, REQUEST, name): ob = getattr(self, name, _marker) if ob == _marker: ob = return self._xs[name].__of__(self) Now, it appears no methods or other attributes of this class are protected by the security machinery, even though the instances involved are wrapped. The DocString stuff still applies but, once a method has a docstring, any anonymous user who can traverse to one of these objects, can execute any method (attributes whinge about a missing docstring, how bizarre, attepting to traverse to __init__ complains the method starts with a _ ;-) of that instance which is more than a little disturbing ;-) I thought Zope's security policy had changed to be disallow by default, but that really doesn't seem to be the case here :-S What am I missing out on? Is there some mixin class I need or something I need to acquire to make the security machinery check these objects? confusedly and worriedly, 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 )
Re: [Zope-dev] Aquisition.Acquired
Shane Hathaway wrote: There's a (much) simpler way: class MyClass(Acquisition.Explicit): your_attribute = Acquisition.Acquired # index_html isn't index_html = None "Acquired" is a special object that the acquisition module looks for. Just noticed you can do this also: class MyClass: # note lack of base class ;-) your_attribute = Acquisition.Acquired ...got the idea from Traversable.py Now if I could just figure out how to make non-SimpleItem classes aware of security (see my other recent post :-S) 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 )
Re: [Zope-dev] Re: ComputedAttribute
Chris Withers writes: with this class, your_attribute isn't going to play in Persistence, is it? (so I can update it lots without worrying about ZODB size growing... :-) But, as I understand it, it is only updated in the thread that did the update. Your next request may get a different thread and see a different value. Huh? If I change self._v_your_attribute it's only going to get updated in one thread? That's a bit sucky :-S Doesn't matter in this _particular_ case 'cos this var gets set at the start of every request, but I'm a bit concerned about its general use... any help is good help :-) 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 )
Re: [Zope-dev] New UI for 2.3
Steve Alexander wrote: However, I do not like the 3-frame interface. I feel that the top frame is wasted space. The Zope logo and "Logged in as username | Logout" could as easily go at the bottom of the tree-view frame on the left. I haven't seen this yet, but I have to agree. Two frames is bad enough btu addign another one with all the wasted border space, etc, sounds like a bad idea... This would leave extra screen space for doing work. ...which is always a good thing I realize that I can make the frame smaller by dragging it with my mouse. Yeah, and that's going to get even more annoying than constantly having to widen the edit box every time you access the same Zope instance through a different domain name :-( so I guess I'll be hacking the top frame out of my management interface :-) Can you post a patch if you do? ;-) I also much prefer blue to black as a background colour for the tabs and the "Root Folder" link. The black seems a bit overbearing. ...I'd agree too... 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 )
Re: [Zope-dev] New UI for 2.3
Brian Lloyd wrote: Are you guys working on 486's with 13in. monitors at 640x480 or something? :^) Well, no, but laptops aren't known for their high resolutions and that can make demonstrating zope a pain :-S Seriously - Zope has been criticized for a very long time for being, ah, aesthetically challenged :) It is a valid criticism - we have been (and quite honestly, will continue to be) more concerned with function over form. That's cool, but couldn't you hire someone just to make the thing look nice? A graphic designer or usability expert who knows what's best for all these things, rather than us, a load of developers, trying to guess ;-) But is it really so bad to make a 32 pixel-high concession to a small pittance of branding? Yes... especially when you could get the same branding without wasting a whole strip of the screen... I know that "branding" isn't important for those who are already believers, but Zope has grown enough that its reasonable to put some effort into "first impression factor". It doesn't help the community for reviews to come out that waste words on the visual appeal shortcomings of the UI and totally miss the point. A better first impression is a Good Thing. I totally agree, and that top bar really spoils it :-S For example, in Netscape, the bottom 5 pixels of the logo are chopped off when you first open the manage screens. In both IE and Netscape you get that horrible chunky frame border (is there any way you can make that go away for the horizontal split?) which wastes more space and looks nasty. The top frame is also a place where we might want to put more "placeless" operations like logout in the future. Any reason why that 'raise Unauthorized' thing couldn't have been put in? I mean it's one line, and way more useful than "Sorry, this is not yet implemented. " :-S You can only jam so much into the tree pane without it looking very much like way too much is being jammed into the tree pane :) Well, how about: [Root Folder] (square brackets mean black background) tree Refresh (having this below (c) Digital Creations makes no sense ;-) [Logged in as X] Logout other placeless operations Then put the Zope logo actually _in_ the manage tabs (in the dead space to the left of the 'Contents' tab) and hey presto, no nead for a top bar, still branded and looks nicer ;-) FWIW, one of the things we may put there later is a way to do "browser preferences" via cookies to control things like default text area sizes. This has always confused me, whats' wrong with just letting the user object be a propertymanager?! After all, the preferences you're talking about are user prefences and users will want them to follow them around, no matter what machine they're using. By implementing that, you remove the need for everyone else to resort to LoginManager any time you want to store data that is associated with a user in the user object... Right, negative comments out the way, on the whole it looks very nice and _much_ better than 2.2. Seems a lot quicker too. Really looking forward to the full release :-) cheers, Chris PS: You could always do a 'top bar' vote on www.zope.org and let everyone have their say ;-) ___ 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 )
