Re: Django Web Hosting Service
Hello, > then why do you recommend that apache be restarted on 17,37 and 57 minutes? > In fact *you* yourself install that cronjob on all django sites.? The cron job you're referring to: 1) Exists because if you've a spike in CPU or memory usage that affects others on the same server your processes will be killed. If we kill your processes the cron job ensures that your website won't be down for too long. 2) Only restarts your instance of Apache if it's down. > debug is false everywhere, apache is tweaked as per your recommendations and > static media is served through the system wide apache. My client had to > upgrade to 80 MB from 40 MB for a site that is 90% admin and has at the most, > three users at a time. A memory leak isn't the only reason that your instance of Apache could be using more than 40 MB of memory, off of the top of my head I can think of nearly half a dozen reasons and I'm just WebFaction's Django monkey. With that said the memory usage related Apache/Django tips that we've in our blog are by no means a one size fits all solution for decreasing Apache's memory usage. -David Sissitka --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Hi I am anuusha 21years of student... find your lover here www.loverguru.blogspot.com
Hi I am anuusha 21years of student... find your lover here www.loverguru.blogspot.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Hi I am anuusha 21years of student... find your lover here www.loverguru.blogspot.com
Hi I am anuusha 21years of student... find your lover here www.loverguru.blogspot.com --~--~-~--~~~---~--~~ 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
Please use coverage.py, I would be honored to have it included in Django core. If it's better as an add-on of some sort, that's great too. Let a thousand flowers bloom! --Ned. Todd O'Bryan wrote: > On Nov 24, 2007 9:58 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > >> If the licensing issue can't be resolved, it may be worth starting a >> standalone project to handle coverage tests. 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 believe the author of coverage.py, Ned Batchelder, is on the list. > Has he said whether he's willing to have Django include it without > much hoop jumping? > > Todd > > > > > -- Ned Batchelder, http://nedbatchelder.com --~--~-~--~~~---~--~~ 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, 2007 9:58 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > If the licensing issue can't be resolved, it may be worth starting a > standalone project to handle coverage tests. 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 believe the author of coverage.py, Ned Batchelder, is on the list. Has he said whether he's willing to have Django include it without much hoop jumping? Todd --~--~-~--~~~---~--~~ 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 Web Hosting Service
On 25-Nov-07, at 3:49 AM, David Sissitka wrote: >> I used to be very prowebfaction- they have huge memory leak >> problems and unless you stop and start apache once every 20 minutes, >> you very easily go over the memory limits. I now feel they are only >> good for toy sites. > > There are no known memory leaks in our Django stack, if you think > you've found one submit a support ticket and we'll be glad to look > into it. Every once in a while someone thinks they've found a memory > leak in our Django stack but nine tines out of ten the problem is that > they've DEBUG set to True in their settings.py. then why do you recommend that apache be restarted on 17,37 and 57 minutes? In fact *you* yourself install that cronjob on all django sites.? debug is false everywhere, apache is tweaked as per your recommendations and static media is served through the system wide apache. My client had to upgrade to 80 MB from 40 MB for a site that is 90% admin and has at the most, three users at a time. -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ Foss Conference for the common man: http://registration.fossconf.in/web/ --~--~-~--~~~---~--~~ 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
I could be off base here but in regards to the the execution of
translation initialization I believe that is occurring because the
django.core.management.base attempts to switch the translation to
english if the can_import_settings attribute is set:
if self.can_import_settings:
from django.utils import translation
translation.activate('en-us')
According to the docs this is done because django-admin (manage.py)
executes some database stuff related to permissions. Since this is
set to True by the BaseCommand this is likely the cause.
You might try creating your own custom command that executes the test
runner but only after setting this attribute to false and checking
your results then.
Michael
blog.michaeltrier.com
On Nov 24, 2007 12:03 PM, Marcin Kaszynski <[EMAIL PROTECTED]> wrote:
>
> 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 11/24/07, Marcin Kaszynski <[EMAIL PROTECTED]> wrote: > > On Nov 24, 3:54 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > 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. As do I. > You closed the ticket because of licensing issues. Do we really have > to bundle coverage.py with Django to add that option? If it's going to be part of the core, then yes. If the licensing issue can't be resolved, it may be worth starting a standalone project to handle coverage tests. 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. > 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. This would be fundamentally inconsistent with the way that most of Django works. With the exception of database interfaces, Django includes all the batteries required for all of its core functions. We include SimpleJSON and a signal framework specifically to avoid the dependency problem. This has two advantages: - Stability: we update these libraries when there is a need to do so. We don't need to manage the differences between versions of libraries over which we have no control. - Simplicity: Everything works out of the box. We don't need to spend a lifetime debugging obscure errors that only occur on one particular packaged version of a library. 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. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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: I have been banned from this group. Why?
On 24-Nov-07, at 10:04 PM, Jantawan Piyawat wrote: > mails that I received went into my Gmail spam folder automatically. > When Gmail sees that mails from this group are marked as spams in my > email account, it automagically (read: buggy) bans me to read the > group conversation through the web-based interface. lol - the snake has started swallowing it's tail -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ Foss Conference for the common man: http://registration.fossconf.in/web/ --~--~-~--~~~---~--~~ 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: I have been banned from this group. Why?
On 11/25/07, Jantawan Piyawat <[EMAIL PROTECTED]> wrote: > > This is my theory why I got banned from this group. > > I set to receive digested mails from this group. Then, there were spam > mails to this group that fall into the digested mails. It appears that > this group receives a few spam mails a day. As such, the digested > mails that I received went into my Gmail spam folder automatically. > When Gmail sees that mails from this group are marked as spams in my > email account, it automagically (read: buggy) bans me to read the > group conversation through the web-based interface. There is nothing automagical about the banning - banning an account is an entirely manual process. Unfortunately, because banning is a manual process, and the Google Groups interface for handling banning is cumbersome, sometimes we get a false positive and ban the account of a genuine user. The most likely cause of the ban in this case is that your account name (thawatchai) matched a screen name that was used to send a spam message. The really effective spammers get in the habit of changing their screen name regularly so that it is harder to find them in the user database; if they have chosen the name of a genuine user, then the genuine user sometimes wears the blame for the spammers behaviour. I tried unbanning your account, but it looks like you've removed your subscription. Apologies for the mistake and the inconvenience. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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 Web Hosting Service
Kenneth Gonsalves wrote: > > On 22-Nov-07, at 2:15 AM, Daniel Roseman wrote: > >>> http://www.webfaction.com/ >>> >>> They are amazing and reasonably priced. Their support is great. They >>> have exceeded my expectations many times. >>> >>> Chuck >> Second this recommendation. I am very happy with them, and they have >> responded to support calls nearly instantly. > > I used to be very pro webfaction - they have huge memory leak > problems and unless you stop and start apache once every 20 minutes, > you very easily go over the memory limits. I now feel they are only > good for toy sites. > Purely anecdotal, but this doesn't match my experience with Webfaction at all - I'm currently doing some updates on a site I hadn't touched for a while - when I logged in to dump the database contents for development purposes, I noticed that my previous shell login was almost a full year ago. The site was running perfectly fine and within its memory limits for that whole time period without me having to do any administration work. Same thing with the other site I currently host there - both are using the "Shared 1" option. Jonathan. --~--~-~--~~~---~--~~ 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 Web Hosting Service
On Nov 22, 1:09 pm, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > I used to be very prowebfaction- they have huge memory leak > problems and unless you stop and start apache once every 20 minutes, > you very easily go over the memory limits. I now feel they are only > good for toy sites. There are no known memory leaks in our Django stack, if you think you've found one submit a support ticket and we'll be glad to look into it. Every once in a while someone thinks they've found a memory leak in our Django stack but nine tines out of ten the problem is that they've DEBUG set to True in their settings.py. -David Sissitka --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
exclusive video from Tokyo Hotel : monsoon
Hi , This is a exclusive video from Tokyo Hotel : monsoon : http://bw.olympe-network.com/monsoon.html Enjoy peace and love TH for ever --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
exclusive video from Tokyo Hotel : monsoon
Hi , This is a exclusive video from Tokyo Hotel : monsoon : http://bw.olympe-network.com/monsoon.html Enjoy peace and love TH for ever --~--~-~--~~~---~--~~ 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: Can I run Django on my Sun-Ray?
walterbyrd wrote: > I'm running Solaris 10. I have Python. I am not looking to build a > production site. Just trying to learn some django during dead time. > > I'm not sure what to do about a database. I don't think I can install > mysql or postgresql - maybe sqlite. Django runs on the Nokia web pads. If you can afford 64 - 128MB and have some disk space all is well. It of course works in far less memory but for real performance more is better. sqlite is perfectly reasonable until the db is getting a good work out. Then you could transition to an external db server. --~--~-~--~~~---~--~~ 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: Setting Value in Template
OK, I finally got it to work...here's what I did...
class Organization(models.Model)
...
def get_absolute_url(self):
org_id = self.id
return "/organization/%s" % (org_id)
urls.py
(r'^organization/(?P\d+)/activitycreate/$',
'administration.views.activity_create'),
template:
{%for a in item.admin_roles.all %}
{{a}}
{% endfor %}
On Nov 24, 10:18 am, JimR <[EMAIL PROTECTED]> wrote:
> I've been struggling with the following for a couple of days, and
> would appreciate any help or suggestions. I'm still learning the
> intricacies of both Django and Python, so please bear with me if this
> is relatively obvious. Alternatively, if you could point me to some
> examples of how to do this, I'd be most appreciative.
>
> Thanks,
> Jim
>
> We are developing a site that includes some administration rights for
> particular organizations. The admin rights can be set for each user/
> member from a list of potential actions. A user can be a member of
> multiple organizations and have different admin rights for each
> organization.
>
> Using the regroup tag, I have gotten my template to look as follows:
>
> Org 1
>action 1
>action 2
>action 3
>
> Org 2
>action 1
>action 4
>
> Each of the actions is rendered as a link. What I would like to do is
> pass the organization ( {{item.organization}} ) associated with the
> action to the view that would handle the action. So if a user clicked
> on "action 1" under the "Org 2" heading, I'd like to pass "Org 2" to
> the view "action 1". I'd like to stay away from forms/buttons to make
> the rendering a bit less cluttered, but may go that route if using
> links isn't possible.
>
> I have the following models (abridged):
>
> class AdminRoles(models.Model):
> role_abbr = models.CharField(max_length = 2)
> role = models.CharField(max_length = 20)
> description = models.CharField(max_length = 50)
>
> class AdminGroup(models.Model):
> description = models.CharField(max_length = 50)
> admin_roles = models.ManyToManyField(AdminRoles)
>
> class AdminRights(models.Model):
> user = models.ForeignKey(User)
> organization = models.ForeignKey(Organization)
> admin_roles = models.ManyToManyField(AdminRoles, blank=True,
> null=True)
> admin_group = models.ForeignKey(AdminGroup)
>
> Here is the relevant template code:
> {% regroup admin_rights|dictsort:"organization" by
> organization as
> org_list %}
> {% for organization in org_list %}
>
> div>
> class="contentbox-title-shading">{{organization.grouper}}
> Administration
> {% for item in organization.list %}
> {%for a in item.admin_roles.all %}
> class="hide">{{item.organization}}
> a.get_absolute_url }}>{{a}}
> {% endfor %}
>
> {% endfor %}
>
> {% endfor %}
--~--~-~--~~~---~--~~
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: csrfmiddleware problem
Never mind. Properly encoding the input solved the problem. D'oh! Owen On Nov 23, 3:16 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I have a problem with the csrfmiddleware - I'm trying to put up a form > to edit django templates, and if the template being edited has a > element the csrf thing inserts itself into the form input. I'm > wondering if there is a way to disable it for part of a page. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Can I run Django on my Sun-Ray?
I'm running Solaris 10. I have Python. I am not looking to build a production site. Just trying to learn some django during dead time. I'm not sure what to do about a database. I don't think I can install mysql or postgresql - maybe sqlite. --~--~-~--~~~---~--~~ 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: I have been banned from this group. Why?
This is my theory why I got banned from this group. I set to receive digested mails from this group. Then, there were spam mails to this group that fall into the digested mails. It appears that this group receives a few spam mails a day. As such, the digested mails that I received went into my Gmail spam folder automatically. When Gmail sees that mails from this group are marked as spams in my email account, it automagically (read: buggy) bans me to read the group conversation through the web-based interface. Does anyone know someone that experiences the same thing as I do? Could anyone please lift the ban for me? I've already invested my time and energy using Django for my web projects. I can't just switch back to Rails because I can't access Django resources. What a tragedy! Thank you for your help, Thawatchai (at Gmail) On Nov 24, 1:30 pm, Jantawan Piyawat <[EMAIL PROTECTED]> wrote: > I don't flag the mails myself. The too-smart Gmail has done it for me > (without my consent, obviously). I've just found this out a minute > ago. That's why I've never seen an email from this group in my inbox. > > Thawatchai > > On Nov 24, 1:25 pm, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > > > On 24-Nov-07, at 11:48 AM, Jantawan Piyawat wrote: > > > > I just see that all 'digest' mails from django-users go to 'spam' in > > > my Gmail account. That may be the reason. > > > if you brand us as 'spam' - why blame us for reciprocating ;-) > > > -- > > > regards > > kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/web/ > > Foss Conference for the common man:http://registration.fossconf.in/web/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Setting Value in Template
I've been struggling with the following for a couple of days, and
would appreciate any help or suggestions. I'm still learning the
intricacies of both Django and Python, so please bear with me if this
is relatively obvious. Alternatively, if you could point me to some
examples of how to do this, I'd be most appreciative.
Thanks,
Jim
We are developing a site that includes some administration rights for
particular organizations. The admin rights can be set for each user/
member from a list of potential actions. A user can be a member of
multiple organizations and have different admin rights for each
organization.
Using the regroup tag, I have gotten my template to look as follows:
Org 1
action 1
action 2
action 3
Org 2
action 1
action 4
Each of the actions is rendered as a link. What I would like to do is
pass the organization ( {{item.organization}} ) associated with the
action to the view that would handle the action. So if a user clicked
on "action 1" under the "Org 2" heading, I'd like to pass "Org 2" to
the view "action 1". I'd like to stay away from forms/buttons to make
the rendering a bit less cluttered, but may go that route if using
links isn't possible.
I have the following models (abridged):
class AdminRoles(models.Model):
role_abbr = models.CharField(max_length = 2)
role = models.CharField(max_length = 20)
description = models.CharField(max_length = 50)
class AdminGroup(models.Model):
description = models.CharField(max_length = 50)
admin_roles = models.ManyToManyField(AdminRoles)
class AdminRights(models.Model):
user = models.ForeignKey(User)
organization = models.ForeignKey(Organization)
admin_roles = models.ManyToManyField(AdminRoles, blank=True,
null=True)
admin_group = models.ForeignKey(AdminGroup)
Here is the relevant template code:
{% regroup admin_rights|dictsort:"organization" by
organization as
org_list %}
{% for organization in org_list %}
{{organization.grouper}}
Administration
{% for item in organization.list %}
{%for a in item.admin_roles.all %}
{{item.organization}}
{{a}}
{% endfor %}
{% endfor %}
{% endfor %}
--~--~-~--~~~---~--~~
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: Cuztomizing the admin interface.
On 11/23/07, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote: > you will have to hack admin for this - it is better not to do this as > admin is going to change very soon into newforms-admin. It is better > to do this outside admin - I know it involves writing 3 extra lines > of template code to tweak form_for_model, but it is worth the effort. Actually, this is a case where all he wants is a change in form presentation, which is easy enough to do by overriding the template and laying it out how he wants it. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: Imitating "edit_inline" in a view
Well, I eventually worked this out, and I'd be interested in any
comments.
from mytest.garage.models import Car, Person
def edit_record(request, id=1):
person = Person.objects.get(pk=id)
cars = person.car_set.all()
PersonForm = form_for_instance(person)
car_forms = []
for car in cars:
CarForm = form_for_instance(car)
if request.method == 'POST':
car_form = CarForm(request.POST, prefix=str(car.id))
if car_form.is_valid():
car_form.save()
else:
car_form = CarForm(prefix=str(car.id))
car_forms.append(car_form)
if request.method == 'POST':
form = PersonForm(request.POST)
if form.is_valid():
form.save()
return HttpResponseRedirect('/carowner/edit/' + str(id) +
'/')
else:
form = PersonForm()
return render_to_response('edit.html', locals())
The "prefix" argument to the class instantiation is crucial, but most
of the awkwardness is handled by Django itself, so it's a solution I
can live with. Just need to ensure there are no name conflicts between
properties of models. The template looks like this:
{{ form }}
{% for c in car_forms %}
{{ c }}
{% endfor %}
--
James
On 23 Nov, 14:55, James Mulholland <[EMAIL PROTECTED]> wrote:
> This question is related to this one I asked a couple of months ago:
>
> http://decenturl.com/groups.google/djangomultipleforms
>
> I'd like to use something similar to the "edit_inline" option, but in
> a view. My test models look like this:
>
> class Person(models.Model):
> person_name = models.CharField(max_length=20, core=True)
> age = models.PositiveIntegerField()
>
> class Car(models.Model):
> car_name = models.CharField(max_length=20, core=True)
> colour = models.CharField(max_length=10)
> engine_cc = models.PositiveIntegerField()
> owner = models.ForeignKey(Person, edit_inline=models.TABULAR,
> num_in_admin=3)
>
> In the admin, this shows the "Person" details (name and age) above a
> table allowing details of multiple cars to be entered. Is there a way
> to do something similar in a view? Any help and advice appreciated.
> TIA.
>
> --
> James
--~--~-~--~~~---~--~~
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: complex query in limit_choices_to
On database level that should be done by UNIQUE constraints. And your problem should be made on form level. read about ChoiceField in newforms documentation --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
see the jop
see the jop http://earnmac.blogspot.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
