generic views and inline formsets
Hi, in the oldforms times the generic views (create_object and update_object) used to handle edit_inline out of the box: ie. for the typical Poll/Question models I could just pass Poll to create_object and have it create poll objects AND related Question instances. With the inline settings pulled out of model definitions, that's no longer true. Is there a simple replacement for that? The easiest way I can think of is to create an inline formset as described here: http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-an-inline-formset-in-a-view ...then add a form for editing the base instance and pass the resulting formset as form_class to create_object. Or did I miss something? -mk -- Marcin Kaszynski http://marcinkaszynski.com/ http://warsztatyit.pl/django/ -- Warsztaty Django --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django-multilingual
Hi, this is just a quick note that after a couple of months of hiatus the Django-Multilingual library went from 'unmaintained' to 'maintained as time permits', which will hopefully be okay for most uses. I received several offers of help, which is incredibly cool and already resulted in much better documentation (thanks, Dan) and support for current Django trunk (thank you, Matthias). There is still a lot to be done, but the library is usable with Django trunk again and keeps getting better. From now on I want to make sure that Multilingual supports at least two versions of Django: trunk and the last stable version (currently 0.96[.1]). I do have a favor to ask of you: if you tried to use the library and ran into problems that are not already solved or present on the project page[1], please add it to the list or at least send me an email. And of course, if you tried to use it and are happy with the results, do not hesitate to let us know either :) Thanks, -mk [1]: http://code.google.com/p/django-multilingual/issues/list --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django-multilingual
On Nov 20, 2:23 am, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > from the 'introduction' page, the links to the 'installation' and > 'usage' pages are broken Fixed, thanks! -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Django's doctest clashes with coverage.py
Hi, I tried to file this as a ticket, but trac kept rejecting it as spam even after I removed all the links and changed contents. I'm posting it here because others might find it useful too. When you use coverage.py in "manage.py test" it incorrectly reports some statements as not executed. This is a known issue with coverage.py. From http://nedbatchelder.com/code/modules/coverage.html : "Older versions of doctest interfere with coverage's tracing of statements, and you may get reports that none of your code is executing. Use this patch[1] to doctest.py if you are experiencing problems." I checked, applying the patch from Zope to django.test._doctest does help. Regards, -mk [1]: http://svn.zope.org/Zope3/trunk/src/zope/testing/doctest.py?rev=28679&r1=28703&r2=28705 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
On Nov 24, 3:54 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> > I tried to file this as a ticket, but trac kept rejecting it as spam
> Have you tried creating a login:
>
> http://code.djangoproject.com/settings
I did have the idea of creating one, but simply could not find the
page -- I poked around the wiki, looked through the patch guidelines,
tried to 'login' and finally decided that apparently trac accounts are
not for the mere mortals :)
Now I see that there _is_ a place that contains a link to a page that
lets you create an account, but I did not notice it because it is in a
section that looked like not interesting to me at that time ("Claiming
tickets").
> Generally, this will convince the spam checker to let you post tickets.
It worked, thanks. Ticket #6024.
> As a side note, there is an existing ticket requesting that we add
> coverage support to Django's test system; any suggestions in this area
> are welcome.
I really like the idea of having a --with-coverage option.
You closed the ticket because of licensing issues. Do we really have
to bundle coverage.py with Django to add that option? The test runner
might use coverage.py if available and complain otherwise. Besides,
bundling modules means additional recurring costs for you (as in "the
Django developers") and coverage.py is a module used only during
development; it might be a better idea to let users install it outside
of Django.
-mk
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
One more comment after a day of writing unit tests: installing coverage.py via a test runner is not a good idea. The test runner is executed pretty late and there is a chance that part of your code gets executed earlier. I do not know if this is the only possible case, but I had the code in appname/__init__.py files executed during translation initialization, which is way before Django even looks at the command line passed to manage.py. Right now my code detects the --with-coverage option and installs coverage right in projectname/manage.py as the very first thing, before importing any other module. This gives far more accurate results. I still believe it would be a good idea to add the --with-coverage option to Django, since it would make it a bit easier it for people to do proper testing (and one less excuse not to do it right). If it sounds good to you I can create a patch for that, moving the code that installs coverage.py to django.core.management. -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django's doctest clashes with coverage.py
On Nov 25, 3:58 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > We recently added the > ability for external projects to define new management commands > specifically so that end-users could contribute features like this > without the need to modify the Django core. I did not know that. Very cool. > And, to pre-empt the follow on discussion - this policy of including > other libraries is not up for debate. You may disagree, but we're not > going to change it. Nope, after reading your explanation I think that is a good policy, especially if there is a way to do such things via external add-ons. But we do have Ned's direct permission and the file does include licensing information that basically means you can redistribute it in source form as long as you don't remove the comments. So, we're back to "think about the best way to handle the option", right? :) Ned: thanks for your work on the module, it is incredibly helpful during testing. I spent the last two days adding tests and removing unused code from my apps. -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: FlatPage and Internationalization
On Nov 27, 11:10 am, Tim <[EMAIL PROTECTED]> wrote: > For multilingual sites, is it not easier to maintain and keep all the > translations in .po files? The idea of splitting up the required > translations would mean that translators must use two different > interfaces. Well, those are two different sets of translators :) It is the difference between code and content. The .po files, just like template files and all texts hardcoded in models and views and, are 'code' and flatpages are usually the 'content' of your site. The latter are supposed to differ for separate installations of your app, safer, changeable without modifications to the application code, without risking breaking anything and thus editable by a larger group of people. This difference should be passed on to translations as well. I realize this line may be blurry in some cases, but a good way of discovering where it goes is to think about using your app or project as a base for two different sites. As for the original question, there is at least one app that gives you flatpages with translations, based on django.contrib.flatpages and midified to use django-multilingual (http://code.google.com/p/django- multilingual/issues/detail?id=30); I did not have the time to add it to the multilingual library yet (unfortunately, this is where the "as time permits" part kicks in), but hope to do so soon. Should be simple to install and try out and I would be happy to have some feedback on what and how it does :) -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
update_object and preserving fields
Hello, is there a way to make update_object preserve values of some fields without putting them in the update form? I have a model with a 'creator' field: class Company(models.Model): creator = models.ForeignKey(auth.User, ) [...] I want to set this field automatically when a Company gets created (I got this part working using the threadlocals trick), but the value should not change after that. I tried several ways to make this work (including a custom save() method in the model and a custom CreatorField with a pre_save method that set the value if add=True) and so far had no luck: update_object simply takes data from POST and if something is not set there then the field will be set to None. Is there some way around it without patching update_object, or do I have to write custom views for such models? -mk PS. My first post on this group. Welcome everyone! --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: update_object and preserving fields
viestards <[EMAIL PROTECTED]> writes: > I think this can help: > http://code.djangoproject.com/wiki/CookBookManipulatorWithPostpopulatedFields Not really. I know how to do this using my own view, but I was hoping to get another freebie from the generic views :) I guess I should simply patch the update_object view to add a constant_fields parameter, most probably doing precisely the same thing this manipulator does -- overwriting some new_data fields with values taken from the original object. Judging from the page you mentioned I'm not the only one who would find such a feature useful :) Nevertheless, thanks for the tip, -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: update_object and preserving fields
Michael Radziej <[EMAIL PROTECTED]> writes: > I've followed your discussion only in parts. But I usually handle > everything that is outside of the scope of the normal generic views > inside the manipulator, and I have patched some generic views so > that they accept a manipulator instance as additional > parameter. (see ticket 1563 for patch). I call the generic view from > the view function. I agree this change is useful, but it will not make my life much easier. The update_object view does, this: new_data = request.POST.copy() errors = manipulator.get_validation_errors(new_data) manipulator.do_html2python(new_data) if not errors: object = manipulator.save(new_data) The way I see it, new_data should be updated (with the values of fields I want to preserve) before validation, so if I was to use your patch I would have to overwrite get_validation_errors and update new_data in there, before calling the "real" get_validation_errors, right? Does not look too pretty to me. > This makes a nice general pattern. You get very short view > functions, the manipulator concentrates on the "real stuff", and the > generic view handles all the GET/POST/validation logic, that tends > to be the same for most views. Still, with my change I can avoid writing views at all (other than keeping my own version of update_object). At the same time the functionality I need seems very generic. I'll try it and see what happens :) -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: update_object and preserving fields
Michael Radziej <[EMAIL PROTECTED]> writes: > If only the Manipulator would use its follow attribute to decide > which fields need to be validated. This way you would get only partial validation that would break stuff like ValidateIfOtherFieldEquals. > Or the if the generic view and manipulators provided a way for a > clean prepopulate. This is exactly what I have in mind. I also thought about adding another parameter to generic views that would let you pass a function to change the contents of new_data right after POST.copy(), but before validation. Say, update_new_data. > Also, I feel I don't have a deeper understanding of the structure > and interactions between generic views, manipulators, and form > fields--yet ;-) Same here, but hey, this is how I learn about this stuff -- I'm sharing my ideas hoping that someone will let me know if I'm about to do something stupid :) -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Re: update_object and preserving fields
"Honza Král" <[EMAIL PROTECTED]> writes: > You can also try and have a look on the follow parametr of > manipulators, note that the generic views do pass this parameter on > from their kwargs... Cool, I did not know about this parameter until now. It looks like it will solve some of my problems (in particular, the creator field). Thanks a lot! -mk --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~--~~~~--~~--~--~---
Extending User model after magic-removal
Hi,
I just spent some time looking for a way to extend the User model in a
way that would allow me to:
1. add fields to the model itself,
2. use the standard admin interface to edit them,
3. keep changes to Django minimal and generic.
I came up with something that actually works well and is generic
enough to extend any other model: I changed ModelBase.__new__ to call
a function that modifies attributes of the new class before it gets
created. The function is defined in project settings file, so it is
easy to have different User models in different projects without
further changes to Django code.
Example from my settings.py:
> def patch_user_model(name, bases, attrs):
> from django.db import models
> from myproject.myapp.models import Company
>
> attrs['phone_numbers'] = models.CharField(maxlength=300)
> attrs['height'] = models.IntegerField(blank=True, null=True)
> attrs['employer'] = models.ForeignKey(Company, blank=True, null=True)
>
> # fields[1] is the 'Personal info' tuple, fields[1][1] is the contents
> dict
> attrs['Admin'].fields[1][1]['fields'] += ('phone_numbers', 'employer',
> 'height')
>
> return attrs
>
> MODEL_PATCHES = {'auth.User': patch_user_model}
It is possible to specify patches for multiple models. You will need
to recreate model tables every time you change the patch function.
The attached file is the patch for Django.
Cheers,
-mk
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
Index: django/db/models/base.py
===
--- django/db/models/base.py (revision 3116)
+++ django/db/models/base.py (working copy)
@@ -25,6 +25,14 @@
if not bases or bases == (object,):
return type.__new__(cls, name, bases, attrs)
+# patch the class
+if hasattr(settings, 'MODEL_PATCHES'):
+# quietly assume it is a dict
+model_patches = settings.MODEL_PATCHES
+func = model_patches.get(attrs['__module__'].split('.')[-2] + '.' + name, None)
+if func:
+attrs = func(name, bases, attrs)
+
# Create the class.
new_class = type.__new__(cls, name, bases, {'__module__': attrs.pop('__module__')})
new_class.add_to_class('_meta', Options(attrs.pop('Meta', None)))
Re: Extending User model after magic-removal
Luke Plant <[EMAIL PROTECTED]> writes:
> This is actually quite interesting. You would need to alter your
> patch a bit so that it works for models with 'app_label' defined --
> the "model_module.__name__.split('.')[-2]" logic should exist in
> only one place.
Good point. Another problem I ran into is that circular dependencies
caused by models imported in the patch function result in somewhat
confusing error messages. I have yet to find a way to fix this.
On the bright side, I already found another use for the patch:
def patch_flatpage(name, bases, attrs):
attrs['Admin'].js = ('tiny_mce/tiny_mce.js',
'tiny_mce/textareas.js')
return attrs
MODEL_PATCHES = {'flatpages.FlatPage': patch_flatpage}
:)
> Other than that it seems quite good -- maybe you should create a
> ticket.
That I will, I posted it here first to get some feedback and a chance
to fix any problems before I submit a patch. Thanks for your
comments!
-mk
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---
