- Zope-Dev - Zope lists

License issues
by palomar＠sg.uji.es 13 Nov '00

13 Nov '00

Hi all, (specially to DC) has come to my ears that there's people who doesn't use Zope because its license is GPL-incompatible, more info here: http://www.fsf.org/philosophy/license-list.html#GPLIncompatibleLicenses only wanted to let you know, if more details are required just reply to this message best regards, jdavid

2 1

strange error on first load of zope page
by Toby Sargeant 13 Nov '00

13 Nov '00

The first page I try and load after restarting the zserver invariably contains the following error. It always occurs *after* the page has successfully been rendered (I have added debugging so that I can see the path traversal, and SQL statements executed). Hitting reload will then display the page properly, and I won't see the error again until i restart the server. (The actual text from the html source is 'Cannot pickle <type 'module'> objects') It seems perfectly reasonable to me that you can't pickle a module, but what I'm having trouble understanding is why zope is trying to. Can anyone suggest a way that I could try and track down why this is happening? thanks, toby. =============================================================================== Zope has encountered an error while publishing this resource. Error Type: UnpickleableError Error Value: Cannot pickle objects ... Traceback (innermost last): File /export/home/toby/zope/Zope2/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /export/home/toby/zope/Zope2/lib/python/ZPublisher/Publish.py, line 187, in publish File /export/home/toby/zope/Zope2/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: proj) File /export/home/toby/zope/Zope2/lib/python/ZPublisher/Publish.py, line 175, in publish File /export/home/toby/zope/Zope2/lib/python/Zope/__init__.py, line 235, in commit File /export/home/toby/zope/Zope2/lib/python/ZODB/Transaction.py, line 251, in commit File /export/home/toby/zope/Zope2/lib/python/ZODB/Connection.py, line 349, in commit (Info: (('Products.ExternalMethod.ExternalMethod', 'ExternalMethod'), '\000\000\000\000\000\000\032 ', '')) UnpickleableError: (see above) -- [ Toby Sargeant : Inpharmatica : Developer : t.sargeant(a)inpharmatica.co.uk ] [ http://www.inpharmatica.co.uk : 020 7631 4644 fax 020 7631 4844 ]

2 1

Re: [Zope-dev] PythonMethods: Can't Slice context.REQUEST.PARENTS
by Dieter Maurer 13 Nov '00

13 Nov '00

The Doctor What writes: > ... > Now here is my next problem. > > Using context.REQUEST.PARENTS doesn't give me the DTML Document that > called me (so to speak). > > I have: > /test/new/foo_html > > My PARENTS shows Zope, Test, and New, but doesn't show foo_html. "PARENTS" contain the objects from root up to but excluding the final object on the URL. You may try to reference the final object by "this()". Dieter

3 2

ZCatalog + ZCatalog
by Casey Duncan 13 Nov '00

13 Nov '00

I am making it my mission to enhance the beast that is ZCatalog. This is the first of many improvements I hope to make to it as time goes on. <DISCLAIMER> This patch has only been moderately tested, and all side affects are not known. I am submitting it here for review before adding it to the collector. You take full risk in using this patch on your installation. </DISCLAIMER> 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: <dtml-in "Catalog(<args>)+Catalog(<other args>)+..."> ... </dtml-in> or even: <dtml-in "Catalog1(<args>)+Catalog2(<args>)"> ... </dtml-in> The latter might be useful for dealing with ZCatalog scaling issues, or combining completely objects from entirely different locations. The patch changes Lazy.py and Catalog.py (very slightly). These files can be found in your {Zopedir}/lib/python/Products/ZCatalog directory. Add the following code into the Lazy class definition in Lazy.py. I added it at the end following line 118 (slice=__getslice__): def __add__(self,other): # Concatenate result sequences together while remaining lazy # Make sure the object we are concating is also Lazy try: if other.__class__.__bases__[0].__name__ != 'Lazy': raise TypeError, """Cannot concatenate objects. Both must be lazy result sequences (ie ZCatalog results)""" except: raise TypeError, """Cannot concatenate objects. Both must be lazy result sequences (ie ZCatalog results)""" if self.__class__.__name__ == 'LazyCat': # Don't nest LazyCat objects unnecessarily if hasattr(self,'_seq'): seq = self._seq else: seq = [self._data] else: seq = [self] if other.__class__.__name__ == 'LazyCat': # Don't nest LazyCat objects unnecessarily if hasattr(other,'_seq'): seq = seq + other._seq else: seq = seq + [other._data] else: seq = seq + [other] return LazyCat(seq) The change to Catalog.py is a single line as follows: Change line 603 (if not r: return r) to: if not r: return LazyCat(r) The change to Catalog.py prevents empty catalog search results from throwing an exception when concatenating it with a non-empty search result. This is the only part that I see as a risk to break existing code. If you, for whatever reason, relied on a ZCatalog returning an empty list ([]) when the search came up empty, your code will no longer work. Here is an example: <dtml-let result="Catalog(<args>)"> <dtml-if "result == []"> <--- This no longer works ... <dtml-else> ... </dtml-if> </dtml-let> However this still does: <dtml-let result="Catalog(<args>)"> <dtml-if result> ... </dtml-if> </dtml-let> And this does what you expect of it when both searches come up empty: <dtml-in "Catalog(<args>)+Catalog(<other args>)"> ... <dtml-else> ... </dtml-in> IMHO this is a very minor side affect, and well worth the gain. Please scrutinize this patch and pick it apart and let me know what works and what doesn't or if I've missed something. Enjoy, Casey Duncan

2 2

ZPatterns: Dataskin property sheets
by Roch'e Compaan 13 Nov '00

13 Nov '00

I'm not as clear as I'd like to be on when to use Dataskin property sheets and when to use common instance property sheets. I understand that with a Dataskin Property Sheet attributes are stored in way that is compatible with attribute providers making overriding of default values possible. If this is the case shouldn't one always use a Dataskin Property Sheet to retain this flexability. Roché

2 1

how do i check if it is an array
by Veiko Schnabel 13 Nov '00

13 Nov '00

i use a form with different input-fields like <form method="" action=""> first place for field_1<br> <input type="text" name="field_1"><br> <input type="text" name="field_2"><br> <input type="text" name="field_3"><br> <input type="text" name="field_4"><br> <br> images/tables second place for field_1<br> <input type="text" name="field_1"><br> </form> at two different places on my site i offer the input into formfield field_1 the point is that i do not know the names of that fields i will hafe 2 or 3 times on my site when i submit this form and look for all this fields like <dtml-in "REQUEST.form.keys()"> <dtml-var sequence-item> - ><dtml-var "REQUEST.get(_['sequence-item'])"> </dtml-in> i get for example the value for field_2 field_2 -> value but field_1 is looking like field_1 -> ['14','12'] in my opinion field_1 is an array now how do i check out if any of my fields are arrays or strings is there a function like php: is_array() if someone could help me would be great I'm not a native english speaker sorry ;-) thanx a lot

2 1

RE: Security and Acquisition?!
by Toby Dickenson 13 Nov '00

13 Nov '00

> Anyone know what those attributes are? Heres a good trick: add this method to your class to see which attributes it is asked for, but doesnt implement. def __getattr__(self,id,reg={}): if not reg.has_key(id): print `id` reg[id]=id raise AttributeError(id) > But these are very specific classes that exist for no longer than the > duration of serving a single page request, and it'd just be > nice to know > that they're not going to acquire and fluff they shouldn't... An alternative approach: apply tighter security to the method that constructs these objects, and leave the objects themselves completely open.

2 1

Re: Refresh and debugging product creation issues.....
by Stephen Simmons 13 Nov '00

13 Nov '00

The combination of Shane's Refresh product and Steve's code to prevent multiple names in the product add list is really useful. Thanks, guys! I've reworked Steve's initialize code so it works for products that have multiple classes. As an added benefit, you no longer need to specify which class is being refreshed, so the meta types can be renamed or the code reused without changing a single line. Cheers, Stephen -------------Here is the code: ---------------------------------------- def initialize(context): """Initialize my product""" context.registerClass(...) context.registerBaseClass(...) # Fix Refresh's behaviour of unconditionally reading all class meta_types. # This code extends Steve Spicklemire's fix for products with multiple classes. import Products found_meta_types = [] new_meta_type_list = [] for mt in Products.meta_types: if mt['name'] in found_meta_types: pass else: found_meta_types.append(mt['name']) new_meta_type_list.append(mt) Products.meta_types = tuple(new_meta_type_list) -----------------Steve Spicklemire wrote----------------------------- Debugging products is a pain... restarting Zope all the time is a Pain.... THANK GOD for Shane Hathaway. ;-) I am delighted to report general success with the Refresh product! My only problem is while debugging the process of creating new EMarket instances, I find that every time I run 'Refresh' I get a new "EMarket" in the 'Available Objects' popup. A quick test of other Products shows the same behavior. Soo... I snooped through the product creation code and found that Products.meta_types was being unconditionally appended to every time context.registerClass was called.... so I changed my initialize to this: def initialize(context): import Products context.registerClass( EMarket.EMarket, permission='Add EMarkets', constructors=(EMarket.addEMarketForm, EMarket.addEMarket), icon='emarket.gif', ) found_count = 0 new_products_meta_types = [] for index in range(len(Products.meta_types)): if Products.meta_types[index]['name'] == EMarket.EMarket.meta_type: found_count = found_count + 1 if found_count == 1: new_products_meta_types.append( Products.meta_types[index] ) else: new_products_meta_types.append( Products.meta_types[index] ) Products.meta_types = tuple( new_products_meta_types) In other words... only include the original version of EMarket.EMarket.meta_type in the Product.meta_types tuple... if there are others... leave them out. ...and that seems to have solved the problem.... Does this seem like an OK idea? thanks, -steve _______________________________ Stephen Simmons HealthArena B.V. phone +31 20 486 0555 mobile +31 6 1505 3086 stephen.simmons(a)healtharena.net

5 7

Wiki Pain
by Toby Dickenson 13 Nov '00

13 Nov '00

Since the beginning of this year DC have moved alot of debate and discussion out of mailing lists, and in to Wikis. http://www.zope.org/WikiCentral/FrontPage lists most Zope Wikis. Does anyone else find Wikis to be far less convenient than a good old mailing list? Ive been annoyed by the following characteristics: 1. No threading. On several occasions I have made comments in a Wiki that were subsequently ignored - I guess because they got lost in the mass of other edits. Recently people have been adding edits to the end of the page: This makes it easier to keep track of changes, but harder to catch up on a discussion when you come to it for the first time. 2. No personal replies. On several occasions I would have liked to email a comment personally to another contributer, but they didnt leave an email address. 3. No update notification. The one time I was update to keep up with a Wiki discussion involved the other participant always manually emailing a change notification. 4. Hard to keep track of many Wikis: Each wiki has its own 'whats changed' page, but even those are too coarse. 5. Too easy to fragment a discussion. On several occasions I have thought that a discussion had dried up, only to find out later on that it had moved to another page. 6. Too easy to miss the creation of a Wiki. On several occasions people have posted comments on zopedev questioning why noone has commented on their page - Noone knew it was there. This is particularly a problem because Wikis tend to get created sooner than a new mailing list would do, out of the desire to capture all discussion inside that Wiki. Mailing lists only tend to get created once there is enough traffic to justify them, and by then everyone is aware of the topic. 7. Too easy to loose content. On several occasions I have been unable to add a comments to a Wiki, either because www.zope.org would not let me login, or because its database was full. 8. Editing is painful. I have to use the browsers text field, and the whole Wiki page has to make a round trip with every change. 9. I never get the structured text quoting of python source right first time. 10. There are too many empty pages, because someone has clicked on a ? next to word that happened to be a WikiName. Useful pages lie hidden behind a sea of links to empty pages. rant ends. Toby Dickenson tdickenson(a)geminidataloggers.com

6 19

Re: [Zope-dev] Security/Acquisition Bug? (take two)
by Charlie Wilkinson 13 Nov '00

13 Nov '00

I should have included this in my previous reply - this is the Zope error I am getting after failing out of BASICAUTH login: ------------------------------------------------------------------------------ Zope Error Zope has encountered an error while publishing this resource. Unauthorized You are not authorized to access this resource. No Authorization header found. Traceback (innermost last): File /share4/Zope2/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /share4/Zope2/lib/python/ZPublisher/Publish.py, line 187, in publish File /share4/Zope2/lib/python/ZPublisher/Publish.py, line 162, in publish File /share4/Zope2/lib/python/ZPublisher/BaseRequest.py, line 463, in traverse File /share4/Zope2/lib/python/ZPublisher/HTTPResponse.py, line 569, in unauthorized Unauthorized: (see above) ------------------------------------------------------------------------------ Does that provide any (additional) clues? -cw- -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Charlie Wilkinson - cwilkins(a)boinklabs.com - N3HAZ Parental Unit, UNIX Admin, Homebrewer, Cat Lover, Spam Fighter, HAM, SWLer... Visit the Radio For Peace International Website: http://www.rfpi.org/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CLOBBER INTERNET SPAM: See!! <http://spam.abuse.net/> Join!! <http://www.cauce.org/> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ QOTD: Al Gore: Please, just concede. I can't handle another four years of whiney Republican bumper stickers!

1 0