What do you think about adding a ValidationError similar to
CriticalValidationError but one that would stop further evaluation of
_all_ validators in the manipulator instead of just the remaining
validators for the current form field being processed?
For example, I have a simple login form with u
Bill de hÓra wrote:
> Gary Wilson wrote:
> > What do you think about adding a ValidationError similar to
> > CriticalValidationError but one that would stop further evaluation of
> > _all_ validators in the manipulator instead of just the remaining
> > validators for t
While dealing with http://code.djangoproject.com/ticket/2127, I
realized that unless your decorator takes the same number of arguments
as the filter function, it will fail since
FilterExpression.args_check() (in django/template/__init__.py) is using
inspect.getargspec() to count the number of requ
Simon Willison wrote:
> On 10 Jun 2006, at 07:39, Malcolm Tredinnick wrote:
>
> > What's our policy on template filters failing? If applying a filter
> > raises an error, should we just trap it and return the empty
> > string, or
> > raise an error? I can't find this written down anywhere, but may
FYI, here is a previous django-dev discussion
Failing silently, and documentation thereof
http://groups.google.com/group/django-developers/browse_thread/thread/40adac6370fc195c/b1656b8e0c036c04
--~--~-~--~~~---~--~~
You received this message because you are subsc
gabor wrote:
> is it true, that people usually forget to escape dangerous variables?
>
>
> a) if no (people do not forget):
> means people are already using 'escape' when needed. in this case, this
> block-level tag is a welcome addition, because it makes it
> simpler/more-convenient to toggle esc
Russell Keith-Magee wrote:
> I've just committed r3246 which implements the change.
Thanks Russell. This is certainly more natural.
This really should be added to the model api documentation too.
--~--~-~--~~~---~--~~
You received this message because you are su
Gary Wilson wrote:
> This really should be added to the model api documentation too.
db api rather.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group,
Proposing an is_loggedin method for User and AnonymousUser models.
Templates treat non-existing variables as False; therefore; a
request.user somehow failing to get assigned would result in the
template treating the user as they are authenticated (is_anonymous
evaluates False). An is_loggedin wo
déjà vu
http://groups.google.com/group/django-developers/browse_thread/thread/2cc178fe7c8c9046/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django
Thinking of this some more, I'm wondering about the names is_logged_in
or is_authenticated. They could be a little misleading since they
aren't really checking if the user is logged in or not. One might be
led to believe that they could do something like logged_in_users =
[user.is_logged_in() fo
So I've got a model resembling:
==
from django.contrib.auth.models import User
class ExtendedUser(models.Model):
user = models.OneToOneField(User)
class Admin:
list_display = ('user',)
search_fields = ('user',)
==
The admin has a user column but it is so
Jay Parlar wrote:
> You can use functions inside list_display:
>
> class Admin:
> list_display = ('get_last_name',)
>
> def get_last_name(self):
> return self.user.last_name
> get_last_name.short_description = "Last Name"
But you can't sort or seach it.
--~--~---
What if we instead make it so that context_processor.auth only sets the
"user" template variable if request.user is not an AnonymousUser
instance and then in templates you would use
{% if user %}
I am logged in.
{% endif %}
to determine if the user is logged in. If the user is not logged in,
th
Luke Plant wrote:
> On Wednesday 12 July 2006 21:27, Gary Wilson wrote:
> > Jay Parlar wrote:
> > > You can use functions inside list_display:
> > >
> > > class Admin:
> > > list_display = ('get_last_name',)
> &
Luke Plant wrote:
> In that particular case, yes (and in this instance it might be possible
> to implement what you want be writing a custom manager and overriding
> get_query_set() so that it adds a join and custom ordering), but there
> is no (feasible) way of introspecting get_last_name() and w
SmileyChris wrote:
> I think we still need the AnonymousUser and from the number of
> references to is_anonymous in python modules I think we still need a
> negation of it.
Yes I think AnonymousUser is still helpful in python code, and yes I
think we should deprecate is_anonymous before removing
Malcolm Tredinnick wrote:
> Is there any alternative to creating an escaped_unordered_list tag? (Any
> better name for this tag? It's too long)
How about {{ obj_bag|unordered_list:"escape" }} ?
--~--~-~--~~~---~--~~
You received this message because you are subs
I think I will first attempt to allow order_by to accept related
objects, like order_by('user__last_name'). Could someone please point
me in the right direction? I am not too familiar with django's db
code. What all would need changing?
--~--~-~--~~~---~--~~
Yo
And so are we keeping is_anonymous or deprecating it? I guess it would
still be useful for determining whether on not your object is an
AnonymousUser instance, which seems to be it's original intent. We can
keep it and just change the docs to use is_authenticated.
--~--~-~--~~-
Has anyone seen/tried the Akismet spam filtering plugin for Trac:
http://trac.edgewall.org/wiki/SpamFilter#Akismet
Would be nice for Django's trac.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers
> """
> 2006-07-17 17:13:08,419 Trac[__init__] WARNING: 500 Internal Error
> (Akismet rejected spam)
> """
>
> Seems to be working.
Good to hear.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers"
Patch for is_authenticated implementation with doc changes and no
deprecation warnings in is_anonymous. Please review.
http://code.djangoproject.com/attachment/ticket/2332/is_authenticated.2.diff
--~--~-~--~~~---~--~~
You received this message because you are su
I never really liked how the templating system leaves all those
newlines. This middleware is cool, but it would really be nice if the
templating system could collapse the lines that only contain one or
more evaluating-to-nothing template tags.
Thoughts on a possible implementation:
What if an e
Malcolm Tredinnick wrote:
> On Tue, 2006-08-01 at 22:53 -0700, Gary Wilson wrote:
> > I never really liked how the templating system leaves all those
> > newlines. This middleware is cool, but it would really be nice if the
> > templating system could collapse the lines tha
Just thought I might share a size converter I wrote a while back...
def bytesToHumanReadable(bytes, binary=True, precision=1):
"""Convert bytes to a human-readable size.
Given a size in bytes, this function converts it and uses the
largest
suffix possible that does not result in a siz
Malcolm Tredinnick wrote:
> That was where I was coming from, too.
Oh yeah, I meant to ask you more about the implementation you have. Is
it functional?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django deve
does matter. Or maybe instead you
specify all the middleware classes to be used in the app and don't do
any inserting into the project's middleware classes.
Sorry if the above isn't very coherent. It's late and I was just
trying to throw s
Adrian Holovaty wrote:
> Oooh, that's a nice idea. I'm not 100% certain "flat=True" is the best
> name for it, but I can't think of anything better at the moment. Would
> you be willing to submit a patch?
Maybe .flatvalues("id", "name") or .valuelist("id", "name") ?
--~--~-~--~~
e applications to make this
> automatically! (I'm +1)
>
> Michael
+1 for periodic job running abilities
Yes, let's move towards more modular applications, please. Session
clean up should be, gasp, in the session application.
Django should be making my serv
e options like
LDAP_SERVICE_BIND_DN
LDAP_SERVICE_BIND_PASSWORD
and then an additional check in authenticate() (after the call to
initialize() and before the bind with the user's DN and password) to
see if first a bind should be attempted with the service account DN and
password.
Gary Wilson
--
een a handful of LDAP implementations, and this is new
> to me.
Not sure how common it is, as this is the only ldap setup I have worked
with. The directory has controlled access via issued service accounts,
in addition to user accounts. The service accounts
So, the mutli authentication seems to work well for the use case of a
site accepting more than one authentication source to access some area,
but not so well for the use case of a site accepting one source of
authentication in one area and another source of authentication in a
different area.
The
the patch, but I hope to try it out later this week
at work.
Gary Wilson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googl
Malcolm Tredinnick wrote:
> One point of view (mine!) is that if an application can't play nicely
> with other applications and wants to do its own authentication, etc,
> then it's not an application, it's a whole other project. The project
> developer should have complete control over what the po
Tim Keating wrote:
> I agree. It seems to me people either care about this or they don't.
> Ergo the Django way to do this would be to make the whitespace handler
> pluggable and set it globally in settings.py.
If performance does not suffer, I'm with Malcolm that it should simply
be done by defa
James Bennett wrote:
> On 8/13/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > The Lawrence guys have mentioned on this list previously that they have
> > many different applications they pull together in various projects.
>
> :)
>
> If we couldn't modularize, we wouldn't be able to sell dif
James Bennett wrote:
> The more I think about it, the more I like the idea of using imports
> in __init__.py to specify an application's dependencies; the thing
> that'd make it especially nice would be some method -- either
> conventional or built straight in to Django -- of checking for
> "impor
James Bennett wrote:
> The new and improved model inheritance that Malcolm is working on will
> also provide a facility for abstract "base" classes, so I'm thinking
> this would probably be redundant; there's also been discussion on this
> list of how the syntax should work, and IIRC the consensus
James Bennett wrote:
> On 8/17/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> > IMO, the dependency checking is the easy part. In the README or
> > something, I say MyCoolApp requires the admin app. It's the
> > configuration settings of the admin app that'
limodou wrote:
> There are some threads talking about the apps repository already, but
> till now, no repository be found. So I want to suggest again: we
> should build an official project web site to host django apps or
> projects. So we can easy share our source code and exchange our ideas.
> An
I created a ticket:
http://code.djangoproject.com/ticket/2594
I also attached a patch that I have done a little testing with and
seems to work ok. I first attacked this at the Node level, but
realized that might not be the best way because the Nodes get rendered
recursively. In order to clean u
limodou wrote:
> I think if this functionality built on django official site is the
> better, because every djangor can easy find it. I think the first
> stage could be the index site supplied by django site, and the exact
> projects could be found everywhere. And the second stage could be
> hosti
Ian Holsman wrote:
> luckily? for me I have a bit of time on my hands tomorrow and
> possibly monday.
> i could get a start on something 'forgish' which could then be used
> to critique/improve on.
Ian, does this mean you are working on a DjangoForge written in Django?
--~--~-~--~~-
One of the cool things about the admin app is the form building,
something that I wish were easier. Stuff like the AdminBoundField
would be nice to have outside of the admin (I don't know, is this
already easy to do?). I am assuming that the admin app will be
rewritten with the arrival of the ne
So I hit another little snag today related to this. The
contrib.auth.middleware.LazyUser calls contrib.auth.get_user (knowing
where to get the user from based on the backend stored in
session['_auth_user_backend']), which will return an
authentication-backend-dependent user object. This user obj
Jeremy Dunck wrote:
> On 8/31/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> > I mean when you're creating a manipulator you can list fields that you
> > don't want it to touch:
> >
> > manipulator = Owner.AddManipulator(follow={'thing': False})
>
> Thanks; I don't see that documented. Proba
Adrian Holovaty wrote:
> Thanks for bringing this up, Gary. The get_and_delete_messages() thing
> has always bothered me -- if it's activated, we do it for every
> request. I suppose we could make the 'messages' part of the context
> processor lazy, so that it would only call get_and_delete_messag
Jacob Kaplan-Moss wrote:
> On Aug 25, 2006, at 7:04 AM, DavidA wrote:
> > One comment on ValidationErrors: When I've done these types of things
> > in the past, I've typically returned two levels of validations
> > messages: warnings and errors. An error indicates that the attempted
> > save will
Just seems a bit silly to me.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send e
After noticing the new NullBooleanField, I am thinking it would be nice
to have the same sort of yes/no dropdown option for BooleanField
(without the "unknown" choice of course). What do you think?
--~--~-~--~~~---~--~~
You received this message because you are s
Adrian Holovaty wrote:
> I'm -0 on having BooleanFields use a drop down in the admin interface.
> Radio buttons are so much more usable, if you only have two choices.
> If anything, we should change NullBooleanFields to use radio buttons.
That would be fine too.
--~--~-~--~~
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
Chris Long wrote:
> The generic auth branch should allow you to create your own custom
> permission checking system easily.
Well, I'm fine with the system that's already there (or the system that
generic auth will be replacing it with). Are you guys also planning on
removing the admin applicatio
using the example model:
class Name(models.Model):
name = models.CharField(maxlength=100)
when making a new Name object...
>>> a=Name()
>>> a.save()
>>> a
>>> a.name
''
The name field does not have blank=True or null=True set, but yet I am
able to create a new Name object using no paramete
Other open source projects seem to have success with Bug Days. Anyone
have experiences with bug days?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
gabor wrote:
> yes, (unfortunately) it is.
>
> the models do not validate their input.
>
> you will have to use a manipulator (Name.AddManipulator) to validate
> your input (and then save the object).
>
> making the models validation-aware is planned, but not done yet.
But I am not talking about
JP wrote:
> What if widgets could act as filters? I think using filter syntax for
> setting the widget for a field in the template would be pretty
> natural::
>
> {{ form.field }}
>
> draws the default widget for the field type, but if you want to use
> SomeOtherWidget, you can do::
>
> {{ fo
Don Arbow wrote:
> Yes, from the documentation:
>
> http://www.djangoproject.com/documentation/model_api/#null
>
> "Note that empty string values will always get stored as empty
> strings, not as NULL -- so use null=True for non-string fields such
> as integers, booleans and dates.
>
> Avoid using
Brantley Harris wrote:
> > Another thing to note: In the current Manipulator framework, sometimes
> > it is convenient to be able to construct self.fields dynamically. We
> > should provide a way to do that with the new syntax.
>
> +1
+1
Being able to contruct fields dynamically would be great.
David and I have both introduced use cases where defaulting to empty
string have caused problems. What are some use cases where an empty
string would need to be used instead of NULL?
IMO, all FormFields should act the same and default to NULL. If you
want the database field to default to someth
Just FYI, I have noticed that when I try to alter tickets and leave
the "anonymous" default for email address, there is a high probability
that Akismet will reject it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Malcolm Tredinnick wrote:
> Think about how the data is entered: through a web form (the admin
> interface, or a custom form). Now, how do you differentiate between an
> explicit empty string and a "no data entered and so it should be NULL"
> field? With web entry, you can't, so Django chooses to
Linicks wrote:
> I have been having issues with Akismet as well. I have submitted a
> ticket(http://code.djangoproject.com/ticket/2801), so hopefully someone
> will have a chance to look at this issue. Akismet has been blocking my
> Wiki updates, but allowed me to submit a ticked without any iss
Carl Wenrich wrote:
> I need one that shows the month where you can click on a day and be shown
> time slots that you can reserve. I'll probably have to do it in JavaScript,
> but I was hoping that something like that was already out there.
You might want to ask this in the "django users" gr
The ticket_show_details option [1] adds the ability for users to view
ticket detail changes in the timeline view. I think this would be nice
to have.
[1] http://trac.edgewall.org/wiki/TracIni#timeline-section
--~--~-~--~~~---~--~~
You received this message becau
James Bennett wrote:
> My personal preference would be to specify an interface that comments
> have to implement, and then let the actual model be whatever the
> developer wants; maybe a subclass of django.contib.models.Comment,
> maybe not. That feels like it'd give the maximum flexibility, and a
I think you raise a valid point. There are valid use cases for both
methods.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@google
Graham King wrote:
> Does this sound sane ? If so I will submit a proper patch.
I don't think anyone would turn down the submitting of a patch. I
would suggest at least opening a ticket.
--~--~-~--~~~---~--~~
You received this message because you are subscrib
> No, I think you're right that we should have a mechanism in place for
> ensuring that methods like this always return results of a consistent
> type. I'm not sure whether it'd be better to do two methods or to
> return singleton tuples, though; anybody got thoughts one way or
> another?
Well, a
[EMAIL PROTECTED] wrote:
> I want to create a bunch of Session Attributes during login. Mostly
> attrs from Active Directory that need to be available without too many
> additional calls to the LDAP server.
>
> User attempts log in -> 3rd party login backend is called -> session is
> also passed t
Michael Radziej wrote:
> Hi,
>
> there's a ticket (#3005) that fixes bad documentation about writing
> forms. It's been closed as wontfix because newforms are coming (and then
> re-opened by the reporter).
Just for clarification, I re-opened #3005 but I wasn't the reporter. I
was, however, the r
Curious, does the new testing setup contain any mechanism for running
tests for my own applications, say in a package /tests instead
of in modeltests/ or regressiontests/ ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google G
Is there a reason why the capfirst and title template filters don't
simply use the capitalize() and title() str methods?
The difference with capfirst is that it capitalizes the first character
without touching the others
>>> Template("{{ name|capfirst }}").render(Context({"name": "DOLORES"}))
'DO
Gary Wilson wrote:
> So why the special cases? Should we keep the filters consistent with
> their str methods?
> title -> str.title()
I did realize an example where the title filter's implementation would
be desired. When you've got a possessive noun:
>>> Temp
Waylan Limberg wrote:
> On 11/16/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> > I did realize an example where the title filter's implementation would
> > be desired. When you've got a possessive noun:
> >
> > >>> Template("{{ text|title
> The current filters work for me as they are, and I can see how changing
> them may cause problems for me (capfirst will not convert an acronym
> like NASA to lower case, whereas capitalize will).
Yes, I think will all of these that it depends on the data you have to
start with. If you have acr
On 11/17/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> someone recently complained that str.title() wasn't quite as clever as
> text|title
> over at comp.lang.python, so I assume that whatever you do, someone will
> think it's doing the wrong thing.
And that is sort of my point. Is it confusin
[EMAIL PROTECTED] wrote:
> I'm porting another application over to django...while the admin tools
> built into django will be nice for some of my tables... I'd prefer to
> stick with my old User/Groups/Permissions for a lot of it ... as we
> have different users that will be logging in to do diffe
Adrian Holovaty wrote:
> On 12/8/06, Gary Doades <[EMAIL PROTECTED]> wrote:
> > Also, how can I pass a validator_list to get similar functionality to
> > manipulators? Having the ability to supply a validator_list containing
> > a list of small single purpose validators is quite nice. Have I misse
Lachlan Cannon wrote:
> Lakin Wecker wrote:
> > as_dl() gets a +1 from me. I've used definition lists for forms and
> > prefer it over tables. :)
>
> Maybe there needs to be an easy hook for people to specify their own way of
> laying a form out. It seems the as_ methods are gonna keep growing an
Gary Wilson wrote:
> I am also a fan of validator_list. As someone mentioned earlier, it is
> sometimes preferable to have two levels of data validation, at the form
> level and the model level. I have several cases where I have multiple
> forms that save to the same model in some
graham_king wrote:
> If just one person could give it a test, I think there's a good case
> for integrating it into the trunk. It behaves like the previous version
> but runs faster and the sort works. Without this you can't actually use
> the filter interface on more than a few thousand entries.
Honza Král wrote:
> On 12/17/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Feel free to take
> > on any of the items mentioned in this e-mail, as long as we've all
> > agreed on the right way to solve the problems. Rewriting the
> > validators to Fields would be a much-welcomed contribution, t
Some more suggestions based on things that I have experienced while
recently making an application that required many forms based on
models:
- Ability to not display certain fields, mainly for when the value will
be post-filled in the view (i.e. the owner of an object being set to
the logged in u
Gary Wilson wrote:
> Some more suggestions based on things that I have experienced while
> recently making an application that required many forms based on
> models:
>
> - Ability to not display certain fields, mainly for when the value will
> be post-filled in the view (i.
Honza Král wrote:
> On 12/18/06, Gary Wilson <[EMAIL PROTECTED]> wrote:
> >
> > Honza Král wrote:
> > > On 12/17/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > > Feel free to take
> > > > on any of the items mentioned in this e-mail
I often find myself writing code like:
try:
user = User.objects.get(pk=user_id)
except User.DoesNotExist:
user = None
What do you think about adding a get_or_none QuerySet method?
def get_or_none(self, **kwargs):
try:
return self.get(**kwargs)
except self.model.DoesNotEx
FYI, I filed a ticket [1] about this same topic last week, but I was
asking for an extra block tag in the change_list template. I am
assuming that you are also putting the object_tool_links on the
change_list page?
Looking at my ticket again, I am thinking it would be better to put the
block tag
Gary Wilson wrote:
Looking at my ticket again, I am thinking it would be better to put the
block tag in the admin/base_site.html template, that way any other page
extending admin/base_site.html could add custom object tools instead of
just the change_list page.
I meant admin/base.html. Added
Patch and a few tests added. Can someone please review and test on
something other than postgres.
http://code.djangoproject.com/ticket/2473
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django
developers" grou
SmileyChris wrote:
On Dec 19, 11:08 am, "Waylan Limberg" <[EMAIL PROTECTED]> wrote:
> something like this:
>
> user = User.objects.get(pk=user_id, default=None)
Except this would break (or at least limit the functionality of)
objects which use "default" as a field name.
Of course, this didn't
Ville Säävuori wrote:
Replying to myself
> This would be great. But I think it would be better to name the
> templates __foo.html. It would make the customization of
> admin pages very easy and Django-like.
D'oh. After looking the admin source code, this allready works! I
wonder howcome it isn
Russell Keith-Magee wrote:
If you can get some confirmation that this approach works on other
backends, I'll put it in as an interim measure; and if nothing else,
the tests are most helpful - Thanks for those.
Installed mysql 5.0.26, and the tests passed.
--~--~-~--~~
Joseph Perla wrote:
There should also be an update_or_create() function. I often find myself
get_or_creating, then updating the object's dict if it wasnt just created,
then saving. This can easily be expressed more clearly in one line with
this function.
This gave me the idea of an update()
Joseph Perla wrote:
Also, here's the pseudo-ish code for it:
def update_or_create( --same arguments as get_or_create()-- ):
object, created = Class.objects.get_or_create( --args above-- )
if not created:
object.__dict__.update(defaults)
object.save()
return ob
[EMAIL PROTECTED] wrote:
But in fact it does not look user intuitive.
I concur with this statement. I've got a form with about 10 fields and
when there are multiple errors for adjacent fields, it's very hard to
tell if the error is for the field above or below.
The problem is visual. I do n
Gary Wilson wrote:
I have created a ticket for this too and have attached some code:
http://code.djangoproject.com/ticket/3182
Documentation and tests attached too now.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Jacob Kaplan-Moss wrote:
Hm - I get a whole bunch of failures when I apply the patch. Looking closer,
you say it depends on an ``update()`` patch in #3181, but I don't see any such
patch attached to #3181.
Sorry about that, it should be #3180.
Can you update #3182 to include this other patc
Jacob Kaplan-Moss wrote:
On 12/24/06 11:15 PM, Gary Wilson wrote:
> Well, the two tickets are different functionality. I could create a
> single patch for both, the only thing was that in the patch for #3180 I
> added an "Updating objects" to the db api documentation, but t
1 - 100 of 286 matches
Mail list logo
