Re: contrib.auth and User model
Alexander Solovyov wrote: > But lets' listen what core developers think about making this the > official way. :) Personally, I like the idea of being able to switch out User models, as long as a base interface can be worked out. It seems that there might be a few people using a version of a patch attached to ticket #3011 (Allow for extendable auth_user module) [1]. I've got a few projects where I'm currently using either a custom user model in place of contrib.auth.User (meaning I had to roll my own pieces of django that have contrib.auth.User model hardcoded, like the auth backend) or using a custom user model with a OneToOne to contrib.auth.User (allowing me to use django's auth and sessions without modificaton). I would love to be able to do away with these solutions in favor of something that allows me to use a user model in place of contrib.auth.User as long as it implements some base interface so that the other code expecting a contrib.auth.User instance will still be happy. Also, this has come up a few times in the past, so you might want to search the archives. I know I have brought up some things before like extracting the user permission checking methods into an ObjectWithPermissions class that could be used as a mixin. Or possibly even using composition with something like: class User(models.Model): permissions = DatabasePermissions() Gary [1] http://code.djangoproject.com/ticket/3011 --~--~-~--~~~---~--~~ 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: auth messages should be lazy
SmileyChris wrote: > It seems silly that currently the auth message system calls > get_and_delete_messages for every request context (assuming you have > the auth context processor enabled, like it is by default). > > 1. You lose messages if you don't actually check for them > > 2. If you didn't check for it, and therefore won't be using them, you > still get punished with a query anyway. > > Doesn't it make sense to change the auth context processor to be pass > a LazyMessages object to context? (the same applies for visitor > messages [1] too) > > [1] http://code.djangoproject.com/ticket/4604 Makes sense to me. Also, see this thread for a previous discussion that popped up about this very issue: http://groups.google.com/group/django-developers/browse_frm/thread/851a3f06c5949cb0/ My last post there got no responses. Gary --~--~-~--~~~---~--~~ 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: Debugging Django
On Fri, Nov 09, 2007 at 08:32:15AM -0700, John M. Anderson wrote:
> > You cannot debug a single Django file in isolation. Instead, insert this
> > line:
> >
> >import pdb; pdb.set_trace()
> >
> > in sql.py, at the point you're interested in. Then run Django normally,
> > and
> > go to a db-based URL: you'll get a debugger prompt.
> >
>
> ok, thanks. I was just trying to debug without modifying files, it seems
> silly
> to have to modify the files to debug, but i'm new to python.
If you are new to python: You don't need a debugger.
Set up your servert, so that code gets reloaded automatically (either 'manage.py
runserver' or mod_python with 'MaxRequestsPerChild 1'). Then
you can add 'assert False' or for example
'assert False, django.db.connection.queries' into the code you want
to inspect. This will give you a lot of information if DEBUG=True is
set in settings.py.
Or: you can set up the logging module and add lines like
logging.info("foo: %s" % (foo)) into the code.
If you are new to python and django, you can ask on the user mailinglist
first.
Thomas
--
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
-~--~~~~--~~--~--~---
Re: ModelForms
On 11/9/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> On Nov 9, 2007 12:42 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Why not just do this? No need for any special new fields at all.
> >
> > class Article(models.Model):
> > author = models.ForeignKey(User)
> > title = models.CharField(max_length=255)
> > body = models.TextField()
> >
> > class ArticleForm(ModelForm):
> > model = Article
> > exclude = ['author']
> >
> > def new_article(request):
> > article = Article(author=request.user)
> >
> > if request.method == 'POST':
> > form = ArticleForm(request.POST, obj=article)
> > if form.is_valid():
> > obj = form.save()
> > ...
> > else:
> > form = ArticleForm(obj=article)
> >
> > It's the business of the form to know what the user is supposed to
> > provide. In this case, author needs to be provided by the programmer,
> > and if the programmer screwed up and saving the Article raises an
> > error due to a missing author field, there's nothing the user can do.
> > Adding extra machinery to handle stuff like that in the form seems
> > overly complicated to me.
>
> True. The only potential advantage of my approach over yours is the
> ability to display information about the author in the template,
> alongside the other forms, but if that's really necessary, the author
> can be passed separately in the context. I hadn't considered just
> creating a new object preloaded with the necessary information and
> treating it as an incomplete instance form. That's quite reasonable.
ModelForms have an obj (or maybe 'instance' or 'original') attribute, so:
{{ form.obj.author }}
:)
> I'm not sure about the "exclude = ['author']" syntax though. It seems
> to me that setting "author" to None would make more sense, rather than
> having a reserved name ("exclude") that takes a list of strings. Part
> of the reason I proposed some Form.for_model(Article) syntax for the
> base class was to eliminate the need for a reserved name ("model" or
> "Meta") just for handling this process. Someone putting together a
> form for a Lego set should be able to use "model" as a field name
> without a problem, just like somebody writing an email form that mails
> to a distribution list should be able to use "exclude" as a field for
> addresses to exclude from delivery.
I see attributes of ModelForm as more like configuration directives.
They wouldn't clash with the Form's namespace at all and are
essentially the same thing as the keyword args that get passed to
form_for_X right now. There's no reason you can't have a field named
'model' or a field named 'exclude' using the ModelForm syntax.
Joseph
--~--~-~--~~~---~--~~
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: ModelForms
On Nov 9, 2007 12:42 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Why not just do this? No need for any special new fields at all.
>
> class Article(models.Model):
> author = models.ForeignKey(User)
> title = models.CharField(max_length=255)
> body = models.TextField()
>
> class ArticleForm(ModelForm):
> model = Article
> exclude = ['author']
>
> def new_article(request):
> article = Article(author=request.user)
>
> if request.method == 'POST':
> form = ArticleForm(request.POST, obj=article)
> if form.is_valid():
> obj = form.save()
> ...
> else:
> form = ArticleForm(obj=article)
>
> It's the business of the form to know what the user is supposed to
> provide. In this case, author needs to be provided by the programmer,
> and if the programmer screwed up and saving the Article raises an
> error due to a missing author field, there's nothing the user can do.
> Adding extra machinery to handle stuff like that in the form seems
> overly complicated to me.
True. The only potential advantage of my approach over yours is the
ability to display information about the author in the template,
alongside the other forms, but if that's really necessary, the author
can be passed separately in the context. I hadn't considered just
creating a new object preloaded with the necessary information and
treating it as an incomplete instance form. That's quite reasonable.
I'm not sure about the "exclude = ['author']" syntax though. It seems
to me that setting "author" to None would make more sense, rather than
having a reserved name ("exclude") that takes a list of strings. Part
of the reason I proposed some Form.for_model(Article) syntax for the
base class was to eliminate the need for a reserved name ("model" or
"Meta") just for handling this process. Someone putting together a
form for a Lego set should be able to use "model" as a field name
without a problem, just like somebody writing an email form that mails
to a distribution list should be able to use "exclude" as a field for
addresses to exclude from delivery.
-Gul
--~--~-~--~~~---~--~~
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: ModelForms
On 11/9/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > > On Nov 9, 2007 9:57 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > > The only thing it doesn't handle yet is how to remove > > fields from the customized form, but this might be as simple as > > assigning the field to None or some new ExcludedField class or > > something. > > I actually like the idea of an ExcludedField. ExcludedFields wouldn't > be output in HTML, and wouldn't be expected in the incoming data, but > would be set in the constructor instead, using keyword arguments. Take > the following example. > > class Article(models.Model): > author = models.ForeignKey(User) > title = models.CharField(max_length=255) > body = models.TextField() > > class ArticleForm(forms.ModelForm(Article)): > author = forms.ExcludedField() > body = myapp.ReStructuredTextField() > > def new_article(request): > if request.method == 'POST': > form = ArticleForm(request.POST, author=request.user) > if form.is_valid(): > obj = form.save() > ... > else: > form = ArticleForm(author=request.user) > > Using this, is_valid would return False if author wasn't set in the > constructor, unless ExcludedField was declared using required=False. I > don't think it'd be necessary to deal with validating the data on an > ExcludedField though, since it would only get set in Python code. > Setting it to the wrong type would be a code error, not an input > error. Why not just do this? No need for any special new fields at all. class Article(models.Model): author = models.ForeignKey(User) title = models.CharField(max_length=255) body = models.TextField() class ArticleForm(ModelForm): model = Article exclude = ['author'] def new_article(request): article = Article(author=request.user) if request.method == 'POST': form = ArticleForm(request.POST, obj=article) if form.is_valid(): obj = form.save() ... else: form = ArticleForm(obj=article) It's the business of the form to know what the user is supposed to provide. In this case, author needs to be provided by the programmer, and if the programmer screwed up and saving the Article raises an error due to a missing author field, there's nothing the user can do. Adding extra machinery to handle stuff like that in the form seems overly complicated to me. Joseph --~--~-~--~~~---~--~~ 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: ModelForms
On 11/9/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> If we're kicking around ideas on this, here's a slightly different
> suggestion. First, an example:
>
> class MyForm(Form):
> extra_field = forms.CharField()
>
> class Meta:
> model = MyModel
> fields = ('a','b')
> def formfield(f):
> return ...
>
> def save():
>...
>
> i.e., rather than writing a new ModelForm base class, put the
> 'form_for_*' stuff into a Meta class (Meta probably isn't the right
> name, but it will do for now), which is used by the BaseForm metaclass
> as a set of assembly instructions for how to add model/instance based
> fields to MyForm.
>
> If you provide a Meta class, any of the field/exclude declarations are
> used to add new fields to the model; if there is a formfield() method
> on the Meta class, it is used to determine which Field class will be
> used.
>
> The fields added from the Meta class augment those provided manually
> (useful for the 'form_for_model plus these extra fields' use case,
> such as is required for password validation). If you need custom
> save/clean methods, you put them right in the form definition where
> they are required, which is exactly what you would do if you were
> manually defining the form from scratch.
The reason I like the ModelForm class is that it provides a clear
separation between a form that knows about models and one that
doesn't. I love that the basic newforms Form has no clue what a Django
model is. Using ModelForm makes it possible to write a SQLAlchemyForm
or a SQLObjectForm. I don't see that happening with the Meta syntax.
I like that your proposed syntax makes it very clear that this is just
a form, it's ok to go ahead and define clean methods on it, etc. The
ModelForm syntax would take documentation, but would behave the same
way.
The ModelForm syntax the rough implementation would look like this (I
emphasize rough):
class BaseModelForm(BaseForm):
# leaving a bunch of other kwargs out here for brevity
def __init__(self, data=None, files=None, obj=None, initial=None):
# get_initial_data pulls data out of the obj as a dict
obj_data = get_initial_data(obj)
# possibly do this:
# obj_data.update(initial)
self.obj = obj
super(BaseModelForm, self).__init__(data, files, initial=obj_data)
def save(self, commit=True):
# mostly a copy of save_instance here.
I'd hate to see the obj arg get put into the constructor of a
BaseForm, so Form's metaclass would end up generating a subclass of
BaseForm or BaseModelForm depending on whether or not the Form had an
inner Meta class (or whatever we call it). The implementation of the
ModelForm syntax seems cleaner to me, but there's most likely a better
way to implement your syntax that I haven't thought of.
Also, I'd like to see more attributes added to ModelForm, but I didn't
want to pollute the core proposal with a bunch of other ideas that may
not sit as well. I'd love to see something like this, but I'd like to
consider these after the foundation is laid:
class MyForm(ModelForm):
model = MyModel
extra_fields = {
'some_field': IntegerField()
}
widgets = {
'existing_field': CustomWidget()
}
def clean(self):
# do some custom cleaning
return self.cleaned_data
The whole idea of a formfield callback is powerful, but it really
lacks in readability for the common tasks of specifying custom widgets
and excluding specific fields.
> > The biggest problem I see is that this would be entirely backwards
> > incompatible with the way form_for_model and form_for_instance work
> > now. (especially the latter) It *may* be possible to change form_for_X
> > into some sort of hackish wrappers, but it wouldn't be pretty.
>
> If we decide to go down this path, I would prefer to see the
> form_for_* APIs deprecated and removed, rather than maintained as
> wrappers. If a wrapper is trivial, there's no real harm in keeping it
> around, but if its going to take a lot of effort to build and
> maintain, we could end up with a bigger bug hole and image problem
> than if we just grit our teeth and rip the band-aid off in one swift
> action.
I don't think the maintenance would be particularly difficult, but the
implementation would be ugly (probably not difficult, but ugly), and
it leaves "more that one way to do it". I may change my mind once I
actually *write* said wrappers, so I'd rather postpone this discussion
until we're talking about some actual code.
> This obviously means preparing the path well - lots of prior warning
> that the change will happen, maybe a release before the change comes
> into effect, plus public commentary on _why_ we're making such a big
> change, a mea culpa for getting it wrong in the first place, and good
> documentation on how to manage the change. However,
Re: ModelForms
I'm agree with you, but this example is just for demonstration purposes, but concerning the proposition, we really need something to reuse our model definitions into forms without rewrite(DRY), since that a form field, in many cases, has the same validation rules in both, back end and front end. On Fri, 2007-11-09 at 10:42 -0500, Marty Alchin wrote: > On Nov 9, 2007 10:07 AM, Smel <[EMAIL PROTECTED]> wrote: > > PS : > > http://smelaatifi.blogspot.com/2007/08/declarative-forms-django-newforms.html > > I'd say I'm -1 on including admin-style field declarations to forms. > I'm of the mind that, if you need that level of design on a custom > form, just write a template to handle it. Forms seem to me to be more > about handling the input than defining the output. Sure, they have > some convenience methods for that, but if we start trying to get those > to do everything, it's form_for_model all over again. Writing > templates is easy enough, I think. > > -Gul > > > --~--~-~--~~~---~--~~ 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: ModelForms
On Nov 9, 2007 10:07 AM, Smel <[EMAIL PROTECTED]> wrote: > PS : > http://smelaatifi.blogspot.com/2007/08/declarative-forms-django-newforms.html I'd say I'm -1 on including admin-style field declarations to forms. I'm of the mind that, if you need that level of design on a custom form, just write a template to handle it. Forms seem to me to be more about handling the input than defining the output. Sure, they have some convenience methods for that, but if we start trying to get those to do everything, it's form_for_model all over again. Writing templates is easy enough, I think. -Gul --~--~-~--~~~---~--~~ 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: Debugging Django
> You cannot debug a single Django file in isolation. Instead, insert this > line: > >import pdb; pdb.set_trace() > > in sql.py, at the point you're interested in. Then run Django normally, > and > go to a db-based URL: you'll get a debugger prompt. > ok, thanks. I was just trying to debug without modifying files, it seems silly to have to modify the files to debug, but i'm new to python. --~--~-~--~~~---~--~~ 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: ModelForms
On Nov 9, 2007 9:57 AM, Marty Alchin <[EMAIL PROTECTED]> wrote: > The only thing it doesn't handle yet is how to remove > fields from the customized form, but this might be as simple as > assigning the field to None or some new ExcludedField class or > something. I actually like the idea of an ExcludedField. ExcludedFields wouldn't be output in HTML, and wouldn't be expected in the incoming data, but would be set in the constructor instead, using keyword arguments. Take the following example. class Article(models.Model): author = models.ForeignKey(User) title = models.CharField(max_length=255) body = models.TextField() class ArticleForm(forms.ModelForm(Article)): author = forms.ExcludedField() body = myapp.ReStructuredTextField() def new_article(request): if request.method == 'POST': form = ArticleForm(request.POST, author=request.user) if form.is_valid(): obj = form.save() ... else: form = ArticleForm(author=request.user) Using this, is_valid would return False if author wasn't set in the constructor, unless ExcludedField was declared using required=False. I don't think it'd be necessary to deal with validating the data on an ExcludedField though, since it would only get set in Python code. Setting it to the wrong type would be a code error, not an input error. -Gul --~--~-~--~~~---~--~~ 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: ModelForms
+1, I agree, since I no longer use form_for_X method for a while
I use something like that:
from forms import SimpleForm
from django.contrib.auth.models import User
import django.newforms as forms
class UserForm(SimpleForm):
model = User
password2 = forms.CharField(label='Confirm password',
widget=forms.PasswordInput())
class Render:
fields = (('first_name', 'last_name'), 'username',
('password','password2'), 'email',
('is_active', 'is_staff', 'is_superuser'))
PS :
http://smelaatifi.blogspot.com/2007/08/declarative-forms-django-newforms.html
--~--~-~--~~~---~--~~
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: ModelForms
Fair warning: I haven't been following this very closely, so I'm probably way out in left field here. Feel free to look strangely at me after I mention this. Would it be possible to use a factory pattern for ModelForm? class Article(models.Model): title = models.CharField(max_length=255) body = models.TextField() class ArticleForm(forms.ModelForm(Article)): body = myapp.ReStructuredTextField() That way, there's a sort of custom form that can be easily subclassed to customize the form. This wouldn't be all that much different from form_for_model, except that we could make sure - perhaps during metaclass processing - that the Form.for_model class did in fact get subclassed. It could simply raise an exception if instantiated without being subclassed. This just seems much cleaner than dealing with model attributes or inner Meta classes. Fields and methods could be overridden like any other class, with fields left out simply being inherited from the parent class. The simple case would just look like this: class ArticleForm(forms.Form.for_model(Article)): pass And everything would Just Work, as long as they don't need more flexibility. The only thing it doesn't handle yet is how to remove fields from the customized form, but this might be as simple as assigning the field to None or some new ExcludedField class or something. I also wholeheartedly agree with Joseph's use of a keyword argument to accept an object instance, avoiding the need for a separate for_instance method. So, I like the overall idea, and I'm not particular on exactly how it gets done. I just thought I'd throw my thoughts in on the subject. -Gul --~--~-~--~~~---~--~~ 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: ModelForms
Hi folks -- Just to make sure everyone's on the same page: Joseph and I have talked about this in person quite a bit, and I'm a strong +1 (if that's possible). I don't feel strongly about the particulars -- Russell's proposal is interesting, but I haven't thought it through fully -- but I fully support the general idea. I think this leads to a good place. Jacob --~--~-~--~~~---~--~~ 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: ModelForms
On Nov 8, 2007 1:26 PM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> form_for_model and form_for_instance seem like complicated and clever
> ways to accomplish what basically boils down to a form that has a save
> method and can accept a model instance in its constructor method.
> ModelForm would be a declarative class that requires, at minimum, a
> model attribute. Other attributes would include:
...
> - formfield_callback (a function that takes a db field and **kwargs
> and returns a form field or None)
> - fields (a list of field names to include in the form)
> - exclude (a list of field names to exclude from the form)
Regular readers will note that I've been an advocate for expanding the
capabilities of form_for_model/instance. This isn't because I believe
that the form_for_* syntax has any particular strengths, but because I
have a lot of use for dynamic form generation based on a model. I know
that it is possible to dynamically generate a form without using
form_for_* (by overriding fields lists in __init__, etc), but those
approaches aren't that elegant, IMHO - certainly not as elegant as
just specifying a list of fields that you want to include on a form.
I was under the impression that the form_for_* syntax was BDFL
blessed; as a result, I was concentrating on how to maximize the
utility of the blessed format. However, if an alternate class-based
syntax is an available option, I'm certainly +1 to persuing those
options.
The sort of syntax you are proposing has the potential to be much more
'legible' than cramming everything into arguments on a function
declaration, and has the potential to make the simple tasks (such as
adding a formfield callback, or a custom save method) much more
intuitive and pythonic.
If we're kicking around ideas on this, here's a slightly different
suggestion. First, an example:
class MyForm(Form):
extra_field = forms.CharField()
class Meta:
model = MyModel
fields = ('a','b')
def formfield(f):
return ...
def save():
...
i.e., rather than writing a new ModelForm base class, put the
'form_for_*' stuff into a Meta class (Meta probably isn't the right
name, but it will do for now), which is used by the BaseForm metaclass
as a set of assembly instructions for how to add model/instance based
fields to MyForm.
If you provide a Meta class, any of the field/exclude declarations are
used to add new fields to the model; if there is a formfield() method
on the Meta class, it is used to determine which Field class will be
used.
The fields added from the Meta class augment those provided manually
(useful for the 'form_for_model plus these extra fields' use case,
such as is required for password validation). If you need custom
save/clean methods, you put them right in the form definition where
they are required, which is exactly what you would do if you were
manually defining the form from scratch.
> The biggest problem I see is that this would be entirely backwards
> incompatible with the way form_for_model and form_for_instance work
> now. (especially the latter) It *may* be possible to change form_for_X
> into some sort of hackish wrappers, but it wouldn't be pretty.
If we decide to go down this path, I would prefer to see the
form_for_* APIs deprecated and removed, rather than maintained as
wrappers. If a wrapper is trivial, there's no real harm in keeping it
around, but if its going to take a lot of effort to build and
maintain, we could end up with a bigger bug hole and image problem
than if we just grit our teeth and rip the band-aid off in one swift
action.
This obviously means preparing the path well - lots of prior warning
that the change will happen, maybe a release before the change comes
into effect, plus public commentary on _why_ we're making such a big
change, a mea culpa for getting it wrong in the first place, and good
documentation on how to manage the change. However, my gut reaction is
that one well managed large change will cause less drama than lots of
little bug fixes to an API wrapper.
Yours,
Russ Magee %-)
--~--~-~--~~~---~--~~
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: caching problems in the documentation pages
Malcolm Tredinnick ha scritto: > On Thu, 2007-11-08 at 22:08 +0100, Manlio Perillo wrote: >> Hi. >> >> I have noted that Firefox does not caches well the pages of Django >> documentation: >> >> GET /documentation/cache/ HTTP/1.1 >> Host: www.djangoproject.com >> User-Agent: Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8.1.8) >> Gecko/20071004 Iceweasel/2.0.0.8 (Debian-2.0.0.6+2.0.0.8-0etch1) >> Accept: >> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 >> >> >> Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 >> Accept-Encoding: gzip,deflate >> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 >> Keep-Alive: 300 >> Connection: keep-alive >> If-Modified-Since: Thu, 08 Nov 2007 20:56:04 GMT >> If-None-Match: eb24440f6bbbfeb65f7c71ab119d2df7 >> >> HTTP/1.x 200 OK >> Date: Thu, 08 Nov 2007 20:59:07 GMT >> Server: Apache >> Expires: Thu, 08 Nov 2007 21:01:04 GMT >> Vary: Cookie >> Last-Modified: Thu, 08 Nov 2007 20:56:04 GMT >> Etag: eb24440f6bbbfeb65f7c71ab119d2df7 >> Cache-Control: max-age=300 >> Connection: close >> Content-Type: text/html; charset=utf-8 >> >> >> >> I'm not sure but if the documentation pages are "quasi static", the >> Cache-Control: max-age=300 header should be present. > Sorry, I have missed a "not" present. However it seems that the problem is that Django does not validates the If-Modified-Since and If-None-Match headers. > Which it is (third last line). > > Malcolm > Manlio Perillo --~--~-~--~~~---~--~~ 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: Debugging Django
John M. Anderson wrote: > I'm trying to debug sql.py > > the steps I've taken so far: > > python /usr/lib/python2.5/pdb.py manage.py sql polls > (python manage.py polls works just fine) You cannot debug a single Django file in isolation. Instead, insert this line: import pdb; pdb.set_trace() in sql.py, at the point you're interested in. Then run Django normally, and go to a db-based URL: you'll get a debugger prompt. -- Nicola Larosa - http://www.tekNico.net/ I grew up with the colonialist propaganda, the "occupier's narrative", and it took me half my life to realize it was all a lie. [...] If I were among those directly afflicted by the genocide, paternalism, exploitation, theft and abuse committed every day by colonial invaders, in almost every nation on the planet, I would be consumed by rage. [...] We should be ashamed of ourselves. -- Dave Pollard, July 2007 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Debugging Django
I'm trying to debug sql.py
the steps I've taken so far:
python /usr/lib/python2.5/pdb.py manage.py sql polls
(python manage.py polls works just fine)
(Pdb) b django/core/management/sql.py:271
(Pdb) c
Traceback (most recent call last):
File "/usr/lib/python2.5/pdb.py", line 1213, in main
pdb._runscript(mainpyfile)
File "/usr/lib/python2.5/pdb.py", line 1138, in _runscript
self.run(statement, globals=globals_, locals=locals_)
File "/usr/lib/python2.5/bdb.py", line 366, in run
exec cmd in globals, locals
File "", line 1, in
File "./manage.py", line 11, in
execute_manager(settings)
File
"/usr/local/lib/python2.5/site-packages/django/core/management/__init__.py",
line 275, in execute_manager
project_directory = setup_environ(settings_mod)
File
"/usr/local/lib/python2.5/site-packages/django/core/management/__init__.py",
line 255, in setup_environ
project_module = __import__(project_name, {}, {}, [''])
ValueError: Empty module name
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
>
/usr/local/lib/python2.5/site-packages/django/core/management/__init__.py(255)setup_environ()
-> project_module = __import__(project_name, {}, {}, [''])
What module name is invalid? does pdb change the way my environment works?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
