[Zope3-dev] Zope3 HEAD test failures on Windows
I just noticed that the tests are failing on Zope3 HEAD on Windows, when run with Python 2.4.2: File "C:\Code\Zope3\src\zope\testing\profiling.txt", line 35, in profiling.txt Failed example: testrunner.run(defaults) Exception raised: Traceback (most recent call last): File "C:\Code\Zope3\src\zope\testing\doctest.py", line 1256, in __run compileflags, 1) in test.globs File "", line 1, in ? testrunner.run(defaults) File "C:\Code\Zope3\src\zope\testing\testrunner.py", line 186, in run os.unlink(file_name) OSError: [Errno 13] Permission denied: 'tests_profile.zn490l.prof' This is because Zope3 is using a tag for zope.testing that baked in some Windows-specific bugs. Moving to a more recent version of zope.testing would fix it (I fixed these things in zope.testing yesterday). Note that it doesn't show up under Python 2.4.1 or 2.4.0, because the test runner takes a different path wrt profiling then. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] views have no __page_attribute__ ?
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> >> >>> Jean-Marc Orliaguet wrote: >>> >>> ... With the '+' view described above, there is a default page attribute to use for displaying the view ('index.html') and but no page attribute explicitly assigned. The following patch fixes the problem, but I'm afraid that I'm missing something: are views supposed to have a '__page_attribute__' or not? >>> >>> >>> >>> They are only supposed to ave a page attribute if they are pages. :) >>> >>> The directive above creates a view *with pages*. This means that the >>> view itself should not a page and is not intended to be callable. >>> >>> Bottom line: views created this way are not callable and are not >>> directly >>> renderable. >>> >>> There's a bit more complexity than I'd like in these view directives. >>> This is >>> why, more and more, I tend to *define* views in Python and just >>> register them >>> with the adapter or view directive. I still do often find it useful >>> to register >>> views with the view directive, mainly so I can avoid having to mention >>> IBrowserRequest. >>> >>> Jim >>> >> >> >> OK, so the 'view' object set in page templates is not the object to call >> for rendering the page. > > > Uh, normally the page template renders the page. > > Different views are constructed differently. Views created > with the page directive and views created with a view directive > without page subdirectives *can* be called to render pages -- > basically because they *are* pages. OTOH a view directive with > page subdirectives is meant to be traversed to get to it's pages, > which then can be called. > >> All in all, I managed to render the '+' view by calling the 'template' >> object and passing the 'view' as the instance parameter >> >> > markup = template(instance=view) > > I'm confused. Aren't you already in the template? > > Jim > > well sort of: I do start from a standard template (the original browser/skin/template.pt) that contains the macro -page definition, the markup, and the actual call to the theme renderer in the part of the template. CSS / JS comes here then I pass the: - context - view - template to theme.render(...) then the renderer in python takes care of rendering for the main content area that would have been displayed otherwise. So I have to "re-render" the page in its original context. It works apparently with: template(instance=view) .. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] '+' view (sequel)
Hi! the '+' view now works fine in cpsskins :-), the only problem is that it also reveals a user interface issue nicely "hidden" in the original Rotterdam skin :-) namely that the menu actions are still visible when the url ends with .../@@+ and the action item urls are not normalized. A second click on the 'Add' action sends the user to: .../folder/@@+/@@+ with a "The page that you are trying to access is not available" error. the same goes with other actions, for instance: .../folder/@@+/@@find.html instead of .../folder/@@find.html BrowserMenuItem.selected() contains the code necessary to normalize action urls, why not use it in actions returned by getMenu() too? /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] views have no __page_attribute__ ?
Jean-Marc Orliaguet wrote: Jim Fulton wrote: Jean-Marc Orliaguet wrote: ... With the '+' view described above, there is a default page attribute to use for displaying the view ('index.html') and but no page attribute explicitly assigned. The following patch fixes the problem, but I'm afraid that I'm missing something: are views supposed to have a '__page_attribute__' or not? They are only supposed to ave a page attribute if they are pages. :) The directive above creates a view *with pages*. This means that the view itself should not a page and is not intended to be callable. Bottom line: views created this way are not callable and are not directly renderable. There's a bit more complexity than I'd like in these view directives. This is why, more and more, I tend to *define* views in Python and just register them with the adapter or view directive. I still do often find it useful to register views with the view directive, mainly so I can avoid having to mention IBrowserRequest. Jim OK, so the 'view' object set in page templates is not the object to call for rendering the page. Uh, normally the page template renders the page. Different views are constructed differently. Views created with the page directive and views created with a view directive without page subdirectives *can* be called to render pages -- basically because they *are* pages. OTOH a view directive with page subdirectives is meant to be traversed to get to it's pages, which then can be called. All in all, I managed to render the '+' view by calling the 'template' object and passing the 'view' as the instance parameter markup = template(instance=view) I'm confused. Aren't you already in the template? Jim -- 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] views have no __page_attribute__ ?
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> ... >> >> With the '+' view described above, there is a default page attribute to >> use for displaying the view ('index.html') and but no page attribute >> explicitly assigned. >> >> The following patch fixes the problem, but I'm afraid that I'm missing >> something: are views supposed to have a '__page_attribute__' or not? > > > They are only supposed to ave a page attribute if they are pages. :) > > The directive above creates a view *with pages*. This means that the > view itself should not a page and is not intended to be callable. > > Bottom line: views created this way are not callable and are not directly > renderable. > > There's a bit more complexity than I'd like in these view directives. > This is > why, more and more, I tend to *define* views in Python and just > register them > with the adapter or view directive. I still do often find it useful > to register > views with the view directive, mainly so I can avoid having to mention > IBrowserRequest. > > Jim > OK, so the 'view' object set in page templates is not the object to call for rendering the page. All in all, I managed to render the '+' view by calling the 'template' object and passing the 'view' as the instance parameter >>> markup = template(instance=view) instead of calling the 'view' directly with: >>> markup = view() This seems to be generic enough /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] views have no __page_attribute__ ?
Jean-Marc Orliaguet wrote: Hi! I've encountered a problem when trying to render views (there is no problem with rendering pages), but for instance with the '+' view that is defined in app/container/browser/configure.zcml when called with: markup = view() ['view' being the 'view' variable gotten from ZPT) results in the following error message: ... markup = view() File "/home/jmo/Zope3/src/zope/app/publisher/browser/viewmeta.py", line 445, in __call__ attr = self.__page_attribute__ AttributeError: '+' object has no attribute '__page_attribute__' because the __call__ method of zope.app.publisher.browser.viewmeta.simple expects views and pages to have a page attribute: def __call__(self, *a, **k): # If a class doesn't provide it's own call, then get the attribute # given by the browser default. attr = self.__page_attribute__ With the '+' view described above, there is a default page attribute to use for displaying the view ('index.html') and but no page attribute explicitly assigned. The following patch fixes the problem, but I'm afraid that I'm missing something: are views supposed to have a '__page_attribute__' or not? They are only supposed to ave a page attribute if they are pages. :) The directive above creates a view *with pages*. This means that the view itself should not a page and is not intended to be callable. Bottom line: views created this way are not callable and are not directly renderable. There's a bit more complexity than I'd like in these view directives. This is why, more and more, I tend to *define* views in Python and just register them with the adapter or view directive. I still do often find it useful to register views with the view directive, mainly so I can avoid having to mention IBrowserRequest. Jim -- 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
[Zope3-dev] Five 1.1 released!
Five 1.1 released! == The Five team is happy to release Five 1.1 final. Compared to the 1.0 release, Five 1.1 brings a few more Zope 3 features to the Zope 2 world, such as * Zope 3-style i18n (including fallback to existing Zope 2 i18n machinery), * Zope 3 to Zope 2 interface bridging (in addition to the already supported Zope 2 to Zope 3 interface bridging), * a couple more standard ZCML directives. Five has also been changed internally -- the code has been restructured and the testing framework has been simplified to be easier to maintain. For more information please consult the _CHANGES document. .. _CHANGES: http://codespeak.net/z3/five/CHANGES.html Five 1.1 can be downloaded here: http://codespeak.net/z3/five/release/Five-1.1.tgz Five 1.1 will not be part of any Zope 2.x release. It is also the last release to support Zope 2.7. Five 1.2 will only work on Zope 2.8. About Five -- Five is a Zope 2 product that allows you to integrate Zope 3 technologies into Zope 2, today. It allows you to use the following parts of the Zope 3 component architecture within Zope 2: * Zope 3 interfaces * adapters * pages (views), including skins, layers and resources * edit and add forms, based on schemas * i18n * ZCML We've tried to keep the Five experience as close to Zope 3 as possible, so this means that what you learn while using Five should also be applicable to Zope 3. More information about Five can be found on our website, here: http://codespeak.net/z3/five/ We hope you'll join our mailing list and let hear from yourself! About the Zope 3 Base - Five is part of the *Zope 3 Base* project, which aims to offer an approachable area for developers of Zope 3 related software. More about the Zope 3 base and its projects can be found here: http://codespeak.net/z3/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: [Zope3-Users] Override a browser class
Switching maling list here. On 10/3/05, Johan Carlsson <[EMAIL PROTECTED]> wrote: > > Hi all, > I want to replace the pasteable in > zope.app.container.browser.contents.Contents > for all content types. > > I've created a sub class to Contents which override > the pasteable but I'm not sure how to configure it > to override the default class (if possible)? > > Best Regards, > Johan > > > PS. The reason I want to change pasteable is that it > raises an exception if the paste action is unknown. > I'm implementing a clone action as an extra variation > of copy and it works in my classes but if I point > to a stock object (with anything I want to clone in > the clipbook) I get an error due to the raise. > > My override returns False if the paste action is unknown. > > Any core developer that has any opinion on this? > Can it be changed in the core or is there a specific > reason for the raise? The standard Contents.pasteable and pasteObjects is hardcoded for two actions, 'copy' and 'cut'. I have the feeling here that it could be cool to actually use adapters instead, so that you adapt yourself to the paste action you want? Or is that overkill. Seondly, Johan has discovered a bug. pasteable raises an error when you try a pste action that is not supported (ie anything else that 'cut' and 'copy'). Ut should return False. It's a copy/paste error from pasteObjects, ironically enough. ;) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] views have no __page_attribute__ ?
Hi! I've encountered a problem when trying to render views (there is no problem with rendering pages), but for instance with the '+' view that is defined in app/container/browser/configure.zcml when called with: markup = view() ['view' being the 'view' variable gotten from ZPT) results in the following error message: ... markup = view() File "/home/jmo/Zope3/src/zope/app/publisher/browser/viewmeta.py", line 445, in __call__ attr = self.__page_attribute__ AttributeError: '+' object has no attribute '__page_attribute__' because the __call__ method of zope.app.publisher.browser.viewmeta.simple expects views and pages to have a page attribute: def __call__(self, *a, **k): # If a class doesn't provide it's own call, then get the attribute # given by the browser default. attr = self.__page_attribute__ With the '+' view described above, there is a default page attribute to use for displaying the view ('index.html') and but no page attribute explicitly assigned. The following patch fixes the problem, but I'm afraid that I'm missing something: are views supposed to have a '__page_attribute__' or not? Index: app/publisher/browser/viewmeta.py === --- app/publisher/browser/viewmeta.py (revision 38719) +++ app/publisher/browser/viewmeta.py (working copy) @@ -275,6 +275,8 @@ required[pname] = permission pages[pname] = attribute +if pname == 'index.html': +cdict['__page_attribute__'] = attribute # This should go away, but noone seems to remember what to do. :-( if hasattr(class_, 'publishTraverse'): /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com