Jeff Watkins wrote:
On 21 Jan, 2006, at 6:03 am, Simon Belak wrote:
Can I just sneak some generic functions into Identity than? ;)
I have no problem with adding generic functions to Identity if generic
functions solve a problem that can't be solved any other way.
"Any other way"? Isn't this a bit drastic? The way I see it these 5
lines of code allow for multiple features which you say you are going to
implement along with a whole class of other possibilities.
There's no need to call this from the require decorator. It doesn't need
any more flexibility than it already has. I don't find myself saying:
"Gosh, I wish I could do XYZ in the require decorator, but I have no
idea how without a generic failure function."
Well I do. I like to separate functionalities. Handling security within
the controller deludes and is more error-prone. Not to mention, it is
not optimal approach when spreading development among a team.
Again, it's not about the generic functions (my remark was, obviously
poor, attempt at a joke), if you have a better (in terms of flexibility
versus bloatware) solution, I will gladly use that.
>> 1) Contextual redirection
>
> Try raising turbogears.redirect instead. That's what it's for, I
> think.
> Or if you need to redirect based on a specific set of errors, you
> should
> try specifying a callable for your identity-failure-url (soon to be
> committed).
If I understand correctly, this requires checking for permissions
"manually" from within the controller (or some such)?
3) Additional error handling
For example properly ending a transaction, saving input of a
multi-page form, etc.
This is a general issue which shouldn't be solved in the Identity or
Visit Tracking framework. Why would you have an authorisation failure in
the MIDDLE of a multi-page form? This sounds more like a
programmer-didn't-think-things-through-completely problem than anything
with Identity.
Perhaps it is just a design mistake, but take trac for instance. On
every page you have a "login" link. Yes it's dumb to try to login in the
middle of something, especially if one forgot one's password, but such
things do happen, especially in intranet applications. Sure, the
programmer could hide all inappropriate buttons etc., but than again
wouldn't it be even more prudent to select a tool where he didn't have to?
So far no one has "stood up" and said: "I need to be able to X and I
just can't without generic functions." And my experience managing
software projects leads me to shy away from features that don't solve a
problem.
I am a bit confused. Didn't you just said that you will (or have)
implement 2 out of 3 of my feature requests? I am most certainly flatter
if it is just for me. ;)
Simon
