Zope-Dev July 1999

zope-dev@zope.dev

72 participants
209 discussions

CatalogAwareness?
by David Kankiewicz 31 Jul '99

31 Jul '99

Working with the current CVS checkout... CatalogAwareness.py: I saw this file added over the last few days and tried to test the "editCatalogerForm", more like played around with it. Having tried a few different zclasses subclassed CatalogAware, with no luck, I wondered if you could explain or hint how you intend it to behave and if its working yet? (any guess when it will be working?) Permission mapping for ZClasses seems to be Showing the Non-Inherited permissions and not Showing the Inherited permissions.. just letting you know its not working.. Suggestion for editCatalogForm.... I was trying to get "editCatalogForm" to list available Catalogs (that what be better then Typing a name of a Catalog, especially if you don't know the name), but I'm too new to python and Zope to get it to work. That brings up, does each ZCatalog create a new Catalog and what would that name be?? Nice new addition of automatic "name" ZClass Permissions. I was thinking of that just before I did a checkout and saw it, cool... David C. Kankiewicz P.S. Zope is the best, my thanks go out to all who have and are working on it...

3 2

Z Classes and contained objects
by Josh Zeidner 31 Jul '99

31 Jul '99

Currently, I am working with ZClasses with a "contained" image object. In other words, I created an Image object in the "method" screen. I also created an "image" upload view that performs one simple function, uploads an image. The problem may lie in the way I am uploading this image. Here is the line of code that I got from a Zope Doc : medium_pic.manage_upload(REQUEST['new_pic']) The symptoms of this bug are either inconsistently broken images when viewing the object or distorted images( the image is not retaining its aspect ratio ). Also- the win32 debugger occasionally causes Zope to crash. Other than that - good job to all the developers! Zope is a really cool system, and I plan on using it quite a bit in the future. - keep up the good work Josh Zeidner Phylogenic Inc. _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

2 1

Secure Transactions
by Josh Zeidner 31 Jul '99

31 Jul '99

Is it possible to use Zope with SSL or any other secure http protocol? -Josh Zeidner _______________________________________________________________ Get Free Email and Do More On The Web. Visit http://www.msn.com

2 1

RE: [Zope-dev] Undocumented? changes to CopySupport.py
by Brian Lloyd 30 Jul '99

30 Jul '99

> While testing my application under Zope2.0.0b1 I noticed that it no > longer cut and pasted correctly. After a bit of digging I found that > CopySupport.py no longer calls _postCopy() after doing a copy > or paste. > As I need to do some post-copy/paste processing I have implemented > _postCopy() in my objects. The code in CopySupport.py calls > manage_AfterClone after doing a copy but there is no equivalent call > after a paste. > Note that the class CopySource (which is documented as an > 'Interface for > objects which allow themselves to be copied.') still has > _postCopy() as > a member function. > > Is this an oversight or is it a design decision ? It's a design decision to simplify the protocols. Effectively, you should be able to do everything that you used to be able to do with the copy protocols using one or more of: def manage_afterAdd(self, item, container): pass def manage_beforeDelete(self, item, container): pass def manage_afterClone(self, item): pass ...which are defined in lib/python/OFS/SimpleItem.py manage_afterAdd will be called on an object after it is added to an ObjectManger. manage_beforeDelete will be called on an object right before it is deleted from an ObjectManager. manage_afterClone is called (as you noticed) after an object is copied. You should be able to use manage_afterAdd to handle whatever you were doing in your _postCopy methods. If not, let us know so we can examine whether the protocols need to be extended... > Are there any other changes like this and if so, are they > documented and > where ? If not, any hints as to what might have changed would be > appreciated :-) and I will attempt to document them. I think that this is the main change as far as protocols go. Certainly there are a lot of new things in the code, and while we are working on documenting them, I don't think that the developer docs are up to date yet. :( Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

Zope Feature discussion
by Anthony Pfrunder 30 Jul '99

30 Jul '99

[Sorry for the length of this post...] Hi, To fill people in on what I'm working on I've decided to post this long-winded "My Zope Directions" piece. At the moment, Zope has excellent aquisition, permissions and information hiding for Products. I propose to extend this for tags and filesystems. I propose that we have a new Product, called TagMethod, which allows you to define a new tag (a la Mr Zippy). This TagMethod can be added to the Methods area of a Zclass to enable the Tag for the Zclass. In addition, any sub-objects within an instance of this Zclass will be able to use this tag. This would most likely involve XML type interfaces. To make this totally useful, we may need to change the dtml syntax slightly: <dtml-var xx> --> <dtml:var xx> This allows XML style namespaces. So an interesting use would be overriding the UL and LI elements in the XHTML namespace to provide animated bullets without modifing the content. (this would work saying <dtml:var XMLstylesheet>, where XMLstylesheet registers UL, LI tags which are called when the document is rendered). A "spin-off" advantage of doing this is to allow automagic documentation of tags. Simply add a doc-string and the Zope Help system will pick it up! The second change I propose is a "Control Panel" Product which replaces the current one but acts like a User Folder. Then, you can add permissions to Products and allow users down the chain to add their own Products by creating a "Control Panel". This would also reduce Control Panel clutter as Products can be placed where they are needed. Also, you can then subclass (via Zclasses) the Control Panel to create more user friendly Add Object systems. Finally, we need a subclassable Filesystem object. When you insert one of these it "captures" the transations and stores them in the local filesystem. This way, you can "plug" filesystems together. Also, it allows better support for server-farms (servers can share filesystems). A useful example of this would be a corporate public website. Here, the top-level website defines and serves the overall "style". Subservers and their public fs databases are "mounted" into the main one. When a change in a subserver is made only the subserver fs is updated but the master server still "sees" the change. So, Public server: + Marketing --> Marketing.fs | + Tech support --> Support.fs | Protected SMB, | NFS or NDS -------- firewall ------------------------ | file server Marketing (internal) server --> MPrivate.fs: | + Public stuff --> Marketing.fs | + Private stuff --> MPrivate.fs | ... Needless to say, they don't have to be Zope fs's. You could, for example, store some properties as an OLE stream inside Word documents. PS Amos: This is also posted you-know-where Cheers Anthony Pfrunder Zope Community Development Partner

2 1

Zcatalog : Indexing and searching UTF-8 encoded Chinese
by Sin Hang Kin 30 Jul '99

30 Jul '99

I have try to do something with Zcatalog to index and search utf-8 encoded Chinese. But it fail to locate the string. Would you consider to include support of unicode in zcatalog? Rgs, Kent Sin

2 3

DA Roadmap
by Christopher Petrilli 29 Jul '99

29 Jul '99

Gang, Below is the Database Adapter roadmap that I've just put up on the web site. It covers both where we are, how we measure where we are, and where we're going. Some of you might find the section dealing with the future of ODBC drivers interesting. Please let me know directly any feedback. Chris Roadmap for Zope Database Adapters Overview The past few weeks, having brought the Zope 2 release to a beta level, have brought to the attention of everyone that the current design and architecture of various DAs is incompatible with use in a fully threaded environment. This document hopefully will clarify some of what the various level of compatibility is, as well as comments on individual DAs, and their future. DA Thread Safety Levels In order to quantify in a uniform manner the compatibility of various DAs with Zope2, we have developed the following "levels" for database adapters to implement. Level 1 All database adapters which implement this level of compatibility must run in a single thread as they have no level of thread safety. This currently applies to nearly all DAs. This means in ZServer that Zope runs in a single thread. Level 2 Level 2 database adapters must be safe to use in a multi-threaded Zope instance. This can take multiple behavior patterns: o Internal locking/mutexes for single DA access o Global locking through the transaction manager if appropriate While a sub-optimal solution, it should be usable on any application that has minimal, or infrequent, database access. This means that all access patterns will be serialized. In addition, all DAs at this level *must* release the Python global interpreter lock. Level 3 A database adapter implementing Level 3 compliance must be fully safe running in a multi-threaded Zope instance. In addition, it must support: o Multiple connections in the same thread o Multiple connections in different threads running simultaneously Note that there are instances (see the CLI information below) under which the DA might implement Level 3, but the underlying client libraries are somewhat different. Transaction Manager Issues Zope has the concept of a Transaction Manager which deals with the integration of Zope transactions and transactions in an external data source. New Semantics With the introduction of Zope 2, there are new Transaction Manager semantics, described as below. If you wish to bring a DA into line with the new specification, these methods are what you must implement. o 'self._begin' - This is called at the beginning of every transaction. Depending on your database, and its implementation of "implicit transactions", you may or may not have to do anything here besides a 'pass'. o 'self._finish' - This is called when a transaction is finished, or committed. o 'self._abort' - Obviously this is called when the transaction involved has been aborted. It should *always* roll back the transaction in the database. Integration Requirements Not all DAs talk to data stores which have transactional semantics These Database Adapters should not implement integration with the Transaction Manager unless it makes complete sense. However, all DAs which deal with data stores which do have a transactional semantics should integrate completely with the Transaction Manager. Relational Database Adapters Available OracleDA (v2.0.0) The current Oracle DA is based on the 'dcoracle' package, and is not currently thread safe. It operates at L1 currently, although L2 is trivial. *Near term progress.* Before the final release of Zope 2.0, the Oracle DA will be renamed to ZOracleDA, and will be brought up to Level 3 compliance. *Long term progress.* Plans have been made to split the ZOracleDA into two seperate DAs: o ZOracle7DA - Compatible with Oracle 7 OCI interfaces. o ZOracle8DA - Comaptible with Oracle 8 OCI interfaces. This will also introduce some level of support for LOBs. *Support availability.* Commercial support is available. Note that this is support for the DA, Digital Creations will not be selling general support for 'dcoracle'. ZSybaseDA (v2.0.0) The current internal Digital Creations implementation of a Sybase DA (using the 'ctsybase' Python level interface) is operating at Level 1, with some work having been made at making it Level 2. Currently it has a Sybase-level memory leak when at Level 2. *Near term progress.* Before the final release of Zope 2.0, the ZSybaseDA will be brought up to Level 2 DA. This is being forced by customer requirements. *Long term progress.* While we desire to bring the ZSybaseDA up to full Level 3 compiance exists, it will not happen until customer requirements have driven it. *Support availability.* Commercial support is available. MySQL Database Adapter (v1.1.3) The current MySQL adapter is at least Level 1 compliant, however, it does not currently implement the new transaction manager symantics. *Near term progress.* We would very much like to transfer ownership of the MySQL DA to someone who has a desire to keep it maintained. *Long term progress.* None. *Support availability.* None. SOLID Database Adapter (v2.0.0) Due to the recent change in SOLID Technologies marketing direction and a clarification from their staff that they are no longer interested in the "stand alone" database market, we have deprecated support for this module. *Near term progress.* None. *Long term progress.* We think if desired, this could be implemented in the upcoming replacement rather than in a seperate module. *Support availability.* None. ODBC Database Adatper (v3.0.3) The current ODBC DA is not compliant with any level of Zope 2 Database Adapter thread safety. In addition, it is not integrated with the new transaction amanger symantics. This is a serious problem. *Near term progress.* By the final release of Zope 2.0, the ODBC DA will be modified to be at a minimum Level 2 compliant, based on the available "thunk" mechanism as well as transaction manager integration. *Long term progress.* See information below on the future of a X/Open CLI interface DA. *Support availability.* Commercial support is available. SQL/CLI Database Adapter In the process of reviewing the desirability of an IBM DB2 database adapter, it has come to our attention that both ODBC and DB2 are derived from the same X/Open and ISO specification called the "Call Level Interface", and are both compatible at that level. Because of this, we will be transitioning to a new design for the ODBC DA, as well as integrating support for IBM DB2 into the same DA. Background on SQL/CLI The X/Open Company and the SQL Access Group jointly defined a specification for a callable SQL interface reffered to as the *X/Open Call Level Interface*. The goal of this interface is to increase the portability of applications by enabling them to become independent of any one database vendor's programming interface. Most of the X/Open Call Level Interface specification has been accepted as part of the ISO Call Level Interface International Specification (ISO/IEF 9075-3:1995 SQL/CLI). Microsoft developed a callable SQL interface called Open Database Connectivity (ODBC) for Microsoft operating systems based on a preliminary draft of the X/Open CLI. Version 3 of ODBC conforms to almost all of the ISO SQL/CLI. ODBC 3.0 does contain considerable functionality that is not part of the International Standard; much of this is being added to the next draft of that standard. A Merged DA This new DA will be called the CLIDAzope :-) Actually, we've not come up with a name, but it will be based purely on the CLI specification intially, with small subclasses to deal with ODBC and DB2 individually. This will allow us to leverage two seperate environments at the same time. Eventually we will integrate with DB2s excellent (Oracle are you listening? :-) LOB support, and work to integrate with the support in Microsoft SQLServer 7 wherever possible. Relation to UNIX Platforms Many people have asked about ODBC support on UNIX, and this is the solution. What this provides is the ability to link directly with an SQL/CLI compatible library without having to deal with the issues of an ODBC Driver Manager. In addition, we hope that this will also reduce the performance impact of the driver manager. Non-Relational Database Adapters In addition to integration with relational databases, there are also various DAs which do not talk to "relational" data stores. These include: o LDAP o Ultraseek o IMAP These databases are covered by the same thread-safety levels, but may or may not be integrated with the transaction manager depending on the paradigm that they are constructed inside. Deprecated Database Adapter Issues As you will note, we have deprecated several database adapters which we have handled the distribution of, and therefore they are now orphaned. In order to help people who currently depend on them, we are offering them to the community to take up the torch of support. Toward that end we are willing to: o Transfer code ownership to a new "champion," so long as the license remains Open Source. o Provide CVS repository space for the management of the project. Please let us know if you have the time and desire to take up the banner of these DAs. The Kludge of the Century While we understand that it is desirable to have everything run beautifiully in a fully threaded environment, it is also unrealistic to assume that this will all be done within the next 48 hours, and so we have provided a klduge to get around this issue. This does not escape the requirement for TM integration, it simply fixes the problem with threading in DAs that don't support threading yet, but do use the Transaction Manager. In order to bring your DA into line, you will need to subclass your 'DB' class as follows:: import Shared.DB.ZRDB.THUNK class DB(Shared.DB.ZRDB.THUNK): ... The result of this "thunk" is to create a DA that is single-threaded through the transaction manager. More so, *all* DAs which are "thunked" are single threaded with each other. This means that a MySQL DA will wait on a Sybase DA, and vice versa. While this is sub-optimal, it is at least functional, which is more than many DAs currently can claim under Zope 2. Support Issues Where support has been discussed, please understand that we will try and provide support on an as available basis to all comers, however we can not guarantee support response times and effectiveness to any non-paying customers. This should be taken into account when selecting a DA. When commercial support is offered it is offered in multiple fashions: o Time & materials o Per-incident basis o Yearly contract Please contact Digital Creations for more information about this option. -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

2 2

Re: [Zope] DA Roadmap
by Christopher Petrilli 29 Jul '99

29 Jul '99

> On Thu, 29 Jul 1999, Christopher Petrilli wrote: > >> Gang, >> >> Below is the Database Adapter roadmap that I've just put up on the web site. >> It covers both where we are, how we measure where we are, and where we're >> going. Some of you might find the section dealing with the future of ODBC >> drivers interesting. >> >> Please let me know directly any feedback. > I've been just wondering, but it seems as the ZPyGreSQL DA is not > mentioned at all. Does this mean it is orphaned, or did I miss something? It isn't ours, so I can't speak for it. That's all there is to it. There's also two of them floating around out there. I'd like for *someone* to take up the mantle of the Postgres DA.... then they can tell me what the real story is. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0

RE: ZClasses
by Michel Pelletier 29 Jul '99

29 Jul '99

> -----Original Message----- > From: Jason Spisak [mailto:webmaster@mtear.com] > Sent: Thursday, July 29, 1999 2:39 PM > To: Michel Pelletier > Subject: Re: ZClasses > > > Michel, > > When you distribute a product to another machine and that product has > ZClasses in it, if you create a bunch of instances then upgrade to the > next distributed product, are those instances still tied to thier > classes? If not, it makes if virtually impossible to run a > system on a > distritbuted product, and you have to copy the Data.fs from the > development machine to the real environment. What it the > skinny on this? > This will work, if the ZClasses didn't originally come from an old ZODB database. If your ZClasses are older than alpha 4, then you will need to make sure that the 'upgrade' ZClasses have the same Product/ZClass/Basic/ClassID as the old ones. -Michel > Jason >

1 0

RE: [Zope-dev] RE: [Zope] ZOracleDA Null Columns and Authorisatio n
by Michel Pelletier 29 Jul '99

29 Jul '99

> -----Original Message----- > From: Michel Pelletier [mailto:michel@digicool.com] > Sent: Thursday, July 29, 1999 11:39 AM > To: 'Anthony Baxter'; Michel Pelletier > Cc: 'zope-dev(a)zope.org' > Subject: [Zope-dev] RE: [Zope] ZOracleDA Null Columns and > Authorisation > > > > > another _really_ ugly issue is that if you create a second ZSybaseDA > > connection, to a different database, Zope hangs. > > > > this is not good - I haven't had time to look at it. > > This is because the C module has a bunch of global variables, > including > the connection (ie, a connection is not malloc()ed for each DA, but > there is one global static one for the C module). Uhm wait, this is not the reason. Which version of Zope are you using? > > The ctsybase module needs alot of work. > This is still true. > -Michel >

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Zope-Dev July 1999