Re: contenttypes and dumpdata options
Hi JD, Yes, using natural keys will allow you to serialize models that use the contenttypes framework. You can read about this feature here: http://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys Preston On Jan 29, 1:59 pm, jd wrote: > hello, > What's the current recommended way to deal with contenttypes when you > move a db using dumpdata? I know about excluding it, but I read > something about using the ---natural option with the dump command > would work as well. Does this work when including contenttypes in the > dump? Which is the preferred method? thanks. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Styling help_text
Hi Scot,
Unfortunately, the patch to that ticket was committed after 1.2 was
released. That feature isn't available until 1.3 or in trunk.
What you see in the docs is an error. The original patch didn't
include an update there. I created a ticket to have the docs
corrected.
http://code.djangoproject.com/ticket/15204
Preston
On Jan 31, 7:23 pm, Scot Hacker wrote:
> This ticket
>
> http://code.djangoproject.com/ticket/8426
>
> says that, as of six months ago, model field help_text rendered in
> forms by {{form.as_p}} gets wrapped in a style-able span. But in
> Django 1.2.4, {{form.as_p}} still generates unspanned help_text. It
> also doesn't show up spanned in the docs:
>
> http://docs.djangoproject.com/en/dev/ref/forms/fields/#help-text
>
> I'm not sure what I'm missing here. I'd really like to stop manually
> creating every field in form templates just to get style-able help
> text.
>
> Any pointers? Thanks.
>
> ./s
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Adding a field to a form during runtime
Hi Marek,
I think that your problem is that the make_car_form function returns a
form class rather than an instance of that class. Once you have the
class you still need to make an instance of it. Something like this
might work:
form_class = make_car_form(True)
carForm = form_class()
Preston
On Mar 19, 7:05 am, Thomas Guettler wrote:
> Sorry, I can't help you here, since I don't create classes
> at runtime (*). I think using __init__() is better, and I guess
> you can solve your problem with it, too.
>
> (*) type('ContactForm', (forms.BaseForm, ), { 'base_fields': fields})
>
> Marek W schrieb:
>
>
>
> > Thanks for your response. Probably the reason was I didn't update a
> > database, because now(after making syncdb) it works correctly. But by the
> > time I've found a second problem:
>
> > while to create a dynamic form this way:
>
> > def make_car_form(extra):
> > fields = { 'carType' : forms.CharField() }
> > if extra:
> > fields['extraField'] = forms.CharField()
> > return type('ContactForm', (forms.BaseForm, ), { 'base_fields': fields
> > })
>
> > View method:
> > (...)
> > carForm = make_car_form(True)
> > (...)
>
> > then on the page there aren't any fields, whether calling make_car_form with
> > extra=True or extra=False.
>
> --
> 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 users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Testing
Hi Filip, The Django test runner looks for tests in two places in an application--the models.py file and an optional tests.py file. If you want to run tests for your views you can move your tests into a file called tests.py in your application. An example of testing a view with doctests can be found here: http://docs.djangoproject.com/en/dev/topics/testing/#overview-and-a-quick-example Preston On Mar 18, 6:34 pm, Filip Gruszczyński wrote: > I am trying to have my function tested using docstring with examples. > When I put it into models.py of an app, it gets tested. If I put > it into views.py, it is not tested; this happens also, if I add > another module (which I import). How can make testing framework test > those? > > -- > Filip Gruszczyński --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: override render_to_response
I am wondering if render_to_response is really the proper function you are looking for. For instance, here is a simple view that returns json using HttpResponse without need of a template: import simplejson from django.http import HttpResponse def output_json(request): data = [ dict(name='joe', weight=165), dict(name='roger', weight=130), ] return HttpResponse(simplejson.dumps(data), mimetype="application/ json") More docs on the HttpResponse is available here: http://docs.djangoproject.com/en/dev/ref/request-response/#django.http.HttpResponse.__init__ Preston --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Saving model with raw=True
Thanks, Alex, I must misunderstand what it is for then. I got the idea from a post where Russ Magee mentioned it as being a way to prevent auto_now fields from being executed: http://groups.google.com/group/django-users/browse_thread/thread/167ee7bddccb4354/069a59146423d013?lnk=gst&q=auto_now#069a59146423d013 I needed to create a test that depended upon a 'date modified' field of a model. That field used auto_now and it did not seem possible to force a date. I have since solved the problem by moving the logic into a custom save method but afterwards came upon the above post and wondered if I wasn't missing something simple. Preston On Mar 16, 5:59 pm, Alex Gaynor wrote: > On Mon, Mar 16, 2009 at 6:55 PM, Preston Timmons > wrote: > > > > > > > At one time it seems there was an intention to have the save method on > > models accept a keyword argument named raw which would allowed the > > model to be saved without pre-processing. This argument is available > > in the save_base method but not available in the save method. > > > Am I right to conclude that I should call save_base directly when I > > want to use this? > > > Thanks. > > > Preston > > What do you mena skipping the processing, right now what raw does is very > internal and doesn't seem like behavior you'd ever want to > chnage:http://code.djangoproject.com/browser/django/trunk/django/db/models/b... > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." --Voltaire > "The people's good is the highest law."--Cicero --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Saving model with raw=True
At one time it seems there was an intention to have the save method on models accept a keyword argument named raw which would allowed the model to be saved without pre-processing. This argument is available in the save_base method but not available in the save method. Am I right to conclude that I should call save_base directly when I want to use this? Thanks. Preston --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
