On Thu, 16 Jun 2005 12:04:58 -0700, Donovan Preston <dp at 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