[Zope3-dev] JavaScript Relic in formlib?
Hey!
I figured, that there seems to be unused JavaScript code in a formlib generated
page:
zc_trackChanges(document.getElementById('zc.page.browser_form'));
in pageform.pt of formlib. I couldn't find the corresponding function by
grepping through the rest of the src.zope sourcecode. Can this be
removed perhaps?
Greetings,
--
R?man Joost
gocept gmbh co. kg ? Forsterstrasse 29 ? 06112 Halle/Saale
fon +49 (0)345 122 98 89 2
pgpjykfqqUYR4.pgp
Description: PGP signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] set of interfaces?
Hi! what is the best way in zope3 to create a collection of interfaces without using classes, lists, etc.? I have a number of interfaces that I'd like to group into a same interface category. e.g. ISomeCollection = I1, I2, I3, I4 and I'd like to be able to query which interfaces ISomeCollection contains. However I'd like not to instanciate a registry just to hold that type of information. regards /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] Re: [Zope-CMF] Fighting the Zope 2.9 testrunner
Philipp von Weitershausen wrote: I've never installed Zope anywhere except on production servers anyway, and there you should obviously use releases. I don't think obviously necessarily applies there. There are good reasons for wanting to install from a checkout. If you absolutely must use make install from a checkout (perhaps because you want to install the trunk somewhere), then you can make a TGZ first using zpkg. That's a possible work-around, but doesn't seem like a good reason to leave make install broken. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] JavaScript Relic in formlib?
Roman Joost wrote:
Hey!
I figured, that there seems to be unused JavaScript code in a formlib generated
page:
zc_trackChanges(document.getElementById('zc.page.browser_form'));
It is a relic and should be removed. It is part of you're about to
leave this page and you haven't saved your changes functionality which
doesn't belong in formlib.
--
Benji York
Senior Software Engineer
Zope Corporation
___
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: [Zope-CMF] Fighting the Zope 2.9 testrunner
Jim Fulton wrote:
From the old testrunner, which I miss *a lot*, I could ensure I am
indeed running a specific module by doing...
Yup, this is one of the things I like least from the Zope 3 world.
What happened to proposals and community agreement before inflicting
big changes on other people who're trying to help out?
Oh cut the crap.
Hmm, I'm confused by this. If there's a proposal, my bad, point me at
it. If there isn't, well, it's kinda odd to receive abuse for pointing
out that you aren't sticking to your own processes...
The new test runner tries very hard to be backward
compatible.
...but misses one of the most common use cases from the old one, and you
didn't seem particularly fussed about fixing this :-S
This breakage was not intentional. It was a bug. There is an
easy work around: just use the -m option.
It can't be that hard to put in some syntactic sugar to support this. I
was going to give it a shot myself but I ran out of time, and I worry
about things like the regex matching the old testrunner used to dowhen
using the missing option.
I particularly hate the fact that no real effort was put into
backwards compatibility, not to mention those silly weird
sort-of-fifty-dots-per-line thing that doesn't actually work.
What the heck are you talking about? What doesn't work?
Here's a literal screen dump:
C:\Zope\2.9iC:\Zope\2.9.1\bin\python.exe C:\Zope\2.9.1\bin\test.py
--config-file C:\Zope\2.9i\etc\zope.conf --keepbytecode
Parsing C:\Zope\2.9i\etc\zope.conf
Running tests at level 1
Running unit tests:
Running:
.C:\Zope\2.9.1\lib\python\OFS\Application.py:598:DeprecationWarning:
The zLOG package is deprecated and will be removed in Zope 2.11. Use the
Python logging module instead.
('New disk product detected, determining if we need '
.
.
Ran 63 tests with 0 failures and 0 errors in 6.009 seconds.
C:\Zope\2.9i
It looks bizarre having that carriage return in the middle of the row of
dots. What's the point of the change that Tres added his patch to avoid
seeing?
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
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: [Zope-CMF] Fighting the Zope 2.9 testrunner
On Wed, Mar 22, 2006 at 06:25:41PM +0100, Martijn Faassen wrote: Anyway, a release and the development situation looking similar helps people actually work on the same codebase and structure, and not having to learn different ways of doing things as soon as they switch. Forcing context switches on people isn't a good idea. +1 -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Why z.a.appsetup.bootstrap function do not return the actual object
Am Montag, 20. März 2006 14:27 schrieb Stephan Richter: On Wednesday 08 March 2006 08:57, Florian Lindner wrote: Hello, I'm currently playning with the functions from zope.app.appsetup.bootstrap and I'm wondering why the functions that create objects (addConfigureUtility, addUtility, configureUtility, ensureObject, ensureUtility) do return the name of the object added (or None) and not the object itself. What is the reason for that? IMO in most cases you add a Utility you want to change some attributes of it afterwards. In order to do that you need the object instance. To get it from the name you have to perform a getUtility call. If the functions above would return the object you could omit the getUtility. What do you think about that? This is a relic from the early days, when we still had context wrappers. I am +1 for the change, but backward-compatibility has to be provided. And since the return value changes, this has to be done in two steps: 1. Create a new option argument to the functions saying ``asObject=False``, and only if set to True the object will return. Done. Then deprecate the string return value by generating a warning message. Mmmhh... how can I deprecate a function argument conditionally? def ensureObject(root_folder, object_name, object_type, object_factory, asObject=False): Check that there's a basic object in the site manager. If not, add one. Return the name abdded, if we added an object, otherwise None. if not asObject: asObject = deprecation.deprecated(asObject, Using asObject=False is deprecated) But that does not do anything 2. After two releases, remove deprecated string value return and set ``asObject=True`` by default. Also deprecate the asObject argument again. Hope I'll remember that. Thanks, Florian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
