Hi,
I was wondering if there is a particular reason why the current value
of a `named` cycle is not exported into the context so that it is
accessable later in the tamplate as variable as well?
Fore example:
{% for obj in object_list %}
[]
{% if obj.need_second_row %}
[
I agree that there is no one model that fits everyone's needs.
Instead, I think it would be nice if the user model to use could be
configurable. The admin application currently expects auth User
objects, when it should instead expect an object that conforms to an
interface, similar to the changes
On 9/10/06, patrickk <[EMAIL PROTECTED]> wrote:
> in my view, anything that´s not needed for user-authentication
> belongs to a user-profile. for me (and I may be wrong here) a user-
> profile is for personal information (like first name, last name,
> address and what have you).
As I see it, pari
I totally agree with what you say - and (if I understand you right)
that´s exactly my point.
it seems like a compromise. we don´t need first_name, last_name and
email for user-authentication. it´s just there because of an
assumption what users might need (or not).
some notes below:
Am 10.
On 9/10/06, patrickk <[EMAIL PROTECTED]> wrote:
> 1. why are these personal values (first name, last name, email) there
> in the first place? did I miss something?
The User model is not meant to be an exact match for the needs of 100%
of all possible authentication use cases; instead it's meant t
while playing with the authentication system, I don´t really get the
pre-defined model.
we have first_name, last_name and email in there - these values are
optional and we don´t need them for authentication. when I extend the
user-model with a user-profile I´m having (profile) values in 2
