So, it seems Chris McDonough figured out what we couldn't *wink*. Now, it seems like Zope HEAD boots fine with an old Data.fs, and I could even get a Plone 1.0 site migrated to Plone 2.0 and CMF 1.4 (a small problem on DCWorkflow, but I checked in a fix). Soo... now, i'm getting some errors out of CMF which seem pretty obvious, and I wonder how they worked before. Example: * <FSPageTemplate at /blog/folder_listing used for /blog/Members/sidnei> TypeError: unbound method pt_getContext() must be called with ZopePageTemplate instance as first argument (got nothing instead) (Also, an error occurred while attempting to render the standard error message.) If you look at FSPageTemplate, its obvious that it doesn't subclass ZopePageTemplate, but the solution is not so obvious. Using: pt_getContext = ZopePageTemplate.pt_getContext.im_func Seemed to work, though I'm almost sure that is not the Right Thing (tm). A similar error also happened with FSImage.__str__ (which is assigned Image.__str__, but FSImage just subclasses FSObject). Any thought on those? Then a completely different error happened, when looking at a item with comments: * Module Products.PageTemplates.ZRPythonExpr, line 48, in __call__ __traceback_info__: container.sort_modified_ascending( here.portal_discussion.getDiscussionFor(here).getReplies()) * Module Python expression "container.sort_modified_ascending( here.portal_discussion.getDiscussionFor(here).getReplies())", line 1, in <expression> * Module Products.VerboseSecurity.VerboseSecurityPolicy, line 157, in validate Unauthorized: The container has no security assertions. Access to 'getReplies' of (Products.CMFDefault.DiscussionItem.DiscussionItemContainer object at 0x419681ac) denied. AFAICT, there's nothing wrong with DiscussionItemContainer. It has been InitializeClass()'ed and has a docstring. Setting __allow_access_to_unprotected_subobjects__ = 1 works, but that is obviously wrong. Ideas? -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher This system will self-destruct in five minutes.
On Mon, 2003-12-15 at 08:04, Sidnei da Silva wrote:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Seemed to work, though I'm almost sure that is not the Right Thing (tm).
This exact fix was already checked in to the CMF HEAD by Yuppie a couple of days ago (and a series of other ones, as well as one for Image.__str__) based on an audit by Dieter. Maybe you're using the 1.4 branch?
Then a completely different error happened, when looking at a item with comments:
* Module Products.PageTemplates.ZRPythonExpr, line 48, in __call__ __traceback_info__: container.sort_modified_ascending( here.portal_discussion.getDiscussionFor(here).getReplies()) * Module Python expression "container.sort_modified_ascending( here.portal_discussion.getDiscussionFor(here).getReplies())", line 1, in <expression> * Module Products.VerboseSecurity.VerboseSecurityPolicy, line 157, in validate
Unauthorized: The container has no security assertions. Access to 'getReplies' of (Products.CMFDefault.DiscussionItem.DiscussionItemContainer object at 0x419681ac) denied.
AFAICT, there's nothing wrong with DiscussionItemContainer. It has been InitializeClass()'ed and has a docstring. Setting __allow_access_to_unprotected_subobjects__ = 1 works, but that is obviously wrong.
I think this may also be fixed in the stuff that Yuppie checked in because plope.com is running fine on the head and it uses discussions too. - C
On Mon, Dec 15, 2003 at 07:56:04AM -0500, Chris McDonough wrote: | On Mon, 2003-12-15 at 08:04, Sidnei da Silva wrote: | > pt_getContext = ZopePageTemplate.pt_getContext.im_func | > | > Seemed to work, though I'm almost sure that is not the Right Thing (tm). | | This exact fix was already checked in to the CMF HEAD by Yuppie a couple | of days ago (and a series of other ones, as well as one for | Image.__str__) based on an audit by Dieter. Maybe you're using the 1.4 | branch? Yep. Sorry for not having checked CMF Head. BTW, Yuppie, can we get a 1.5 soon? -- Sidnei da Silva <sidnei@awkly.org> http://awkly.org - dreamcatching :: making your dreams come true http://plone.org/about/team#dreamcatcher Memory fault - where am I?
Sidnei da Silva wrote:
Yep. Sorry for not having checked CMF Head. BTW, Yuppie, can we get a 1.5 soon?
Maybe zope-cmf@zope.org is a better place for questions like that? Today Tres Seaver wrote:
BTW, I plan to post a draft roadmap for CMF 1.5 soon (today, I hope), and to ask for feedback.
Yuppie
Hi Sidnei! Sidnei da Silva wrote:
So, it seems Chris McDonough figured out what we couldn't *wink*. Now, it seems like Zope HEAD boots fine with an old Data.fs, and I could even get a Plone 1.0 site migrated to Plone 2.0 and CMF 1.4 (a small problem on DCWorkflow, but I checked in a fix).
Maybe you should have a look at CMF HEAD and either test with HEAD or backport some fixes.
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Seemed to work, though I'm almost sure that is not the Right Thing (tm).
Why? Based on Dieter's patches I fixed HEAD this way and it looks ok to me. I guess the Right Thing would be refactoring the classes so we can inherit these methods, but even if we change Zope now CMF would need the old code for a long time for backwards compatibility.
A similar error also happened with FSImage.__str__ (which is assigned Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Same as above. What I'm missing is an easy way to find *all* of them.
AFAICT, there's nothing wrong with DiscussionItemContainer. It has been InitializeClass()'ed and has a docstring. Setting __allow_access_to_unprotected_subobjects__ = 1 works, but that is obviously wrong.
Ideas?
No idea so far. The others didn't have a docstring. Cheers, Yuppie
Sidnei da Silva wrote:
If you look at FSPageTemplate, its obvious that it doesn't subclass ZopePageTemplate, but the solution is not so obvious. Using:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your code works out to the same thing. I don't endorse this sort of cross-tree method copying, but if we're going to do it on this scale, at least we can make it tidier. Before the Globals.InitializeClass: zpd = ZopePageTemplate.__dict__ for m in ('func_code', '_default_bindings', 'manage_FTPget', 'get_size', 'PrincipiaSearchSource', 'document_src', 'pt_getContext', 'ZScriptHTML_tryParams'): setattr(FSPageTemplate, m, zpd[m])
A similar error also happened with FSImage.__str__ (which is assigned Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Yep -- it seems very silly to copy a one-line method like that. Cheers, Evan @ 4-am
On Mon, 15 Dec 2003 10:02:58 -0600 Evan Simpson <evan@4-am.com> wrote:
Sidnei da Silva wrote:
If you look at FSPageTemplate, its obvious that it doesn't subclass ZopePageTemplate, but the solution is not so obvious. Using:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your code works out to the same thing. I don't endorse this sort of cross-tree method copying, but if we're going to do it on this scale, at least we can make it tidier. Before the Globals.InitializeClass:
zpd = ZopePageTemplate.__dict__ for m in ('func_code', '_default_bindings', 'manage_FTPget', 'get_size', 'PrincipiaSearchSource', 'document_src', 'pt_getContext', 'ZScriptHTML_tryParams'): setattr(FSPageTemplate, m, zpd[m])
A similar error also happened with FSImage.__str__ (which is assigned Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Yep -- it seems very silly to copy a one-line method like that.
Smells like a broken class hierarchy to me. I really think we need to consider refactoring the code so this sort of sillyness isn't necessary. -Casey
On Mon, 2003-12-15 at 11:51, Casey Duncan wrote:
On Mon, 15 Dec 2003 10:02:58 -0600 Evan Simpson <evan@4-am.com> wrote:
Sidnei da Silva wrote:
If you look at FSPageTemplate, its obvious that it doesn't subclass ZopePageTemplate, but the solution is not so obvious. Using:
pt_getContext = ZopePageTemplate.pt_getContext.im_func
Wow, FSPageTemplate is lousy with this sort of thing, isn't it? I'd have spelled it ZopePageTemplate.__dict__['pt_getContext'], but your code works out to the same thing. I don't endorse this sort of cross-tree method copying, but if we're going to do it on this scale, at least we can make it tidier. Before the Globals.InitializeClass:
zpd = ZopePageTemplate.__dict__ for m in ('func_code', '_default_bindings', 'manage_FTPget', 'get_size', 'PrincipiaSearchSource', 'document_src', 'pt_getContext', 'ZScriptHTML_tryParams'): setattr(FSPageTemplate, m, zpd[m])
A similar error also happened with FSImage.__str__ (which is assigned Image.__str__, but FSImage just subclasses FSObject).
Any thought on those?
Yep -- it seems very silly to copy a one-line method like that.
Smells like a broken class hierarchy to me. I really think we need to consider refactoring the code so this sort of sillyness isn't necessary.
While we are at it, we need to refactor the "core" bits of ZPT (expressions, PageTemplateFile, etc.) out of 'Products.PageTemplates' and into a better "top-level" pacakge. People are beginning to use PTF for ZMI, which shouldn't break in the absence of a product. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
participants (6)
-
Casey Duncan -
Chris McDonough -
Evan Simpson -
Sidnei da Silva -
Tres Seaver -
Yuppie