Re: [Zope-dev] Redirecting from the manage interfaces.
Erik Enge wrote: > > call, it won't redirect. So you should be able to achieve the same > > results just by invoking manage_addImage without including the REQUEST > > object. > > But I have to pass something with the REQUEST, or else it won't add the > image, right? I do not think so. "manage_addImage" does not need REQUEST to add the image. The request is only used to redirect. 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] getting request variables values
Steve Alexander wrote: > My question is "why was __getitem__ of HTTPRequest.py designed this > way?". > > Is there a good reason that it filters the keys according to membership > of a standard-cgi-keys list, or whether they start with 'HTTP_' ? > Would there be any disadvantage to altering __getitem__ so that it > behaves according to its docstring? I looked at the entire history of that code. This algorithm dates back to 1996. I think the issue is that environ may include the Zope process environment variables, such as PATH, LD_LIBRARY_PATH, CVSROOT, USER, etc. Publish.publish_module() appears to pass in os.environ . That's just a quick analysis, though. Shane ___ 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] Problem acquiring via a newly created object
Richard Barrett wrote: > I'm using the following python expression in the manage_addFolder and > manage_addDocument functions to determine the location in the file > system for the RCS backup of the data. > > rcspath = os.path.normpath(getattr(self, 'website_RCS_root') + \ > '/' + self.absolute_url(1) + \ > '/' + ob.id) > > As you can see it depends an acquiring the value of the > 'website_RCS_root' attribute from its containment environment. I believe this may work better in Zope 2.2.0--or perhaps the latest CVS. Jim made some changes to FactoryDispatcher that involve the factory method's "self" argument. Try it out. Shane ___ 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] Python 2.0
Is anyone else using Zope with python 2.0? (on NT, fwiw) I am occasionally seeing protection faults as Zope starts up. When it happens, the fault is repeatable until I truncate data.fs. There may be some correlation to changing a help file (Zope's new help system will reindex its help files at startup if any have changed). Annoyingly, the it doesnt happen with a debugging build. Is anyone else seeing this? Or not seeing this? Toby Dickenson [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] Problem acquiring via a newly created object
Richard Barrett wrote: > > My classes (and some others yet to be written) are intended for use > when requirements stipulate that published material must be > held/protected in RCS as well as being served via Zope. I've elected > to put an attribute called 'web_RCS_root' at the top of the Zope > object hierarchy which contains the server local file system path > under which files to be held by RCS. http://www.zope.org/Members/sspickle/ZCVSMixin Perhaps this product will help. You might be able to use CVS instead of RCS, or you may find that Steve Spicklemire has solved some of the problems already. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] Problem acquiring via a newly created object
Steve Alexander wrote: > > Richard Barrett wrote: > > > > My classes (and some others yet to be written) are intended for use > > when requirements stipulate that published material must be > > held/protected in RCS as well as being served via Zope. I've elected > > to put an attribute called 'web_RCS_root' at the top of the Zope > > object hierarchy which contains the server local file system path > > under which files to be held by RCS. > > http://www.zope.org/Members/sspickle/ZCVSMixin Screenshots linked from here: http://www.zope.org/Members/sspickle -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] Problem acquiring via a newly created object
I'm stumbling to find a solution to the following problem. Using python I have created two classes which respectively derive from the standard Zope Folder class and DTMLDocument class. My classes (and some others yet to be written) are intended for use when requirements stipulate that published material must be held/protected in RCS as well as being served via Zope. I've elected to put an attribute called 'web_RCS_root' at the top of the Zope object hierarchy which contains the server local file system path under which files to be held by RCS. When instances of the Folder derived class are created, the add function creates a file system folder below the 'web_RCS_root'. The add function for my folderish objects effectively creates a directory hierachy in the file system isomorphic to the hierachy of the URL's being served by Zope. Instances of my DTMLDocument derived class are only allowed within my Folder derived class. The add document function that creates them and the edit function for them use RCS check-in to preserve copies of the document contents. I'm using the following python expression in the manage_addFolder and manage_addDocument functions to determine the location in the file system for the RCS backup of the data. rcspath = os.path.normpath(getattr(self, 'website_RCS_root') + \ '/' + self.absolute_url(1) + \ '/' + ob.id) As you can see it depends an acquiring the value of the 'website_RCS_root' attribute from its containment environment. This works fine for both folder-like and document-like classes if the add functions are called from the management interface. However, I want to create an instance of my document class within the containment of an instance of my folder class while creating that instance of my folder class. Just like creating a public interface (index_html) as part of creating a regular folder, which is what my code is based on. I'm doing this by calling my manage_addDocument function from within the my manage_addFolder function. But this fails with Zope reporting an AttributeError of the acquired attribute 'website_RCS_root'. My best guess as to why goes something like: "until the transaction in which the folder is created is committed, the acquisition of attributes higher in the containment hierarchy will fail. As you are trying to create the document in the same transaction this is bound to fail", but I've no proof this is the problem. What's going wrong and what's a good solution to the problem. I'm working with Zope 2.1.6 running under Suse 6.4 Linux on an x86 processor. -- Richard Barrett, PostPoint 27, e-mail:[EMAIL PROTECTED] Fujitsu Telecommunications Europe Ltd, tel: (44) 121 717 6337 Solihull Parkway, Birmingham Business Park, B37 7YU, England "Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well armed lamb contesting the vote." Benjamin Franklin, 1759 -- ___ 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] dtml-in problem at Zope 2.2.0
Here is the scenario: On Folder X I have a Z ODBC Database Connection and some Z SQL Method. I´m sure all are working because I´ve tested them all. Under Folder X I have another Folder Y with an index_html with the following: No need to include anything inside the dtml-in. This works fine with Zope 2.1.6 but with Zope 2.2.0 I get the user/password dialog from the browser and I can give whatever user/password combination but none of them works. Thanks in advance, Jacques ___ 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] several permissions for the same method
Chris Withers wrote: > You could just check for the permissions specifically, here's a quote > from Folder.py in Zope 2.2: Yes. though it seems odd to create permissions not protecting any method that are just meant to be checked. calling a method that the current user is not not allowed to access raises Unauthorized for you. I can just check 'manually' the permission if I want to display a specific message. thanks for your comments [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] zzLocale 0-0-3a released on Zope Japan
Hi Zopistas, This is the second alpha release of zzLocale, a Zope locale support Product. zzLocale provides a framework for Zope interface internationalization (Zope and Products management screens). The localization is done on a per request basis, which allows developers from different countries to work on the same Zope while each of them having an interface in his native language. With zzLocale, Product developers can easily provide localized interfaces for their Products. All that is needed is to put the localized interface DTML templates in a "locales/[lang]" subdirectory of the Product, and zzLocale does the rest. This version of zzLocale is pretty useable, and usually falls back nicely when something goes wrong. However, it is still alpha, and we would not recommend using it on a production server. This release includes a complete (I mean, as complete as current zzLocale features permit) French interface, and a partial Japanese one. Tranlators are welcome to provide other languages. Please send us your translated templates so that we can include them in the next release. For more information and download: http://www.zope.ne.jp/users/yemartin/zzLocale Regards, -- Yves-Eric Martin Digital Garage Inc. [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] Zope bug (w/ patch): hard coded Unix separator in special_dtml.py
Hello Zopistas,
When trying to figure out why our Product zzLocale was behaving
strangely under Windows, I found that the raw attribute of management
screens was weird (had a unix separator '/' before the template name),
and I traced it back to what I believe is a bug in Zope:
In lib/python/App/special_dtml.py, we have:
> def __init__(self,name,_prefix=None, **kw):
> if _prefix is None: _prefix=SOFTWARE_HOME
> elif type(_prefix) is not type(''):
> _prefix=Common.package_home(_prefix)
>
> args=(self, '%s/%s.dtml' % (_prefix,name))
^
hard-coded unix separator
> if not kw.has_key('__name__'): kw['__name__']=name
> apply(HTMLFile.inheritedAttribute('__init__'),args,kw)
I think this should rather be (tested and working patch):
> args=(self, os.path.join(_prefix, name + '.dtml'))
Does that sound right to you? If no one disagrees, I'll fill a bug
report w/ patch in the Collector.
--
Yves-Eric Martin
Digital Garage Inc.
[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] Datebug?
I have encountered a strange and irritating problem. As I live in Sweden we use timezone 'GMT+1'. I have a form like this: And when I press submit I come to this page: The input field are correctly displaying the date (in GMT+1) but when I submit the form and use the "fmt" the date is displayed with a decrease of 24 hours. Like if I write 2000-07-21 in the input-field the next page will display 2000-07-20. I I dont format the date on the second page the same date will be shown. It cant really be a timezone issue because it is decreasing the date by 24 hours and I only live 1 hour from GMT. The date on my computer and the server are correct. Does someone knows why this happens when I use "fmt" or is this a DateTime bug? ___ 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] getting request variables values
Steve Alexander wrote: > > My question is "why was __getitem__ of HTTPRequest.py designed this > way?". > > Is there a good reason that it filters the keys according to membership > of a standard-cgi-keys list, or whether they start with 'HTTP_' ? > Would there be any disadvantage to altering __getitem__ so that it > behaves according to its docstring? ...although the class docstring says that the environment variable names are as in the CGI specification (http://hoohoo.ncsa.uiuc.edu/cgi/env.html). It doesn't say that they should **only** be from the CGI specification, though. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] getting request variables values
Steve Alexander wrote:
>
> However, looking in the code, it starts off by looking in "other", and
> doesn't look in "environ" at all.
>
> I suggest a patch to go right after the method's docstring:
>
> def __getitem__(self,key,
> default=_marker, # Any special internal marker will
> do
> URLmatch=regex.compile('URL[0-9]+$').match,
> BASEmatch=regex.compile('BASE[0-9]+$').match,
> ):
> """Get a variable value
>
> Return a value for the required variable name.
> The value will be looked up from one of the request data
> categories. The search order is environment variables,
> other variables, form data, and then cookies.
>
> """ #"
> + environ=self.environ
> + if environ.has_key(key):
> + return environ[key]
> other=self.other
> if other.has_key(key):
> if key=='REQUEST': return self
> return other[key]
Ok... I was wrong :-/
A bit later we have:
if isCGI_NAME(key) or key[:5] == 'HTTP_':
environ=self.environ
if environ.has_key(key) and (not hide_key(key)):
return environ[key]
return ''
I was only sort-of wrong though :-)
The code certainly doesn't stick exactly to its docstring. The "other"
dictionary is seached first, then URLx where x is a number.
Then "environ" is searched, but *only* if the key begins with 'HTTP_' or
is in the following list:
SERVER_SOFTWARE, SERVER_NAME, GATEWAY_INTERFACE, SERVER_PROTOCOL,
SERVER_PORT, REQUEST_METHOD, PATH_INFO, PATH_TRANSLATED, SCRIPT_NAME,
QUERY_STRING, REMOTE_HOST, REMOTE_ADDR, AUTH_TYPE, REMOTE_USER,
REMOTE_IDENT, CONTENT_TYPE, CONTENT_LENGTH, SERVER_URL
Looking in Leonardo's sample environment, a posted to this list, there's
a lot of keys that won't get matched:
SSL_*
HTTPS_*
REMOTE_PORT
SERVER_ROOT
SERVER_SIGNATURE
My question is "why was __getitem__ of HTTPRequest.py designed this
way?".
Is there a good reason that it filters the keys according to membership
of a standard-cgi-keys list, or whether they start with 'HTTP_' ?
Would there be any disadvantage to altering __getitem__ so that it
behaves according to its docstring?
If so, the patch would probably be something like:
line 753.
""" #"
+ environ=self.environ
+ if environ.has_key(key) and (not hide_key(key)):
+ return environ[key]
other=self.other
if other.has_key(key):
if key=='REQUEST': return self
return other[key]
if key[:1]=='U' and URLmatch(key) >= 0:
path = self._script + self._steps
n = len(path) - atoi(key[3:])
if n < 0:
raise KeyError, key
URL=join([other['SERVER_URL']] + path[:n], '/')
other[key]=URL
self._urls = self._urls + (key,)
return URL
- if isCGI_NAME(key) or key[:5] == 'HTTP_':
- environ=self.environ
- if environ.has_key(key) and (not hide_key(key)):
- return environ[key]
- return ''
Comments?
--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net
___
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 )
