Re: [Zope-dev] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
On Feb 19, 2004, at 1:09 PM, Jeremy Hylton wrote: Jeffrey, Any luck with your core dump? I recompiled Python 2.3 with a bigger stack size, and that seems to have worked. We had similar problems with Python 2.1.3 (it's a pretty infamous Python+FreeBSD problem, AFAICT), and I thought that it was patched in the Python core by now as I thought I heard something along those lines a while back, but I may have been hearing about the patch being applied to the BSD 'ports' collection. -- Jeffrey P Shell [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Core Dump (Zope 2.7, Python 2.3.3, FreeBSD 4.5)
I've been experiencing the most peculiar core dump under Zope 2.7. It's on a web application we only decided to revive late last week, so it was never tested under earlier beta/RC conditions. The core dump occurs when visiting manage_main on a particular folder. The contents of this folder are basically just Python Scripts, Page Templates, and a few DTML Methods (including standard_error_message). I can get manage_main to render in zopectl debug (using Testing.make_request to make enough of a REQUEST object for it to render with). And I can read everything in that particular folder with zopectl debug. I used this to experiment with moving items around between folders - including moving all of the templates/scripts into their own folder outside of the web application. It still core dumps. At one point, I thought I had narrowed it down to a particular template (although the reasons for why it would be this template elude me) by doing some interactive Python work [I had written some helper 'move_object' and 'copy_object' functions a while back, and used them to move items between a pair of folders and then seeing which one Zope would crash on]. I got the contents of the template out using ``zopectl debug``, and recreated the template by hand, now that I could actually get into the target folder. It worked for a brief moment, but so did the source folder, which now had this one particular template remaining. I tried various imports and exports of the web application, including using one that was known to still be working off of a production server (Zope 2.6.1, Python 2.1). I even tried copying the contents (individually) of the folder - completely removing them from original context. It still core dumps. (Before I tried imports and exports, it was running in a Data.fs that had been copied from a Zope 2.6.1 instance to 2.7. Python Scripts were recompiled) Finally, I thought it might be a Python 2.3.3/FreeBSD issue (like there were issues with default stack size on Python 2.1.x and FreeBSD). This Python 2.3.3 had been built from source just last week, on the day I installed Zope 2.7 final on our development server. So I downloaded Zope 2.6.4 and ran that with Python 2.3.3, importing the problematic export. I could list the contents of this particular folder just fine. The import had Python 2.1 compiled scripts, so I recompiled them and exported it again just to see if that was causing strange issues - but when brought into Zope 2.7, the core dump still happens. The folder in question is not terribly large - when I extracted the scripts/templates manually into a new folder, I think it has about 41 items in it. What should I do next? Should I familiarize myself with gdb and inspect the core? What are some things I could look for if that's the next step? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] how can I prevent undo?
Actually, this should be doable by removing access to the ``Undo changes`` permission. -- Jeffrey P Shell [EMAIL PROTECTED] On Oct 26, 2003, at 1:49 PM, Andreas Jung wrote: By removing the Undo tab or by removing Un doSupport from the baseclasses of your objects? -aj --On Sonntag, 26. Oktober 2003 20:38 Uhr +0100 robert [EMAIL PROTECTED] wrote: Hi there, I have objects that are linked to an external database. When they are deleted, also the data in the external database is deleted. Now an undo is bad, because I then get an object with ab link to non existing data. I must therefore prevent undo. How can I do that? Thanks, Robert ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [CRITICAL] Conflict Errors, Transactions, Retries, Oh My....
On Thursday, May 29, 2003, at 07:32 AM, Chris McDonough wrote:
On Thu, 2003-05-29 at 01:08, Jeffrey P Shell wrote:
Thanks for the information. Is it safe at all to try to catch a
ConflictError during the critical part of the code, log some
information, and then reraise the error to let the system do what it
needs?
Sure, but I'm not sure what that buys you in your case. The system
will
still retry the request if you reraise a conflict error. And it would
be spotty coverage at best; it's almost impossible to know where a
ConflictError might be raised. The only reasonable solution would be
to change ZPublisher's default behavior to not retry requests on
conflict errors, which is probably not what you want either.
Changing ZPublisher doesn't sound like fun times. I think I'll avoid
that one :).
The main thing that I want to catch is the fact that this event has
occurred so that we can (a) get notified by monitoring software that
something is screwy, (b) have a record identifier in the logs that
would help us clear the right record out of the external system as soon
as possible, and (c) let us know with accuracy when this situation
occurs. We've only had one report of this happening, but we have some
other suspicious data that we're not sure about.
I have an idea on how to handle it, thanks to your TransactionManager
suggestion. We still need to send the data out through the gateway
immediately (we can't wait for a transaction commit), but might be able
to do this:
def send(self, data):
self._txn_note = data['item_id']
...
def abort(self, reallyme, t):
if self._txn_note:
LOG('Outro', PROBLEM,
'Received abort after sending transaction id %s' %
self._txn_note)
self._txn_note = None
def tpc_finish(self, transaction):
self._txn_note = None
It's a rough view of the transaction methods that I think I'll have to
implement to do this. It might make a good howto/recipe ultimately.
*shrug*.
We've also found that accessing session data early in the request can
help reduce the number of conflicts that happen later in the request.
See http://mail.zope.org/pipermail/zope-dev/2003-March/019081.html for
more information.
Thanks. Quite an interesting read (I got a bit of a ways through it
and have bookmarked it for closer evaluation when I get to the office).
I apologize if this post is making little sense (or stupid sense) -
dealing with threads, locks, conflicts, etc, has been the part of Zope
I've understood the least. I like that for the most part I don't have
to think about it, but I don't know where to go for [fairly] current
documentation on how to deal with it for those rare times I do.
FWIW, the Zope Book 2.6 edition session chapter speaks a bit to what
conflict errors are. The ZDG persistence chapter talks a bit about
threading and concurrency.
A little off-topic: any idea when the 2.6 ZB can be marked as current?
Or are we waiting for Zope 2.7 to do that? ;)
That documentation has been helpful. Although I still don't know when
Zope/ZODB start new threads. Is it for every REQUEST?
Know that any change to a PersistentMapping needs to load and repersist
the entire data set in the mapping when a key or value is updated or
added. It is very likely that this will cause a conflict, particularly
when two threads try to do this at once.
OTOH, a BTree is made up of many other persistent subobjects, and there
is less of a chance (but still a good chance) that two concurrent
accesses to a BTree will cause a conflict error.
I'll move that data structure to a BTree. I have to do some other work
on that code anyways.
The best source of docs for sessions in the 2.6 Zope Book sessions
chapter. The maillist thread that I mentioned above gives some
information from Toby Dickenson about accessing session data early in a
transaction to reduce the possibility of read conflicts.
Good luck!
Thanks. I owe you yet more beer.
--
Jeffrey P Shell
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] [CRITICAL] Conflict Errors, Transactions, Retries, Oh My....
I need to know more about Conflict Errors. We're running into a lot of them lately, it seems, on production Zope 2.6.1 sites (running on FreeBSD). The primary culprit seems to be Temporary Storage/Sessions. Something that has happened, and is causing a small amount of alarm, is that a large method that interfaces to external non-transactional systems seems to (on occasion) send their information off to that external system twice, but there's only one matching set of Zope data. As the two writes to the non-transactional system are very close to each other and contain nearly identical data (except for one bit that gets regenerated in the method), and there are conflict INFO reports in the Event Log from around the same time, I'm assuming that a conflict error is happening somewhere in this method and causing the transaction to be retried (if I'm understanding how Conflict Errors work). Zope and the relational databases seem to do things fine with rolling back the data, but the non-transactional systems now have duplicate data that they **absolutely should not have**. This doesn't happen often, but (as stated), this is a critical operation that needs to be better protected. All other exceptions and bits and pieces in the block of code in question has been tested thoroughly and we have not had any other problems that cause erroneous writes. Is there a way I can protect against Conflict Error retries as well? Is there some sort of Try/Except or Try/Finally I can wrap around the code that won't interfere with the ZODB? Is there any other sort of best-practice here that could help me (and others) who might unknowingly trigger this problem? I know there are some fixes likely to be in Zope 2.6.2 that may help with the situation, but I'd like to put extra protections around this code regardless of what may be coming in the future. Thanks in advance, Jeffrey P Shell [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [CRITICAL] Conflict Errors, Transactions, Retries, Oh My....
On Wednesday, May 28, 2003, at 10:19 PM, Chris McDonough wrote:
This doesn't happen often, but (as stated), this is a critical
operation that needs to be better protected. All other exceptions and
bits and pieces in the block of code in question has been tested
thoroughly and we have not had any other problems that cause erroneous
writes. Is there a way I can protect against Conflict Error retries
as
well? Is there some sort of Try/Except or Try/Finally I can wrap
around the code that won't interfere with the ZODB? Is there any
other
sort of best-practice here that could help me (and others) who might
unknowingly trigger this problem?
Not infallibly. You can really never know where a ConflictError will
might be raised. Any concurrent access to a persistent object is a
possible candidate.
Thanks for the information. Is it safe at all to try to catch a
ConflictError during the critical part of the code, log some
information, and then reraise the error to let the system do what it
needs?
I guess you're right though - it's hard to know when it will occur.
In the production system, in this particular method, there are only two
known persistent object interactions. At the end of the entire method,
after a notification email has been sent, I have something like:
session['pieces'] = {}
(session['pieces'] was a dictionary of {item_id:integer} bits. It
never gets large for an individual user). I think that the one recent
case of desync'd data happened when we got to this point. Since it's
at the very end of the script (no more writes are expected beyond this
point), I imagine that a get_transaction().commit() might be OK to
precede this statement, just so that even if any conflicts happen when
trying to write back to the session, we at least have synchronized data
between the two systems. Although, prior to this, there are a few
reads of this session data. Might it be safer to do something like
this at the top of the method?:
pieces = session['pieces'].copy()
I apologize if this post is making little sense (or stupid sense) -
dealing with threads, locks, conflicts, etc, has been the part of Zope
I've understood the least. I like that for the most part I don't have
to think about it, but I don't know where to go for [fairly] current
documentation on how to deal with it for those rare times I do.
The other persistent data write occurs earlier in the method, an object
that generates serial numbers based off of some simple data in a
PersistentMapping gets updated. I think that PersistentMapping has
become fairly large by now. It maps the item_id referenced above to a
regular dictionary containing three key/value pairs each. I make sure
to follow the rules of persistence when dealing with these
dictionaries-with-a-PersistentMapping, but I'm guessing that an OOBTree
might be better instead. I still don't understand the potential
pitfalls of Zope/ZODB BTrees (I keep reading about 'bucket splits'
causing conflicts, and I don't know if that would be better or worse
than any pitfalls a PersistentMapping gives).
Finally, the system in question has a few (three? four?) public Zope
sites using the same session storage. Is there any documentation,
notes, etc, about fine tuning the default session storage set up to
handle large sites (or groups of sites) with less conflicts?
Thanks again for the help. I'll take a look at MailDropHost. Maybe
I'll have to wrap another gateway around the gateway to the external
system to try to catch these conflict situations. Fortunately, the
critical area only occurs once in the current copy of the code.
Hopefully that will make it easier to protect.
Thanks again,
Jeffrey
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.6.1b2?
I updated the Zope 2.6 project page to reflect this, figuring that it should at least be *somewhere* on the web :). http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/FrontPage It's nothing fancy, I just included the note and took out some of the older Status notes that reflected the development path towards 2.6.0. On Monday, January 27, 2003, at 11:47 AM, Brian Lloyd wrote: Here's the status - an engagement that we're doing has been bringing up some issues regarding ZODB and ZEO in large-scale environments. I think that the fixes are useful enough that they should be in 2.6.1, but getting them finalized has taken longer than I expected. I'll know better later today, but I expect that the fixes will be wrapped up this week, enabling a 2.6.1 b2 next week. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope and python compatibility
On Thursday, January 9, 2003, at 10:06 AM, Tena Sakai wrote: Greetings zope-dev folks, Please help me out. I have seen below via google search: Zope 2.5 + Python 2.1 -- Good Zope 2.6 + Python 2.1 -- Good Zope 2.7 + Python 2.1 -- Bad Zope 2.5 + Python 2.2 -- Bad Zope 2.6 + Python 2.2 -- Bad Zope 2.7 + Python 2.2 -- Good This article/note was from September, 2002. Can someone please comment if the data above is still valid? To my knowledge it is, although I recall reading that Zope 2.6.1 is intended to be Python 2.2 compatible - not breaking, but not requiring any Python 2.2 features. 2.6.1 is supposed to have its second beta soon. I suppose I should give the first beta a test against Python 2.2 to see how it goes. 2.6.1b1's been solid under Python 2.1.3, at least on our development box. Jeffrey P Shell, [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope] Re: [Zope-dev] Zope Book call for assistance
On Saturday, December 7, 2002, at 04:11 AM, Tino Wildenhain wrote:
Hi Chris,
--On Freitag, 6. Dezember 2002 21:27 -0500 Chris McDonough
[EMAIL PROTECTED] wrote:
On Fri, 2002-12-06 at 19:13, Tino Wildenhain wrote:
These are exactly the things you shouldn't neither do in DTML
nor in ZPT :-)
What do you suggest people use for a templating language for email,
JavaScript, SQL, etc? I think it's too much to expect them to use
Python to do this (esp. wrt SQL methods).
Oh, is it? I'd rather like to write %(name)s %(value)d
then dtml-whatever value
Recently I read the python-dbi spec and its very nice to see
what you could do with the above form. There are even
standard ways to do multiple querys or function calls.
(Hope I can contribute a product for this as time permits)
But SQL Method DTML is very very very very nice. It has a lot of type
enforcement/safety measures (ie - autoquoting SQL Strings, ensuring
that a 'sqlvar type=float' operation is inserting a float); a lot of
*very* nice features for generating 'where' clauses (the sqltest
'optional' flag and the smart 'dtml-and and dtml-or' tags that
won't render if an optional 'sqltest' preceding them was not rendered);
the 'sqltest multiple' feature is especially nice:
dtml-sqlgroup where
dtml-sqltest foo type=nb multiple optional
/dtml-sqlgroup
If foo is a blank string or empty list, that will render nothing.
If foo is a single string, that renders::
where foo = 'bar'
But if foo is a list of strings, that will render::
where foo in ('bar', 'baz')
Doing that programatically in Python is counterintuitive and awkward
(just as it was before the specialized 'dtml-sql___' tags in DTML).
For simple queries, doing it in the host programming language is not
bad. But for complex queries, it's very awkward to generate SQL. It's
almost as bad as generating HTML inside of a programming language - it
becomes difficult to maintain.
For E-Mail and Javascript templates I also find it less confusing
if I can use %(var)s form.
It's worth noting that there's a little known DTML format that's of
this style. Again - when doing simple insertion, %(var)s is not bad.
But once anything fancy comes into play - conditional insertion,
looping, etc - maintainability goes out the window when staying in the
host programming language. When I was evaluating Roundup
http://roundup.sf.net, I wanted to generate emails that looked as
good as the ones generated by Tracker. I had to write lines and lines
and lines of Python code to do it in order to replace a subclassed
method. There was no template that I could jigger around. (To be fair
to Roundup and Tracker both, I think customizing Tracker's email
messages is even harder).
I wouldn't mind seeing DTML.String re-emerge, which complements the
Python formatting string with DTML constructs to handle more advanced
templating needs. If you took a lot of the programming-language style
tags (dtml-try, dtml-return) out of DTML and normalized the expression
system (ie - to use TALES), you'd have a very usable system. The core
design concepts of DTML are good, it's just corrupted itself over the
years by stepping out of the plain-text templating language domain and
straddling the templating/programming language domains. DTML is even
used to generate DTML, by using the Extended Python Format String
syntax. This is how the 'Z Search Interface' custom reports are
generated.
As a general solution for texts one can use file which has an edit
tab for several releases of zope now. Then use it like this:
context.thefile.read() % context.REQUEST.form
or whatever seems appropriate to get values from.
E-Mail even gets clearer with the solution since you can easyly
loop and do whatever instead of multiple dtml-sendmail tags.
Life would be so much better if odd tags like dtml-sendmail could
just go away, and instead we had 'SMTP Methods' or something like that
- mail specific templates that are bound to a mailhost, with special
DTML tags (like the mime tag), similar to SQL Methods.
I love the SQL Method specific DTML tags. They make writing dynamic
SQL statements so easy, especially when compared to _any_ other system
that I've seen. It's a good showcase for DTML's ability to turn into a
domain specific templating language.
Regards
Tino
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KeywordIndex and PersistentList (Bug?)
What about ``if callable(aq_base(newKeywords)):`` to remove potential acquisition wrappers? On Wednesday, November 20, 2002, at 12:41 PM, Casey Duncan wrote: Just a note that this can't be put in Zope 2.6 since functions and methods don't have a __call__ in Python 2.1. -Casey On Wednesday 20 November 2002 02:33 pm, Steve Alexander wrote: Thomas Guettler wrote: Hi! In KeywordIndex the newKeywords get called if they are callable: def _get_object_keywords(self,obj): newKeywords = getattr(obj, self.id, ()) if callable(newKeywords): # (*) newKeywords = newKeywords() if hasattr(newKeywords,'capitalize'): # is it string-like ? newKeywords = (newKeywords, ) return newKeywords This fails if the newKeywords are stored in a PersistentList. Callable is true, but there is no __call__ attribute. I changed the line marked with (*) to if hasattr(newKeyword, __call__): and this seems to work I think this does not break anything and could be included in the original. Am I the first how uses PersistentList for an indexed attribute? Is there a reason not to do so? The KeywordIndex should be changed to check for the __call__ attribute, rather than relying on 'callable'. You cannot reliably use 'callable' when you're also using acquisition wrappers. See my comment to this Collector report. http://collector.zope.org/Zope/578 I suggest you report the bug you have found in the Collector. -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Proposed Additional reStructuredText Deliverables
I'll volunteer for (1). I think implementing it will be easy, but writing tests for it could be tricky... On Monday, November 11, 2002, at 10:44 PM, Andreas Jung wrote: 3) is a *must-have feature*, 1) and 2) are *can-have features* (especially 2) ). At least for 1) I need a volunteer ;-) -aj 1. reStructuredText support in the Zope Help System. 2. reStructuredText support for Product README handling. 3. Ensuring that Page Templates and Python Scripts can access the reStructuredText.HTML() function. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Proposed Additional reStructuredText Deliverables
With Andreas plugging away at reStructuredText Integration into Zope,
I'm thinking of some extra deliverables. I'm not sure how deep we want
to put ReST support in at the moment, considering that while the spec
is pretty solid the codebase is still a moving target, but I would like
to add and help work on the following proposed deliverables to the
project:
1. reStructuredText support in the Zope Help System.
2. reStructuredText support for Product README handling.
3. Ensuring that Page Templates and Python Scripts can access the
reStructuredText.HTML() function.
#1 looks like it would require adding a ReSTHelpTopic class in the
HelpSys package which could probably mimic (or even sublass) the
HelpSys.HelpTopic.STXTopic class. Then support would have to be added
into ``ProductContext.registerHelp()`` to map certain file suffixes to
the ReSTHelpTopic ('.rst', etc).
#2 could probably be handled the same way (look for a 'README.rst'
file), but may be served better if the contents of the README.txt could
be introspected enough to detect format. :\
#3 is easy, I just want to make sure it's not forgotten. We just have
to decide the right one way to do it: expose it in
'Products.PythonScripts.standard' where all of the other DTML
formatters are exposed, or out of its own namespace (ie:
tal:content=structure python:modules['reStructuredText'].HTML(foo)).
Or both ways.
--
Jeffrey P Shell
[EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] 2.6.1 Plan?
On Wednesday, October 30, 2002, at 04:22 AM, Chris Withers wrote: Ross J. Reedstrom wrote: It what world do you live, and can I move there? You miss the point ;-) The flurry to get features into a 'stable' release is what I was on about. If you flurry, the release won't be stable. I like the pattern of having stable releases and CVS or nightly builds for people who want the latest and greatest. That way everyone gets to contribute easily and freely and yet we still get truly stable versions. Maybe not to the extent of having seperate 'dev' and 'stable' streams a la Linux, but that's a good feeling in essence. Still, the overarching thing is release early and often. The fewer features in each release, the fewer problems of I need this feature, but that means I also have to accept this one that I don't trust But release often is a BITCH for software configuration management. Good for developers, bad for deployers. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] My 2.6.0 feature patch didn't make it!?
On Wednesday, October 30, 2002, at 07:07 AM, Andreas Jung wrote: Better put the patches at a public place (member area on zope.org). Or a collector issue, since they do allow file attachments. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] __getattr__ and Acquisition
On Monday, September 23, 2002, at 09:14 AM, Andreas Kostyrka wrote: Am Mon, 2002-09-23 um 11.12 schrieb Florent Guillaume: Anoter way to do that is to play games with __of__. Look at the implementation of the skins tool in CMF for an example. Doesn't help, as I do NOT know my container :( Basically __getattr__ when called does not know it's containment anymore. :( This is why my stock suggestion to needing to do anything with acquisition and __getattr__ (or any other acquisition jump-arounds) is: Don't. There are a lot of complexities that can arise out of Acquisition, Wrappers, and so on, that really require a deep understanding of exactly HOW acquisition works, versus what it usually does. The other problem with __getattr__ is interfacing with Persistence. ZODB handles it now, but it wasn't all that long ago that it couldn't. But with Acquisition - once you go beyond fair use, there's not enough Scotch in the world to kill the brain cramp. :) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Speaking of Structured Annoyances
On 9/4/02 9:14 PM, R. David Murray [EMAIL PROTECTED] wrote: On Wed, 4 Sep 2002, Jeffrey P Shell wrote: Um, how does one escape * in STX-NG? As in - what if one is entering an equation inline like 2 * 2 * 3 = 12? Or, does one just fall back on using x? How about '2 * 2 * 3 = 12'? Doesn't work. At least, not where I tested it (ZWiki 0.7-ish). :\ -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of StructuredText
On 9/4/02 10:59 AM, Chris McDonough [EMAIL PROTECTED] wrote: IMHO, the indenting hassle is one of the best features of classic STX. It's a pain to line things up but it does make for very readable source documents. I think STX-NG is a little better than ReST for constructing readable source docs; especially if they are long, like chapters of a book due to this indenting. When writing books, however, you're most likely using an editor that makes it easy to reformat blocks at the proper indentation level. For a lot of web input where you still want to allow some simple structure, indentation is a pain in the ass. I do it because I'm used to it, but a lot of people just will type in a paragraph as a single line. Most of the time, this is fine in Structured Text, until they indent one of the paragraphs even by one space, turning the parent paragraph into a header block. The indentation in STX is especially annoying when trying to drop in example code, most likely pasted in from another source, and having to then move every line to the right level - thus, code that was formatted to fit well in eighty columns can be tricky to fit into an eighty column source STX document if it's a few sublevels in. I still have to find the right level, mix of colons and spacing, etc..., after all these years. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Speaking of Structured Annoyances
Um, how does one escape * in STX-NG? As in - what if one is entering an equation inline like 2 * 2 * 3 = 12? Or, does one just fall back on using x? -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Fix broken python on Mac OS X version 10.2
On 8/26/02 11:49 AM, Jens Vagelpohl [EMAIL PROTECTED] wrote: well, the basic cause is worse than that: they moved symbols around between system libraries. jens But nicely, they include Python (2.2, not even 2.2.1) on the Developer Tools CD. Finally. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] DTML and REQUEST data changes about to be checkedin
On 8/9/02 8:43 AM, Toby Dickenson [EMAIL PROTECTED] wrote: I agree it is true in most cases, but not all. Have you analysed how many applications will be broken by this? how they can detect the breakage? I certainly will not have time to assess the implications on my applications before the scheduled release of 2.6. This is why I raised the flag of can there be a way to disable it?, and Martijn put a fix in: - dtml-var name and dtml.-name; will now automatically HTML-quote unsafe data taken implictly from the REQUEST object. Data taken explicitly from the REQUEST object is not affected, as well as any other data not originating from REQUEST. This can be disabled (at your own risk!) by setting the environment variable ZOPE_DTML_REQUEST_AUTOQUOTE to one of 'no', '0', or 'disabled'. I have the same concerns you do, but I figure that if any problems are found during normal execution of any Zope release this is attached to that I don't have time to investigate a fix for myself, I can add this environment variable (which normally I am not fond of doing), restart, and make a note investigate fixing site blablabla. Is there any reason why this solution wouldn't work for you? Like I said before, this is probably a good feature. If it was available as a patch then I would probably use it on a number of my sites, and would recommend it to others. I would be very happy see it (or something like it) in 2.7. But not 2.6. Oh, 2.6 will never happen anyways ;) (seriously folks - what's the plan?). Since there's no current release plan for 2.6, it's hard to plan future deployments around it anyways. But if you have any sites you plan to move to 2.6, you should test this Autoquote change aggressively during the alpha/beta cycle. Since the ZOPE_DTML_REQUEST_AUTOQUOTE change has been put in, I've reserved future judgments until I get a chance to actually do some testing. I know that if I do run into any issues in the future that I don't have time to deal with, I can just flip that switch off. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] 2.6 / 2.7? (was: DTML and REQUEST data changes about to bechecked in)
On 8/8/02 1:19 PM, Toby Dickenson [EMAIL PROTECTED] wrote: On Thursday 01 Aug 2002 3:46 pm, Martijn Pieters wrote: Eeek - a week ago. sorry for the late reply. I am about to land some big changes in the way DTML deals with data taken from the REQUEST object when accessed implicitly, in both the Zope Trunk and the Zope 2.5 branch. In my opinion this change is completely unacceptable at this late stage of the release cycle. As you said: These changes could potentially break existing Zope sites. The existing behavior might be flawed, but it is a flaw we have all lived with for a long time. In my opinion this needs: 1. To be deferred until the 2.7 cycle. 2. A detailed fishbowl proposal. Speaking of all this - what's up with 2.6 and 2.7? 2.6a1 is creaking towards to its two month birthday, and I seem to hear more about 2.7 developments than 2.6 ones lately. Is there a roadmap / schedule for the two releases that's up to date? -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: DTML and REQUEST data changes about to bechecked in
On 8/1/02 10:08 AM, Martijn Pieters [EMAIL PROTECTED] wrote: On Thu, Aug 01, 2002 at 10:46:44AM -0400, Martijn Pieters wrote: I am about to land some big changes in the way DTML deals with data taken from the REQUEST object when accessed implicitly, in both the Zope Trunk and the Zope 2.5 branch. These changes could potentially break existing Zope sites. It's in. Let the testing begin! Hopefully I'll get a chance to test it with some of our 2.5 sites - I have a small worry that old code on small sites that we don't have much worry about will break if this is put into a 2.5.2 or later release. Could there be a way to disable this feature in 2.5 via a z2/environment variable or some other configuration setting, but have it be automatic in 2.6? Potential code breakage and point point release leave me a little worried about maintaining 2.5 sites. It may not be an issue - I have to digest the changes in more depth that I've had (or currently have) time for, but that's the thought that crossed my mind earlier. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Restricted Compiler issues on FreeBSD? (Core Dumps...waaa!)
For a while now, Tracker has been core dumping on my with Zope 2.5.1 with both Python 2.1.2 and 2.1.3 on FreeBSD 4.5 (Intel). The culprit seems to be expressions that are heavy on parenthesis. For example, the following works: !--#let val=(init or (type == 'simple' and (_['sequence-key'] not in ['requester', 'supporter', 'priority', 'stage']) )) and _['sequence-item']-- But it core dumps when changed to: !--#let val=((init or (type == 'simple' and (_['sequence-key'] not in ['requester', 'supporter', 'priority', 'stage']) )) and _['sequence-item'])-- Don't ask me what this expression does - I just kept whittling at it until the crashes stopped. Then I went and found quite a few others. I made a lot of fixes by turning complex expressions into many smaller ones inside a single 'let' tag. Does anyone know other possible fixes for this issue? Is there some Python stack size setting I can set at compile time? I have some other code that has not survived the move to Zope 2.5.x/Python 2.1.x/FreeBSD. FWIW, the Python 2.1.2 used was from the BSD Ports, while the 2.1.3 was compiled by hand. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Temp Folders and Transient Object Containers
Under the category of feigning smartness by blindly copying what I see, In a subfolder of the Zope root, I set up a browser_id_manager, a session_data_manager, a temp folder (cleverly named 'temp_folder'), and put a Transient Object Container inside that temp folder, named 'tix_sessions'. Of course, when I restarted Zope, the 'tix_sessions' object itself was gone. So, why is the default Transient Object Container put in a Temporary Folder? If I want to use an application specific one that doesn't get lost on restart, is it OK to put it into a normal persistent folder? -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Temp Folders and Transient Object Containers
On 6/20/02 4:01 PM, Chris McDonough [EMAIL PROTECTED] wrote: So, why is the default Transient Object Container put in a Temporary Folder? If I want to use an application specific one that doesn't get lost on restart, is it OK to put it into a normal persistent folder? Yup. The TOC is put into the temp folder mostly because: 1) Sessions are write-intensive and cause bloat on undoing storages like FileStorage. 2) Sessions are write-intensive and cause conflicts when accessed via a normal ZODB connection. The temp folder is mounted into a database which has a special low conflict connection type that ignores read conflict errors. You will get more conflicts and more bloat if you put a TOC into a normal persistent folder (esp. one backed by FileStorage), but it will work. That said, there are a few bugs in the 2.5 transience implementation that I'm working on as we speak that might be more egregious if you have a truly persistent TOC, so pls. keep an eye towards 2.6 (or CVS ;-) in the next few weeks. You will notice the bugs in the form of phantom key errors (not unlike the old Catalog bugs ;-) Oh yes. Those were fun days! So, I want to have different TOC's, preferably in non persistent folders (the site I'm working on could be quite high traffic at times). A big problem is - if one is in a temporary folder, it will disappear if Zope ever restarts. So, at present, it looks like you can only have one reliable non-persistent TOC per Zope instance, since that one's always initialized during the time Zope is checking its root for required objects (Zope 2.5.1 lib/python/OFS/Applicatoin.py (revision 1.179.4.1), starting at line 277). This could be a rather crappy situation for Zope instances hosting multiple applications with different Session requirements. Fortunately for the project I'm on, I think it will have a dedicated Zope instance. No one's working on a Kinda Sorta Temporary Folder are they? ;) Or, as Jim might put it Temporary, except for when I don't want it to be. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution FeatureRequest
On 5/13/02 1:51 PM, Jim Penny [EMAIL PROTECTED] wrote: On Mon, May 13, 2002 at 03:32:21PM -0400, Shane Hathaway wrote: Florent Guillaume wrote: Jim Penny [EMAIL PROTECTED] wrote: Are you referring to what I call magic boolean attributes ? http://lists.zope.org/pipermail/zpt/2002-March/003013.html Yes, thanks very much, this is very helpful. I see that you could find no documentation on this, and got no reply. Is this intended to be a permanent feature, or is is experimental? I'm pretty sure it's permanent, only undocumented. Florent, do you have committer privileges? You can certainly check in documentation of this behavior. You can also add a comment to the Zope book. http://www.zope.org/Documentation/ZopeBook/AdvZPT.stx I will write up something and do the feedback thing in the Zope book. It seems to me it should be in both the advanced section and the ZPTRef section. Would like a bit of guidance on the Ref writeup, i.e., what does ZC want to call it (presumably not magic boolean attributes)? Boolean HTML Attributes perhaps? From TAL/HTMLTALParser.py :: BOOLEAN_HTML_ATTRS = [ # List of Boolean attributes in HTML that may be given in # minimized form (e.g. img ismap rather than img ismap=) # From http://www.w3.org/TR/xhtml1/#guidelines (C.10) compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer ] You should mention that these only get rendered in the classic HTML way when a page template is in HTML mode (content type equals 'text/html'), which I presume is the default. -- Jeffrey P Shell www.cuemedia.com Industrie Toulouse on Zope http://radio.weblogs.com/0106123/categories/zope/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [ZPT] Order of attribute execution FeatureRequest
On 5/10/02 4:53 AM, Chris Withers [EMAIL PROTECTED] wrote: Jim Penny wrote: on the surface, to be pretty ugly. I have said that there are three specific things I dislike about ZPT -- 0) lots of things have changed spelling again -- request v. REQUEST, here v. context v. container v. this v. ? Yeah, there was absolutely no need for this and I did find it extremely frustrating. That said, the whole area has always been a mess, particularly in DTML. I do, however, wish that Script (Python)'s and ZPT could have been consistent :-(( Me too. I keep typing 'here' in Python Scripts now. While I know I can change the bindings, I'm sure that would just make more confusion for me down the road. In regards to request v. REQUEST, I do like the page templates spelling. 'request' is just another path root, and all path roots are lower case. 1) infix notation that makes program scansion hard, You don't HAVE to use infix ;-) tr tal:repeat=x xes td tal:content=x/idan ID/td /tr ...can also be written as: tal:x repeat=x xes tr tdtal:x replace=x/id//td /tr /tal:x I think this is another good feature of ZPT which seems almost like a side benefit of XML Namespace usage (and instead of 'tal:x', you can also use more meaningful terms like 'tal:loop'). As for program 'scansion', I don't view a Page Template as program. But I think programmer readability can be achieved just by good formatting. And when using some HTML tools, whether they're text oriented, visually, or both, some of them hilight unknown attributes differently. GoLive 6 by default colorizes unknown attributes/tags in orange, while known ones are in blue. Attribute values remain in brown. So, a combination of good formatting and a half decent editor can yield good usability. If these are problems for the pure-programming set, there is still DTML. And, if anyone can plug in a good XSLT processor, that could open up another alternative templating system. XHTML aware editors should present the least amount of problems, as namespaces (in theory) shouldn't cause any confusion. 2) the order of operations, which I think is baroque. Six levels of precendence for eight statements is pretty amazing. And it is certainly harder to explain/remember than things happen in the order you specify. *shrugs* I've done a u-turn on this. Tim's comments make it perfectly obvious why this needs to be the case, and at least it is very well defined what order things happen in (as Ken pointed out). My only beef is that define sometimes happens in an order that is less helpful than it could be ;-) tal:x repeat=fish fishes define=species fish/species ...doesn't do what I'd like it to ;-) Evan Simpson explained this to me once in a way that made sense, but I can't remember what it is right now. [SNIP!] -- Jeffrey P Shell www.cuemedia.com Industrie Toulouse on Zope http://radio.weblogs.com/0106123/categories/zope/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and 'else'
On 5/10/02 9:25 AM, Marc Lindahl [EMAIL PROTECTED] wrote:
on 5/10/02 12:47 AM, Jeffrey P Shell at [EMAIL PROTECTED] scrivened:
You would need something to close off the 'if' statement, otherwise, a
document full of 'if' statements and no 'else' ones could fill up a stack
needlessly.
What's so bad about that? The stack wouldn't carry over after html/html
or body/body - couldn't practically more than 1000's - insignificant!
Still, yuck. It's - for better or worse - not a valid XML way. Even XSLT
does things like this:
xsl:stylesheet version=1.1
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=/
xsl:choose
xsl:when test=system-property('xsl:version') = 1.1
xsl:exciting-new-1.1-feature/
/xsl:when
xsl:otherwise
html
head
titleXSLT 1.1 required/title
/head
body
pSorry, this stylesheet requires XSLT 1.1./p
/body
/html
/xsl:otherwise
/xsl:choose
/xsl:template
/xsl:stylesheet
xsl:if can stand on its own, but to do the equivalent of else, one has to
use:
xsl:choose
xsl:when test=expression(template)/xsl:when
xsl:when test=expression(template)/xsl:when
xsl:otherwise(template)/xsl:when
/xsl:choose
But, Page Templates are not XSLT. And I thank gods for that. XSLT is
powerful, but I wouldn't be able to do the type of work I've been doing this
week with them as easily as I've been able to do them with Page Templates.
I couldn't even have done them as easily using DTML.
You would at the very least need something like:
condition
if.../if
elif.../elif
else.../else
/condition
Which would ensure / cut back on needless growth of stacks and/or global
variables.
Personally, I think the way Page Templates can do it (via a 'not'
expression) is fine. When I used it today (and in the past), I never felt
myself missing 'else', because there's not really an 'if' to begin with.
Just conditions. It keeps TAL light, and lets TALES take on the lifting of
how to write those conditions.
Point is, it's slow and inefficient, and a clunky syntax. Reasons the whole
idea of 'else' was invented in the first place. I worry, that ZPT is
benchmarked 4x slower than DTML and it's becoming the standard - not a step
forward. And issue like this haven't been satisfactorily resolved.
If speed mattered that much, we'd all still be using C and/or assembly
language. Scripting Languages have become very standard, even though
they're orders of magnitude slower than their compiled counterparts. I
don't think it would be any more worth turning Page Templates back into an
imperative programming language than it would be to turn Python into C. Or
Haskell into Python. Or J into Lisp. Or Zope into PHP. Every language
and platform has its strengths and weaknesses, and I think ZPT's strengths
more than make up for its current speed deficiencies. I spend less time
debugging and cleaning up Page Template code than I did with DTML,
particularly late-generation DTML. And the results look *much* better.
I personally can't see a way of having an else (or equivalent of
'xsl:choose') without starting to clutter up the current elegance of Page
Templates, and it has to do with the way Page Templates are designed (and
it's a design that I think is done pretty close to right). One reason being
that, since all TAL things happen on attributes (it is the 'Template
Attribute Language', and by law all XML attributes have to be quoted, you'd
end up with something like this:
div tal:choose=
h1 tal:condition=some/expressionYay!/h1
h1 class=warning tal:otherwise=Boo/h1
/div
The only way out of this is to introduce special TAL tags. And at that
point, we're back to some of the problems with DTML - 'special markup tags
and the editors the bruise them'. And at _that_ point, we're out of one of
the intended audiences of Page Templates.
I think, if it's going to have logic in there, make it sufficiently powerful
and efficient. Otherwise get rid of it altogether, unapologetically, and
require Python for such things
Another option is the XMLC route, which is painful. XMLC identified every
possible writable element with an id, and id only. Then, corresponding Java
code could refer to that ID and replace the element with something. It kept
the visual design side very clean, but the code to do the dynamic generation
could get very ugly.
Or, there's the option is to give up on templating altogether and go with
PHP style syntax, or fill up Python code with:
s += 'emNo contents available/em'
I personally think Page Templates are rather elegant and a joy to use after
five and a half years of DTML usage. I keep having to deal with other
solutions like 'tea', 'cheetah', ASP/PSP, and it's just a mess.
--
Jeffrey P Shell
www.cuemedia.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo
[Zope-dev] ZPT and 'else'
On 5/9/02 7:07 PM, Tim Hoffman [EMAIL PROTECTED] wrote: Just my 2c worth, but I would like to defend order of execution of ZPT. What it does mean for me is I can guaruntee zpt commands will always be processed in a known order irrespective of where you put them in a tag, this I like ;-) Me too. Occasional alarms, no surprises. What I do miss is else clause but I think it would be probably be too hard to implement, and too much of encouragement for people to start putting more logic in the template, so on the whole it is probably best to leave it out. See ya T On Fri, 2002-05-10 at 05:15, Jim Penny wrote: My most-missed DTML feature has not been mentioned at all -- it is not loop batching -- it is the dtml-else option of dtml-in -- which made it much easier to handle the nothing found case. 'else' is tricky within the block oriented structure of anything XML-ish, because of the concept of 'well-formedness'. The 'if' statement would have to be singly wrapped, and the else block wrapped separately, looking at least somewhat awkward any way you go about it. The best I can come up with in my mind is this, in order to have the 'else' pick up on the condition expressed in its surrounding container. But, yuck: if ... true stuff else false stuff /else /if A good page template way is something like this: tal:if condition=myTalesExpression truth /tal:if tal:else condition=not:myTalesExpression false /tal:else The 'not' TALES namespace is valuable. The downside is that you evaluate the expression twice. A good way to work within this is something that I did earlier today, outside of this conversation, where I evaluate an expression earlier and assign it to a variable: div id=edit-area tal:define=editItems python:here.getMenuItem(...) h3Edit Menu Items/h3 form action=Delete method=post name=actForm tal:condition=editItems ... (form and table elements, and a loop over editItems contained in here if there were results) ... /form div class=emph tal:condition=not:editItems No menu items available /div /div This is something I did a lot in DTML too, setting a search result to either a global variable, or inside of a large dtml-let namescape -- Jeffrey P Shell www.cuemedia.com Industrie Toulouse on Zope http://radio.weblogs.com/0106123/categories/zope/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPT and 'else'
On 5/9/02 9:39 PM, Marc Lindahl [EMAIL PROTECTED] wrote: Yecch! Why not: if ... True stuff /if else False stuff /else If leaves around boolean result, else picks up the most recent one... It's like they push on a stack so you can nest them Something like that? You would need something to close off the 'if' statement, otherwise, a document full of 'if' statements and no 'else' ones could fill up a stack needlessly. You would at the very least need something like: condition if.../if elif.../elif else.../else /condition Which would ensure / cut back on needless growth of stacks and/or global variables. Personally, I think the way Page Templates can do it (via a 'not' expression) is fine. When I used it today (and in the past), I never felt myself missing 'else', because there's not really an 'if' to begin with. Just conditions. It keeps TAL light, and lets TALES take on the lifting of how to write those conditions. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] updateObjectList for objectManagers?
On 4/30/02 8:27 AM, Lennart Regebro [EMAIL PROTECTED] wrote: I have had a couple of problems with an object managers self._objects getting out of sync with reality, so that it keeps the wrong names or the wrong meta_types in the _objects list. Is there an update function that you could call to make it scrap this list and rebuild it? I've never seen this problem. ObjectManager works best when you use its API's (_setObject/_setOb, _getOb). Since normal ObjectManager instances store subobjects as attributes, it would take some trickery to decide what was a subobject, and what was just an attribute. If you're not careful, you could end up with an even worse list in _objects. That being said, I imagine it wouldn't be *too* difficult to implement something like this. However, since (in theory) an ObjectManager subclass can change the behavior of the core _getOb/_setOb/_delOb methods to store subobjects in a different fashion, you'd have to take this into account. Basically, if you don't trust _objects, how do you get the list of actual subobjects? -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] updateObjectList for objectManagers?
On 4/30/02 10:59 AM, Lennart Regebro [EMAIL PROTECTED] wrote: From: Jeffrey P Shell [EMAIL PROTECTED] Basically, if you don't trust _objects, how do you get the list of actual subobjects? abel deuring suggested that I would check for a meta_tag attribute on the attributes. That might work I guess? Just be sure to avoid accidental acquisition of the folder's meta_type via Acquisition.aq_base(attr). -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Need to instantiate zclass in location other thancurrent
On 4/17/02 4:49 PM, Max Slimmer [EMAIL PROTECTED] wrote:
I have created a zclass and want to create a new instance of this class and
have it be child of some other know object in the tree.
Given that we know the path (url) to the new prospective parent how do we do
this.
I do this a lot, with my own custom add in screens that add objects in
special locations. I have it working like this in a python script::
REQUEST = container.REQUEST
target = context.content.documents # folder to put the document in
### Create a new instance.
new_item = target.manage_addProduct[
'MyProduct'].MyZClass.createInObjectManager(new_id, REQUEST)
## other operations on the new item
new_item.setTitle('Rockabilly Bob')
...
A second question. I need to manage lists of these zobjects within other
instances of the same, is there a reason to store the url vs the object(s).
I have has some problems getting back a string repr of the object instance
of ..
instead of the object? It would probably be better for me (the code) to
store objects thus not need to get the object each time I want to call a
method...
You'll want to store the path to the object. Making other 'hard' references
to a persistent object in Zope is still a scary proposition.
--
Jeffrey P Shell
www.cuemedia.com
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Speaking of 2.6...
On 4/17/02 9:56 AM, Gary Poster [EMAIL PROTECTED] wrote: On Wednesday 17 April 2002 11:48 am, Brian Lloyd wrote: Ok :) As far as vetting virtual host folder, my concerns boil down to: a. dependency / requirement for ordered folder b. having yet another virtual host thing in the core will confuse people ... Hey Brian. Thanks for your response. All points understood and appreciated. And I guess, then, that I'll choose not to make that commitment, since I'm looking forward to Zope3 these days anyway. If folks still want OrderedFolder (or, at least ordering capability) in the core I'm still willing to help with that. I'm a little surprised this hasn't come up for inclusion earlier. When showing a site to some top-management folk in a previous life, the question that came up most often was can we organize those links on the side so that blablabla is first?. One person would ask it, I'd respond with the hmmm, not easily - at least, not in time for our deployment date. Then the next person would come in late to the meeting, ask the same question, we'd laugh and tell them the scenario - to make admin easy, it's just listing the documents in that folder that are public, using the API's already available!. They'd go OK. The tour continued. Another straggler comes in, the loop repeated itself... :). For add-to-the-core functionality, I'll vote +0.5. I wouldn't mind seeing it in the core, but I also like the idea someone mentioned of a sort of expansion pack of other good products that was well maintained alongside each core release. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: death to index_html; ObjectManager?
On 4/16/02 8:53 AM, Casey Duncan [EMAIL PROTECTED] wrote: The implementation adds the API to manage browser default for all objectmanagers. However, no browser_default handler is actually added to the object unless you specify a default other than index_html What was the specific undesirable effects you were seeing? If it is agreed that this management should apply to folders rather than all object managers, then I can make this change. In that case using a separate mix-in makes sense to me. It could even be registered for use as a base class for ZClasses then, which would be some advantage I suppose. +1 for the separate mix-in. I use ObjectManager as a base class frequently for non-folderish objects, for which the whole 'death to index_html' notion is moot. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [RFClet]: What about the request method and theclient side trojan?
On 4/12/02 2:49 AM, Toby Dickenson [EMAIL PROTECTED] wrote: On Thursday 11 April 2002 6:37 pm, Jeffrey P Shell wrote: On 4/11/02 7:55 AM, Toby Dickenson [EMAIL PROTECTED] Then you're lucky. Usually, any time I see dtml-var someNonIdempotentMethod(), I immediately change it to the name lookup call. Don't blame me, I've been following this paradigm for years (since before there were expr's in DTML). I would hate to have to special case those methods OK, that kills the second half of my proposal. (I still think your style is bizarre though ;-) Personally, I absolutely abhor the difference between dtml-var foo And dtml-far foo It's violently non-obvious and confusing, even to seasoned Zope developers just glancing over code. So, personally, my bizarre style is to always explicitly say 'expr=...', but I try to avoid expr's where necessary to make life simpler. Fortunately, there's the happy land of TAL and TALES for me to play in these days. :) (which I use a lot, usually as accessors, ie: def Summary(self): return self.title + self._description ). Aha! maybe not! That example method definitely is idempotent. Under my proposal it should not be declared non-idempotent, and would not have restricted dtml-name-lookup semantics. I agree being able to write dtml-var Summary is a good thing whether Summary is an attribute or method (and not at all bizarre). I agree that changing this would be disasterous. I have to now admit to not having seen the proposal, I've just been following along here and struggling to capture the meaning of idempotent as it applies to Zope security, but I *think* I'm starting to grok it. Since a search for idempotent on zope.org yields no results, I'm assuming that your proposal isn't up there (or the catalog is up to its old charms ;) But now, does this mean I have to go through and tag every method that might cause a state change? Or might not? Im not sure whether you misunderstood the proposal, or just gave a poor example to explain why you thought the proposal is bad. Since I haven't read the proposal, only the recent mail messages, I'm just trying to get clearer understanding. Maybe I'm just having the same sort of trouble with idempotent versus nonidempotent that I did with mutable and immutable (for some reason, I unlearned the differences between the two between CS and the real world, and invented new meanings around the word 'mute' instead of 'mutate'). My proposal only affects method which have been declared to be non-idempotent. This declaration would only be added to methods that change externally visible state (in ZODB, Filesystem etc) or have external side effects (such as sending an email) Here is a differnet example. Suppose you write a method: def setEmptyTitle(self): self.title = 'empty' How would you call it from dtml. I think the 'right' answer is that you generally wouldnt call this method from dtml. From a PythonScript maybe, but not dtml. However if you did call if from dtml, would you still be using the name-lookup form, such as: dtml-var setEmptyTitle or would you use dtml-call setEmptyTitle dtml-call setEmptyTitle() dtml-var setEmptyTitle() ? (Im not going to argue that anyone is 'wrong' to prefer the first form in this case. Its my *personal* preference that calling non-idempotent methods using the name-lookup form should be caught and reported as an error I am wondering whether this preference is shared.) I think that it could be caught and reported as a Warning, but not an error. It's been a common thing for a long time, and I think it would be bad to label it as an error. Warn first, slap later. :) Now that I'm understanding things more, I never call non-idempotent methods (I hope I'm using that term right) from DTML anymore, and when I did it was always with a dtml-call expr=..., with rare uses of direct name use (dtml-call ...), usually in regards to SQL methods. So, it was my misunderstanding of the proposal. Overall, I still don't know how I feel about the whole thing. It's good to have Zope as secure as possible, but if putting that security makes it suddenly much harder to develop for or upgrade to/for, I worry about the support costs involved. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: ZMI / JavaScript brainstorm
On 4/8/02 1:17 PM, Martijn Jacobs [EMAIL PROTECTED] wrote: What is wrong with editing the files trough FTP / WebDAV? I've mounted a complete zopedatabase on a directory, and you can edit all files with your favorite editor. Why wanting such editing posibilities in a easy to use , in everybrowser working interface like the ZMI? +1. The ZMI is really good as an object property browser/inspector - good for managing a huge suite of objects. It's not the best content editing environment, and I'm not sure it should be. For doing quick edits, it'd be very annoying having to wait for an Applet to reload/refresh every time I hit something with a rich text area. On the other hand, Radio Userland http://radio.userland.com/ has a WYSIWYG editor built in for its web based editor, with a preference to disable it. The editor, I believe, is for Windows IE only. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Catalogs, Imports, and Path Awareness (was Re: [Zope-dev] ZClassConstructor Cleanup for 2.6)
On 3/30/02 5:55 AM, Didier Georgieff [EMAIL PROTECTED] wrote: On Wed, 2002-03-27 at 17:31, Casey Duncan wrote: ZClasses have been overlooked enough. Nobody has even bothered putting a ZCatalogPathAware available for them... I've done that locally (changing __init__ and the the py but had no chance to make it work with __existing__ ZClasses. Something was coded inside the zclass instance ;- So i had to patch ZCatalog for getting the right behaviour for my existing products. So, even if ZClasses are not cooked completely, they allow guys like me to use zope, to promote zopet even if we are useless at good python programming ;-), and until Z3 exists. All my support for ZCatalogPathAware in 2.6. Maybe we should investigate : - how updating old CatalogAware ZClasses for taking care of that - what impact for already updated construtor scripts ? (shuild be none, but not sure) Even with CatalogPathAware (or otherwise smartly cataloged objects), I've come across a major annoyance that I'm sure others have seen. The annoyance stems from objects getting re-cataloged somehow upon Import, so now I've got two entries for each object - one with the correct shortened Virtual Host friendly path, and one with the big long unfriendly path. So now, as I move a site from development to testing to deployment, I have to run a Python script that goes through the catalog, and removes everything that has a certain folder in its path, leaving only the correctly cataloged objects from the previous site in place. This is especially annoying because I seem to have to run the script 5-10 times before all of the re-cataloged-upon-import objects are removed. If other people have come across this, I think finding a resolution to this would be a more-than-worthy 2.6 project. If I'm just smoking crack and it's only a ZPatterns/TransactionAgents behavior that I'm witnessing, then I'll just leave my huffing and puffing and whining and yelling and fainting to myself and immediate coworkers next time I have to go through this situation. :/ Oh! And while on the CatalogPathAware part, documenting how Paths and SiteRoots and VirtualHostMonsters are all supposed to work together would be nice. I still haven't figured it all out, which is currently leaving me with a few VHM's scattered precariously about a couple of sites. (:/ ** 2). -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] FW: Catalogs, Imports, and Path Awareness (was Re: [Zope-dev]ZClass Constructor Cleanup for 2.6)
On 4/1/02 5:59 PM, R. David Murray [EMAIL PROTECTED] wrote: On Mon, 1 Apr 2002, Jeffrey P Shell wrote: If other people have come across this, I think finding a resolution to this would be a more-than-worthy 2.6 project. If I'm just smoking crack and it's only a ZPatterns/TransactionAgents behavior that I'm witnessing, then I'll just leave my huffing and puffing and whining and yelling and fainting to myself and immediate coworkers next time I have to go through this situation. :/ I thought that with ZPatterns one was recommended to avoid the Catalog mixins and instead use something like SteveA's catalog trigger from ZPAddOns (I think that's the right product name). That's what I did. But, looking at the import machinery, the newly imported object is added in to it's parent object with '_setObject', which then goes and calls self.manage_afterAdd(), which then goes down into all of the subobjects and calls that. That's probably the right thing, but it is what's causing the double cataloging, regardless of how the item is cataloged. Catalog*Aware objects call into the catalog during manage_afterAdd, and I'm sure that the same thing is happening to my WHEN OBJECT ADDED... triggers as well. *sigh*. I've got a few quarter assed solutions in my head, but I don't like any of them. Waaa. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] WebDAV locks disappearing...
A WebDAV client may request a timeout length for a lock, but it's basically just a suggestion. You say you investigated again some time later. Zope's default timeout is thirty minutes. Clients can ask for longer ones and Zope will obey, but the 30 minutes is granted for 'infinite' timeout requests (the spec says that the server may decide the timeout time independent of the clients request). The timeout should get refreshed with every HTTP request made by you (the lock owner). But the timeout also exists so that the problem of Person X locks a document for editing, and then leaves in a hurry (forgetting to release his lock). Person Y really needs to edit the document, but it's held hostage by X's lock. Cadaver may be caching the locks. Since HTTP/WebDAV are stateless, you have to refresh your listing in order to see if locks are still there. Most GUI based WebDAV clients have a refresh listing option, which is the only way they can know of new members in a collection and new lock states. On 3/7/02 11:38 AM, Jerome Alet [EMAIL PROTECTED] wrote: Hi, I've just tested webDAV access for the very first time using cadaver, so maybe this is a known problem. I've locked some objects using cadaver's lock command, and then opened a browser keeping cadaver's connection opened. then I've searched for this locks using the ZMI and also a method of my own. All worked fine, the locks were found. Then some time later I've retried to find the locks, and both the ZMI and my method returned no lock. However in cadaver the locks still seemed to be there... Then I've unlocked the objects and relocked them in cadaver and retried, this time the locks were found again... I hadn't the time to do some more testing but I find this surprising. Does anyone have seen the same problem ? FYI Zope 2.5.0 + Python 2.1.2 both up-to-date Debian Woody packages. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] improved logging
See PEP 282 [1]. If this PEP is accepted, work should probably follow its course. It would be nice to have a single logging mechanism for Python, and for Zope to use and/or extend it. Granted, if it is accepted, it won't be in Python until Python 2.3 which I believe is due in August. ..[1] http://python.sourceforge.net/peps/pep-0282.html On 2/28/02 3:34 PM, Romain Slootmaekers [EMAIL PROTECTED] wrote: Yo, questions wrt logging: -) What are the plans to improve the rather primitive logging facilities in zope ? I couldn't find anything in the plan for 2.6, nor on the 3.0 homepage. I think we need at least an extendibl framework with following types of components: - Loggers (fi, file logger, db loggers, remote logger, nulllogger,...) - Filters (fi on severity, on subsystem, ...) - LogBus (central accesspoint for the logging framework, where you can (dynamically) hook your loggers, filters etc... if time is an issue, we could just copy the design of fi Log4J which is a good logging framework for apache. -) If there are no such plans, can we hack something up ourselves and add/donate it to the product ? I hate writing stuff that gets replaced by something else afterwards input appreciated. Sloot. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 2.6 planning - call for contributors!
On 3/1/02 7:30 AM, Chris McDonough [EMAIL PROTECTED] wrote: I'd suggest starting with the combination of Evan's zopemake and zctl scripts. One thing that zopemake could be extended with is an autoconf-style configure that figures out where the appropriate version of Python is, which C compiler to use, etc. Can't the distutils framework be used? It's got all of the utilities to deal with various platform issues already. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Dynpersist.so and makefile.pre.in
On 1/31/02 5:02 PM, Ed Colmar [EMAIL PROTECTED] wrote: Huh... I found a makefile.pre.in, but I'm seeing tons of errors on make There was some note in the Zpatterns docs that after zope2.2 the dynpersist woudn't be neccesary anymore. Is this true? It seems like it should be true. To the best of my knowledge, DynPersist got around the issue that it wasn't all-too-safe to override __getattr__ and __setattr__ for persistent objects. I know that this issue was fixed in the ZODB, probably around the time of Zope 2.2. However, even in the most recent ZPatterns releases (as maintained in the 'TransactionAgents' package), some Python code still seems to depend on DynPersist. Are there any other (simple) solutions to doing authentication through a SQL DB? Jumping through hoops to get Zpatterns working seems silly when all I need is basic authentication. Though it would probably make my life easier once I figure it out. You might want to check out http://www.zope.org/Members/otto/userdb, although it looks rather old. If it's what I think it is, it's based on something done at Zope Corp back in the Principia (Zope before it was Zope) days. UserDb was a pretty simple system that might work for you if it still works. Much easier than anything ZPatterns based - especially given that ZPatterns has gone relatively unmaintained for so long. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Interfaces
On 1/28/02 8:17 AM, Chris Withers [EMAIL PROTECTED] wrote: Jeffrey P Shell wrote: On 1/27/02 11:25 AM, Steve Alexander [EMAIL PROTECTED] wrote: Hi folks, When I define an Interface, are the methods of the interface supposed to have self as the first argument? No. Can you expand on this a little? It doesn't make sense to me to exclude 'self'... Jim [Fulton] explained it to me once. He can explain it better than I can. But think of it this way -- theoretically, an interface can be implemented by a folder full of Python scripts as [relatively] easily as it can be implemented by a class. Should you then include all of the binding options (context, container, etc)? Or, if you were defining the interface in IDL (mmm, almost-avoiding-redundancy through acronyms!) with the target language being Python, would you include self? An interface defines a contract on the usage of an object/component; it's not necessarily a specification on how to implement it. The concept of 'self' as the first argument for instance methods is a product of implementing in a Python class (not to mention that 'self' is not a required name, just an extremely common convention. You could use 'this' just as easily). The big theory behind most component models is that the implementation shouldn't matter so long as certain interfaces are satisfied. And the following simple interface could be satisfied a number of ways in Zope already - by a normal Python class implementation; by a folder with a Python Script or External Method; by a ZClass with the same; or (in Python 2.2) by a class with a static method (which would have no 'self'). class ISubscriber(Base): Subscriber base interface def EventService_inform(event): Informs the subscriber that the event has occurred -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Interfaces
On 1/27/02 11:25 AM, Steve Alexander [EMAIL PROTECTED] wrote: Hi folks, When I define an Interface, are the methods of the interface supposed to have self as the first argument? No. It certainly seems that way from ./lib/python/AccessControl/IUserFolder.py in Zope2. It also seems that way from the Interface Interface. However, many of the interfaces in Zope3 omit the self argument. -- Jeffrey P Shell www.cuemedia.com Sent using the Entourage X Test Drive. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Defining Interfaces
On 1/27/02 3:09 PM, Steve Alexander [EMAIL PROTECTED] wrote: In which case, perhaps we should change InterfaceInterface and InterfaceBaseInterface from Interface/iclass.py to reflect this. The ZDG should also be updated to reflect this, as the example is wrong. http://www.zope.org/Documentation/ZDG/ComponentsAndInterfaces.stx from Interface import Base class Hello(Base): The Hello interface provides greetings. def hello(self, name): Say hello to the name class HelloComponent: __implements__ = Hello def hello(self, name): return hello %s! % name Shall I throw this into the Collector? Probably. I made a comment on the page itself, just a couple of days ago, but it's unknown how often those comments are reviewed: jshell - Jan. 24, 2002 12:56 pm - This should all be updated to reflect where interfaces are going for Zope 3. First, the interface should be named IHello, and there should be no 'self' in the signature for the 'hello()' method. -- Jeffrey P Shell www.cuemedia.com Sent using the Entourage X Test Drive. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] FYI: Sprint schedule online
On Tuesday, January 15, 2002, at 07:45 AM, Paul Everitt wrote: Whew, at long last, I've posted a Sprint Schedule at: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SprintSchedule Boy, that URL is too long. I edited the dev.zope.org homepage to add links to the Zope3 page and the sprint schedule. This page also answers the question, What is a sprint? You of all people better not be whining about Zope URLs! ;) Jeffrey P Shell, [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] References, persistence, BTrees
I'm experimenting with an event notification service based on a publish-subscribe model for some projects I'm working on. When a subscription comes in, a 'Subscription' object is made, that basically looks like this: class Subscription(Base): def __init__(self, subscriber, eventType, filter=None): self.subscriber = subscriber self.eventType = eventType self.filter = filter def __hash__(self): return hash(self.subscriber) \ hash(self.eventType) \ hash(self.filter) 'subscriber' is a reference to the subscribing object, and it's very likely to be to an object in the ZODB. Is it wise to have more than one persistent reference to a single persistent object? I swear that I had once heard Jim say (vocally) that you could do references like this in the ZODB now. I'm trying to avoid using Paths because objects have a tendency to move around[*], and I have performance concerns for a single event service object to have to call 'unrestrictedTraverse' to every subscriber. [*] (it's due to the annoyances with manage_beforeDelete() and friends that I'm writing this tool.) Second question: If I use the hash of the Subscription as a key, is there any advantages/disadvantages with using an IOBTree to hold Subscription objects instead of a PersistentMapping? Jeffrey P Shell, [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Open Letters and Zope 3
On Tuesday, December 4, 2001, at 06:37 AM, Joseph Wayne Norton wrote: [SNIP[ p.s. It is my own personal taste but I don't really care for the tkgui interface for running the zope test suite. Any possibilites of making the test suite run in a fashion similar to the python installation test suite? You can run unittest.py directly. Instead of doing python2.2 utilities/unittestgui.py ..., do python2.2 /usr/local/lib/python2.2/unittest.py ... (based on wherever your python2.2 libraries are). It works just the same. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Open Letter to zope-dev
software shortcomings that may exist as much as any of us in the community. Give them some credit for the great work that they do. They've given up more for the cause of keeping Zope Open Source than most people will ever truely realize. And, after I'm done dealing with my current situation, I'd be willing to head back east for them again if they'll have me. :) Jeffrey P Shell, [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Catalog improvements
On Tuesday, November 20, 2001, at 03:35 PM, Wolfram Kerber wrote: Hi, i'm currently working on a product that allows to attach relational information to zope-objects. It works quite well so far, but to further enhance it i need to make some changes to the Catalog. I could perhaps implement it as a separate product, but i strongly feel that those changes are best applied to the Catalog itself, as they are of general use (i think) and involve a lot of changes to the inner workings of the Catalog. In particular i need the following: - named/stored queries these are precompiled queries, so they can be executed without parsing and are easily cacheable i.e. similar to what is implemented in CMFTopic, but stored in the Catalog and a bit smarter There used to be something like this in ZTables/Tabula (a Zope 1.x product that was sort of the genesis of the Catalog, for better or worse) called 'Hierarchies'. Hierarchies were actually indexes (I think the current Keyword index is descended from the Keyword Hierarchy). I don't know what happened to that code. If it's not available, you could probably achieve the effect that you're looking for here with PluginIndexes, which wouldn't require changing the Catalog at all. Just write a Query Index that indexes objects that match its pre-cooked Query. This would speed up searching tremendously, but you could take a big hit at indexing time if you have many of them. Jeffrey P Shell, [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] PathIndex query options
I've looked hard at the two pages returned for PathIndex on Zope.org, and cannot make sense out of how to use 'level'. From the example, which is full of paths like '/aa/bb/cc' and '/cc/bb/cc' - all of the same size and using the same three letters -, I cannot tell if I can do a path query to find objects ONLY in a certain path, and not above or below it. I have a situation where I have a hierarchy of Task content objects, and in one case I only want to display the immediate child tasks at certain paths (basically to top-level tasks), using the catalog query except for (hopefully) one changed parameter. http://www.zope.org/Members/michel/ZB/SearchingZCatalog.dtml http://www.zope.org//Wikis/DevSite/Proposals/PathIndexDocumentation Jeffrey P Shell, [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] WebDAV API
On Thursday, November 1, 2001, at 05:20 PM, Dethe Elza wrote: Because many existing Windows programs understand FTP but not WebDAV, we're trying to create an alternative way to lock/unlock files when we FTP them. This could be a simple HTTP call (preferred) or XML-RPC. The documentation I've been able to dig up on Zope's DAV implementation isn't too clear on how to programmatically lock/unlock files. I can easily check if a file is locked using DTML Methods, but actually locking it has eluded me. Do I have to create a Lock object first? At first wl_lockItems, wl_lockTokens, and wl_getLock all looked like methods to create a lock, but they seem to be methods for retrieving existing locks, wl_setLock seems to be what I want but I don't see how to create a token or a lock item. Can I do this in a DTML Method? When the WebDAV writelocking project was in its early stages, some debate went to whether the locking mechanism should be exposed to a higher level, and what that mechanism would be. Ultimately, however, it was decided that WebDAV writelocking would be kept entirely within the WebDAV system. It's not recommended that you try to use these outside of that, primarily due to the importance of the 'locktoken' objects, which you need to understand in order to use wl_setLock() and other methods. Jeffrey P Shell, [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] WebDAV API
On Thursday, November 1, 2001, at 06:53 PM, Dethe Elza wrote: Andreas Jung wrote: See Lockable.py and LockItem.py. OK, I was confused and thought an object could serve as it's own lock (Java does something like this). So I need to create a LockItem. Is this class accessible from a DTML Method or should I be looking at an External Method? An external method. LockItems basically model all of the data required by WebDAV to represent what is expected in a WebDAV lockdiscovery property. An object cannot serve as its own lock as there is not a larger locking mechanism in play here - only the WebDAV system. Thus, LockItems are very WebDAV specific - 'exclusive write lock' specific in fact. See also webdav/davcmds.py, classes Lock and Unlock to see how the locks are created and applied. You might also want to check out the seatbelt mechanism in the CMF's Document class as an alternate approach. Jeffrey P Shell, [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] _getOb or __getattr__?
"Chris Withers" [EMAIL PROTECTED] wrote: Jeffrey P Shell wrote: _getOb and _setOb are for placing subobjects somewhere besides attributes (which is the default implementation). When would __getattr__ be used then? In what context? You could wire __getattr__ to call into _getOb (and probably __getitem__ too, since that's also used in traversal and as a way of getting non-Pythonic ID'd objects). def __getattr__(self, attr): return self._getOb(attr) Until very recently, __getattr__ on persistent objects was like playing with nuclear fire. But now, I *believe* it behaves properly, which means __getattr__ gets called when it receives an unknown name. How that affects Acquisition, I don't know. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Geeks] Interface Meta Data proposal
On 11/28/00 4:05 PM, "Michel Pelletier" [EMAIL PROTECTED] wrote:
I've added a sub-proposal to the Interface proposal for describing
additional meta-data with Interface objects:
http://www.zope.org/Wikis/Interfaces/ExtesableMetaData
Please comment about this interesting possibility.
-Michel
Without these things being supported more in the core language, it seems
quite awkward. Being able to do the followng is nice:
class ILockToken(Interface.Base):
def frame(self, width, height):
"a frame"
class LockToken:
__implements__ = ILocktoken,
...
The following would (will?) be better:
interface ILockToken:
def frame(...):
class LockToken implements(ILockToken):
...
But I'm not sure how one would go about setting your meta-data in a way that
is at all natural to Python. I think that exceptions that a method
must\should raise *should* be part of a signature\contract. This is one of
the really cool things about Java. If you use a method, 'readFile' that
says it raises IOError, you *HAVE* to catch that exception (I believe in
order to compile). But it looks like what you're really wanting is to use
interfaces for documentation purposes, not for contract purposes. Not for
interfaces at this level of the language.
I'm guessing along your proposal, to state that a method raises ValueError
or Attribute I'd have to do the following?:
class ILockToken(Interface.Base):
def frame(self, width, height):
"a frame"
frame.setMetaData('exceptions', (ValueError, AttributeError))
...
Meta Data is a deadly term. Be careful with it.
Anyways, I doubt we want to invent our own IDL (no!) or reinvent Eiffel
(specifying pre and post conditions are only truely useful if they're
enforced, and without this enforcement in the core language I imagine that
could be expensive. They're a good thing for large systems, but Python
doesn't support them automatically), so it seems that this information seems
to be best put in the documentation (since doc strings in an Interface don't
also mean "Publish Me!", they can be used to document!).
Interfaces are contracts and pretty darn good ways of specifying parts of
the system, but don't confuse them with headers in C\C++\Objective C.
'IObjectManager' is a critical interface for Zope (so instead of having
attributes like 'isPrincpiaFolderish', we can ask
'IObjectManager.implementedBy(fooObject)'. Folder, on the other hand, is an
important class in Zope, but is primarily an amalgam of classes implementing
important Interfaces (ICopyable, IPropertyManager). It's unlikely that
we'll really have a need for a Folder Interface, because what's important
about Folder's is that they implement ObjectManager behaviors and
CopySupport behaviors.
To bring Java back into play here for a moment, a simple example is the
interface 'Cloneable'. By implementing 'Cloneable', well then.. when it's
time to clone, you can be cloned. If you don't say you implement
'Cloneable', an exception gets raised (even if you implement the proper
method). This is similar to how we sniff things today, but we just do
things like 'if hasattr(obj, "cb_isCopyable") and obj.cb_isCopyable()):'
I get the feeling sometimes that what you want with interfaces is actually a
bit closer to what Objective C does with the word Interface. And that is
that in Foo.h, you have the interface for class Foo:
@interface Foo {
...
And in Foo.m, you have the implementation:
@implementation Foo {
...
These interfaces are header files, and they're damn nice to use for
documentation since the specification of the class is separate from the
implementation. But they don't imply contracts in the way that Java's use
of the word Interface does. (Some implementations of Objective C call those
things Protocols).
Both needs are valid, but I think we'll benefit most from the first
(contracts). In order to make those work, we probably shouldn't make them
too foreign to specify, or the incentives to write them go way down (as is
evidenced by the amount of doc strings that go """ """ or "XXX: Fill in
later", getting developers to fill in too much 'meta data' is hard).
But if we can get some of the information in your proposal more integrated
with the language, I think it would be beneficial.
Jeffrey P Shell, [EMAIL PROTECTED]
http://www.digicool.com/ | http://www.zope.org
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Tag DTML
On 11/2/2000 3:12 PM, "Aitor Grajal Crespo" [EMAIL PROTECTED] wrote: Yeahhh, thanks. But , one more step.:-) can i do it in the init method ??? The init method no have the md parameter. no??? No, __init__ is called at parse time and has no knowledge of the surrounding environment. render\__call__ is called at render time when the namespace becomes important. Jeffrey P Shell, [EMAIL PROTECTED] http://www.digicool.com/ | http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] WriteLocking RiskFactors updated
The WriteLocking RiskFactors artifact has had some new work done on it and I'm interested in some editorial comments and review before work begins on Architecture and UseCases. http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/RiskFactors Make any comments you have at: http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/ProjectDiscussion -- Jeffrey P Shell, [EMAIL PROTECTED] http://www.zope.org/ | http://www.digicool.com/ ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Meaning :-S
On 10/23/2000 11:37 AM, "Chris Withers" [EMAIL PROTECTED] wrote: ...yeah, Zopelet means absolutely nothing, and will just add to confusion :-( The worse confusion is choosing a name that means something and then either o Having to explain that it means different things in different contexts, even within Zope. (This is a bigger problem with the name Method than the whole binding issue. Ditto for script. Instructing a user to write a Python Script will cause a Python programmer to go to the file system). o Having to explain "it's like ... but different..." This was apparently one of the other problems with the name Method, in that PythonMethods (the through-the-web variety) may or may not behave like traditional Methods in programming languages. This is especially bad when the code is Python since Python is also what we develop in. Python can now exist in many places in Zope (web, Extensions/, and Products (disk based)). External Methods were a nice name in that they connoted that it was a chunk of code that was external to Zope (at least the ZODB). The use of 'method' can come back into issue regarding how they got bound (ugh), but the External bit fit. If I was told "write an External method", I knew what that meant. When*ever* I hear someone mention writing a new python method to do something, it has to be qualified with "you mean in a product\class on the file system or a _PythonMethod_?" Function, Script.. They all fall prey to the same thing. Zopelets follows the cute naming of Applet, Servlet, Scriptlet... (IE has Scriptlets). I'm not advocating it entirely, but it follows a nice silly tradition in a way that is explainable - small chunks of Zope code managed through the web. And they happen to be in Python. (or could be predicated by the language of choice). Jeffrey P Shell, [EMAIL PROTECTED] http://www.digicool.com/ | http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] WriteLocking Project Initialized
http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/FrontPage WriteLocking became a full fledged Fishbowl Project this week, and I've been spending the past couple of days getting the initial Artifacts and structure of the Project site together. The current structure should stand through elaboration. There is no planned schedule yet as the Risks themselves are still being scoped out and the UseCases haven't even been started on yet, but it is currently planned to get the proposed functionality into Zope 2.3. The main pages of interest right now are: VisionStatement (what the project is about, from the original proposal) http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/VisionStatement RecentChanges http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/RecentChanges CurrentStatus (I really will work on keeping this up to date) http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/CurrentStatus There are other pages outlining o RiskFactors (this is the one most actively being worked on right now), o TargetClients (LOCKing WebDAV clients we're planning to test against), o ProjectGlossary (Terms and definitions) And the general ProjectDiscussion page at http://dev.zope.org/Wikis/DevSite/Projects/WriteLocking/ProjectDiscussion I ask that if you make comments on the proposal to either do them on the ProjectDiscussion page or on the [EMAIL PROTECTED] list. Please read the Scope section of the VisionStatement first, which outlines both what the intended goals Are and Are Not. Remember that the project is still in the early stages of Elaboration, and some of the artifacts are incomplete. In light of this election season, I pledge to you I will try my hardest to go to work 50+ miles south of Washington and fight to keep the information flowing through the Wiki updated and available to ALL Zope people, everywhere. No fuzzy math in these parts! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Typo in Version.py
On 10/18/2000 9:04 AM, "Greg Ward" [EMAIL PROTECTED] wrote: Now if only I could figure out why Zope is trying to raise that exception on me... (I'm not deleting a version, I'm just renaming something within a version!) Greg Because Rename deletes. The basic sequence of a renameObject command is (in short): In short, it: 1.Gets the object off of the objectmanager using the old id. 2.Deletes it from the objectmanager (doesn't delete the object itself!). 3.Changes the id of the object. 4.Adds it back to the objectmanager with the new id. The detailed version is: 1.Check ID (is the new id invalid or already used?), raise Invalid ID if so. 2.Get the object using _getOb 3.Check if object supports copying\moving using cb_isMoveable, raise CopyError 4.Use _verifyObjectPaste (Does some verification to make sure the user. 5.Try to notify recipient of the copy (in this case "self" - the ObjectManager or other CopySupport-subclassed class instance), if that fails, raise a Rename Error. 6.Delete the object off of the object manager (self._delObject) 7.If possible, get the aq_base of the object, then set the objects id to the new id. 8.Set the modified object on the ObjectManager, leaving the ownership info unchanged. (self._setObject). Jeffrey P Shell, [EMAIL PROTECTED] http://www.digicool.com/ | http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Typo in Version.py
On 10/18/2000 9:27 AM, "Jeffrey P Shell" [EMAIL PROTECTED] wrote: On 10/18/2000 9:04 AM, "Greg Ward" [EMAIL PROTECTED] wrote: Now if only I could figure out why Zope is trying to raise that exception on me... (I'm not deleting a version, I'm just renaming something within a version!) Greg Because Rename deletes. The basic sequence of a renameObject command is (in short): Actually, I'm not sure what you're asking here: are you renaming the Version object itself? Or renaming something else while inside the version? Jeffrey P Shell, [EMAIL PROTECTED] http://www.digicool.com/ | http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Writelocking Proposal rev 3.1
http://dev.zope.org/Wikis/DevSite/Proposals/WriteLocking The proposal has been updated with a new deliverable discussing documentation as noted and requested by Brian. Jeffrey P Shell, [EMAIL PROTECTED] http://www.digicool.com/ | http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] WriteLocking Proposal Revisited. Again.
WriteLocking http://dev.zope.org/Wikis/DevSite/Proposals/WriteLocking Revisited and rewritten again after some internal discussions and a decision to ensure that the proposed Write Locking for WebDAV behaves in a matter that the clients (particularly the more popular ones) expect. There's less architectural discussion in this revision of the proposal, intentionally. --jeffrey ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Locking (supercedes original writelocking proposal)
This supercedes the original WriteLocking proposal which was initially just to cover WebDAV's current write locking ability. http://dev.zope.org/Wikis/DevSite/Proposals/WriteLocking -- Jeffrey P Shell, [EMAIL PROTECTED] http://www.zope.org/ .oO ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
