Hanno Schlichting wrote:
> Hi there,
>
> I was in too much of a good mood while having some vacation. So I
> thought I need more work to do :)
>
> I'd like to step up as the release manager for Zope2 for the 2.12 and
> 2.13 (trunk) releases.
Sucke^H^H^H^H^H Good man!
Very happy you're doing this.
Christian Theune wrote:
> Hi,
>
> here's this week's summary.
>
> For those of you who can't/don't participate in those meetings, there's
> the open question about how useful you consider my summaries to be.
> Please tell!
>
> Also in short: we decided to keep going with the meetings, so I'd be
> h
Charlie Clark wrote:
> Am 31.03.2010, 13:54 Uhr, schrieb Martin Aspeli:
>
>> Why -1 if it's just about windows binaries?
>
> Because I don't think that, if this were the case, this would be the best
> solution to the problem.
What would be a better solution?
Wi
Charlie Clark wrote:
> Am 30.03.2010, 17:31 Uhr, schrieb Hanno Schlichting:
>
>> It simplifies the release process for Zope2. In most cases upgrading
>> to a new version of Zope2 won't involve any changes to C code. If the
>> C code is split out, we won't have to release any new Windows binary
>> e
Hanno Schlichting wrote:
> On Tue, Mar 30, 2010 at 5:26 PM, Martin Aspeli
> wrote:
>> Hanno Schlichting wrote:
>>> For Zope 2.13 (trunk) I'd like to try to reduce the C dependencies of
>>> the Zope2 distribution itself. Ideally it would not have any C
>&
Hanno Schlichting wrote:
> Hi.
>
> For Zope 2.13 (trunk) I'd like to try to reduce the C dependencies of
> the Zope2 distribution itself. Ideally it would not have any C
> dependencies in its own distribution
Why?
Martin (who spent all day trying to get Zope 2 to build on SuSE Linux
before reali
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martin Aspeli wrote:
>> Hi,
>>
>> In some cases (e.g. large OFS.File/Image responses), Zope 2 will use
>> response.write() to stream the response.
>>
>> We have events th
Hanno Schlichting wrote:
> On Sun, Mar 21, 2010 at 12:05 PM, Martin Aspeli
> wrote:
>> Hanno Schlichting wrote:
>>> Why would you need to have the event on the request, if all you want
>>> is to set headers? Why not make it an event with the response as the
&
Hanno Schlichting wrote:
> On Sun, Mar 21, 2010 at 10:07 AM, Martin Aspeli
> wrote:
>> We'd therefore like to add a new event in the HTTPResponse class (in
>> ZServer, though I think it makes sense to add to the ZPublisher base
>> class version as well). It&
Hi,
In some cases (e.g. large OFS.File/Image responses), Zope 2 will use
response.write() to stream the response.
We have events that fire before and after a "regular" response is
returned, but none that allow us to set headers (caching headers, in
this case) before such a streaming response i
Hi,
I'm struggling to get custom ComputedErrorViewMessage adapters to work
in z3c.form. I'm still debugging, but I came across this:
In error.py:
ErrorViewMessage = value.StaticValueCreator(
discriminators = ('error', 'request', 'widget', 'field', 'form',
'content')
)
ComputedErr
Hi,
I posted about this earlier, but the message seems to have gotten lost
in the ether.
I am trying and struggling to use ComputedErrorViewMessage. So far, I've
discovered two problems, one which affects IValue adapters in general.
1. The last discriminator of a ComputedErrorViewMessage (and
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> David Glick wrote:
>> Log message for revision 109667:
>>add a failing test for a regression in parsing ISO format datetimes from
>> DateTime 2.10, as discussed at http://dev.plone.org/plone/ticket/10140
>> ...note that
Wichert Akkerman wrote:
> On 3/1/10 13:41 , Tres Seaver wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Marius Gedminas wrote:
>>> On Sun, Feb 28, 2010 at 05:05:51PM +0100, Wichert Akkerman wrote:
On 2010-2-26 18:25, Tres Seaver wrote:
> Wichert Akkerman wrote:
>> I se
Stephan Richter wrote:
> On Friday 26 February 2010, Martin Aspeli wrote:
>> The z3c.form doctests make it look like raising zope.interface.Invalid()
>> would be an acceptable thing for a validator to do. It also makes it
>> look like the argument passed to the Invalid() co
Hi,
The z3c.form doctests make it look like raising zope.interface.Invalid()
would be an acceptable thing for a validator to do. It also makes it
look like the argument passed to the Invalid() constructor is a string
that would be displayed as an error message.
However, when I do this (in a co
Hi,
A lot of the forms I write perform a redirect at the end of the action
handler for a successfully submitted form.
z3c.form's __call__() indiscriminately calls update() and then render().
This means that even if something in update() (the action handler in
this case) causes a redirect, the
Wichert Akkerman wrote:
> It is not useful, it is critical. Without the context you can not use
> any browser views for example.
Well, the use cases that have been to date have done without it. :) I'm
not disagreeing with you, I'm just saying we need to make sure we don't
break existing use cas
Wichert Akkerman wrote:
> On 2/23/10 11:09 , Hanno Schlichting wrote:
>> On Tue, Feb 23, 2010 at 10:56 AM, Wichert Akkerman
>> wrote:
>>> In Zope 2.10 exception views were acquisition-wrapped in the publisher
>>> context.
>> In Zope 2.10, exception views didn't exist in Zope2. They were only
>>
Charlie Clark wrote:
> Am 06.02.2010, 15:21 Uhr, schrieb Matthew Wilkes
> :
>
>> It seems like a lot of work for no gain. I can think of a couple of
>> examples where DTML templates are monkey-patched in Plone and none of
>> those are anything particularly vital. DTML works for the ZMI, new
>> pa
Christian Theune wrote:
>> As a matter of constructive criticism, it would be useful to have
>> something like this on the z3c.caching PyPI page. Right now, there is no
>
> That's a typo, right?
D'oh; z3c.coverage, I meant.
>> way that I can see to understand how the package is meant to be used
>
Jan-Wijbrand Kolman wrote:
> Martijn Faassen wrote:
>> Hi there,
>>
>> This is to announce my withdrawal from the Zope Toolkit steering
>> group.
>
> I'm not sure if you're reading this, but I wanted to thank you anyway
> for the tremendous amount of energy you've put into the steering
> group.
I
Stephan Richter wrote:
> On Sunday 17 January 2010, Martin Aspeli wrote:
>> I'm using zope.testing-3.7.7, which is what comes with Zope 2.12.
>
> Here is what I have in effectively any package:
>
> [coverage-test]
> recipe = zc.recipe.testrunner
> eggs = pkg
Attila Oláh wrote:
> You can get the same result as with `pwd` by using --coverage=../../coverage
D'oh! The current path is parts/test (via zc.recipe.testrunner). I did
*not* expect that.
I think this needs to be documented at least, though I think it would
make more sense if the current direc
Hi,
A couple of questions about zope.testing's --coverage option:
1. When specifying the coverage output directory, I have to specify an
absolute path:
./bin/test -s plone.caching --coverage="$(pwd)/coverage"
works
./bin/test -s plone.caching --coverage="coverage"
does not. Is this intenti
Michael Howitz wrote:
> Am 13.01.2010 um 06:08 schrieb Martin Aspeli:
>> Michael Howitz wrote:>>> Hi,
>>>
>>> it seems to me that z3c.form.group.GroupForm does not send
>>> enough ModificationEvents: only one event for the context of the
>>> Gr
Michael Howitz wrote:
> Hi,
>
> it seems to me that z3c.form.group.GroupForm does not send enough
> ModificationEvents: only one event for the context of the GroupForm
> but not for each modified object in the groups.
-1 to this being default behaviour.
IObjectModifiedEvent is fired from EditForm
Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi there,
>
> I would like to inform you that I intent to retreat from the Zope 2
> release manager position soon. I have been serving the Zope community in
> this position for almost seven years and now it is time to move on
Laurence Rowe wrote:
> 2010/1/10:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Martin Aspeli wrote:
>>> Wichert Akkerman wrote:
>>>> On 2010-1-10 04:36, Martin Aspeli wrote:
>>>>> so in your test, `DateTime(md.Crea
Wichert Akkerman wrote:
> On 2010-1-10 04:36, Martin Aspeli wrote:
>> so in your test, `DateTime(md.CreationDate())` will always be the
>> current time, but with an implicitly added 'GMT+0' while `DateTime()`
>> will be the current time in your local time zone. so i
Hi,
We have a failing test in plone.app.dexterity 1.0a7. This is simply
trying to compare two dates:
>>> from DateTime import DateTime
>>> DateTime() > DateTime(md.CreationDate())
True
At least here in Australia, the second test fails. Right now, the
following expressions are:
Tres Seaver wrote:
> You can "lock" the status and body of the response, which causes
> subsequent attempts to set them to fail silently.
Oh, that's great! I even remember reading that code and it never struck
me. Thanks a lot!
Martin
--
Author of `Professional Plone Development`, a book for
Laurence Rowe wrote:
> 2009/12/31 Martin Aspeli:
>> Hi,
>>
>> A few of us are playing with some caching tools, trying to get to a more
>> sane and less monkey patch-laden approach than CacheFu
>> (Products.CacheSetup), for use with Zope 2.12.
>>
>>
Martin Aspeli wrote:
> Baiju M wrote:
>> On Mon, Jan 4, 2010 at 11:53 PM, Baiju M wrote:
>>> Hi All,
>>> I am proposing to call "Zope 3 - the web frame work"
>>> as "BlueBream".
>> I am unable to make a conclusion out of th
Baiju M wrote:
> On Mon, Jan 4, 2010 at 11:53 PM, Baiju M wrote:
>> Hi All,
>> I am proposing to call "Zope 3 - the web frame work"
>> as "BlueBream".
>
> I am unable to make a conclusion out of this discussion as many
> real users of "Zope 3 - the web frame work" is not given +1
> But th
Jim Fulton wrote:
> - When we refactor zope.app.foo to be zope.foo (or something else),
> rather than changing
>zope.app.foo to use zope.foo, just leave zope.app.foo alone, if possible.
One problem with this is that if you have interfaces for which there are
components registered, this can m
Jens Vagelpohl wrote:
> How is that any different from people who won't use the ZTK because they
> don't want to deal with any zope.app* baggage?
We have a proposal for dealing with that now: To maintain two KGS', one
for ZTK and one for ZopeApp.
We can and should run tests for both, and ensure
Martijn Faassen wrote:
> Hey Tres,
>
>
> Tres Seaver wrote:
>
>> You're kidding, right?
> [snip]
>> My self-interest? Not really: you are appealing to my altruism, in the
>> fact that I care about the *broader* Zope community (broader than Zope2,
>> Grok, Plone, or whatever. Neither of my chosen
Andreas Jung wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Baiju M wrote:
>> Hi All, I am proposing to call "Zope 3 - the web frame work" as
>> "BlueBream". The main use for name is documentation. But the
>> package named "bluebream" will not provide any part of framework
>> code by
Jan Ulrich Hasecke wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05.01.10 08:36, Martin Aspeli wrote:
>> +1. It puts the final nail in the Zope 3 coffin and allows a reborn
>> vampire to emerge from slumber.
>
> Ok, we all hate the damage that Zope
Baiju M wrote:
> Hi All,
> I am proposing to call "Zope 3 - the web frame work"
> as "BlueBream". The main use for name is documentation.
> But the package named "bluebream" will not provide
> any part of framework code by itself. All the framework
> code will be in "zope" and "zope.app"
Hi,
> So here's my proposed solution for the ZTK shrinking issue:
>
> The ZTK branch 'faassen-smaller' contains Hanno's smaller ZTK. Since
> Zope 2 forked the ZTK in response and continued to make changes to their
> fork, I've tried to keep it in sync with the Zope 2 fork.
>
> I've created a new '
Martijn Faassen wrote:
> What lowered the quality of this discussion? I think it is because
> various people became quite upset and annoyed. That's because I reverted
> Hanno's changes to the ZTK trunk. I shouldn't have done that just like
> that, but I needed the subsequent discussion to come up
Martijn Faassen wrote:
> Hi there,
>
> This is a summary of the previous discussions for those who weren't
> paying attention last week and don't want to read a huge thread coming
> back from vacations. I'm talking about you in particular, other steering
> group members. I'll spread it out over mul
Martijn Faassen wrote:
> Martin Aspeli wrote:
> [snip]
>> We've had good success with
>> http://pypi.python.org/pypi/collective.recipe.sphinxbuilder
>
> I'm having trouble with this. I'm trying to set up a "narrative_docs"
> di
Martijn Faassen wrote:
> Hi there,
>
> I am interested in creating sphinx-driven documentation for Zope Toolkit
> packages. I'd like to maintain the documentation for a package (say,
> zope.component) in that package, in a 'doc' directory.
>
> I'm wondering what experiences people have with maintai
Hi Paul,
Nicely done! I think it'd be useful to wrap this into a small library
and release it for people who want to use it, with a bit of narrative
documentation on its own for the PyPI front page.
One thing you may want to think about, is to have an option for delaying
the registration until
Baiju M wrote:
>> The packages that we might want to break out (like we did with
>> Acquistion, ExtensionClass, DateTime) should retain their name, so
>> nobody has to change any code to work with them.
>
> I think we could have added those packages in a namespace.
Why? A million things depend on
Hi,
A few of us are playing with some caching tools, trying to get to a more
sane and less monkey patch-laden approach than CacheFu
(Products.CacheSetup), for use with Zope 2.12.
It is relatively easy to set response headers, e.g. in an
IPubBeforeCommit event handler.
However, we also need to
Hanno Schlichting wrote:
> On Wed, Dec 30, 2009 at 6:38 PM, Martijn Faassen
> wrote:
>> zope.testing.doctestunit emits a deprecation warning. It also defines a
>> function pprint. How does one use pprint without getting a deprecation
>> warning? It seems impossible now, and an equivalent pprint d
Hanno Schlichting wrote:
> From my point of view most of the original UI building blocks of Zope
> 3 have failed to catch on. More modern systems like repoze.bfg prefer
> a much simpler model using ZPT macros or trying to mirror the CMF
> skins model. In the Plone world we adopted the CA to build
Tres Seaver wrote:
> After a question on the repoze list about running Zope 2.12.x behind a
> WSGI server, I went to try that out. I came up with a minimal .wsgi
> file to run behind mod_wsgi::
>
> $ cat src/Zope2/utilities/skel/bin/zope2.wsgi.in
> from Zope2.Startup.run import configure
>
Hanno Schlichting wrote:
> Hi Tres,
>
> I've seen you started some work on Zope2 and its WSGI publisher. This
> is awesome :)
>
> How does this relate to repoze.zope2?
>
> I'd love to have Zope2 actually support WSGI out-of-the-box. It should
> probably be based on either a simplified repoze.zope2
Helge Tesdal wrote:
> On 18. des.. 2009, at 13:24, Andreas Jung wrote:
>
>> Publisher events are part of Zope 2.12 (not sure if they were
>> backported to older versions).
>>
>> Perhaps of interest:
>>
>> http://pypi.python.org/pypi/haufe.requestmonitoring
>> http://pypi.python.org/pypi/haufe.ztop
Tres Seaver wrote:
> In either case, I think TypeError (or maybe LookupError) is the *right*
> choice: we don't want to "hide" zope.component's API functions and then
> turn around and require folks to import zope.component just to catch its
> local exception types.
Yeah, that's a compelling rea
Tres Seaver wrote:
>>> +1 to TypeError: nobody really cares about the type of the error: code
>>> that wants to be robust about a failure uses the 'query' methods. As
>>> long as the message is informative enough (which ComponentLookupError
>>> isn't, really) we should be fine. If we made CLE
Tres Seaver wrote:
>>> * The hook invokes the `query*` functions to play nice with any other
>>>component hooks and the interface methods raise a TypeError if all of
>>> them
>>>fail to find a component.
>> A TypeError instead of a ComponentLookupError?
>>
>> I was thinking we should keep
On 15/12/09 5:45, Tres Seaver wrote:
>> I've committed this in r106436 and merged to trunk in r106437.
>
> OK, sounds fine to me. Can you merge to the 2.11 branch as well? I
> think Andreas will be releasing 2.9.x through 2.12.x fairly soon.
Sure, I'd forgotten about that one.
>> If anyone obj
On 13/12/09 16:49, Martin Aspeli wrote:
> On 13/12/09 10:52, Tres Seaver wrote:
>
>> Doesn't smell like a regression to me: the code there hasn't changed in
>> a good long while. Can you write a test case for it, so that we can
>> test against earlier versi
On 13/12/09 10:52, Tres Seaver wrote:
> Doesn't smell like a regression to me: the code there hasn't changed in
> a good long while. Can you write a test case for it, so that we can
> test against earlier versions?
Aha! http://codespeak.net/pipermail/z3-five/2007q2/002185.html
This is the same
On 13/12/09 10:52, Tres Seaver wrote:
> Doesn't smell like a regression to me: the code there hasn't changed in
> a good long while. Can you write a test case for it, so that we can
> test against earlier versions?
I'm almost completely sure that this was an issue ages ago, and slightly
less s
Hi,
Ages ago, I started a thread (I think on this list) about the use of TAL
expression in Zope 3-style page templates (i.e. ViewPageTemplateFile's
used on views) incorrectly performing security checks when using TAL
expressions.
I think Tres fixed it at the time (I can't find the original mai
Shane Hathaway wrote:
> Martin Aspeli wrote:
>> Can we all get back to our lives now? :-)
>
> FWIW, I try to participate in discussions like these by reading and
> writing only short emails. I find that I don't miss much that way.
> Life is more enjoyable without es
Martijn Faassen wrote:
> Hi there,
>
> I think we've had enough discussion to make a decision.
I'm a little worried that neither Stephan Richter, nor Jim Fulton have
had much weight in on this. They seem like important stakeholders. :)
> Hopefully
> everybody is at least reasonably happy with
Martijn Faassen wrote:
> Martin Aspeli wrote:
> [snip]
>> Thinking out loud further, I think I may actually prefer IFoo.instance()
>> instead of .utility(), but maybe that debate is already passed.
>> .utility() is OK too.
>
> Haven't you been one of the peop
Lennart Regebro wrote:
> On Thu, Dec 3, 2009 at 03:14, Gary Poster wrote:
>> I think I could get fully behind the following proposal that others have
>> made (Shane I think was one of several?).
>>
>> IFoo.adapt(...)
>>
>> IFoo.utility(...)
>
> Change that to Martins IFoo.adapter(...) and I'm be
Gary Poster wrote:
> I think I could get fully behind the following proposal that others have made
> (Shane I think was one of several?).
>
> IFoo.adapt(...)
>
> IFoo.utility(...)
Thinking about it a bit, it strikes me that IFoo.adapt(context) may not
be right. This reads "IFoo adapt context",
Gary Poster wrote:
> On Dec 2, 2009, at 11:09 PM, Martin Aspeli wrote:
>
>> Gary Poster wrote:
>>> I think I could get fully behind the following proposal that
>>> others have made (Shane I think was one of several?).
>>>
>>> IFoo.adapt(...)
>&
Gary Poster wrote:
> I think I could get fully behind the following proposal that others
> have made (Shane I think was one of several?).
>
> IFoo.adapt(...)
>
> IFoo.utility(...)
I could get behind this too.
We'd need the current IFoo(context, default) for single adaptation to
continue to wor
Chris McDonough wrote:
> Thomas Lotze wrote:
>> Martijn Faassen wrote:
>>
>>> * a utility never has a connection. That's because it already got
>>> instantiated long before the lookup takes place.
>> Isn't it the other way around: A utility never has a connection to any
>> adapted object, and that'
Joachim König wrote:
> Martin Aspeli wrote:
>> Clearly, it could. But that's not the way we went. Changing it now would
>> be really damaging, and I'm not sure what would be gained.
>>
>> I can imagine use cases where getting a new instance each time would b
Chris McDonough wrote:
> I am more or less somewhere between -0 and +0
That is a high degree of precision. Maybe we need to start thinking of
our voting system as a Decimal instead of an int?
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plo
Martijn Faassen wrote:
> First a statement about the goal of this discussion. The goal of this
> discussion is to convince people to unify the lookup API. I wouldn't
> want to make lookup API improvements depend on improvements to
> zope.component inspired by the discussion below. I'm in favor
Martijn Faassen wrote:
> Joachim König wrote:
> [snip]
>> To me the fact that an object "is" a singleton or a factory is
>> orthogonal to the registry stuff.
>>
>> Why can't utilities be factories too that simply return themselves when
>> being called? Then being
>> a singleton or not would be in
Martijn Faassen wrote:
> I don't like the word singleton very much either. Singleton in the
> Design Patterns book has a very particular implementation that is
> criticized by a lot of developers and in particular that particular
> pattern is very uncommon in the Python world (people just use g
Martijn Faassen wrote:
> Hi there,
Thanks for doing the summarise-and-move-it-on job so well, Martijn. It's
really important.
> I'd like to summarize the options I've seen appear in the discussion so far.
>
> We have the following options:
>
> 1) introduce a new method, such as "instance()" or
Martijn Faassen wrote:
> Stephan Richter wrote:
>> On Friday 27 November 2009, Martijn Faassen wrote:
>>> Are people okay with the proposed semantics?
>>>
>>> Would people be okay with such an upgrade path? Any better ideas?
>> Looks good.
>>
>> Note: We had Thanks Giving over the weekend, so pleas
Martijn Faassen wrote:
> The most elegant backwards compatible solution would be multi adaptation
> using a tuple. I think 'name' can probably also be added to the adapter
> hook without breaking stuff. People adapting tuples will need an
> explicit way to do so. It's still backwards incompatib
Hanno Schlichting wrote:
> On Mon, Nov 30, 2009 at 2:39 PM, Wichert Akkerman wrote:
>> We could also say that we will clean up the API when we move to Python
>> 3. That is a natural breaking point anyway, so it will not any extra
>> pain for users of the ZCA.
>
> Except that is precisely what the
Hanno Schlichting wrote:
> On Mon, Nov 30, 2009 at 1:21 PM, Martin Aspeli
> wrote:
>> Martijn Faassen wrote:
>>> This implies we don't want to release zope.component 4.0 for a long time
>>> yet.
>> I think the answer should be "never". :)
>
Martijn Faassen wrote:
> Martin Aspeli wrote:
>> Martijn Faassen wrote:
>>
>>> Multi-adaptation:
>>>
>>>IFoo(one, two)
>> Please note that this will break an incredible amount of code "in the
>> wild". A good number of my pa
Martijn Faassen wrote:
> Multi-adaptation:
>
>IFoo(one, two)
Please note that this will break an incredible amount of code "in the
wild". A good number of my packages do something like this:
foo = IFoo(context, None)
if foo is None:
...
There is a lot of documentation out ther
Tim Hoffman wrote:
> Just re-inforcing this I almost never do IFoo. adaption as I am almost
> always using
> multiadapters and utilities so I completely forget about the IFoo
> adaption capability.
> Which means I always just write getAdapter as well as it seems more
> consistent to
> from an api c
Chris McDonough wrote:
> I fear it was for naught, sorry.
>
> Adding an attribute is unsightly and turning this into a component problem
> doesn't have enough immediate gain. The BFG registry will just continue to
> be
> a dict subclass.
>
> If Zope folks later want to use libraries that com
Chris McDonough wrote:
> I think we have to divorce the requirement from "the ZCA".
>
> The requirement:
>
> - an attribute of an instance of the class
>"zope.component.registry.Components" which is dictionarylike
>(accepts any key type, any value type).
>
> If I can get that, I'd be ha
Martin Aspeli wrote:
> I *do* actually like the "named IAnonymousUtility" thing as a
> convenience, because it retains some consistency. Maybe it's slower,
> which would be a negative. But it also allows all the other ZCA stuff
> (overriding, introspection, global/l
Chris McDonough wrote:
>> Except at this point we've lost all the other ZCA stuff. You can't
>> override with a local utility, for example.
>
> I see. I didn't understand that this was a use case, because I don't use any
> persistent registries. If you say this is a use case, I believe it.
N
Chris McDonough wrote:
> OK after rereading this, I think we may be massively overthinking this. The
> above is getting kinda silly. I can't think of a use case where being able
> to
> alternate between:
>
>reg.utils['root_factory']
>
> and
>
>reg.getUtility(IAnonymousUtility, name
Chris McDonough wrote:
> Chris McDonough wrote:
>>> Off the top of my head, another way to think of this *might* be to say
>>> that the 'dict access' is basically looking up a *named* utility
>>> providing a very generic marker interface, e.g.
>>> zope.component.interfaces.IUtility or even just
Hi Chris,
Chris McDonough wrote:
> Martin Aspeli wrote:
>> We need to make sure that we're not inventing a different way to achieve
>> something which is already possible. This will lead to confusion,
>> because people will have to know "which way" is appl
Chris McDonough wrote:
>> A lookup keyed entirely on strings and not interfaces is perfectly
>> possible using the ZCA, just register your utility to provide
>> z.i.Interface and name it. Your semantics are the same as the simple
>> dictionary use-case, but it doesn't force people to choose on
Matthew Wilkes wrote:
> Right, but I think mixing the two is just going to be confusing. Your
> alternative spelling may well be useful, but only if it works within
> the confines of the ZCA itself, otherwise you're just hijacking the
> component root for your own (nefarious) purposes.
The
Hi Chris,
>>> In repoze.bfg, we've actually decided to use a subclass of the component
>>> registry which also inherits from "dict". This makes it possible to
>>> spell
>>> common unnamed "utility" registrations and lookups as:
>>>
>>> utility = SomeUtilityImplementation()
>>> registry['someutil
Leonardo Rochael Almeida wrote:
> Wouldn't it be better to just move IPubFailure before the abort? Is
> there a reason for subscribing to such an event which would required
> the transaction to be aborted already? I can see the usefulness of the
> transaction being already doom()ed before this even
Hi,
In Zope 2.12 ZPublisher we have a good set of events now, which provide
useful hooks for modifying the response before or after publication.
However, I'd like to add one more. ;-)
Basically, we have IPubFailure, but this is sent *after*
transaction.abort() and endInteraction(). This means
Martin Aspeli wrote:
> Hi,
>
> I'm trying to turn the results of a test run using zope.testing
> (zc.recipe.testrunner) into a JUnit compliant XML format so that I can
> graph it with Hudson (a continuous integration tool).
>
> Are there any hooks in zope.testing to
Martin Aspeli wrote:
> Hi,
>
> Something has changed in Zope 2.12 that is causing tests that use
> PlacelessSetup's tearDown() with Five to fail:
>
> Error in test
> /Users/optilude/Development/Plone/Code/Build/plone/4.0/src/plone.autoform/plone/autoform/tests/../auto
Hi,
Something has changed in Zope 2.12 that is causing tests that use
PlacelessSetup's tearDown() with Five to fail:
Error in test
/Users/optilude/Development/Plone/Code/Build/plone/4.0/src/plone.autoform/plone/autoform/tests/../autoform.txt
Traceback (most recent call last):
File
"/Users/o
Adam Groszer wrote:
> Hello,
>
> After quickly glancing over plone.behavior it seems more like
> something to extend a schema, and does it solve the problem of "new
> properties -- new schema -- change everything around it"?
>
> What I need is to be able to change schema properties per site. And
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martin Aspeli wrote:
>> Tres Seaver palladion.com> writes:
>>
>>> There is no way to tell the difference between a WebDAV GET and a
>>> "normal" browser GET, period:
101 - 200 of 474 matches
Mail list logo
