[Zope3-dev] Re: [Zope-dev] Zope definition on Wikipedia
On Thu, 2006-01-26 at 14:53 +0100, Stefane Fermigier wrote: I have made a little update on the Zope article on Wikipedia: http://en.wikipedia.org/wiki/Zope Great! Here is the diff: http://en.wikipedia.org/w/index.php?title=Zopediff=36787848oldid=36094466 It would probably be very helpful if some knowledgeable people would also take some time to review the whole content of the article. Maybe split Zope 3 to a separate page, or at least start a page on the component architecture. There already is a separate Zope 3 page: http://en.wikipedia.org/wiki/Zope_3 There are also some disputable assertions, like this one More recently the Zope community branched in two directions. The Plone community turned Zope into a nice-looking content management system, complete with modern well-designed style sheets. The original authors released Zope 3. that should be corrected. That is definitely misleading. -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Refresh / Change-Buttons
Hi, is there a chance we can get rid of the Refresh button on the standard forms? Every now and then, I hit the wrong one. And I do not see a clear need for the refresh. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Refresh / Change-Buttons
Christian Theune wrote:
On Fri, 2006-01-27 at 09:33 +0100, Michael Haubenwallner wrote:
'Refresh' should be called 'Reset' -- in fact resetting the form
contents to the original loaded values
('Reset' is also the buttons default value displayed in the browser)
Well. That's not what the button currently does. When I click on it, it
does a page reload. A form reset does this without.
Then, I also don't see many 'reset' buttons nowadays. And I don't miss
them. After all, I'm not sure in which order I would want them.
Should have been resolved as by this Issue
http://www.zope.org/Collectors/Zope3-dev/467
Michael
--
http://zope.org/Members/d2m
http://planetzope.org
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Refresh / Change-Buttons
Hi,
On Fri, 2006-01-27 at 09:39 +0100, Michael Haubenwallner wrote:
Christian Theune wrote:
On Fri, 2006-01-27 at 09:33 +0100, Michael Haubenwallner wrote:
'Refresh' should be called 'Reset' -- in fact resetting the form
contents to the original loaded values
('Reset' is also the buttons default value displayed in the browser)
Well. That's not what the button currently does. When I click on it, it
does a page reload. A form reset does this without.
Then, I also don't see many 'reset' buttons nowadays. And I don't miss
them. After all, I'm not sure in which order I would want them.
Should have been resolved as by this Issue
http://www.zope.org/Collectors/Zope3-dev/467
A grep through the src/ directory lists me only one occurance where it
was changed to 'reset':
app/dublincore/browser/edit.pt
Whereas quite some more have the old behaviour:
app/demo/widget/browser/popup.pt:65:
input type=submit value=Refresh
app/zptpage/browser/inlinecode.pt:64:
input type=submit value=Refresh
app/schemacontent/browser/permission_edit.pt:33:
input type=submit value=Refresh
app/workflow/stateful/browser/definition_edit.pt:24:
input type=submit value=Refresh
app/workflow/stateful/browser/definition_edit.pt:51:
input type=submit value=Refresh
app/workflow/stateful/browser/instance_manage.pt:74:
input type=submit value=Refresh
app/pythonpage/edit.pt:70:
input type=submit value=Refresh
app/error/browser/error.pt:53:
input type=submit name=submit value=Refresh
app/apidoc/browser/prefIndex.pt:118:
input type=submit value=Refresh
app/preference/index.pt:14:
input type=submit value=Refresh
app/preference/edit.pt:112:
input type=submit value=Refresh
app/component/browser/editregistration.pt:48:
input type=submit name=refresh_submit value=Refresh
app/form/browser/edit.pt:53:
input type=submit value=Refresh
Christian
--
gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development
signature.asc
Description: This is a digitally signed message part
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Bytes versus ASCII
Hi, (this is about zope.schema) I assumed that the fields Bytes and ASCII have some distinction. The ASCII field explicitly checks for every character to have an ordinal value lower than 127. Bytes however does a cast in fromUnicode(u) that does str(u). This will break if there are non-ascii characters in the unicode string. Effectively this makes it an ASCII field as well. However, I don't know enough about the environment, so eventually this is all good. When does the fromUnicode method get called? Everytime I use this field through zope.app.form or zope.formlib? Cheers, Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Deploying WSGI Apps with Zope 3.2+
Dieter Maurer wrote: Stephan Richter wrote at 2006-1-26 10:16 -0500: but ZCML meta directives and schemas are so easy to use. I do not yet know ZCML... In my experience it is indeed fairly easy to extend ZCML; it's a pretty nice system that way. When I have read your book I was scared away from ZCML by the amount of namespaces and directives -- In practice I find myself using about 2 namespaces even large applications -- zope and browser. Five adds a third namespace, 'five'. There are indeed too many directives. in addition that I do not like the XML hype (that part that seems to imply that as soon as something is XML it is also easy and well understood). I don't think anyone in the Zope 3 world is claiming this about ZCML, right? I think the current world with XML is somewhat better than what was there before, which was (more or less) complete chaos in ways to spell formats. The current world is far from perfect though. :) XML is definitely not automatically going to make something easy or well understood, though. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Refresh / Change-Buttons
Christian Theune wrote: Hi, is there a chance we can get rid of the Refresh button on the standard forms? Every now and then, I hit the wrong one. And I do not see a clear need for the refresh. +1 on getting rid of the refresh button. What others say about reset (refresh?) buttons: http://www.useit.com/alertbox/2416.html http://www.joeclark.org/book/sashay/serialization/Chapter12.html#h5-1380 Tonico ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Refresh / Change-Buttons
On Fri, 27 Jan 2006 00:39:41 -0800, Michael Haubenwallner [EMAIL PROTECTED]
wrote:
Christian Theune wrote:
On Fri, 2006-01-27 at 09:33 +0100, Michael Haubenwallner wrote:
'Refresh' should be called 'Reset' -- in fact resetting the form
contents to the original loaded values
('Reset' is also the buttons default value displayed in the browser)
Well. That's not what the button currently does. When I click on it,
it
does a page reload. A form reset does this without.
Then, I also don't see many 'reset' buttons nowadays. And I don't miss
them. After all, I'm not sure in which order I would want them.
Should have been resolved as by this Issue
http://www.zope.org/Collectors/Zope3-dev/467
Good peoples!
Please don't include the Reset functionality in HTML forms. It is
absolutely useless, and is considered one of the classic usability
mistakes. Just say no, kids!
Seriously.
http://www.useit.com/alertbox/2416.html
--
_
Alexander Limi · Chief Architect · Plone Solutions · Norway
Consulting · Training · Development · http://www.plonesolutions.com
_
Plone Co-Founder · http://plone.org · Connecting Content
Plone Foundation · http://plone.org/foundation · Protecting Plone
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Deploying WSGI Apps with Zope 3.2+
Jim Fulton wrote: Also, on a related note, I've been somewhat impressed lately with the way people have been able to twist ConfigParser beyond its apparent capabilities in both Paste Deploy and in our prototype buildout system. In particular, we've been able to create hierarchical sections by introducing the equivalent of path separators in section names. Interestingly a proposal has been made on python-dev to replace/supplement ConfigParser with ConfigObject. The message summarizes its features and benefits: http://mail.python.org/pipermail/python-dev/2006-January/060138.html. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Correction to RFC
Obviously I'm blind. I found the __traceback_info__ code a few lines down. Obviously they are used for slightly different things. Obviously I'm going to investigate again, why the __traceback_info__ elements don't appear. Mea culpa, Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Bytes versus ASCII
On Jan 27, 2006, at 5:16 AM, Christian Theune wrote: Hi, (this is about zope.schema) I assumed that the fields Bytes and ASCII have some distinction. The ASCII field explicitly checks for every character to have an ordinal value lower than 127. Bytes however does a cast in fromUnicode(u) that does str(u). This will break if there are non-ascii characters in the unicode string. Effectively this makes it an ASCII field as well. However, I don't know enough about the environment, so eventually this is all good. When does the fromUnicode method get called? Everytime I use this field through zope.app.form or zope.formlib? I think it might be leveraged elsewhere, but the big client AFAIK is zcml. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Correction to RFC
On Fri, 2006-01-27 at 18:46 -0200, Sidnei da Silva wrote: On Fri, Jan 27, 2006 at 09:37:03PM +0100, Christian Theune wrote: | Is it intentional that there is a distinction? It took me quite a while | to actually notice that minore difference and come to the conclusion | that there are two different mechanisms used. There's a proposal from Shane Hathaway to remove this distinction, as I understand it. It might have been accepted already, and he had code ready to checkin. I found the proposal you're referring to. I don't think this tackles the issue I found. Shane is talking about the event log copies of the tracebacks, not the error page shown to the browser. -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] local grants don't work properly for objects with object fields
Local grants (i. e. roles/permissions granted to local users of a site) don't work properly for objects with objects fields (i. e. when trying to acces objects that have somefield=Object(...) entries in their interface definition). I have provided a short description of the problem below and have already prepared a complete example demonstrating the problem in a step by step manner, but that seems better suited for a bug report to me. - Has anyone experienced the same problem (below) and has some good advice, otherwise I am going to submit a bug report. Short description of the problem (I have used a family example - this is how I originally learned about Object fields and widgets, cf. e. g. Zope3/src/zope/app/form/browser/objectwidget.txt and messages on the zope3-users mailing list): * Create two different components with and without Object(...) fields, say family and simplefamily. * protect them with families.View and families.Edit permissions, respectively grant these permissions to families.Reader and families.Editor roles * create a folder say myfolder and within that folder some family and simplefamily objects. * Make the folder a site and create some local users within that site. This involves creating a pluggable authentication utility (say pau) within the site management folder (registering it), a prinicpal folder (say users) within the pau (registering it, going back to the configuration of the pau now using the users utility as an authenticator plugin and Zope Realm Basic Auth as Credential plugins) and creating some prinicpals within the users principal folder (say a user local). * Go to myfolder Grant, search for the newly created local user in /myfolder/++etc++site/default/pau/users and select him. Now grant him the families.Reader and families.Editor roles * Create two more users say reader (with the families.Reader role) and user (with families.Reader and families.Editor roles) in your principals file. * Now try to acces the two objects family and simplefamily with these three different users (in a different browser). Note that the local user of the site has the same roles (permissions) as the user from the principals file. * Whereas in the case of simplefamily the local user and the user from the principals file both have the same behaviour (and that is correct), the local user can't view the family object - this seems a bug to me. -Andreas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Correction to RFC
Hi, On Fri, 2006-01-27 at 20:34 +0100, Christian Theune wrote: Obviously I'm blind. I found the __traceback_info__ code a few lines down. Obviously they are used for slightly different things. Obviously I'm going to investigate again, why the __traceback_info__ elements don't appear. I found out that simply there are two different types of ways to get a view on a traceback: - The one the user sees. This one currently is a standard Python traceback. - The one you see in the error log. This includes all the shiny formatting. Is it intentional that there is a distinction? It took me quite a while to actually notice that minore difference and come to the conclusion that there are two different mechanisms used. Christian -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Refresh / Change-Buttons
On Fri, 27 Jan 2006 14:58:02 -, Alexander Limi [EMAIL PROTECTED] wrote: Please don't include the Reset functionality in HTML forms. It is absolutely useless, and is considered one of the classic usability mistakes. Just say no, kids! Agreed. Hands up anyone who ever clicked one? Martin -- (muted) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Refresh / Change-Buttons
On Fri, 2006-01-27 at 20:47 +, Martin Aspeli wrote: On Fri, 27 Jan 2006 14:58:02 -, Alexander Limi [EMAIL PROTECTED] wrote: Please don't include the Reset functionality in HTML forms. It is absolutely useless, and is considered one of the classic usability mistakes. Just say no, kids! Agreed. Hands up anyone who ever clicked one? I did. That's why I'm posting. I had to go through that form again. :) -- gocept gmbh co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Deploying WSGI Apps with Zope 3.2+
Martijn Faassen wrote at 2006-1-27 13:21 +0100: ... Five actually adds a 'five' namespace, which I think is very useful -- it clearly marks which directives are only there for Zope 2 and thus you cannot expect them to work in Zope 3. Not having namespaces would make this a lot harder to mark, and the temptation would exist to mangle namespaces into the names by using prefixes and the like. I think that is the major complaint: the need to associate an easy to remember and (in a restricted context) completely sufficient prefix (like five:) with a horrible URN, you always have to look up. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
RE: [Zope3-dev] Mini-proposal: Change CSS on forms
Hi Christian, [...] I'd love to know if there is a strong feeling towards those blue-background-titles. See the proposed changes attached as a patch to zope/app/rotterdam/zope3_tablelayout.css. Regards, Christian btw, do you know that there is a /++skin++Boston/ skin? Regards Roger Ineichen Projekt01 GmbH www.projekt01.ch _ END OF MESSAGE ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Refresh / Change-Buttons
On 1/27/06, Christian Theune [EMAIL PROTECTED] wrote: I did. That's why I'm posting. I had to go through that form again. :) Even worse, those are the first submit button for many pages, so that's what gets submitted when you hit Enter. That's even easier to do than clicking the button itself. +1 to remove the sucka's. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com There is no wealth but life. --John Ruskin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: __traceback_supplement__ versus __traceback_info__
Christian Theune wrote: Hi, somehow there is a mixup between using __traceback_supplement__ and __traceback_info__. In Zope 2, I'm used to use __traceback_info__. In Zope 3 it seems like the exception formatters use __traceback_supplement__. However, quite some code in Zope 3.2 uses __traceback_info__ still, and only a few places (security checkers) use __traceback_supplement__. Actually, Zope 2 has both forms as well. We use it primarily to tell ZPT authors which page template broke and where. __traceback_info__ is for arbitrary information. repr(__traceback_info__) gets dumped to the traceback. __traceback_supplement__ is more structured. It should be a tuple. The first item of the tuple is a callable that produces an object that implements ITracebackSupplement, and the rest of the tuple contains arguments to pass to the factory. The traceback formatter makes an effort to clearly present the information provided by the ITracebackSupplement. I just added this explanation to zope.exceptions.interfaces. Other than the excessive length of the name __traceback_supplement__, I like the way the system works. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
