Re: [Zope-dev] Added rename to ZOPE FTP server (another bug: jpg images are not autodetected)

2001-01-28 Thread Tom Vijlbrief

Joachim Werner wrote:
 
 Hi!
 
 I've found one problem with FTP and KDE: jpg-images are uploaded as
 files, not images. This works fine with wedav (tried cadaver) and plain
 command line FTP, but using KDE2 konqueror it doesn't work. Maybe
 because of the partial upload magic it does?
 

Yes, I checked the code (ZClasses/Method.py, PUT_factory)
and that's the reason. The Zope ftp server checks the extension
when a file is created with "put", but not when it is renamed
to a file with the .jpg (or other) extension.

A method manage_FTPrename should be added to this
file which does the same checks.

Fixing this bug and the problem with identical named files in
different directories in the object filesystem tree (described
in my original posting) should not be very hard
to fix for someone with knowledge of the object file system.

I don't have that knowledge so I'll leave it to others to
fix. I suggest posting both problems in the bug collector...

Tom

___
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] How to avoid ConflictErrors ?

2001-01-28 Thread Morten W. Petersen

Hi zopers,

I'm having problems with a product I'm developing.  The product is part of the
ZopeGUM package, the GUM product.  If you have a look in gum.py in that
product, you can see a method named _retrieve_messages, which can at
times store enourmous amounts of objects and data in one transaction.

Now, if I access the GUM instance at the same time as this method is being
called, I may either get a ConflictError raised in the page, or in the
Zope debug output. 

I've read all the posts I could find regarding ConflictErrors, and they
mention that careful programming could help in avoiding these exceptions.
I'm assuming that this applies only to whenever two threads are trying
to *modify* the same object; and frankly, I can't see where I'm modifying
any objects, unless modifying one object, an rfc822_message instance in
a message_container instance also somehow modifies the message_container.

Any idea what I'm doing wrong?

Thanks  cheers,

Morten

___
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] How to avoid ConflictErrors ?

2001-01-28 Thread Morten W. Petersen

[Chris Withers]

| Please check that both rfc822_message and message_container subclass
| Persistence.Persistent.

They do.  *ponder*

-Morten

___
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: [Zope] Creating a namespace

2001-01-28 Thread Chris Withers

Stephan Richter wrote:
 
 ...and search the list archives.
 
 The e-groups search is pointless and never gives you anything useful (I did
 that already).

So use the ones at NIP:

http://zope.nipltd.com/public/lists.html

 Thanks so much for your hints, but I am just a little frustrated right now
 (not because of you), since some of the Zope code looks like a hack. I
 could live without documentation, if the code would be some sort of readable.

Well, maybe if you explained exactly what you're trying to do, we could be more
helpful ;-)

cheers,

Chris

___
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.3.0 ZCatalog Copy Paste Bug Fixed :-)

2001-01-28 Thread Chris Withers

 ...but the error message looks better ;^)=

Oh boy, Chris P's gonna kick himself for this one ;-)

The idea was to change the meta_type of ZCatalog to Z Catalog so it was like
everything else in core Zope, but he left a 'bad' line in ZCatalog.py. The
patch below fixes the problem.

*grinz*

Chris

--- zcatalog.py.old Fri Jan 26 14:03:24 2001
+++ zcatalog.py Sun Jan 28 20:31:50 2001
@@ -141,7 +141,6 @@

 """

-meta_type = "ZCatalog"
 icon='misc_/ZCatalog/ZCatalog.gif'

 manage_options = (


___
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] asynchat producer ready() method patch.

2001-01-28 Thread Dieter Maurer

Donovan Baarda writes:
  I remember reading ages ago on a wishlist for ZServer that someone was
  thinking of adding blocking support to producers. This patch adds support
  for just that in a non-intrusive way. I haven't tried applying this patch to
  ZServer, but it _should_ work.
What does "blocking support dor producers" mean?



Dieter

___
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] ZCatalog Bug Fix II

2001-01-28 Thread Chris Withers

 Chris Withers wrote:
 
  Okay, tracked down what's happening, can't understand why :-(

Now I can... convoluted but with a simple answer ;-)

 As to why the object is on the top of the namespace, I dunno whether it's
 dtml-in or ZCatalog that's responsible...

The reason for this, was because the object was being acquired. The naming
similarity was pure chance. I had an index called TestCase in the catalog,
the same name as the DTML method for the form. I _didn't_ have a column
called TestCase in the ZCatalog MetaData, so when the result-displaying DTML
method tried to dtml-var it, it was acquired, and hence the method was
plopped on top of the namespace.

The actual problem is that ZCatalog was using the indexes instead of the
metadata when telling Z Search was results form to build. The following
patch solves that, I'm sure I put it in the collector when I moved Squishdot
to use ZCatalog too :-S

cheers,

Chris

--- zcatalog.py.old2 Sun Jan 28 20:56:06 2001
+++ zcatalog.py Sun Jan 28 21:00:09 2001
@@ -486,7 +486,7 @@

 def _searchable_result_columns(self):
 r = []
-for name in self._catalog.indexes.keys():
+for name in self._catalog.schema.keys():
 i = {}
 i['name'] = name
 i['type'] = 's'

PS: I won't bother with the collector on this one, since both relevent
people are already being CC'ed ;-)


___
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] ZDebug patch for 2.3.0

2001-01-28 Thread Chris Withers

The patch below got ZDebug working with Zope 2.3.0 for me. Hope I didn't
miss anything ;-)

cheers,

Chris

--- debugsecuritypolicy.py.old Sun Jan 28 21:59:23 2001
+++ debugsecuritypolicy.py Sun Jan 28 22:07:21 2001
@@ -89,7 +89,7 @@
 __version__='$Revision: 1.4 $'[11:-2]

 from AccessControl import SimpleObjectPolicies
-_noroles=[]
+_noroles=SimpleObjectPolicies._noroles

 from AccessControl.PermissionRole import \
  _what_not_even_god_should_do, rolesForPermissionOn
@@ -99,7 +99,7 @@
 class DebugSecurityPolicy:

 def validate(self, accessed, container, name, value, context,
- None=None, type=type, IntType=type(0), DictType=type({}),
+ roles=_noroles, None=None, type=type, IntType=type(0),
DictType=type({}),
  getattr=getattr, _noroles=_noroles, StringType=type(''),
  Containers=SimpleObjectPolicies.Containers,
  valid_aq_=('aq_parent','aq_explicit')):
@@ -116,7 +116,8 @@

 
 # Try to get roles
-roles=getattr(value, '__roles__', _noroles)
+if roles is _noroles:
+roles=getattr(value, '__roles__', _noroles)

 if roles is _noroles:

@@ -174,7 +175,14 @@
 value=container

 # Short-circuit tests if we can:
-if roles is None or 'Anonymous' in roles: return 1
+try:
+if roles is None or 'Anonymous' in roles: return 1
+except TypeError:
+# 'roles' isn't a sequence
+LOG('Zope Security Policy', PROBLEM, "'%s' passed as roles"
+" during validation of '%s' is not a sequence." % (
+`roles`, name))
+raise

 # Check executable security
 stack=context.stack



___
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: Creating a namespace

2001-01-28 Thread Michael Halle


Stephan Richter [EMAIL PROTECTED] writes: 

 I want to make my own name space with the following situation:
 class X:
 attributes = {'foo': 'bar'}
 x = X()
 Then I want to use it like that:
 dtml-with x
   dtml-var foo
 /dtml-with

I puzzled through a related problem a little, but for (I think) a
different reason.  I have an External Method that takes a significant
amount of time to run, and returns a collection of data. I didn't want
to have to push the names of all the subvariables returned onto the
stack; that pollutes the name space.  What I wanted to do was the
following:

dtml-let x="MyExternalMethod(arg1, arg2)"
Variable 1: dtml-var expr="x.variable1" br
Variable 2: dtml-var expr="x.variable2" br
/dtml-let

(But, as in your case, I could also have done:

 dtml-with expr="MyExternalMethod(arg1, arg2)"
Variable 1: dtml-var expr="variable1" br
Variable 2: dtml-var expr="variable2" br
 /dtml-let )


To me, this first example seemed like a pretty common and obvious
thing to to.  I didn't need "x" to be persistent, I didn't need or
want acqusition, I just wanted to keep my variables containerized in a
structure.  For this purpose, FunctionTemplate, InstanceDict, and
TemplateDict all seemed either inappropriate, too complex, or too
heavyweight.

So, I wrote the simple container class at the end of this message that
contains a grab-bag of methods that can be used for my application as
well as with a variety of others that use dtml-with and dtml-in.
It essentially provides all that "_.namespace()" does, plus some extra
introspection.  It's concocted from various pieces of Zope and the
HowTos.

Now, philosophical Zope questions:

* To those in the know, is there any problems returning non-persistent
structures?

* Next, it there a reason that there's no sanctioned class for this
purpose?

* Can you return a populated namespace from a DTML Method or a Python Script
using existing mechanisms?

* Why can't you set values in "_.namespace()" in DTML after a
namespace has been created?

* To me, it would make so much more sense to be able create a namespace
with temporary variables (as shown in one of the HowTos) rather than
forcing people to hack them using REQUEST.set().  The namespace
could be used directly as a structure (eg, "ns.x") or as a scope 
(eg, dtml-with ns dtml-var x /dtml-with ).  Is there a deep
reason it doesn't exist?

Anyway, here's my "no-guarantee" class.  Notice the magic member
"__allow_access_to_unprotected_subobjects__", which the documentation
(read, code) says can also be set to a list of members that you want
to be publicly accessible and unprotected.  Use this code as a guide;
you can trim it down to get what you want.  An instance of this class
can be used directly as an argument to dtml-with; to use with
dtml-in, use either the "getItems" or "getMap()" methods.


-

class StructureInstance:
"""A simple, non-persistent, class-based dictionary
that's useful for returning arguments to Zope"""

__allow_access_to_unprotected_subobjects__ = 1

def __init__(self, dict={}):
self.__d=dict

def __getattr__(self, name):
try: return self.__d[name]
except KeyError: raise AttributeError, name

def __getitem__(self, name):
try: return self.__d[name]
except KeyError: raise KeyError, name

def __setitem__(self, name, value):
self.__d[name] = value

def update(self, dict):
self.__d.update(dict)

def getKeys(self, spec=None):
if spec is None:
return self.__d.keys()

return filter((lambda x, spec=spec: x in spec), self.__d.keys())

def getValues(self, spec=None):
if spec is None:
return self.__d.values()

return map(lambda y: y[1],
  filter((lambda x, spec=spec: x[0] in spec),
 self.__d.keys()))

def getItems(self, spec=None):
if spec is None:
return self.__d.items()

return filter((lambda x, spec=spec: x[0] in spec), self.__d.items())

def getMap(self, spec=None):
items = self.getItems(spec)
dict = {}
for (i, j) in items:
dict[i] = j
return dict

def set(self, **args):
self.update(args)

setitem=__setitem__


---
Michael Halle
[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] Possible TransparentFolders bug?

2001-01-28 Thread Itai Tavor

I can't reproduce this problem myself. In fact, as of this morning it 
doesn't happen anymore. Guess it was just one of those flukes the 
universe throws at me to try to convince me to move to another 
universe.

Shane Hathaway wrote:

Itai Tavor wrote:
  The TransparentFolders Product seems to make everything
  transparent... not just transparent folders.

  Zope/
   Folder_A/
   method_A
   Folder_B/ (transparent folder)
   method_B

  I'd expect the only effect of the transparent folder to be that
  /Folder_A/method_B would work. But /method_A and /method_B also work.
  Tested in Zope 2.3b2 and 2.3b3 with TransparentFolders 0.3.

Hmm... I can't get mine to do that.  You're sure Folder_A isn't
transparent also?  Did you ever have a transparent folder by that name,
in that same place?  (Indicating a bug)

Otherwise leaving things as they are, if you put a transparent folder at
the root of the site, do you still get the same behavior?

What path does it tell you if you visit
http://yourserver:8080/method_{A|B}/manage_main?

Shane

-- 
--
Itai Tavor  -- "Je sautille, donc je suis."--
[EMAIL PROTECTED]--   - Kermit the Frog --
-- --
-- "If you haven't got your health, you haven't got anything"  --


___
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] Unable to clear proxy roles in Zope 2.3.0

2001-01-28 Thread Dirksen

In Zope 2.2.x, one can clear the proxy roles for one method by unseleting all proxy
roles. In Zope 2.3.0, this lets to this error: You must select one or more proxy roles.
Is it a bug, or is it done in a different fashion?

cheers
Dirksen

__
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices. 
http://auctions.yahoo.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.3.0 release badness

2001-01-28 Thread richard

I've just updated to 2.3.0 release using CVS. My CSS serving has
subsequently broken. The CSS serving worked fine with the CVS code from
2.3.0b2. I didn't get to check b3 - we had a public holiday on Friday and
that meant that the one working day assigned to the b3 release was lost to
me (and _most_ other Australians). Anyway, that's a separate issue ...

I've done a diff against the CVS as of last Tuesday, but I can't see an
obvious place where the Zope code has changed to make the CSS serving fail.

Under Netscape (versions 4.72 - 4.75), a 'back button' request results in
a truncated plain-text display of the CSS that is linked from the page. The
zope server log shows the request as being successfully served. I telnet'ed
to the server and requested the CSS manually, and the headers all look
fine. A packet sniffer seems to say that all is well.

Now for the fun: this only happens for local requests - someone requesting
the same pages over the ethernet will get them fine. Only Netscape and only
locally. Konqueror locally works fine.

The CSS is being served using the attached class.

Some further experimentation:
1. load the same page five times as follows:
  http://mymachine:8080/blah/
  http://127.0.0.1:8080/blah/
  http://127.0.0.2:8080/blah/
  http://10.0.0.20:8080/blah/
  http://127.0.0.3:8080/blah/
2. starting from either end of those URLs in the browser history, hit the
'forward' button or 'back' button four times to get to the other end.
3. note that the first hit of 'forward' or 'back' (and sometimes other hits
too) the CSS is served as plain text

Of course, embedding the style in the page (a-la the Zope management
interface) gets around this problem, but this is not an option for us.

Again, this was not a problem pre 2.3.0 b3 / release...


   Richard

-- 
Richard Jones
[EMAIL PROTECTED]
Senior Software Developer, Bizar Software (www.bizarsoftware.com.au)
 CSSFile.py


Re: [Zope-dev] 2.3.0 release badness

2001-01-28 Thread Pablo Bleyer Kocik

[EMAIL PROTECTED] wrote:

 I've just updated to 2.3.0 release using CVS. My CSS serving has
 subsequently broken. The CSS serving worked fine with the CVS code from
 2.3.0b2. I didn't get to check b3 - we had a public holiday on Friday and
 that meant that the one working day assigned to the b3 release was lost to
 me (and _most_ other Australians). Anyway, that's a separate issue ...
 (...)
 Under Netscape (versions 4.72 - 4.75), a 'back button' request results in
 a truncated plain-text display of the CSS that is linked from the page. The
 zope server log shows the request as being successfully served. I telnet'ed
 to the server and requested the CSS manually, and the headers all look
 fine. A packet sniffer seems to say that all is well.
 (...)
 Now for the fun: this only happens for local requests - someone requesting
 the same pages over the ethernet will get them fine. Only Netscape and only
 locally. Konqueror locally works fine.
 (...)
 Again, this was not a problem pre 2.3.0 b3 / release...

Richard

Hi!

Nope, this is not only a problem of 2.3.0. I have had the same issue in all
of the 2.3.0x Zope versions, and the problem is not really Zope but Netscape
4.X.

For me, the trouble arises once in a while and specially when I start doing
page reloads quickly. It seems that, when Zope starts serving the document,
Netscape asks for the stylesheet file almost instantly (because it is inside
the HTML's header) and then a sort of synchronizing error happens. When you are
at the local machine the delay between the document requests is larger so the
problem is less frequent.

I have never seen the problem under Netscape 6 or Mozilla. I don't know to
what extent this could be Zope's fault.

Cheers!

--
Pablo Bleyer Kocik |
pbleyer|"Rintrah roars  shakes his fires in the burdend air;
  @embedded.cl | Hungry clouds swag on the deep" — William Blake



___
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] asynchat producer ready() method patch.

2001-01-28 Thread Donovan Baarda

On Sun, Jan 28, 2001 at 09:31:07PM +0100, Dieter Maurer wrote:
 Donovan Baarda writes:
   I remember reading ages ago on a wishlist for ZServer that someone was
   thinking of adding blocking support to producers. This patch adds support
   for just that in a non-intrusive way. I haven't tried applying this patch to
   ZServer, but it _should_ work.
 What does "blocking support dor producers" mean?

Disclaimer: you must be moderately familiar with ZServer/medusa/asynchat for
the following to make sense;

Asynchat used by ZServer and medusa use producers as a way to "push" data
through an async interface. The current version of asynchat requires that
producers be able to produce data immediately on calling their more()
method, untill they are finished, when they return ''. 

My patch adds support for producers being able to "block" by letting
asynchat know if they are ready via a ready() method. This allows you to use
the simple producer model to push data that may not be immediately
available. An example would be a http-fetch producer that fetches data from
upstream for a proxy.

This patch is only useful for people creating or modifying things like
medusa or ZServer.

-- 
--
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
--

___
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.3.0 release badness

2001-01-28 Thread Pablo Bleyer Kocik

 the HTML's header) and then a sort of synchronizing error happens. When you are
 at the local machine the delay between the document requests is larger so the


Oops. That should be "When you are *not* at the local machine...". Sorry ;^)

--
Pablo Bleyer Kocik |
pbleyer|"Rintrah roars  shakes his fires in the burdend air;
  @embedded.cl | Hungry clouds swag on the deep" — William Blake



___
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 )