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
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.
I thought the opposite of "expose" was "inpose" :)
WORKSFORME
> 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>
@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)
@process(form=..., validators=...)
Validate could be confusing since you will end up with something like:
@validate(validators=...)
Ciao
Michele
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
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
You're right... form is a lot more pleasant. "inputform" was a
holdover from when you specified a form being output in expose...
Kevin
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
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
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.
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 :)
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
+1