On 3/13/06, Adrian Holovaty <[EMAIL PROTECTED]
> wrote:
Thoughts, criticisms? The only part I'm sketchy on is the side effectof converting the values to their Python data types. Thecleanliness/consistency is quite nice, but it's slightly not somethinga developer might expect. However, we can solve
Gary Wilson wrote:
> I think it would be nice to have the authentication backend
> configurable per app instead of project-wide. This way, I could use an
> LDAP backend for the app that my users use, and use the builtin backend
> for the admin app.
I continue to use the example of OpenID authent
I think it would be nice to have the authentication backend
configurable per app instead of project-wide. This way, I could use an
LDAP backend for the app that my users use, and use the builtin backend
for the admin app.
--~--~-~--~~~---~--~~
You received this m
Joseph Kocherhans wrote:
> On 3/14/06, Max Battcher <[EMAIL PROTECTED]> wrote:
>> -1. I don't want to add layer after layer of code to my views to
>> support whatever authentication backends I feel necessary.
>
> You don't have to. There is "one true way" to access authentication
> regardless of
Max Battcher wrote:
> Authentication/Authorization really doesn't belong in every view. That
> way leads to bad coupling and lots of repetition.
please note, that even with the current auth-system, you have to handle
it in every view.
gabor
--~--~-~--~~~---~--~---
On 3/14/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> On 3/13/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> > Maybe implement generic support for /* .. */ in template tags?
> A definite no on that one -- it's too programmerish.
hugo wrote:
> >{% endif %}{# endif start_process #}
>
> Ug
I like the idea of shorter comment syntax. The current way is just too
ugly and inhibiting.
{! Comment !} -- Similar to HTML comment.
{# Comment #} -- Similar to Python comment.
Since Django templates use Python-ish language in the {}'s, I say {# #}
is better.
I see a striking resemblance...
On 3/14/06, Max Battcher <[EMAIL PROTECTED]> wrote:
>
> -1. I don't want to add layer after layer of code to my views to
> support whatever authentication backends I feel necessary.
You don't have to. There is "one true way" to access authentication
regardless of the backend. The specific backen
Joseph Kocherhans wrote:
> I've rethought how to implement multiple authentication backends,
> updated the wiki and posted a new patch. This should be a lot simpler
> than the previous attempt. Please check it out, and post your comments
> to the list rather than the wiki. Also, question for Jacob
I've rethought how to implement multiple authentication backends,
updated the wiki and posted a new patch. This should be a lot simpler
than the previous attempt. Please check it out, and post your comments
to the list rather than the wiki. Also, question for Jacob/Adrian, is
an ldap backend somet
On 3/14/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> This is based on a simplistic assumption that everytime we are talking about
> validation in django context we are talking about model based validation.
No, it's based on an assumption that the facilities for doing custom
validation that curr
On 3/13/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
>
> Am 13.03.2006 um 08:00 schrieb Adrian Holovaty:
> [snip]
> > Thoughts, criticisms? The only part I'm sketchy on is the side effect
> > of converting the values to their Python data types. The
> > cleanliness/consistency is quite nice, but
On 3/14/06, hugo <[EMAIL PROTECTED]> wrote:
>
> >{% endif %}{# endif start_process #}
>
> Ugh, no. Sorry, but I am definitely -1 on this.
>
> If we want something useful, go for the {% if something %} ... {% endif
> something %} where the "something" on the endif is optional and if it
> is given,
>{% endif %}{# endif start_process #}
Ugh, no. Sorry, but I am definitely -1 on this.
If we want something useful, go for the {% if something %} ... {% endif
something %} where the "something" on the endif is optional and if it
is given, must match the corresponding if. Everything else is just
s
On 3/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
* It's conceptually simpler; instead of worrying about whichvalidation layer you got down to before an error occurred, you onlyhave to worry about two states: success and failure.* It's more logical; I still don't see any good reason why informat
Gábor Farkas wrote:
>or have a new constructor, that takes a dictionary of strings:
>
>def myview(request):
> try:
> m = MyModel( request.POSTDATA)
> m.save()
> except SomethingFailedError:
> //handle it
>
>
I also proposed something like th
16 matches
Mail list logo
