m 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 me
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 bet
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
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. Th
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 --
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 appn
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.
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 differ
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 Compan
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 th
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 add
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 manipulator
"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
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 gen
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
15 matches
Mail list logo
