Re[2]: [Zope3-dev] widget bug?!?
Hello Stephan, Seems like you smashed it, now a ComponentLookupError exception is coming which seems adequate. Tuesday, January 3, 2006, 8:00:49 PM, you wrote: On Thursday 15 December 2005 08:17, Adam Groszer wrote: If I make a schema which has no registered widget, then no exception, no error message is coming just a plain empty response. Is this still happening. I just recently fixed a bug like that? Regards, Stephan -- Best regards, Adammailto:[EMAIL PROTECTED] -- Quote of the day: Everyone is an explorer. How could you possibly live your life looking at a door and not open it? - Robert D. Ballard ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Python search path in Zope 3
Hello. Thank you for replying. Stephan Richter wrote: On Monday 12 December 2005 09:08, Yoshito Komatsu wrote: Are there any problems with adding them? Nope, +1. I made the patches. May I commit them by myself? Or, should I submit them to Issue Collector? Regards, -- Yoshito Komatsu [EMAIL PROTECTED] ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Wiki subscription on mailing list?, hosting offer
Latest zwiki allows each subscriber to choose all edits or just the comments/creations, which is enough for most people. NB if the community wants, I would host the zope3 wiki on the zopewiki.org server for as long as that's useful - until zope3.org or whatever. This would allow us to fix a number of problems and benefit from the latest enhancements. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Zope3 tarball build/test run log
Brian,
What are you trying to accomplish with this test? I think buildbot does a
better
job. If there is a function you'd like to suggest for our emerging buildbot
setup,
I'd like to hear it.
A message like this, with no useful information might as well be spam.
Jim
Zope 3 tarball build/test script wrote:
Traceback (most recent call last):
File /home/jinty/releases/release-assistent.py, line 260, in ?
main(sys.argv)
File /home/jinty/releases/release-assistent.py, line 257, in main
builder.run()
File /home/jinty/releases/release-assistent.py, line 169, in run
self.buildReleases()
File /home/jinty/releases/release-assistent.py, line 177, in buildReleases
self.buildRelease()
File /home/jinty/releases/release-assistent.py, line 226, in buildRelease
self.runner.runMany(self.release['test_command'])
File /home/jinty/releases/release-assistent.py, line 157, in runMany
self.run(cmd)
File /home/jinty/releases/release-assistent.py, line 152, in run
raise CommandException('%s failed!' % cmd)
__main__.CommandException: cd tst bin/zopetest failed!
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/jim%40zope.com
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.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] Zope3 tarball build/test run log
On Wed, Jan 04, 2006 at 07:08:59AM -0500, Jim Fulton wrote: Brian, What are you trying to accomplish with this test? This is the result of building and testing the tarball/multiple tarballs. I started this because zope3 was breaking my schooltool nightly tarball build too often. Practically all of my commits over the last months have been fixing tarball setup breakage caught by this test. I wanted others to help as well;) I think buildbot does a better job. If there is a function you'd like to suggest for our emerging buildbot setup, I'd like to hear it. Yes, building and testing tarballs. Another interesting idea is testing old bodies of code against newer Zope 3 versions. For backwards compatibility. For example, schoolbell, released with Zope 3.1 fails its tests with Zope3.2. A message like this, with no useful information might as well be spam. I agree, and have stopped forwarding these messages until I can be certain they will be more useful. Even before you sent this mail;) -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Python search path in Zope 3
On Wednesday 04 January 2006 04:18, Yoshito Komatsu wrote: May I commit them by myself? Or, should I submit them to Issue Collector? Please commit them yourself. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: [Zope3-Users] Re: Get classes implementing Interface
Am Samstag, 31. Dezember 2005 14:48 schrieb Florian Lindner: Am Freitag, 30. Dezember 2005 20:57 schrieb Jeff Shell: On 12/30/05, Florian Lindner [EMAIL PROTECTED] wrote: Am Freitag, 30. Dezember 2005 17:45 schrieb Jim Fulton: Philipp von Weitershausen wrote: So, what you want is not a list of classes but a list of factories that can create IContainers. This is possible by using zapi.getUtilitiesFor(IFactory) and then checking each factory's getInterfaces() method whether IContainer is a part of the returned result. I would probably base an implementation of all on the UtilityVocabulary. I'll also note that the use case is also directly addressed through containment constraints. You can say that a container should only contain objects of some given types and you will get just those types in the add list. But the HomeFolderManager is not a container itself it's just a utility that creates container upon requests. And I want to make choosable which container to create. Or do I misunderstand you? Well first (and I apologize if this has been mentioned before), 'containers' are a more abstract notion while 'folders' are more concrete. A message or document that allows comments might be a container, but it's not something that you'd see in the ZMI or any content management type interface as a folder. You'd see it as an article. Something that's Folderish (to drag up an old term) will probably have a folder icon, will probably (but not necessarily) will have sub-folders, will have a view to manage its contents, and so on. [...] Basically the HomeFolderManager (HFM) only creates an 1:1 relation between a principal and an object. It can also auto-create these objects if the relation is being read for the first time. In this case the object to be created is hardcoded to be a zope.app.folder.Folder. The HFM does not care what is being done with the objects it just returns them. In my project I've another folderish object that I want to have created, therefore I forked the HFM and modified the code to create the object I want. Of course, the common use case would be to create a folderish object, but any other kind of objects would make sense to. A principal could have a home page (just one site) which is not folderish neither a IContainer which could the HFM return. Or a project which can contain comments, which is not folderis either but is an IContainer implemention. I think that the HFM should allow creation of ANY objects, regardless of being folderish or IContainer implemenations. Of course, the name HomeFOLDERManager would not make sense anymore in this case. What do you think? Florian No thoughts / opinions of anyone? Can I make the changes to the HomeFolderManager (list box of all classes implementing IContainer to select which class to create) and commit? Florian ___ 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: RFC: abolishing python: expressions in ZPT TALES
On 1/3/06, Wade Leftwich [EMAIL PROTECTED] wrote: Andreas Jung wrote: To bring it to the point: _scripters_ should be able to develop in Zope 3 as easy as in Zope 2 :-) Or at least almost as easily as in RoR or Django. TTW is not a requirement; Chris McDonough's TTB posting was right on target (http://www.plope.com/Members/chrism/ttb_programming). Are those 'scripters'? I see RoR and Django going down the same path that Zope 2 went down. They're great, they're young, they're inexperienced. Django's horrible query syntax reminds me of the cryptic early index querying that Zope / Principia had that was geared primarily for input coming in from web forms and not scripting. I see both of those projects taking either shortcuts or blanket we only do things this way statements. [Django: we don't support HTTP auth. We've never needed it.]. It's not to say they're bad products at all. To work in Django, you essentially are using Django's admins, which apparently many of their target users don't mind. This is akin to just using and promoting the Plone UI, the ZMI (zope 2 or zope 3's) or whatever. Neither I nor my customers have wanted those UIs. I love Zope 3 for finally giving me the freedom of detaching from the ZMI completely (with me having the option to use it for emergencies, but our own much more focused skins should do the job well enough to not need it). There are 3 PHP developers in the group I work in, and they know they want something better, and they like Python. But when they look at Z3 they get all upset confused. I like Ruby. But when I look at rails I get all upset and confused. I still have no idea how its widgets work. With Zope 3, I was able to follow the adapter lookup chain. Granted, I'm pretty familiar with Zope 3's component architecture by now. Zope 3 needs better advocacy. It needs better web site(s). If zope3.org turns out to be a Wiki I promise to take extra medication and try to add some helpful material to it as possible, because I think Zope 3 is really lacking in different levels of tutorials from different authors who have different perspectives that may better help different audiences. *whew!* That's the problem. It's great that there are books out there. But there's no good central and well promoted advocacy sites. Many Zope 3 developers, like myself, I imagine are often very heavy with real work engagements and finding spare time to write and advocate aren't there. Is this (increased usability for non-experts) a possible project for the Zope sprint at Pycon? I'll be there. And since I am not an expert myself, I will have a head start. I still think that a great increased usability could come from a zope3 focused web site that is simple and fun. With the time based releases, it's known what's going to be in each release. My gods, I'd LOVE to see articles like Exploring Zope 3.x: New feature - Viewlets. I'd LOVE to see clear documents like Exploring Zope 3.x: what's deprecated, why, and how to fix it. The doctest documentation about content providers, forms, and viewlets are great for experts. At least there's fairly comprehensive documentation that I can read and figure out and go ahh!. But turning that into a more comprehensive non-expert story on a web site would be a good thing. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Scripters, websites, documentation, advocacy
On 1/4/06, Jeff Shell wrote: On 1/3/06, Wade Leftwich [EMAIL PROTECTED] wrote: Andreas Jung wrote: To bring it to the point: _scripters_ should be able to develop in Zope 3 as easy as in Zope 2 :-) Or at least almost as easily as in RoR or Django. TTW is not a requirement; Chris McDonough's TTB posting was right on target (http://www.plope.com/Members/chrism/ttb_programming). Are those 'scripters'? I see RoR and Django going down the same path that Zope 2 went down. They're great, they're young, they're inexperienced. Django's horrible query syntax reminds me of the cryptic early index querying that Zope / Principia had that was geared primarily for input coming in from web forms and not scripting. I see both of those projects taking either shortcuts or blanket we only do things this way statements. [Django: we don't support HTTP auth. We've never needed it.]. It's not to say they're bad products at all. To work in Django, you essentially are using Django's admins, which apparently many of their target users don't mind. This is akin to just using and promoting the Plone UI, the ZMI (zope 2 or zope 3's) or whatever. Neither I nor my customers have wanted those UIs. I love Zope 3 for finally giving me the freedom of detaching from the ZMI completely (with me having the option to use it for emergencies, but our own much more focused skins should do the job well enough to not need it). There are 3 PHP developers in the group I work in, and they know they want something better, and they like Python. But when they look at Z3 they get all upset confused. I like Ruby. But when I look at rails I get all upset and confused. I still have no idea how its widgets work. With Zope 3, I was able to follow the adapter lookup chain. Granted, I'm pretty familiar with Zope 3's component architecture by now. Zope 3 needs better advocacy. It needs better web site(s). If zope3.org turns out to be a Wiki I promise to take extra medication and try to add some helpful material to it as possible, because I think Zope 3 is really lacking in different levels of tutorials from different authors who have different perspectives that may better help different audiences. *whew!* That's the problem. It's great that there are books out there. But there's no good central and well promoted advocacy sites. Many Zope 3 developers, like myself, I imagine are often very heavy with real work engagements and finding spare time to write and advocate aren't there. Is this (increased usability for non-experts) a possible project for the Zope sprint at Pycon? I'll be there. And since I am not an expert myself, I will have a head start. I still think that a great increased usability could come from a zope3 focused web site that is simple and fun. With the time based releases, it's known what's going to be in each release. My gods, I'd LOVE to see articles like Exploring Zope 3.x: New feature - Viewlets. I'd LOVE to see clear documents like Exploring Zope 3.x: what's deprecated, why, and how to fix it. The doctest documentation about content providers, forms, and viewlets are great for experts. At least there's fairly comprehensive documentation that I can read and figure out and go ahh!. But turning that into a more comprehensive non-expert story on a web site would be a good thing. I agree completely. What else can I say? Maybe just a few things: Yes, the best fastest way to get better usability for non-experts (including but not limited to 'scripters') is through more tutorials better docs. This is also the point I took away from Chris McDonough's TTB posting. If I can help in that regard, I would love to participate. Love it or don't love it, Ruby on Rails definitely raised the bar for having a cool website and generating lots of buzz around your web application server project. Setting aside all technical considerations, Django and TurboGears picked up on this lesson and got some traction, and Subway did not and did not. Meanwhile, Zope 3 moves forward in spite of its web presence. Actually the place I have been going to help me get ahold of the big concepts in Zope 3 is http://griddlenoise.blogspot.com. It's also one of very few weblogs where you can find any kind of Zope 3 advocacy. I still think that a great increased usability could come from a zope3 focused web site that is simple and fun. With the time based releases, it's known what's going to be in each release. My gods, I'd LOVE to see articles like Exploring Zope 3.x: New feature - Viewlets. I'd LOVE to see clear documents like Exploring Zope 3.x: what's deprecated, why, and how to fix it. Absolutely. ___ 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)
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... -- 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] Zope3 tarball build/test run log
On Wed, Jan 04, 2006 at 11:29:47AM -0500, Jim Fulton wrote: Brian Sutherland wrote: Yes, building and testing tarballs. What does this mean? What tar balls? Do you mean releases? basically the contents of releases/Zope-test.py. For schooltool, the testing script I use is the same as the script I use to make a schooltool release. In fact the products of these tests are called the schooltool nightly tarballs and are actually released. Another interesting idea is testing old bodies of code against newer Zope 3 versions. For backwards compatibility. For example, schoolbell, released with Zope 3.1 fails its tests with Zope3.2. I think this is a great idea. We do this internally. Of course, it doesn't make sense to send schoolbell test failures to the Zope 3 list. It does often make sense to raise breakage issues in the collector, or on the list. Great, here is the first: from zope.server.http.publisherhttpserver import PublisherHTTPServer Traceback (most recent call last): File test.py, line 1115, in ? exitcode = main(sys.argv) File test.py, line 1077, in main test_cases = get_test_cases(test_files, cfg, tracer=tracer) File test.py, line 333, in get_test_cases test_suite = func() File /home/jinty/src/schooltoolrepo/schoolbell-1.2.x/src/schoolbell/app/tests/test_main.py, line 630, in test_suite optionflags=doctest.ELLIPSIS), File /home/jinty/src/schooltoolrepo/schoolbell-1.2.x/Zope3/src/zope/testing/doctest.py, line 2334, in DocTestSuite module = _normalize_module(module) File /home/jinty/src/schooltoolrepo/schoolbell-1.2.x/Zope3/src/zope/testing/doctest.py, line 235, in _normalize_module return __import__(module, globals(), locals(), [*]) File /home/jinty/src/schooltoolrepo/schoolbell-1.2.x/src/schoolbell/app/main.py, line 49, in ? from zope.app.server.http import http ImportError: No module named http -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! ___ 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)
[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. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
