Re: [Zope-dev] Unable to add folder in today's cvs w/traceback
Bill Anderson <bill.anderson@libc.org> writes:
Upon trying to add a new folder in today's updated cvs, I get the following:
<!-- Traceback (innermost last): File /home/www.deliverymenus.com/lib/python/ZPublisher/Publish.py, line 256, in publish_module File /home/www.deliverymenus.com/lib/python/ZPublisher/Publish.py, line 161, in publish File /home/www.deliverymenus.com/lib/python/ZPublisher/mapply.py, line 154, in mapply (Object: manage_addFolder) File /home/www.deliverymenus.com/lib/python/ZPublisher/Publish.py, line 98, in call_object (Object: manage_addFolder) File /home/www.deliverymenus.com/lib/python/OFS/Folder.py, line 137, in manage_addFolder TypeError: too many arguments; expected 2, got 3
-->
This happens regardless of options selected. Root folder obviously ;-)
Just thought I would give a heads up in case someone has fixed it and I missed it somewhere.
Yes we have broken it somehow. Such are the risks of following the CVS very closely. ;) There is one thing cvs need BAD, a 'cvs unupdate' to revert a recently updated tree to it's previous state. I know this can be done on a file by file basis, but it would be nice to step a whole tree of code back one iteration. Any CVS Gods out there know the knack? (There MUST be a way) -Michel PS: Don't CVS update if you ever see Jim check in anything that says 'Hold onto your Butts'. ;)
Bill
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://www.zope.org/mailman/listinfo/zope-dev
(For non-developer, user-level issues, use the companion list, zope@zope.org, http://www.zope.org/mailman/listinfo/zope )
michel@digicool.com wrote:
This happens regardless of options selected. Root folder obviously ;-)
Just thought I would give a heads up in case someone has fixed it and I missed it somewhere.
Yes we have broken it somehow. Such are the risks of following the CVS very closely. ;) There is one thing cvs need BAD, a 'cvs unupdate' to revert a recently updated tree to it's previous state. I know this can be done on a file by file basis, but it would be nice to step a whole tree of code back one iteration.
Any CVS Gods out there know the knack? (There MUST be a way) I'll look into it ...
-Michel
PS: Don't CVS update if you ever see Jim check in anything that says 'Hold onto your Butts'.
BWAAAAHAHAHAHAAA! Anyway. I have a fix that has been working for me for a few adds now. Not sure if it breaks anything else though ;-) ============================================================ --- Folder.py.bad Thu Jul 1 08:31:57 1999 +++ Folder.py Fri Jul 2 22:57:16 1999 @@ -134,7 +134,7 @@ ) ob.manage_addDTMLDocument(id='index_html', title='') if REQUEST is not None: - return self.manage_workspace(self, REQUEST, update_menu=1) + return self.manage_main(self, REQUEST, update_menu=1) ============================================================ Cheers, Bill
At 11:02 PM 7/2/99 -0600, Bill Anderson wrote:
michel@digicool.com wrote:
Yes we have broken it somehow. Such are the risks of following the CVS very closely. ;) There is one thing cvs need BAD, a 'cvs unupdate' to revert a recently updated tree to it's previous state. I know this can be done on a file by file basis, but it would be nice to step a whole tree of code back one iteration.
Any CVS Gods out there know the knack? (There MUST be a way)
I'll look into it ...
Whenever you check out a release, make a note of the precise date/time. Then, if you need to revert to that release later, just: cvs upd -D'date you checked out something that works'
Now that all of Zope is Open Source, might it make sense to move the tree tag and sql* tags to the DocumentTemplate package, since they don't really require the rest of Zope, and make useful additions to DocumentTemplate in its own right? It seems to me that adding them as dynamically loaded tags would enhance the value of the DocumentTemplate package. The sendmail tag of course wouldn't make sense because it requires a MailHost object, but the other tags do not require any ZInfrastructure besides DocumentTemplate. Right now, I have to surgically excise the .py files from the Zope distribution and find some reasonable place in my ZPublished code to import them, and then repeat the process whenever either Zope or DocumentTemplates are updated. Although it could be argued that the sql* tags shouldn't be in the "core" package, if they're dynamically loaded it doesn't affect much. In fact, they're quite useful there, as I've occasionally found the need to call regular DTML from SQL methods in order to break up big queries into smaller chunks or to share common code between multiple queries. While I'm on the subject of DocumentTemplates, a seperate and entirely unrelated suggestion that would be a lot more difficult than the one above, but might perhaps be more relevant for Zope's core audience of content developers... A Zope newbie I was helping the other day found the message "KeyError" to be hopelessly confusing, when what they'd done was misspelled a variable name. Perhaps certain exceptions should be re-formatted by the DTMLDoc/DTMLMethod classes so that Zope displays more meaningful messages like "Unrecognized name: foo", instead of the weird public-traceback + hidden error data combo.
participants (3)
-
Bill Anderson -
michel@digicool.com -
Phillip J. Eby