Exposing DeclarativeFieldsMetaclass
Hi, I've written a library on top of django.form that adds support for highly dynamic forms, including removing and adding inline forms after page load-time. To do so, I subclassed forms.BaseForm and added the needed functionality to it. My problem is ,that I'd like to support the same declarative syntax as forms via Form and DeclarativeFieldsMetaclass. However, only BaseForm and Form are exposed from the forms module and I can't use DeclarativeFieldsMetaclass in my application. Would it be possible to change this? The same applies to BoundField. It's also hidden inside the module. Regards, Marco This message was sent using IMP, the Internet Messaging Program. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Ability to delete contents of FileField and ImageField in admin
Hi, I notice some discussion about this from a while back but as far as I can tell it has all gone quiet. This may be because it has been fixed, or possibly because it has been forgotten about. Can anyone give me a status update of whether or not it is possible to delete the contents of a FileField or ImageField from within the admin? Thanks, David -- David Reynolds [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Localizing digits
Hi all, A Farsi-localized Django site I'm working on will need Farsi digits, so I'm looking for a solution for replacing digits with their localized counterparts. The GNU gettext has support for localized digits using the 'I' flag on numerical format variables, e.g. "%Id". Unfortunately this works only for glibc, and then even not in Python. Furthermore, all template translations are based on string. As a starting point I created a template filter that does the replacing [1] (only for Arabic and Farsi at the moment), and now I'm looking for the correct place to integrate localized digits into the Django translation system. I thought the best place to integrate such a function would be django.utils.translation.trans_real.py in function ugettext (because localized digits will always be in unicode). Also, localized dates would need to pass the replacement function. I'm also not sure were the digits would be stored: django.utils.translation? django.contrib.localflavor? Would this be the correct way to go about it? Regards, Joost [1] http://www.djangosnippets.org/snippets/980/ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Exposing DeclarativeFieldsMetaclass
On Mon, Aug 18, 2008 at 2:45 PM, <[EMAIL PROTECTED]> wrote: > > Hi, > > I've written a library on top of django.form that adds support for > highly dynamic forms, including removing and adding inline forms after > page load-time. To do so, I subclassed forms.BaseForm and added the > needed functionality to it. My problem is ,that I'd like to support > the same declarative syntax as forms via Form and > DeclarativeFieldsMetaclass. However, only BaseForm and Form are > exposed from the forms module and I can't use > DeclarativeFieldsMetaclass in my application. Would it be possible to > change this? The same applies to BoundField. It's also hidden inside > the module. Huh? $ ipython In [1]: from django.newforms.forms import DeclarativeFieldsMetaclass In [2]: DeclarativeFieldsMetaclass? Type: type Base Class: String Form: Namespace: Interactive File: /home/users/patrys/Desktop/web/django/newforms/forms.py Docstring: Metaclass that converts Field attributes to a dictionary called 'base_fields', taking into account parent class 'base_fields' as well. In [3]: from django.newforms.forms import BoundField In [4]: BoundField? Type: type Base Class: String Form: Namespace: Interactive File: /home/users/patrys/Desktop/web/django/newforms/forms.py Docstring: A Field plus data Constructor information: Definition: BoundField(self, form, field, name) -- Patryk Zawadzki --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ability to delete contents of FileField and ImageField in admin
On Mon, Aug 18, 2008 at 7:30 AM, David Reynolds <[EMAIL PROTECTED]> wrote: > I notice some discussion about this from a while back but as far as I > can tell it has all gone quiet. This may be because it has been > fixed, or possibly because it has been forgotten about. Can anyone > give me a status update of whether or not it is possible to delete > the contents of a FileField or ImageField from within the admin? Keep an eye on http://code.djangoproject.com/ticket/7048. -- Brian Rosner http://oebfare.com --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Exposing DeclarativeFieldsMetaclass
OK, thanks. I'm pretty new to python. So I was not completely familiar with the meaning of __all__. Thanks for clarifying. On Aug 18, 2008, at 3:51 PM, Patryk Zawadzki wrote: > > On Mon, Aug 18, 2008 at 2:45 PM, <[EMAIL PROTECTED]> > wrote: >> >> Hi, >> >> I've written a library on top of django.form that adds support for >> highly dynamic forms, including removing and adding inline forms >> after >> page load-time. To do so, I subclassed forms.BaseForm and added the >> needed functionality to it. My problem is ,that I'd like to support >> the same declarative syntax as forms via Form and >> DeclarativeFieldsMetaclass. However, only BaseForm and Form are >> exposed from the forms module and I can't use >> DeclarativeFieldsMetaclass in my application. Would it be possible to >> change this? The same applies to BoundField. It's also hidden inside >> the module. > > Huh? > > $ ipython > > In [1]: from django.newforms.forms import DeclarativeFieldsMetaclass > > In [2]: DeclarativeFieldsMetaclass? > Type: type > Base Class: > String Form: 'django.newforms.forms.DeclarativeFieldsMetaclass'> > Namespace:Interactive > File: /home/users/patrys/Desktop/web/django/newforms/forms.py > Docstring: > Metaclass that converts Field attributes to a dictionary called > 'base_fields', taking into account parent class 'base_fields' > as well. > > In [3]: from django.newforms.forms import BoundField > > In [4]: BoundField? > Type: type > Base Class: > String Form: > Namespace:Interactive > File: /home/users/patrys/Desktop/web/django/newforms/forms.py > Docstring: > A Field plus data > > Constructor information: > Definition: BoundField(self, form, field, name) > > -- > Patryk Zawadzki > > > -~--~--~--~~---~--~--~--~-~~--~--~--~- Marco Biasini M.E. Mueller Institute for Structural Biology Biozentrum of the University of Basel Klingelbergstrasse 50-70 CH-4056 Basel --~--~--~--~-~~--~--~--~--~--~--~--~~- --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Ability to delete contents of FileField and ImageField in admin
On 18 Aug 2008, at 2:56 pm, Brian Rosner wrote: > Keep an eye on http://code.djangoproject.com/ticket/7048. Thanks, Brian. -- David Reynolds [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Localizing digits
Hi Joost, On Mon, 2008-08-18 at 06:48 -0700, Joost Cassee wrote: [...] > As a starting point I created a template filter that does the > replacing [1] (only for Arabic and Farsi at the moment), and now I'm > looking for the correct place to integrate localized digits into the > Django translation system. I thought the best place to integrate such > a function would be django.utils.translation.trans_real.py in function > ugettext (because localized digits will always be in unicode). Also, > localized dates would need to pass the replacement function. I'm also > not sure were the digits would be stored: django.utils.translation? > django.contrib.localflavor? Any time you feel the need to patch core, it's a warning sign that some real design work is needed. The first thing to consider here is whether these digits need to go anywhere at all or if there's just going to be a correct answer all the time. By which I mean, it's not a style choice what the localised version of a Farsi digit is. There's a single right answer. So we treat it like dates, decimal separators, first day of the week, etc and include data as to what the local form is. If Django didn't have to support Windows, this would be relatively trivial, since the information already exists in POSIX locale files. That's a fantasy world, though. Post-1.0, we'll introduce something, most likely based on the Unicode Common Locale Data for each locale we support, but the exact details will wait until then, because we just have time right now. We also need to think through the consequence of always translating every number we output and what the performance will be like. It sounds like a *lot* of string manipulations, breaking every potential number up into digits and then recombining them, so this isn't a trivial issue. I can't imagine that if we add support for this, we're going to be able to get away with just "translating" some digits and not others unless we've thought through the issues very carefully to support our position, so, again, work is needed here. In short, right now, things like filters in your templates are the way to go and manage the source whatever works for you. Post-1.0, bring this up again when we start working on the UCLD (or similar) support. Ticket #7980 is probably an appropriate ticket to add your "cc" to if you want to be alerted when we start doing stuff and then help out. I really don't mean to put you off here. I definitely want help from people with experience in understanding these problems. But right now is a bad time for me and some other people to be doing any serious design thinking on this because it's hard and requires a lot of concentration to review proposals and all our spare time (and then some) is devoted towards getting 1.0 out in two weeks. Regards, Malcolm --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
You've broken Oracle
This is just a heads up since clearly some committers must be unaware: checkins of the last two days have created 27 (yes, twenty-seven) new test case failures for Oracle. I had been working on cleaning up the existing few failures for the Oracle backend, but unless those who actually committed the weekend's changes are able to look at this, Oracle should not be included in the 1.0 release IMHO. I realize running all the backends (and all three pythons) to check for regression failures before committing code is onerous. However, that's what I do, and now I'm reminded why. It's not enough to see that the code runs on sqlite or postgres and call it a day. Here is Leo Soto's buildbot, so you can see what I'm talking about: http://certenium.ingenium.cl:8080/hudson/job/django-trunk/ I'll do my best to fix some of these as time permits, but I'm hoping others will pull together to rectify this quickly. Thanks! --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: You've broken Oracle
On Mon, 2008-08-18 at 12:04 -0700, Matt Boersma wrote:
> This is just a heads up since clearly some committers must be unaware:
> checkins of the last two days have created 27 (yes, twenty-seven) new
> test case failures for Oracle. I had been working on cleaning up the
> existing few failures for the Oracle backend, but unless those who
> actually committed the weekend's changes are able to look at this,
> Oracle should not be included in the 1.0 release IMHO.
I'm always happy to look at problems, but some specific details are
required, for the reasons described below.
> I realize running all the backends (and all three pythons) to check
> for regression failures before committing code is onerous.
No, it's actually impossible, not merely difficult. I simply don't have
the disk space or the CPU resources to run Oracle on my laptop. My
recollection is that even when I had access to a 64-bit 2 GHz desktop
machine, it still took over an hour to run all the tests even if I did
nothing else on the machine.
Leo's buildbot has only been available for a few days now and I did
actually try to check it a couple of times over the weekend and it timed
out on a number of ocassions (I managed to get through just now, but it
took a while). To utilise a buildbot we do have to commit first,
obviously.
> However,
> that's what I do, and now I'm reminded why. It's not enough to see
> that the code runs on sqlite or postgres and call it a day.
However, we do rely a lot on the Oracle backend maintainers to also help
us out here. That's why commit messages often include quite a bit of
detail. I'm obviously responsible for a number of the internal changes
and whilst I try very, very hard not to break stuff and be clear about
what's going, sometimes breakages happen.
Some of the differences are because Oracle does do some extra query
munging, so it sometimes takes a day or two until it becomes clear that
breakages are happening. Leo's buildbot has only just become available
and is a bit slow to respond to requests (i.e. timed out over the
weekend). Every resource is obviously a benefit here, but we do have to
commit before we can see failures.
So, I definitely apologise for any inadvertent hardship caused here. I
fully appreciate that we're all volunteers. If you could work with us on
this as the backend maintainer there, it would be helpful. I'm obviously
not intending to break the Oracle build, but I'm also not in a position
to do more than document cleanly what's going, try to be pre-emptively
careful and answer questions about specific quickly.
Perhaps some actual specific questions instead of mail titled "You've
broken Oracle" would be more useful to all of us. I'm quite happy to
explain the motivation and necessities behind a bunch of the changes and
work out better ways to do things once I know what the problem is ("it's
broken" and even "the tests fail" is not a problem report; neither
includes enough information to debug the root cause).
I can probably guess, for example, that the select_related failures are
due to r8426, but I can't be sure without more information.
Regards,
Malcolm
--~--~-~--~~~---~--~~
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 email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: You've broken Oracle
Matt, On Mon, Aug 18, 2008 at 4:04 PM, Matt Boersma <[EMAIL PROTECTED]> wrote: > > Here is Leo Soto's buildbot, so you can see what I'm talking about: > http://certenium.ingenium.cl:8080/hudson/job/django-trunk/ > > I'll do my best to fix some of these as time permits, but I'm hoping > others will pull together to rectify this quickly. Thanks! Some of these failures might be related to the changes in the `extra_select` (and `extra_select_params` that got deleted) Query class attributes introduced in r8426 because, as you know, the Oracle backend (and the MS SQL Server backends) uses `extra_select` to insert a synthetic placeholder needed to use the ORDER_BY function to emulate LIMIT+OFFSET. FWIW, in my work on a MS SQL Server backed I circumvented the bulk of the problem by accident (actually, because this is one of the things that allowed me to get a whole bunch of the Django test suite to start passing on SQL Server 2005 whose SQL dialect also has the ORDER_BY function) some time ago by migrating away from using `extra_select` to using the `ordering_aliases` attribute to handle the placeholder by appending to it: http://code.google.com/p/django-pyodbc/source/browse/branches/ramiro/django-sql-server/sql_server/pyodbc/query.py#163 Later on during the lifetime of the query, the `execute_sql()` Query method will take care of ignoring that alias. This also allowed me to do away with the `set_limits()` and `clear_limit()` custom Query class methods. I don't know if this is also possible for the Oracle backend, hopefully it is. HTH, -- Ramiro Morales --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: You've broken Oracle
On Mon, 2008-08-18 at 17:20 -0300, Ramiro Morales wrote: > Matt, > > On Mon, Aug 18, 2008 at 4:04 PM, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > > > Here is Leo Soto's buildbot, so you can see what I'm talking about: > > http://certenium.ingenium.cl:8080/hudson/job/django-trunk/ > > > > I'll do my best to fix some of these as time permits, but I'm hoping > > others will pull together to rectify this quickly. Thanks! > > Some of these failures might be related to the changes in the `extra_select` > (and `extra_select_params` that got deleted) Query class attributes introduced > in r8426 because, as you know, the Oracle backend (and the MS SQL Server > backends) uses `extra_select` to insert a synthetic placeholder needed to use > the ORDER_BY function to emulate LIMIT+OFFSET. > > FWIW, in my work on a MS SQL Server backed I circumvented the bulk of the > problem by accident (actually, because this is one of the things that allowed > me to get a whole bunch of the Django test suite to start passing on SQL > Server 2005 whose SQL dialect also has the ORDER_BY function) some time ago by > migrating away from using `extra_select` to using the `ordering_aliases` > attribute to handle the placeholder by appending to it: Is that robust enough for you? Would it be better/easier if the extra_select dictionary -- which right now stores (select-string, params) pairs -- was to also have a flag in there to say whether it was inserted by the main query or by the backend wrapping class? What I'm thinking about is something like making Query.add_extra() put in triples (select-string, params, 1), where "1" is the flag to say it is part of the main query. Then, if you need to add bonus stuff to handle the ordering, you can put in (select-string, params, 2), for example. That extra_select attribute is internal and we change it to accommodate that sort of situation if it makes things easier. I don't want to mess more than necessary with internal Query structures after 1.0, but I'm aware there is this need to write nested selects to get limit/offset equivalence in some backends (MS SQL, Oracle, etc), so if there's an alternate internal structure that helps there, please ask. The one approach I'd personally be a little resistant to is having another attribute just for the limit/offset extra columns, since that's special casing based on the requirements of one approach in backends (and, yes, we already special case with the standard LIMIT/OFFSET stuff, but I'd like to keep to a small number of special cases, if possible). But if that's really necessary, so be it. There are hooks already in place that are only used by one other thing right now, but can't be avoided, so it's not something I have moral objections to or anything like that. Regards, Malcolm --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #6845 - model validation DDN
Hi Honza, What's the story with this? Are you aiming for the 1.0 release? On Aug 12, 8:14 pm, "Honza Král" <[EMAIL PROTECTED]> wrote: > Hey all, > thanks for the feedback, I am still on vacation (haven't opened my > notebook for days, what a feeling ;) ). I will be back in a couple of > days and this thread is right at the top of my ToDo list. > > I plan to see this thing through unless somebody beats me to it or the > design decisions go exactly opposite to my ideas (unlikely, even after > reading this) and have set aside some time to do it next week. > > Thanks again for the feedback and patience... > > Honza Král > E-Mail: [EMAIL PROTECTED] > ICQ#: 107471613 > Phone: +420 606 678585 > > On Sat, Aug 9, 2008 at 01:40, Steve Holden <[EMAIL PROTECTED]> wrote: > > > Jacob Kaplan-Moss wrote: > >> On Fri, Aug 8, 2008 at 4:51 PM, David Zhou <[EMAIL PROTECTED]> wrote: > >>> On Aug 8, 2008, at 5:43 PM, Jacob Kaplan-Moss wrote: > > weird the BDFL had > > >>> wear the BDFL hat? ;) > > >> See, that's how uncomfortable I am in this particular hat -- I > >> temporarily lost all control of the English language. > > > It's a dirty rotten job, but someone's got to do it. > > >> Port sausage unstop the blog barrel. > > > Meat inspector. > > > regards > > Steve > > -- > > Steve Holden +1 571 484 6266 +1 800 494 3119 > > Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #6845 - model validation DDN
Ignore me sorry i just read Jacobs comment. What a shame, i really didn't want to be stuck with newforms validation in 1.0 Never mind, keep up the good work :) On Aug 18, 11:11 pm, tobydeh <[EMAIL PROTECTED]> wrote: > Hi Honza, > > What's the story with this? Are you aiming for the 1.0 release? > > On Aug 12, 8:14 pm, "Honza Král" <[EMAIL PROTECTED]> wrote: > > > Hey all, > > thanks for the feedback, I am still on vacation (haven't opened my > > notebook for days, what a feeling ;) ). I will be back in a couple of > > days and this thread is right at the top of my ToDo list. > > > I plan to see this thing through unless somebody beats me to it or the > > design decisions go exactly opposite to my ideas (unlikely, even after > > reading this) and have set aside some time to do it next week. > > > Thanks again for the feedback and patience... > > > Honza Král > > E-Mail: [EMAIL PROTECTED] > > ICQ#: 107471613 > > Phone: +420 606 678585 > > > On Sat, Aug 9, 2008 at 01:40, Steve Holden <[EMAIL PROTECTED]> wrote: > > > > Jacob Kaplan-Moss wrote: > > >> On Fri, Aug 8, 2008 at 4:51 PM, David Zhou <[EMAIL PROTECTED]> wrote: > > >>> On Aug 8, 2008, at 5:43 PM, Jacob Kaplan-Moss wrote: > > > weird the BDFL had > > > >>> wear the BDFL hat? ;) > > > >> See, that's how uncomfortable I am in this particular hat -- I > > >> temporarily lost all control of the English language. > > > > It's a dirty rotten job, but someone's got to do it. > > > >> Port sausage unstop the blog barrel. > > > > Meat inspector. > > > > regards > > > Steve > > > -- > > > Steve Holden +1 571 484 6266 +1 800 494 3119 > > > Holden Web LLC http://www.holdenweb.com/ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Authentication using email
Hello everyone, For my current project I'm replacing the username with the e-mail address wherever the end-user sees it. I haven't had to implement a different authentication backend since I'm saving the email address with the @'s and dots replaced with underscores as the username field for the django.contrib.auth.models.User model. So far, I've customized my registration form getting rid of the username field and simple deriving it from the e-mail field inside the save() method of the registration form. In the login form I ask the user to type an e-mail address and then I wrap the view at django.contrib.auth.views.login with another view that copies the POST QueryDict of the request in order to make it mutable and have the username prepared as needed. It's a bit of an ugly hack but for now it works. My problems have started when I realized I could log in as both [EMAIL PROTECTED] and john_company_com with the current approach so I wanted to replace the login form with a custom form in which the username field has been turned into an email field implemented using a proper forms.EmailField field. The issue is django.contrib.auth.views.login doesn't accept a custom form as parameter only a custom template so I'm kind of forced to copy and paste 27 lines of Django internal code into a custom view to essentially use my own custom form because currently the form is hardcoded to be django.contrib.auth.forms.AuthenticationForm. I searched through the tickets and found #8274 that patches Django to do exactly what I need it to do and it looks it might make it into 1.0 since it's marked "1.0 maybe". I could move completely to using an alternative authentication backend but the main reason I haven't already do it because of the admin preventing me from logging-in with my email address even if the authentication backend would accept it. The ticket for this bug is #8342. I run Django from trunk updating almost everyday in order to be fully ready for 1.0 :) So, what chances do you think this two tickets have to make it into the 1.0 release? Is there anything else that can be done to make it happen? Yes, I know there are patches for both issues but I really want to avoid depending on a patched Django. Regards and thanks for your time, Antonio. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Multiple weblogs or catecorized news
Hi all. Got a question unsolved yet. I'm making a news site on Django. App has e.x. 2 models: Type and Element. "Type" is simply a definition of some type of news it handles, literally its source info: title, site link, type_name (as slug). "Element" handles the news elements with a foreign key "type_id". So, there are some news sources (Types) and corresponding news articles (Elements). The questions is: how do I make an url pattern or something else to make the next thing work? site.com/news/first_type/2008/01/02/first_news/ - first news type, first article site.com/news/second_type/2008/01/02/ - second news type, day archive site.com/news/third_type/2008/01/ - third news type, month archive site.com/news/seventh_type/2008/ - seventh news type, year archive site.com/news/unlimited_type/ - unlimited news type, index archive I do want to do it with generic.views.date_based because the functionality suffices, but I don't know how to implement a Type.slug into urls, something like splitting all the news into categories. Thanks ahead. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple weblogs or catecorized news
On Mon, Aug 18, 2008 at 7:01 PM, tezro <[EMAIL PROTECTED]> wrote: > > Hi all. Got a question unsolved yet. Wrong list — you want django-users. django-developers is for development *of* Django, not *using* Django. ^_^ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple weblogs or catecorized news
On Mon, Aug 18, 2008 at 7:36 PM, Tom Tobin <[EMAIL PROTECTED]> wrote: > On Mon, Aug 18, 2008 at 7:01 PM, tezro <[EMAIL PROTECTED]> wrote: >> >> Hi all. Got a question unsolved yet. > > Wrong list — you want django-users. django-developers is for > development *of* Django, not *using* Django. ^_^ (And you know, I still think we'd be better off with "django-YES-THIS-ONE" and "django-NO-THE-OTHER-ONE". Or perhaps a tad more seriously, something like "django-community" and "django-core" — otherwise we'll be fighting this battle forever.) --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple weblogs or catecorized news
Argh, thanks ) On Aug 19, 4:36 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > On Mon, Aug 18, 2008 at 7:01 PM, tezro <[EMAIL PROTECTED]> wrote: > > > Hi all. Got a question unsolved yet. > > Wrong list — you want django-users. django-developers is for > development *of* Django, not *using* Django. ^_^ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Authentication using email
On Aug 19, 8:19 am, Antonio Ognio <[EMAIL PROTECTED]> wrote: > In the login form I ask the user to type an e-mail address and then I > wrap the view at django.contrib.auth.views.login with another view > that copies the POST QueryDict of the request in order to make it > mutable and have the username prepared as needed. It's a bit of an > ugly hack but for now it works. You wouldn't need to use that hack if you were using a custom authentication backend, as `username` would point to whatever you like, in your case an email. > My problems have started when I realized I could log in as both > [EMAIL PROTECTED] and john_company_com with the current approach so I > wanted to replace the login form with a custom form in which the > username field has been turned into an email field implemented using a > proper forms.EmailField field. Again, with a custom auth backend, you could fully control what you can login with: a user name, an email, or both. Or even a social security number, a date or whatever. > The issue is django.contrib.auth.views.login doesn't accept a custom > form as parameter only a custom template so I'm kind of forced to copy > and paste 27 lines of Django internal code into a custom view to > essentially use my own custom form because currently the form is > hardcoded to be django.contrib.auth.forms.AuthenticationForm. If you don't feel like copying the whole view, you can go by monkey- patching the form, much cleaner in my opinion: AuthenticationForm.base_fields['username'].max_length = 75 Without it, the standard login view will still work with emails, but not with those longer than 30 characters (that is, the limit for the standard username behaviour). > I could move completely to using an alternative authentication backend > but the main reason I haven't already do it because of the admin > preventing me from logging-in with my email address even if the > authentication backend would accept it. The ticket for this bug is > #8342. If you were using a custom backend then you'd have no problem logging in the admin. That ticket suggests a fix for a misleading error message that is displayed when login fails, and which assumes you can't login with an email (that is the default behaviour). So this is not a bug, but more like a proposal for making things more flexible to customise. > Yes, I know there are patches for both issues but I really want to > avoid depending on a patched Django. You should really use a custom backend. Very easy to set up, and it would cleanly fix most of the problems you describe here. The monkey- patch I mentioned above would fix it for long emails. With those you should be sorted, even if these tickets don't make it into 1.0. --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Authentication using email
Hello Antonio, I am in the exact situation as you mention, I used a snipped in http://www.djangosnippets.org/snippets/142/ But as you mention, it doesn't work with Admin. What we're doing is log in via the application and since we have the session, jump to the Admin url to be logged. I didn't know about the tickets you mention, They address my issue perfectly and the patches seem to work, I just don't feel confortable patching my copy of Django to mantain my work. They could also allow me to use Django auth views to login with whatever authentication I want, such as one time password tokens or two passwords, or whatever I may need to authenticate with. Antonio Ognio wrote: > Hello everyone, > > For my current project I'm replacing the username with the e-mail > address wherever the end-user sees it. I haven't had to implement a > different authentication backend since I'm saving the email address > with the @'s and dots replaced with underscores as the username field > for the django.contrib.auth.models.User model. > > So far, I've customized my registration form getting rid of the > username field and simple deriving it from the e-mail field inside the > save() method of the registration form. > > In the login form I ask the user to type an e-mail address and then I > wrap the view at django.contrib.auth.views.login with another view > that copies the POST QueryDict of the request in order to make it > mutable and have the username prepared as needed. It's a bit of an > ugly hack but for now it works. > > My problems have started when I realized I could log in as both > [EMAIL PROTECTED] and john_company_com with the current approach so I > wanted to replace the login form with a custom form in which the > username field has been turned into an email field implemented using a > proper forms.EmailField field. > > The issue is django.contrib.auth.views.login doesn't accept a custom > form as parameter only a custom template so I'm kind of forced to copy > and paste 27 lines of Django internal code into a custom view to > essentially use my own custom form because currently the form is > hardcoded to be django.contrib.auth.forms.AuthenticationForm. > > I searched through the tickets and found #8274 that patches Django to > do exactly what I need it to do and it looks it might make it into 1.0 > since it's marked "1.0 maybe". > > I could move completely to using an alternative authentication backend > but the main reason I haven't already do it because of the admin > preventing me from logging-in with my email address even if the > authentication backend would accept it. The ticket for this bug is > #8342. > > I run Django from trunk updating almost everyday in order to be fully > ready for 1.0 :) > > So, what chances do you think this two tickets have to make it into > the 1.0 release? > > Is there anything else that can be done to make it happen? > > Yes, I know there are patches for both issues but I really want to > avoid depending on a patched Django. > > Regards and thanks for your time, > > Antonio. > > > -- Jesús J. Del Carpio Aureal Systems (cel) +511 991681653 (tel) +511 7197100 #300 (www) http://aureal.com.pe/ --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Debug logging of swallowed exceptions
Hi, Swallowed or reraised exception without a pointer to the real exception are bad. One point where I discovered this is here: http://code.djangoproject.com/ticket/6623 Writing to stdout out is not a good solution. I would prefere to use the python logging module. Thomas Güttler J Meier schrieb: > Hi folks, > > There's a number of places where Django deliberately swallows > exceptions. Most notably, misbehaving template filters are silenced. > Errors unpickling session data are silently also silently ignored (a > fact that brought me a two hours debugging session this afternoon). > These are always well-considered design decisions, but they leave the > developer in the dark about what has happened. > > I think it would be best if these behaviors were to remain unchanged, > but a log message with an informative traceback be emitted (if DEBUG > is set). Whether this is just printed to stdout or makes use of the > python logging module is immaterial to me. > > I've given a quick search and can't find a specific thread discussion > this idea - if I'm wrong, please point me to it/them. > > If this is seen as a desirable change, I volunteer to submit a patch > covering all swallowed exceptions - avoiding these 2+ hour "bug" > hunting sessions is well worth my time. > > There's no need for this to be a 1.0 feature. > > -Jim Meier > > > -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ 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 email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
