"gasolin" <[EMAIL PROTECTED]> writes:
> 1. "idenntity.require" broke the consistency usage of decorators, such
> as @expose, @validate (no subfix)
Instead of "from turbogears import identity" use "from turbogears.identity
import require" and be happy with a "@require" decorator. You can even alias
it to something else if you want.
> 2. idenntity.require and identity.in_group owned total different dutys
? I didn't get it... Let me see the examples later...
> 3. "validate" and "validator" looked too similar and was easy to be
> confused.
This isn't common usage if you're using widgets and forms. You'd either use a
schema ("@validate(schema=MySchema)") or the form itself
("@validate(form=my_form)"). Specifying individual validators is possible and
allows for a fast validation if you have just some few fields...
> Here is My thought of those questions:
>
> identity:
> We may omit the "require" and do what we intended to do :
> @identity.in_group("admin")
> (con: performance)
(And namespace pollution since you're pulling all this from require's
namespace into identity's. Everywhere you just imported identity. I don't
have a ratio of how many useful things without handling authorization you can
do with just the authentication part (one that comes to my mind is some kind
of bookkeeping where you just log the responsible for something, but everybody
can do that thing, another is using class authorization through SecureResource
(or something like that) as one of the base classes for your classes).
> or Maybe we can seperate their namespace :
> @identity(auth.in_group("admin"))
> (con: leads to import scary size of libs)
If typing is the problem I still prefer:
- creating a custom decorator and standardizing some interface with it
(e.g. by specifying some default naming for my methods and allowing the
decorator to receive some parameters to override that)
- importing "require" explicitly
> validate:
> People had some discussion about renaming the namespace
> @validate(schema={"number": schema.Int(), "name": schema.String()})
This would break compatibility with FormEncode, wouldn't it? It would create
a new barrier for newcomers already used to that technology. Besides, it
would render a lot of FormEncode's recipes and docs around the net useless to
our syntax.
> Some coin about @error_handler and @exception_handler,
>
> I think one of TurboGears advantage is hide the lower infrastructure
> from developers,
> but @xxx_handler let me feel "low" and changed my mind flow.
>
> 4. @error and @exception make sense for me and fit the decorators
> naming consistency.
I don't have any objection here since it fits my brain equally well:
"who'll handle the error/exception on the form is ..."
or
"errors/exceptions will be redirected(?)/handled(?)/taken care of(?) by ..."
(Hmm... Writing the above makes me like the "_handle" there since it makes it
an easier association with the meaning of the thing...)
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~----------~----~----~----~------~----~------~--~---
