- Zope-Dev - Zope lists

Re: [Zope] HappySession 0.1.0 released!
by Hung Jung Lu 05 Jun '00

05 Jun '00

>From: Itamar Shtull-Trauring <itamar(a)maxnm.com> >I'd be very grateful for a description of how you built the session server >in combination with persistence, transactions, and the fact that each >thread >has it's own copy of data. > >If I understood correctly, the references to the server are stored in the >class (which I assume is global for all Zope threads.) I see some worries from, you, ha! Let me explain a little bit to calm down your worries. First of all, let me tell you that the long term plan goes way beyond what the innocent happy face may hide. :) HappySession is aimed at serving multiple copies of Zope running at multiple threads each, and with multiple session servers located at multiple machines! It's not doing that now, but I have laid out things so it can be extended that way. And I have separated client aspects from server aspects in my code, so eventually it can be hooked up to SQL server or File System server, not just RAM server. (1) Persistence: no need to worry about storing garbage in ZODB. No persistence at all for the session data. You are correct, the main session data is stored in the class, which is global to all Zope threads. (2) Transaction: per REQUEST transaction per thread, a copy of the session data pertinent to that particular REQUEST is created as volatile attribute inside the SESSION instance. The updated temporary copy is stored back to the main session data if and only if transaction completes without errors. (3) Thread safety: locking mechanim is in place to prevent simultaneous modification of the main session data dictionary from different threads. All is in the codes. Take a look and you'll see it's not too innocent at all. :) regards, Hung Jung ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

1 0

Re: [Zope] HappySession 0.1.0 released!
by Itamar Shtull-Trauring 05 Jun '00

05 Jun '00

Hung Jung Lu wrote: > I have been using RAM-based session management for a while, but never wrote > a product for it. Since Graham Chiu has mentioned it again about making a > real product, I have taken the time to make one, and called it HappySession. > :) Well, in short, it uses cookie for session id, you specify a maximum > session expiration time, and expired session data are automatically deleted. > It's Zope-transaction-aware. I'd be very grateful for a description of how you built the session server in combination with persistence, transactions, and the fact that each thread has it's own copy of data. If I understood correctly, the references to the server are stored in the class (which I assume is global for all Zope threads.) -- Itamar S.T. itamar(a)maxnm.com "It don't get thingier than that!"

1 0

__ac_permissions__
by Chris Withers 04 Jun '00

04 Jun '00

Hi, The ac_permissions for Squishdot currently looks like this: __ac_permissions__=Folder.__ac_permissions__+( ('Manage postings', ['manage_delete', 'manage_postings', 'recatalogPostings']), ('Add postings', ['addPosting'], ('Anonymous', 'Manager')), ) So how come someone with only the following permissions: Access contents information Add postings Manage postings View can view manage_main and execute the updateIndexing method, even though that's not mentioned anywhere? What I'd like to have is for people with the 'Manage postings' permission to be able to view the manage_postings form (the 'Postings Tab) as the only tab in the /manage view as well as execute manage_delete and recatalogPostings ONLY. How do I do this? Do I use __ac_permissions__ or do I have to manaually check things in the updateIndexing method? (which won't work for manage_main...) Is there any documentation on __ac_permissions__ other than in the Old Product API? cheers, Chris

1 0

TextIndex Questions
by Chris Withers 04 Jun '00

04 Jun '00

>From http://www.zope.org/Members/AlexR/KeywordIndexes: > Text Index: property values are applied against a lexicon object that > stems, stops, and parses the value into a full text index. The index > may be queried with a simple boolean query language that allows > 'and', 'or', phrasing, parenthesized boolean expressions, and > proximity matching. Relevance ranking is supported and returns the > sum of the occurances of all query terms in the "hit". A normalized > score is also provided that is normalized from 0 to 100 over the > whole result set. This sounds really useful... Is it still true? How do you use the query language and return the relevance rating from a ZCatalog query? Is it documented anywhere? also, which of FieldIndex, KeywordIndex and TextIndex is case sensitive on matching? I thought they all were but I'm not sure anymore... cheers, Chris

3 3

Basic LoginManager HowTo
by Bill Anderson 03 Jun '00

03 Jun '00

Has anyone out there actually sarted _using_ LoginManager with ZODB storage? IOW, one that is not dependant on LDAP/SQL/etc., but that is functioning in place of a non-PTK acl_users folder? I am starting to play with it (so many toys, so little time...), and would like to see (if it exists) a basic walkthrough of how to go from: Folder with no userfolder, LM installed -to- Folder with LM-acl_users folder, and ZODB member storage. So, what about it? Anyone got one, or at least could write down the steps/requirements? Much Appreciated, Bill

3 4

Re: ZPatterns complexity?
by Phillip J. Eby 03 Jun '00

03 Jun '00

At 07:02 PM 6/3/00 +0800, Mike wrote: >"Phillip J. Eby" wrote: > >> Two things. 1) WebDAV support requires the ability to add arbitrary >> property sheets containing arbitrary data. 2) Propertysheets (especially >> when used with XML namespace URL's) give a way of standardizing an >> interface to common properties, without polluting an object's "main" >> namespace. This way, one can take an object that wasn't designed for a >> certain purpose, and attach a propertysheet that serves as an adapter to >> give it a different interface to its data. >> > >Just to be sure I understand this right. In my case this can mean one >(person who manages product catalog) can once decide the products should >contain also customer's feedbacks. He will need to add new propertysheet >defining new properties and provide storage where those properties will >be saved. Right? That's correct. If you have a "Persistent Sheet Provider" in the Rack that supports the correct name/namespace (or uses a "*"), then any new sheet you add will get saved in the Rack, as long as there isn't another provider earlier in the list that supports that sheet. This means that you can initially have that sheet be a plain ZODB sheet, and later decide you want it in an SQL database. You simply add an SQL-based sheet provider set up to store that sheet, and put it in the provider list ahead of the persistent sheet provider. From now on, when you add a sheet of that name/namespace, it will be stored in the SQL database. When you retrieve a sheet, it will come from SQL if it's there, or the old ZODB if not. And if you delete an object's sheet and re-add it, it will be transferred to the SQL database. >Would you be so generous please and suggest me how to handle other hard >situation. My old catalog products were based on folders so they were >able to contain data of any kind - images, tiny tables, etc. Will it be >a big sin if I create product property called, for example, >'associated_resource_id_list' and create 'universal' rack containing all >that junk? Of course, every junk item will support certain protocol such >as (__call__,index_html). (But how I will edit them?). Or should I >create separate property sheets for every junk item type as they appear? >Really, I'm in the big doubt. If you use the option of storing your objects persistently in the rack, you can subclass your DataSkins from ObjectManager or Folder, but you will have to do a little work to get manage_afterAdd/beforeDelete working properly, since their default implementation in the DataSkin class doesn't handle sub-objects. All of the standard attributes of a folder would then be stored just like a regular folder; only the propertysheets and extra attributes defined by providers on the rack would be inserted from other data sources. (By the way, you'll notice that I've been cc:ing my replies to the zope-dev list; I'd appreciate it if you could send your questions there as well. By our having this conversation on the list, other people can benefit from it as well. Thanks.)

1 0

ICSE2000 conference
by Steve Alexander 03 Jun '00

03 Jun '00

On Sunday, I'm leaving for the ICSE2000 conference in Limerick, Eire. http://www.ul.ie/~icse2000/ I'll be staying all week. Any other Zopers planning to be there? -- Steve Alexander Software Engineer Cat-Box limited

1 0

Re: [Zope-dev] Zope 2.1.6: ZCatalog's Reindex unintuitive?
by Dieter Maurer 03 Jun '00

03 Jun '00

Kevin Dangoor writes: > > I know, of cause, that a DMTL method could do this job. > > However, a general method "manage_catalogRefind" might be > > generally useful. It would remember the parameters for > > the last find operation and reapply the find. > > I like the other solutions that exist/are coming into existence/are > proposed. They are: > > 1) CatalogAwareness for ZClasses .... > > 2) ZPatterns 0.4 (http://www.zope.org/Members/pje/Wikis/ZPatterns/HomePage) > .... > > 3) ObserverAndNotification Interface > (http://www.zope.org/Members/michel/Projects/Interfaces/ObserverAndNotificat > ion): .... > > I like all of these solutions, because they are automatic. Having a > catalogRefind implies that someone needs to actively do something to make > the catalog get updated... I am especially interested in a solution for standard Zope objects (which make most of our Zope site that should be made searchable). I hope, I can automate "catalogRefind", too. At least under Unix, the CRON demon can start programs at fixed times. Such a program would execute the "catalogRefind" either with a ZClient or directly with Python's HTTPlib. Dieter

1 0

Re: [Zope-dev] TextIndex Questions
by Dieter Maurer 03 Jun '00

03 Jun '00

Michel Pelletier writes: > > simple boolean query language that allows > > 'and', 'or', phrasing, parenthesized boolean expressions, and > > proximity matching. > Except for proximity searching, it is all true. I was in error when I > stated that proximity searching was supported. The code is there, buy > the back end storage and references to the objects to do the proximity > matching had to be ripped out of ZTables because of size constraints. > You would have to create a meta-data table entry for your text content > that was indexed which is not efficient at all for a minor feature. Zope 2.1.6 contains a minor bug for "and not". Patch coming soon. I think, I can provide soon (Tuesday/Wednesday) a patch that allows for proximity searching. The code is almost ready: rather than remembering the text information, it remembers the object and extracts the text on demand. The code currently fails, if the object no longer exists or is a "Local File System" object (which can not truely be remembered in an IOBTree). Thus, I need to add some exception handling, and test a bit. Dieter

1 0

ZPHP [was Re: [Zope] CHAT]
by Stuart 'Zen' Bishop 02 Jun '00

02 Jun '00

On Thu, 1 Jun 2000, [iso-8859-1] Gon�alo Gomes wrote: > Silver_Surfer: how do you see the future of Zope fighting against PHP space on the web? > Jim: I don't know much (enough) about PHP, but from what I vaguely know, PHP methods seem like a logical step. Hmm... I'm having to setup a PHP web environment for the students next semester, and have elected to run it as a CGI application (tie into existing suid security arcitecture). I'm told there won't be any functionality loss except, just a bit of performance (?). If we didn't care about persistance of the PHP engine, it would be a trivial task to create a PHP method object - just a small python stub using the CGI libraries to call PHP. Or even more trivial - I could hack my existing Logger product to create a <dtml-php> tag, so you would be able to preprocess your PHP code with DTML tags or embed PHP output in DTML for standard_html_header etc. (Is that my foot bleeding?). The standard response to a <dtml-python> tag is that it would make it too PHP like, so <dtml-php> seems very appropriate :-) And then the next step is to import IMP and other PHP apps into Zope land... -- Stuart Bishop Work: zen(a)cs.rmit.edu.au Senior Systems Alchemist Play: zen(a)shangri-la.dropbear.id.au Computer Science, RMIT University

2 1