Re[2]: [Zope3-dev] widget framework missing a registration?
Hello Stephan, Seems like I made a mistake somewhere. Now it is working without the 'extra' registration. I was so puzzled in the jungle of the widgets that I created a table from the registrations to have an overview. (first col=for_ first interface, second col=I for IInputWidget; D for IDisplayWidget, remaining cols are for the for_ second interface) What I don't understand is that currently test_registrations.py is not checking exactly this info. What I propose is to change the registration to: IList, IDisplayWidget -- ListDisplayWidget ISet, IDisplayWidget -- SetDisplayWidget or maybe to a general ISequence, IDisplayWidget -- ItemsMultiDisplayWidget The difference between these widgets is rather small. The ListDisplayWidget is using tag = 'ol', the others tag = 'ul'. I'm afraid I can't checkin, I don't have permission. I can provide diff's. Tuesday, January 3, 2006, 7:05:03 PM, you wrote: On Tuesday 13 December 2005 05:06, Adam Groszer wrote: Is that by intention? No. Though we would need it for the set as well. Feel free to check this ion, preferably with a test. Regards, Stephan -- Best regards, Adammailto:[EMAIL PROTECTED] -- Quote of the day: Never let a man imagine that he can pursue a good end by evil means, without sinning against his own soul. The evil effect on himself is certain. - Robert Southey widgets.csv Description: Binary data ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] zopectl in linux-ha environment
Hello,
I am testing Zope3 in a linux-ha environment. I wrote
a resource.d-file for starting and stopping zope when
system toggles ha-mode.
snipp:
[...]
zope_status () {
cd $ZOPEDIR
./bin/zopectl status2
rc=$?
ha_log info: $0: zope_status1/return=$rc
}
[...]
(attention: 'status2' not 'status')
Result:
[EMAIL PROTECTED] /etc/ha.d/resource.d]# ./zope status
*** Unknown syntax: status2
2006/01/05_14:16:19 info: ./zope: zope_status1/return=0
[...]
(attention: return-code is 0, should be !0)
What is the correct way to get the exit code of zopectl-
script in my shell-script.
In zopectl:
[...]
if __name__ == '__main__':
run()
[...]
What kind of return-statement/exception i have to use?
Is there a chain of this return-/exception-statements for
zopectl - zope.app.twisted.controller.main - zdaemon.zdctl.main - ZDCmd
?
Regards
Markus Leist
ps.
should i post the complete script to this mailing-list?
is there someone else working with linux-ha?
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] mini-proposal: make unauthorized exception view smarter
Problem: The view for the unauthorized exception (zope/app/exception/browser/ unauthorized.py/.pt) gets the authentication utility to issue a challenge, and then draws a page. Drawing the page is silly in some cases, and problematic in others. In particular, for session credentials, the user is redirected to another page because she received an Unauthorized exception on this one: there is no need to draw an unviewed page for the redirect request (and I think we don't care about browsers that can't handle a redirect request). Moreover, if the metal macro page that wraps the drawn page itself raises an unauthorized error, the redirect can be overridden. Solution: Make the unauthorized view smarter: call the authentication utility's unauthorized method before rendering the page, and if the request then has a 303 status, don't bother to render the page. This is simply the default view, so if someone really cares about a browser that doesn't support redirects, they can register one more like the one we have now. Risks: Requires more developer work to support browsers that don't support redirects. Thoughts? Gary ___ 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: make unauthorized exception view smarter
Gary Poster wrote: Make the unauthorized view smarter: call the authentication utility's unauthorized method before rendering the page, and if the request then has a 303 status, don't bother to render the page. +1 -- 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
Re: [Zope3-dev] mini-proposal: make unauthorized exception view smarter
Gary Poster wrote: Risks: Requires more developer work to support browsers that don't support redirects. Are you aware of any browsers that don't support redirects? Even Lynx and wget support redirection. Shane ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Tim Peters wrote at 2006-1-4 14:51 -0500: [Dieter Maurer] If the backward compatibility period gets shorter, we will skip more and more releases because of the increased burden to get our applications running again... Well, every new release will remove features deprecated N releases ago, where N is presumably some constant whose value is being debated here. That will be so in steady state whether N is 1 or 10 (i.e., the value of N doesn't really matter to that): the pressure to recode (and your temptation to skip releases) is related more to the frequency of releases than to the length of the deprecation grace period. In fact, whether I upgrade or not depends on the merits of the new version (with respect to that currently used) and the effort necessary for the upgrade. You are right that the (long term) average number of features removed in a given release depends on the time between releases but not the length of the deprecation period. However, a long deprecation period allows to cluster the renewal work. If the deprecation period is e.g. 4 releases, then I can 3 times upgrade without to worry about deprecations if I am ready to resolve all deprecation problems in the 4 th one. This increased clustering gives more flexibility to do the renewal work at times when projects are not to heavily pressing. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Benji York wrote at 2006-1-4 14:22 -0500: Dieter Maurer wrote: Jim Fulton wrote at 2006-1-3 14:41 -0500: I think 12 months is a bit short. I don't think the backward-compatibility code is that burdonsome, once written. What do other folks think? If the backward compatibility period gets shorter, we will skip more and more releases because of the increased burden to get our applications running again... Does that mean that you think 12 months is too short, just right, or nearly too short? I answer here as a user (of the Zope[3] framework) not as a (framework) developper. As a user, I prefer the deprecation period to be as long as possible. I cannot dictate the developpers what deprecation period they choose but I can refrain to upgrade. -- 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] Ajax in Zope 3
On Dec 6, 2005, at 5:35 PM, Tarek Ziadé wrote: Gary Poster wrote: ... I have old proposals for this, and some revisions of them on the basis of conversations with Jim, Fred, Stephan, and Benji. ... ... I am looking forward for the proposal revision :) Just a heads up that I am unlikely to be able to get to this anytime soon. Sincere apologies for being all smoke and no fire on this. :- ( Please work on the AJAX Zope 3 story! :-) Gary___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
