Re: [Zope-dev] Request for a Pluggin Index (NameIndex)

2001-06-06 Thread ender

On Monday 04 June 2001 16:55, Andreas Jung wrote:
Looks like you should write your own index type. Zope 2.4
comes with an PlugableIndex interface to allow third-party
indexes to be integrated into the Catalog.

this brings up an interesting question of what is the best way to register a 
new plugindex thats distributed with a product. Glancing over the cvs logs it 
looks as though plugin indexes are arranged to be the first product installed 
in Given that what is the suggested method for registering a 
new plugin index?


- Original Message -
From: Chris Withers [EMAIL PROTECTED]
Sent: Monday, June 04, 2001 4:05 PM
Subject: [Zope-dev] Request for a Pluggin Index (NameIndex)


 If anyone's got the time or fancies a challenge, could they write an
 index that behaves as follows:

 Indexed values:
 1) C.J.Withers
 2) Chris Withers
 3) C Petrilli
 4) Christopher McDonough

 search result
 C  1,2,3,4
 withers mcdonough  1,2,4
 Chris  2,4

 I think the basic rules are:
 - split on whitespace and punctuation (not accentuated characters and the
 like ;-)
 - index each remaining name part
 - when searching, return all records where any of the name parts match
 something like:

 ...oh yeah, and do it blindingly quickly ;-)

 This would be really useful for the Creator dublin core field and
 anywhere you're searching for someone's name. The CMF could benefit from
 it and


 eliminate the phrase next to the Creator field which has haunted me from

  Note that you must enter their username exactly. 



 Zope-Dev maillist  -  [EMAIL PROTECTED]
 **  No cross posts or HTML encoding!  **
 (Related lists - )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Experiments with ORMapping

2001-05-14 Thread ender


i want to thank DC (jim, shane, and paul) for inviting me to come to the new 
DC offices. i had a great time and learned a bunch... and met 
the BFDL.

i gave a quick overview of the smartobjects design/framework and  jim and 
shane presented some ideas for an or mapping for the zodb.

to be honest it seemed both extremely elegant and slightly disturbing at the 
sametime. I've grown accustomed to treating the ZODB as a magic black box, 
that just works. integrating an or layer at this low level disturbs me as it 
meant that application developers would need to tinker at the lowest level of 
the zope framework, plus the dangers that to properly support application 
development the zodb would need to be bloated with accessory apis. at the 
same time it offers a really elegant way to make the or mapping available to 
python programmers on a pure python level (which is something i'm also 
interested in). 

for both approaches there are some similiar problems that must be tackled, 
namely definition of the or mapping, generation of stub python classes, 
integration with zope notions (permission, etc). so hopefully discussion here 
will flesh out, to the point of making a choice clear.

i'm primarily focused on doing the or mapping definition in xml, as its 
language neutral and allows me to leverage other tools (like torque to assist in application 

i've thought about it for a few days, and while i'm not convinced completely
that a zodb approach is the best method, i'm going to start work on the some 
of the support classes nesc. for moving forward, namely some of  the xml 
model/generators outlined in my design (embryonic)

most of my concerns echo the issues that philip has brought up re the 
need of application developers. i do feel some if not most of these issues
can be solved, i'm just wondering if for zope this is the best solution. for
pure python development it seems alright. for zope, i wonder if a higher 
level application framework is more suitable. 

to clarify some existing points in this thread to date.

- (IMO) zpatterns is about two things, delegation and data abstraction at
the application level. the zpatterns framework doesn't assist in automating
this and its up to the integrator/developer to manually wire together all the 
app/business objects. the smartobjects framework is about automating
development and presenting easier development interfaces for both 
developers and designers. this isn't to say that such automation and 
interfaces couldn't be built on top of zpatterns, just to say that there are 
some different design goals. 

- one of the primary goals of smartobjects is easy integration with zope in a
manner that is natural for zope developers. this does not mandate a new db 
access api, its about facilitating automation of this api so that the objects 
can be treated as normaly zope objects. both approaches (smartobjects and or 
zodb) must still tackle similiar fundamental issues to integrate with zope. 
on the zodb level this seems complicated to me (which betrays my incomplete 
understanding of the zodb internals), plus it requires some additions to the 
zodb interface to allow effective application usage (namely a generic query 
mechanism, and probably interogation of a class information). 

- one of my main objectives in developing an or mapping is to use the
acs4 ( applications natively (or as close as possible) 
within zope.

- my smartobjects design ( is
mine, in that smartobjects is primarily a iuveno project this does not mean 
it is smartobjects. stephen richter (of iuveno) liked parts of the design and 
will likely use it parts of it in a iuveno implementation but what comes out 
of iuveno is not limited or beholden in anyway by my proposal. the key focus 
of the proposal is a metamodel (schema) based approach.


- i think any integration of or layer should be complementary to the zope 
framework. shane's existing examples and discussion of an or layer seem to be 
more geared towards replacing the zodb, than complementing. is the idea to 
use some sort of zodb product as a mounted storage?, or is this a replacement 



Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Re: [Zope] **Important Notice** for Zope public CVS users

2001-04-13 Thread ender

On Friday 13 April 2001 02:22, Oleg Broytmann wrote:

On Thu, 12 Apr 2001, Brian Lloyd wrote:
 We are soon going to begin checking in changes to the head of
 the Zope CVS that will require the use of Python 2.1. Once we
 start on the 2.4 tasks, you will not be able to use a public
 CVS checkout of Zope with older Pythons.

   Why not make a branch, and port some important things from one branch to
the other? This allows people to checkout from the branch, not from the

i asked brian much the same thing on zope-dev (i was trying to avoid cross 
posting). his is response follows. 


There is (and will continue to be) a "current release branch", 
which is the branch that stable (bug-fix) releases are made 
from. Currently the release branch name is 'zope-2_3-branch'.

This is probably the branch that most CVS users actually want 
to be using anyway. Running from the trunk you get all of the 
latest bugfixes, but you also get all of the latest half-baked 
work for the next feature release - which might be worse than 
the bugs you were trying to avoid in the first place :)

So if you are running from CVS (but are not running from the 
current release branch) you can go into your local copy and 
do: 'cvs up -d -P -r zope-2_3-branch' to update to the release 
branch checkout.

The warning is mostly aimed at the bleeding-edge people who 
use the CVS trunk. If you are running the release branch you 
will continue to get bug fixes and will not need to upgrade to 
Python 2.1, as the changes in preparation for 2.1 will only 
go into the trunk.

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] **Important Notice** for Zope public CVS users

2001-04-12 Thread ender

On Thursday 12 April 2001 12:46, Brian Lloyd wrote:

We are soon going to begin checking in changes to the head of
the Zope CVS that will require the use of Python 2.1. Once we
start on the 2.4 tasks, you will not be able to use a public
CVS checkout of Zope with older Pythons.

We are not going to start this until after Python 2.1 final
is out (expected next monday), but wanted to give CVS'ers
fair warning. If you are using the current public CVS and
don't want to start using Python 2.1, you should either
avoid doing any CVS updates until you're ready to migrate
or move off of CVS to a current (2.3.1) release.

will there be a 2.3 maintenance branch or will all development stop on 2.3?



Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] ZPatterns, DataSkins, forms and error checking/handling

2001-04-06 Thread ender

On Tuesday 27 March 2001 17:40, Itai Tavor wrote:

I'm trying to work out the best way to check for and report errors
when DataSkin objects are created/edited, but I'm having a lot of

For form validation, Zope's build-in constraints are pretty
useless... things like ValueHandler are a little better, but IMO not
good enough. When a user types incorrect data in a form, I don't want
to display a page with a list of errors and say "click Back to fix
your errors". I want to return the form, with a list of errors and
the bad fields highlighted. So I need to perform field checks in the
form action method and in case of errors call the original form,
giving it an error list.

I know that to ensure that object data is always valid I should
validate the object in a SkinScript, using WHEN OBJECT ADDED,CHANGED
call self.validate(), and raise an exception in validate in case of a
problem. But this can't deal with returning the original form. It can
only display error pages, and to display nicely formatted error pages
it has to return a DTML Method so I can use dtml-raise, rather than
directly do raise in validate.

So I'm looking at a validate method for use at commit time, a
show_errors DTML Method, and a validate_form to call from the form
action method...

The validate_form method is defined in the DataSkin class. But it is
also used when a new object is created from a form, so it needs to be
called from a Specialist before the object is created, so I need to
import it in the Specialist. But this method might use other methods
of the DataSkin class, so I need to import those too...

So, to sum up, I need a method used in commit time, that renders a
DTML method to raise an error message, another method to verify form
submissions and return the form with error messages, and I need to
import that method and all other methods it uses into the Specialist.
This seems too much work...

Can anyone suggest a simpler approach (one that still retains the
ability to return the original form in case of errors)?

check out dtml-contract.

sample form processor with dtml contract

this page retrieves records from the db based on user input
foobar:range(int, 0,10)

user gets redirected if bar is not a valid date string, and foobar is not a 
integer compatible string between 0 and 10. if foo is present it must be a 
integer compatible string (compatible means coercible via int(foo)). if any 
of these things does not happen than all the collected errors for the page 
are sent to the error handler bad_user_input. this is not a redirect, the 
error handler is evaluated in the context of the page with an additonal value 
added to the namespace to denote the list of errors. page processing stops 
after evaluation of the tag if an error occurs.

this may be clear as mud, i don't know, i tried to make the included 
documentation pretty inclusive and readable, its not completely insync with 
the code but it does elaborate on the feature set pretty well. if you have 
specific questions feel free to ask.

so in your case you can just use the original form as the error handler and 
add logic to it to insert the values if they already exist in the request, 
and display error messages to the user on the particular vars that have 
problems based on the existence of the special error variable.



TIA, Itai

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] DBObjects 1.0 and Demos for Proiektor ZQuest released

2001-04-05 Thread ender


this seems pretty cool, and i'd like to thank stephen and iuveno for 
releasing it, but the release seems pretty half-baked.

the website
1. dbobjects demo is not existent
2. the documentation for projektor is password protected
3. there are no downloads apparent for anything but dbobjects

dbobjects distro
1. no, hence not usable in zope without guessing your own.
2. the DBFolderishObject references a SQLTools module that is not present
   - it does not seem to use this so i just removed the reference.

1. it should be explicitly stated that these are for subclassing in python
and the name restrictions imposed.

dbobjects arch
1. no use of volatile variables to minimize read/writes to db.
2. the use of exec can lead to only sorts of ref count problems, using
of __imp__  (or imp) would probably be better. 

hopefully some of the above can be fixed, and then i'm sure these products 
will see some use in the zope community.



Hello everyone,

iuveno AG, Ingolstadt Germany, has made available a demo and products page,
releasing several products:


1. DBObjects 1.0 - DBObjects is a framework that maps relational data to a
Zope object tree. It provides many features (such as SQL Method
auto-generation) and saves up to 95% development time on object creation
with relational data. API Documentation, a Demo, Feature List and so on are
available on the site.

2. Proiektor - Proiektor is a groupware and project management system
developed by iuveno. It is based on DBObjects and implements a nice set of
features with some unique design ideas. But see yourself...

3. ZQuest - ZQuest was originally written for a university as testing tool
and is now also developed by iuveno AG. It has a good set of features,
especially for scientific questions. ZQuest uses DBObjects of course. If
you are interested, click on the link above ...

4. CMS - Our Content Management System is coming soon with a true
user-friendly management interface...

ALL THESE PRODUCTS ARE OPEN SOURCE!!! Please feel free to contact me any
time via E-mail ([EMAIL PROTECTED] or [EMAIL PROTECTED]) or via phone at
+1-901-230-ZOPE (9673).

I hope you enjoy!


Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development  Technical Project Management

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] SAP DB -- ZODB ?

2001-03-10 Thread ender

On Friday 09 March 2001 07:20, Steve Alexander wrote:
I just heard that the SAP DB has gone Free and Open Source.

sapdb isn't open source yet. it will be in a few months. when it does it 
looks like it will instantly become the most advanced open source database 
out there. my current rankings of the general os rdbms  in terms of features 

currently sapdb has only opened the database manager and the client 
interfaces as well as the build environment needed to make these from src.

the feature list of this database is astonishing

to name a few
outer joins
sql 92 compliant, possible modes for db2, oracle 7
very nice prodecural sql language.
lots of statistics information
really rich set of standard functions
scrollable cursors

this is a great candidate for a zodb storage


  SAP DB is an open, SQL-based, relational database management system that
   provides high availability and performance scaling from small to very

  In addition, SAP DB goes beyond relational database technology by
 offering object orientation as well as support for managing unstructured
 data. It supports open standards including SQL, JDBC and ODBC; access from
 Perl and Python; and HTTP-based services with HTML or XML content. SAP DB
 is platform independent, so users can deploy it for a wide array of

   Since 1994, the SAP e-Business Solution is available on SAP DB
Today  SAP DB is being used by nearly 800 customers.

  On October 5, 2000, at Linux World SAP DB was announced to be made
as Open Source software using the GNU General Public License for the
kernel and the GNU Lesser General Public License for clients and
 programming interfaces.

I'd never heard of SAP DB before, although I've heard of SAP.

This looks as if it would be good for a ZODB storage.

Steve Alexander
Software Engineer
Cat-Box limited

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] The field converters (:int, :text, etc.)

2001-02-06 Thread ender

my alpha quality dtml-contract tag does allows custom field converters much 
as has been requested here, its meant as a generic form processing engine 
with the ability to define per variable error pages. its got some other 
features. its modeled on the arsdigita (acs) ad_page_contract.

due to my stupidity you have to add a custom filter directly to the filter 
dictionary defined in

fyi for the license impaired its gpl'd

available at


  On 4 Feb 2001, at 15:59, Morten W. Petersen wrote:
   IIRC, there was some talk about modularizing the field
   converters (checkers) so that they could be easiliy modified
   and added to.  Is there currently any efforts to solving
   this problem?  If not, there's definently a need for it,
  I agree. Each time I get a Zope update I have to edit
  What I want is something like :empty_as_none
  So a float, int or date field will be passed as None if the fields are


  rather than having the converter raising an exception.
  ignore_empty doesn't work, because then the field isn't passed in the
  Record at all.
  I use SQLDict as the backend for all my forms (wow, it's great), so None
  really is needed for every field if its blank. If I have ignore_empty,

 then that

  field doesn't get updated in the database, so if someone wants to blank
  out a field, they can't do it.
  Brad Clements,[EMAIL PROTECTED]   (315)268-1000  (315)268-9812 Fax
  netmeeting: ils://   AOL-IM: BKClements
  Zope-Dev maillist  -  [EMAIL PROTECTED]
  **  No cross posts or HTML encoding!  **
  (Related lists - )

 Zope-Dev maillist  -  [EMAIL PROTECTED]
 **  No cross posts or HTML encoding!  **
 (Related lists - )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Creating IMAP and SMTP services for Zope

2001-02-03 Thread ender

On Saturday 03 February 2001 10:28, Morten W. Petersen wrote:
 Hi guys,

 I'm wondering about creating IMAP and SMTP services for Zope.
 Someone mentioned to me that extending (using?) the ZServer
 could be a Good Thing (tm).

probably. i've always been curious though about the threads in zserver, i 
thought they were allocated to handle only zpublisher requests (maybe just 
http requests). assuming you don't want to tie up the thread handling the 
asyncore it seems you might need to create a pool of threads for handling 
requests, or adjust your code to translate imap/smtp requests into zpublisher 
requests so the default pool can be used. granted if you're not also running 
a  busy website on this than it probably won't be a concern as esp. if the 
server operations are fast.

 Could anyone point me in the right direction?

micheal already pointed out his imap code. i'd like to give warning that 
handling imap properly with different clients can be a pain. the protocol is 
a bit complex and there are some gray areas, which different clients handle 
differently. pop is much, much simpler if you want to go that route (with the 
option of just leaving mail on the server, you might be able to treat it 
superficially  like imap).

barry warsaw has an async implementation of a smtp server that he uses to 
test out mailman, its on his homesite at



Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

[Zope-dev] Re: [medusa] Re: [Zope-dev] asynchat producer ready() method patch.

2001-01-31 Thread ender

On Wednesday 31 January 2001 04:18, Donovan Baarda wrote:
 On Mon, Jan 29, 2001 at 07:26:56PM +0100, Dieter Maurer wrote:
  Donovan Baarda writes:
On Sun, Jan 28, 2001 at 09:31:07PM +0100, Dieter Maurer wrote:
 Donovan Baarda writes:
   I remember reading ages ago on a wishlist for ZServer that
   someone was thinking of adding blocking support to producers.
   This patch adds support for just that in a non-intrusive way. I
   haven't tried applying this patch to ZServer, but it _should_

 What does "blocking support dor producers" mean?
Disclaimer: you must be moderately familiar with
ZServer/medusa/asynchat for the following to make sense;
Asynchat used by ZServer and medusa use producers as a way to "push"
data through an async interface. The current version of asynchat
requires that producers be able to produce data immediately on calling
their more() method, untill they are finished, when they return ''.
My patch adds support for producers being able to "block" by letting
asynchat know if they are ready via a ready() method. This allows you
to use the simple producer model to push data that may not be
immediately available. An example would be a http-fetch producer that
fetches data from upstream for a proxy.
This patch is only useful for people creating or modifying things like
medusa or ZServer.
  Thank you for this good explanation.
  By now, I think, it would not be usefull for ZServer, at least
  not for standard operations.
 ZServer is a multi-threaded server, where different requests
 are serviced by different threads.
 The thread may block and does simply not return from "more()".
 On first thought, you patch might free some blocked threads
 to do productive work. However, Zope's transaction system
 is linked to thread management. If you patch would be used
 for that, Zope's transaction subsystem would need to be

 Hmmm, it's been a while since I looked at ZServer, I might have to take
 another look. I thought that it pre-spawned a number of threads that each
 ran their own asyncore.loop event handler. I thought this was a neat way to
 get the benefits of async event handlers and distributing threads on
 multiple processors. Unless it spawns new threads when it needs them, it
 would still be possible for ZServer to get blocked if all the threads were

disclaimer: insert here.

zserver has a main thread which binds and listens, passing requests to a pool 
of zpublisher threads. the zpublisher threads communicate with the client via 
the main threads dispatcher, ie output is funneled back into the main 
thread's dispatcher so as not to tie up threads talking to distant clients.

reference: Zserver/medusa/

python has a global interpreter lock, so multiple cpus have little utility. 

 However, my patch is only useful if you _have_ producers that can block. It
 is usually possible to re-structure your system so that no producers block
 (typicaly by using a dispatcher instead of a producer). The ready() block
 feature is really a shortcut way of modifying an existing producer-based
 design when you realise that the producer can block; ie an alternative way
 of implementing it that may or may not be better.

i've taken a quick look at the patch, i find it interesting in that it 
provides i think a way to implement a Proactor type server vs the standard 
medusa Reactor style server.

reference: Patterns of System Architecture Vol II.  Douglas Schmidt et al

and a webserver that makes use of this pattern


 In my case I wanted to create a cached-ftp-backend filesystem that medusa
 could serve via ftp or http. Unfortunately the existing ftp and http server
 implementations used producers to pull data from the abstract filesystem.
 Since my "filesystem" could block pretty severly, I either needed to
 completely re-write the http and ftp servers to use dispatchers instead of
 producers, or implement blocking for producers (or use a seperate thread
 for each request, but I thought that defeated the purpose of using an async
 event loop).

 I really must look at ZServer to figure out how it handles things... I
 suspect that my patch by itself would not _hurt_ ZServer, but perhaps if
 you started using the ready() feature it provides it might cause problems.
 I'll have a look at ZServer again soon and give you an evaluation of how my
 patch would interact with it.

 Who knows, someone might find a need for blocking producers as ZServer
 evolves, and if people know the patch exists, they might use it instead of
 re-structuring to get around it :-)

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or 

[Zope-dev] Annouce Developer Version DTML-Page-Contract

2001-01-22 Thread ender

hello zen masters

i just finished documenting a developer version of a port of the ACS's 
(arsdigita community system) acs_page_contract to dtml.  test it out,
i'm pretty sure everyone will be happy with the simplification of the 
resulting dtml. 

feed back and thoughts welcome.

if no bugs are found in the next week or so i'll make it a general release,
new filters are always welcome.

available at


readme included below.


extract PageContact.tgz in your zope directory. it will create
a python product in lib/python/Products. you will need to
restart zope before you can use dtml-contract

remove the PageContract directory from lib/python/Products and
restart zope.

I. What
Page-Contract is a python product that adds a new type of dtml-tag 
to your zope installation. dtml-contract is a multi-purpose tag that
is designed to provide documentation, marshalling and filtering of
request data, and custom error handling of the request data. the
documentation comes from a read only section of the contract 
which should describe the purpose of the object, its author, and
some information about its parameters. the marshalling and filtering
is done by naming variables expected in the request and associating
one or more filters with those variables. PageContract comes with
a set of prebuilt filters although it can easily be extended by
writing new filters. lastly it allows association of different
error handlers to different variables.

II. Why
Zope already includes facilties to perform simple marshalling of 
REQUEST values submitted via GET/POST into python data_types. This
facility is built into ZPublisher. There are a couple of problems
with this facility in real world usage. First, ZPublishers 
marshalling isn't secure because it retrievesmarshalling info from
the REQUEST, a cracker could perform url surgery to by pass
the marshalling. Second, ZPublishers marshalling isn't easily
extensible to provide application level support of. The marshalling
is buried square in the guts of the Publishing process, even if you
did extend it would be too early in the Publishing of the object to
perform any meaningful application specific processing (ie you don't
know where you're going so how do you know what you'll see when you 
get there). Third ZPublisher has no concept of excluding parts of 
the REQUEST that aren't needed, this is mitigated by Zope placing the
REQUEST on the bottom of the namespace stack, however it still 
provides a means for accidents (ie. you're expecting this object to have this
attr, but it doesn't but the REQUEST has that attr). dtml-contract 
can optionally strip the REQUEST of variables not explicitly named
within it. Fourth, ZPublisher is inflexible about how it handles 
errors. ZPublisher has hardcoded return values whenever it hits
a bad input AND it short circuits the evalutation. Users don't 
get informative messages regarding their errors other than they 
made one. dtml-contract differs in that it collects all errors 
and associates them with their variables and provides the option
of custom error pages on a variable by variable basis with 
information passing about the errors. (The current implementation
is limited in that it only passes a list of filter errors to the
error handler via a url string.)

The dtml-contract also hopes to offer a standardized form
of documenting your zope objects (DTML_METHODS, DOCUMENTS,
and the like) by standardizing on a documentation format
and a location for that documentation.

III. How
So how do you use it?


Documentation about this object

@author Kapil Thangavelu [EMAIL PROTECTED]
@params myobj_id the id of the object where after
@params title we'll set the object's title to this value
@params thedate should be the range of the bada and bing
@params foobar optional integer value that tells us whats going on


thedate:range(date, 1.1.1, 11/11/11)

Generally dtml-contracts should be used at the start of a dtml
page. why? so they can be easily referenced for documentation
and knowledge of the expected parameters.

Caveats. Note that there are no strict enforcements of the documentation
section. Although some future documentation extraction 

Re: [Zope-dev] Massive scalability

2001-01-17 Thread ender

On Tuesday 16 January 2001 20:42, Michael Bernstein wrote:

 Are you saying that Zope's startup and shutdown time is
 affected by the size of the ZODB?

AFAIK on a filestorage zope loads up the indexes (oid, file_offset?) into 
memory on start to facilitate object retrieval which impacts start up time. i 
don't think the other storages operate this way.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

[Zope-dev] mounting obj to more than one zodb location

2001-01-17 Thread ender

whats happens when you create a persistent object and mount it 
to multiple points on your zodb. do you get a shared ref or multiple
copies of the object?


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Questions, Jar, Transactions, Metaclassess, ZPatterns

2000-11-27 Thread Ender

sorry for the poorly worded question (midnight madness), let me try and
restate them a bit better in the fond hope that someone will answer any
of them.

whats is a jar? as far as i know its just the data  representation of
the object that gets stored in the zodb, hence its directly related to
the __dict__ of the object. but then what is the signifigance of calling
methods directly on the jar like i see in some of the transaction
machinery, is this an indirect call to the thread's zodb connection?

 does zope restrict you from doing metaprogramming with python products?
 or does zope's own metaprogramming reserve some names __klass__, etc?

i was reading through guido's essays yesterday, and happened upon the
metaprogramming essay ( i read it when i was first learning python but
it made a lot more sense now:). i was thinking about creating my own
caching metaclass, but i know that acquisition (and probably
persistence, and zclasses) use some c-based metaclasses to work. i'm
just curious what the possibilites and restrictions are of doing
metaclasses in zope, so my classes play well with others. 

in /lib/python/Shared/DC/ZRDB/, i see the class Surrogate defining
methods for __inform_commit__ and __inform_abort__, what are these for?

In ZPatterns/ I see some talk of transaction boundaries,
namely the inability for an object participating in the transaction to
know that a transaction is finished. From my understanding of
transactions i thought that an object could assume a transaction was
over if it has its tpc_finish called on it when its not in a
subtransaction. I understand that the Zpatterns problem here might be
related to providing attrs to other objects which might be used in a
tpc_finish but i just wanted to clarify/make sure.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] objectValues performance

2000-11-27 Thread Ender

Brett Carter wrote:
 I have a folder with greater than 5000 ZClass instances in it.  It
 takes  5mins to do an objectValues for every object in the folder -
 is there a higher perfomance call I could make?

use a catalog. (which only help if you want a filtered set or a schema
attrs of the object)

beefing up your memory (assuming you want zope to use alot), could also
help, assuming these objects are accessed frequently enough to stay in
the object cache.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] SQL-Methods Through-the-FileSystem

2000-11-26 Thread Ender

Johan Carlsson wrote:
   Does anybody have a good suggestion how to
   develope SQL Method ftfs (through the filesystem)
   rather than ttw.
   Perferably in someway similare to the HTMLFile way
  try something like this:
from Products.ZSQLMethods.SQL import SQL
import PoPy
def manage_add_user(self,email,password):
  conn = 'PoPy_database_connection'
  self.sql_add_user=SQL('sql_add_user', '', conn, 'email password', 
  _sql_add_user = """
  insert into tbl_users(email,password)
  values (
dtml-sqlvar email type=string,
dtml-sqlvar password type=string
 Hi Seb,
 I guess I could skip putting it in a method and create the SQL instance
 as a attribute of the class (that I currently would be working on)?


 Why do I need to import the database module?

sql methods are bound to database connections, you could instantiate one
without, but than you wouldn't be able to use it. 

 Couldn't I just try to locate/create a DA when my class is instantiated?

you could, the search routine in /lib/python/Products/ZSQLMethods/
is a good starting point

 Would it be poor design to create a DA connection as an attribute of the class?
 Or would it be perferd to create it in the __init__ as a instance attribute?

do you really want to create a new db connection for every instance of
your class?


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Conflict Errors

2000-11-22 Thread Ender

Chris Withers wrote:

i'm no expert but deeply nested data structures in a single object are
rife with possibilities for conflict errors. if data might be changing
concurrently in the structures or frequently changing you would be
better off to switch the structure to nested persistent objects.

 No, for once it has nothing to do with the catalog. ;-)
 This is a python product of ours that stores lots of data in somewhat
 nested, persistent dictionaries. How can this be improved so this
 doesn't happen?
  I know your next questions are going to be "why?" and "how do I fix it?" and
  "why don't you fix it?".
 While I'd love it if you'd fix our code for free, it's probably beyond
 the OSS remit ;-) Any clues about how to make our code 'less bad' would
 be cool...
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 **  No cross posts or HTML encoding!  **
 (Related lists - )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] strange FTP bug

2000-11-16 Thread Ender

Robin Becker wrote:
 I'm using python's ftplib to automate transfer of my dtml methods back
 and forth into my ZClasses
 I seem to be unable to GET a method called 'filtered_meta_types'
 I get instead a permissions error 550. I get the same transferring using
 another FTP client. I checked the ownership etc and it should be OK. I
 can only think it's some horrible acquistion problem relating to the
 default filtered_meta_types thing. Indeed when I rename to FMT it all
 works quite happily. Is this kind of 'feature' known/expected?

filtered_meta_types is used by zope to keep a list of the object
types/meta types that a user can create (and interact? with) in the
current context.

so yes this behavior is known and expected, else it would be possible to
bypass the security system.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] 2 Zopes

2000-10-25 Thread Ender

Andre Schubert wrote:
 Can anyone tell me a way to get Zope Objects from the first
 Zope-Installation to the second.
 I need this because i have to program a Product to putting data into
 different Zope Installations from one point of the Web.
 My boss want this way because he want a central point for data input,
 where the data are of different type and therefore they have to stored
 in different locations( different Zope Installations) My idea is to use
 ZPublisher.Client, but i don't find a way to use it.
 thanks as

i've never done it before, but the options as always are multiple
depending on your needs and requirements.

if you can distill your objects down to simple python types (lists,
dicts, etc) you can try using xml-rpc and reconstructing the object on
the separate system. there is even a product that uses xml-rpc to
facilitate sharing between zope installs.

if you don't need to really replicate the info, and depending on the
frequency which it will need to be accessed you can just use xml-rpc to
a function on the second server and display the results directly on the
first server.

if you need to copy the actual objects verbatim you might want to
investigate exporting to zexp and using file transfer between the hosts
and (using Client to faciltate calling into zope) importing them on the
second server.



Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Unit testing, ZUnit

2000-10-23 Thread Ender

What do people think of this? 

you get my vote


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Excluding meta_types

2000-10-22 Thread Ender

you can redefine the meta_types tuple like so

btw how is GUM going?


"Morten W. Petersen" wrote:
 When I'm building a class which inherits from the OFS.Folder.Folder, how
 do I exlude the meta_types it brings with it (if it's there they come
 In other words, if I have a class, with meta_type 'MessageFilterFolder',
 which should only be able to contain instances of meta_type 'MessageFilter',
 what do I do (i.e. exlude all the other meta_types)?
 Thanks in advance.
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 **  No cross posts or HTML encoding!  **
 (Related lists - )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Object references from dtml

2000-10-20 Thread Ender

Ross Boylan wrote:
 I have a log composed of sublogs, and so on.  I would like for people to be
 able to see some kind of summary (e.g., short versions of the logs down n
 levels) on the screen and then click on one of interest and see a fuller
 display of it.
 Is there a good way to do this using dtml?
 I've thought of two approaches.  The "standard" zope

having recently debugged company's zope server, i can safely say that
there is no 'standard'.

 way seems to be to
 make each log folderish, and give each entry an id.  Then I can embed the
 address in the html.  The problem with this is that I would have to make up
 the id's and add extra machinery that the logs don't really need.

 I'm leaning toward a second approach, of getting an object id and putting
 it in the html.  This also raises some issue.

you lost me. your problem with the first method is having ids for your
log entries and your second method starts with getting ids for your

looking ahead, YIKES, you just went from can i do this in dtml to
messing with python code in the guts of the ZODB. that was a SERIOUS
leap. IMO i'd highly recommend against messing with the zodb stuff, _p_
attrs are supposed to be reserved. i understand you want to treat them
as read only, but i wouldn't even go near it if it could be implemented
easily otherwise or i had developed a strong masochistic tendency and
already knew the zodb well (well enough to know the answers to the below

 This also raises some issue.
* Will the id be stable in the face of the db potentially
 dematerializing objects underneath?

what id?

* If I use a persistent id (_p_oid, I think), will that be stable?

see above commentX2.

* (Also, I'll need to be sure everything has persisted, but I think I
 can do that by forcing a transaction end before getting the _p_oid).

transactions are important, but also telling it before hand that the
object is dirty and needs to be saved. you might want to read jim's
paper on the zodb. it and alot of other good material are linked from

* Can I map from object id back to object?  (_p_jar.something or other)

this is getting worse(scarier?) as i go on... i have no idea. consider
also that a url is also a unique persistent object id that maps into the
zodb, why your first method works. 

* Will this be robust across database changes (minimally, from ZODB to
* Will the object id consist of characters which can be embedded easily
 in html?


there are alot of other ways to do this... of the top of my head

you could always store log entries in a sql db. 

since you seem not adverse to doing it in python, despite your original

so why not just write a python class for the log folder thats
persistent, add some methods for managing/storing log entries in a some
attr (maybe list of dicts) of the logfolder. write some dtml accessible
accessor methods to the attrs. write a dtml page for summary and one for


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Re: [Zope-dev] Lists of Objects

2000-10-19 Thread Ender

please don't post html to this zope mailing lists, many people aren't
using html email readers

 Jack Fitzgerald wrote:
  I am currently keeping a list of objects sorted in a particular
 object. I am wondering if
 anyone has an opinion about whether I should keep just the 'id' in
 this list or if it is ok
 to actually keep a reference to the object in the list. When I use the
 list at a later point in time
 I will need to access several attributes of the object. If I keep the
 'id' I would have to find the object
 for each entry in the list. Thanks in advance for any opinions.
 -Jack Fitzgerald

depending on your application you could just do it the way zcatalog does
it and store the url and resolve the url to an object when you want to
access attributes.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )