name of input processing decorator
Kevin Dangoor
I'm working on the expose decorator split that's been talked about for
a while now. The idea, for those who weren't here for the initial
discussions, is to make it easier to use other decorators besides
expose if your app needs to. (This is currently difficult because of
how many functions are built in to expose.)
The proposed change was to have two decorators: one for input and one
for output. The "expose" decorator would continue to handle all output
funtions. Sean Cazzell's original suggestion for the input decorator
was "unpack". Jason Pellerin mentioned "input" the other day. I'm not
fond of unpack and input, while nicer than unpack, is a Python builtin
which seems like a bad idea.
What do you think of "process" (it has inputform and validators
parameters)? It's rather generic, but it is all about processing the
input. Or maybe "validate"?
Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
Karl Guertin
> What do you think of "process" (it has inputform and validators
> parameters)? It's rather generic, but it is all about processing the
> input. Or maybe "validate"?
I'm happy to see this change happen. I would think the opposite of
expose would be 'accept' or 'accepts', but in the interest of not
having a bikeshed argument, I'll take process.
Kevin Dangoor
I thought the opposite of "expose" was "inpose" :)
Karl Guertin
> I thought the opposite of "expose" was "inpose" :)
WORKSFORME
Jorge Godoy
> What do you think of "process" (it has inputform and validators
> parameters)? It's rather generic, but it is all about processing the
> input. Or maybe "validate"?
One common term in telecom is 'incoming' and 'outgoing'... 'incoming',
and 'receiving' sounds better than validate (risk of confusing with
validators) to me...
--
Jorge Godoy <jgo...@gmail.com>
Mike Orr
asks what's it validating, what else can it be but the input?
@accept and @unpack are OK but less self-evident. @accepts sounds
wrong: how many other decorators have a verb ending in s?
@process gets confusing with OS processes. @process_input would be better.
So pages that just display would use @expose, and pages that receive
input would use both @??? and @expose? So the form would be both an
@??? argument and in the return dictionary?
--
Mike Orr <slugg...@gmail.com>
(m...@oz.net address is semi-reliable)
Michele Cella
@process(form=..., validators=...)
Validate could be confusing since you will end up with something like:
@validate(validators=...)
Ciao
Michele
Kevin Dangoor
>
> @validate sounds best because that's what it's doing. And if anybody
> asks what's it validating, what else can it be but the input?
That was what I was thinking. You're either validating that set of
validators or the inputform (or both).
> So pages that just display would use @expose, and pages that receive
> input would use both @??? and @expose? So the form would be both an
> @??? argument and in the return dictionary?
The existing usage would still exist for backwards compatibility.
Here's an example:
@expose(html="foo")
def index(self):
return dict(form=myform)
@expose()
@validate_or_process_or_whatever(myform)
def save(self, field1, field2):
...do something...
Kevin
Michele Cella
> On 12/27/05, Mike Orr <slugg...@gmail.com> wrote:
> >
> > @validate sounds best because that's what it's doing. And if anybody
> > asks what's it validating, what else can it be but the input?
>
> That was what I was thinking. You're either validating that set of
> validators or the inputform (or both).
>
Well, you are both right, +1 for validate then.
Also since (as Mike said) you are obviously validating input shouldn't
inputform be renamed to form?
@validate(form=..., validators=...)
Ciao
Michele
Kevin Dangoor
> Also since (as Mike said) you are obviously validating input shouldn't
> inputform be renamed to form?
>
> @validate(form=..., validators=...)
You're right... form is a lot more pleasant. "inputform" was a
holdover from when you specified a form being output in expose...
Kevin
Jeff Watkins
everything I do is Ajax oriented) but there's no reason to even
bother with keyword parameters. Just accept varargs and process them
left to right based on type: if it's a form, validate the form, if
it's a validator, validate it.
That way you have:
@expose( html="my.template" )
@validate( myForm, anExtraValidatorJustForThisMethod )
def anOperation( self, arg1, arg2 ):
pass
On 27 Dec, 2005, at 4:38 pm, Michele Cella wrote:
> Also since (as Mike said) you are obviously validating input shouldn't
> inputform be renamed to form?
>
> @validate(form=..., validators=...)
>
--
Jeff Watkins
http://newburyportion.com/
"Just because you have the right to do something, doesn't mean it's
the right thing to do."
-- Fred Friendly, former president of CBS News
Wavy Davy
>
> I don't usually chime in on things like this (because almost
> everything I do is Ajax oriented) but there's no reason to even
> bother with keyword parameters. Just accept varargs and process them
> left to right based on type: if it's a form, validate the form, if
> it's a validator, validate it.
>
> That way you have:
>
> @expose( html="my.template" )
> @validate( myForm, anExtraValidatorJustForThisMethod )
> def anOperation( self, arg1, arg2 ):
> pass
Not a fan for two reasons: "Explicit is better than implicit", and
you'd lose consistancy between related functions (either expose and
validate should both have kwargs, or neither should)
Plus, IMHO using type introspection is a bit broken (though sometimes
necessary in python at the moment).
+1 for validate, process is too generic
--
wavy davy
"True religion confronts earth with heaven
and brings eternity to bear on time"
- A. W. Tozer
Jeff Watkins
multiple parameters of the same type: html, template, format, and
content_type. Simple type introspection isn't sufficient in these cases.
I'm not going to touch the argument that type-checking is broken...
On 27 Dec, 2005, at 6:27 pm, Wavy Davy wrote:
> Not a fan for two reasons: "Explicit is better than implicit", and
> you'd lose consistancy between related functions (either expose and
> validate should both have kwargs, or neither should)
>
> Plus, IMHO using type introspection is a bit broken (though sometimes
> necessary in python at the moment).
--
Jeff Watkins
http://newburyportion.com/
Computers, they're just a fad.
Wavy Davy
>
> The reason expose requires keyword parameters is because it accepts
> multiple parameters of the same type: html, template, format, and
> content_type. Simple type introspection isn't sufficient in these cases.
OK, fair enough. But we may want to expand the options to validate at
some point in the future, so the samemay apply.
> I'm not going to touch the argument that type-checking is broken...
Fair enough :)
Ah well, so much for avoiding another bikeshed moment :)
Michele Cella
One more thing, what about renaming
cherrypy.request.form_errors
to
cherrypy.request.validation_errors
This enforces the relationship with the validate decorator (that can
contain a form or validators) and with the upcoming new error handling
mechanism.
Ciao
Michele
Kevin Dangoor
> One more thing, what about renaming
>
> cherrypy.request.form_errors
>
> to
>
> cherrypy.request.validation_errors
+1