[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
view
for=zope.app.container.interfaces.IContentContainer
name=+
menu=zmi_actions title=Add
class=zope.app.container.browser.adding.ContentAdding
permission=zope.ManageContent
allowed_attributes=addingInfo isSingleMenuItem hasCustomAddView
page name=index.html template=add.pt /
page name=action.html attribute=action /
/view
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
[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
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
view
for=zope.app.container.interfaces.IContentContainer
name=+
menu=zmi_actions title=Add
class=zope.app.container.browser.adding.ContentAdding
permission=zope.ManageContent
allowed_attributes=addingInfo isSingleMenuItem hasCustomAddView
page name=index.html template=add.pt /
page name=action.html attribute=action /
/view
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
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
[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__ ?
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
head markup, and the actual call to the theme renderer in the body
part of the template.
metal:block define-macro=page
metal:block define-slot=doctype
html
headCSS / JS comes here/head
body tal:content=python: theme.render(...) /
/html
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] 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 doctest profiling.txt[8], 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
