Returning Deferred from coerce method in formless - patch
Hi, http://divmod.org/users/roundup.twistd/nevow/msg436 Coerce methods, used when validating formless.annotate.Typed objects, can return Deferreds. The problem with formless is, that it can accept them only when GroupBinding is used. This patch fixes that for MethodBinding. Why return Deferred from coerce methods? Well, there are various reasons. You could validate an e-mail address using queries to DNS servers, or you could validate login name using pgasync.ConnectionPool, or do anything else, that requires deferred methods. Even that I've still have Nevow commits, I don't want to commit this patch myself - I'd really appreciate someone reviewing it before. Many thanks, -- m
On Wed, Jun 15, 2005 at 07:46:46PM +0200, Michal Pasternak wrote:
various reasons. You could validate an e-mail address using queries to DNS servers, or you could validate login name
FWIW, I also needed to return deferred from coerce. Right now I'm using the autocallable to do that. The autocallable returns annotate.ValidateError if something goes wrong. But the dns is checked only if all the coerce methods all passes, so I can't show the dns error until all coerce passed, which made the dns check a kind of last special check, for no good reason. It'd be more coherent to check for all errors even when some other coerce in the same form fails. Thanks for working to add this feature. BTW, I'd also need "context" to be passed to the coerce method (as last argument), I had to write my own ProcessTypedContext to do that, and it'd be much nicer if the default formless process handler would pass the context to coerce too (though I believe it would break current apps, but it'd be a very visible breakage, no risk of silent malfunctions at runtime). Said that I also appreciate backwards compatibility ;) I need the context in order to reach the session with inevow.ISession(ctx) inside the coerce handler. Thanks!
On Jun 15, 2005, at 8:43 PM, Andrea Arcangeli wrote:
On Wed, Jun 15, 2005 at 07:46:46PM +0200, Michal Pasternak wrote:
various reasons. You could validate an e-mail address using queries to DNS servers, or you could validate login name
Thanks for working to add this feature.
I got it to work, but I'm seeing some weirdness in several situations. I guess they would be classified "regressions". I seem to need this all of a sudden, so you are in luck. I will take a look at fixing the weirdness I see and try to fix it, and commit it to trunk soon.
BTW, I'd also need "context" to be passed to the coerce method (as last argument), I had to write my own ProcessTypedContext to do that, and it'd be much nicer if the default formless process handler would pass the context to coerce too (though I believe it would break current apps, but it'd be a very visible breakage, no risk of silent malfunctions at runtime). Said that I also appreciate backwards compatibility ;)
It should be the first argument, for consistency. Also, to retain backwards compatibility, we could rename the "coerce" method which takes a context. Perhaps it could be named "convert".
I need the context in order to reach the session with inevow.ISession(ctx) inside the coerce handler.
Indeed. formless was originally designed to be web-agnostic and be usable outside of nevow, but in this case I think it's compelling enough to allow it. Donovan
On Thu, 16 Jun 2005 12:04:58 -0700, Donovan Preston <dp@ulaluma.com> wrote:
On Jun 15, 2005, at 8:43 PM, Andrea Arcangeli wrote:
On Wed, Jun 15, 2005 at 07:46:46PM +0200, Michal Pasternak wrote:
various reasons. You could validate an e-mail address using queries to DNS servers, or you could validate login name
Thanks for working to add this feature.
I got it to work, but I'm seeing some weirdness in several situations. I guess they would be classified "regressions".
I seem to need this all of a sudden, so you are in luck. I will take a look at fixing the weirdness I see and try to fix it, and commit it to trunk soon.
BTW, I'd also need "context" to be passed to the coerce method (as last argument), I had to write my own ProcessTypedContext to do that, and it'd be much nicer if the default formless process handler would pass the context to coerce too (though I believe it would break current apps, but it'd be a very visible breakage, no risk of silent malfunctions at runtime). Said that I also appreciate backwards compatibility ;)
It should be the first argument, for consistency. Also, to retain backwards compatibility, we could rename the "coerce" method which takes a context. Perhaps it could be named "convert".
I need the context in order to reach the session with inevow.ISession(ctx) inside the coerce handler.
Indeed. formless was originally designed to be web-agnostic and be usable outside of nevow, but in this case I think it's compelling enough to allow it.
Rather than propagating the context to yet another API, how about just improving the support for dynamic autocallable signatures? If it weren't so difficult to do dynamic bindings, Typed subclasses could be instantiated with references to anything they needed, rather than needing to magically pull objects out of thin air. I also wonder what's more compelling about this use-case than about any other use-case of the context. Jp
participants (4)
-
Andrea Arcangeli -
Donovan Preston -
Jp Calderone -
Michal Pasternak