Re: include behavior
For 1., did you import play_django?
On Jun 21, 11:17 am, tekion wrote:
> All,
> I noticed that putting single quote around include argument makes a
> different, for example:
> (r'^admin/', include(admin.site.urls)),
> (r'^polls/', include('play_django.polls.urls')),
> works. Where as:
> (r'^admin/', include(admin.site.urls)),
> (r'^polls/', include(play_django.polls.urls)),
>
> yield this error:
> NameError at /polls/
>
> name 'play_django' is not defined
>
> Request Method: GET
> Request URL: http://127.0.0.1:8000/polls/
> Exception Type: NameError
> Exception Value:
>
> name 'play_django' is not defined
>
> Two question:
> 1. why putting single quotes works, no NameError was thrown for
> play_django.
> 2. why admin.site.urls works without quote and putting quote around it
> doesn't, this is an inconsistency that really bothers me.
--~--~-~--~~~---~--~~
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: OT: running custom management command from cron & Unicode output error
import sys, codecs, locale sys.stdout = codecs.getwriter(locale.getpreferredencoding()) (sys.stdout) or you can hard-code locale.getpreferredencoding() as 'utf-8' On Jun 7, 2:19 am, "Carlos A. Carnero Delgado" wrote: > Hi there! > > I'm having a problem with a custom management command. Running > interactively on the console will work perfectly, merrily printing its > output in Unicode (I need that; accented characters among other > things). > > But, if I put that command in a cron job, it will fail with > > UnicodeEncodeError: 'ascii' codec can't encode character > > (getting those from cron's email messages). I *think* it's because the > interactive environment is different from cron's. I've tried putting a > LANG=en_US.UTF-8 into cron's (dunno if that's Ubuntu specific) but I'm > getting the same error. > > Any ideas? > > Best regards, > Carlos. > > >>> import sys > >>> print sys.platform > linux2 > >>> print sys.version > 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) > [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]' > >>> import django > >>> django.VERSION > (1, 1, 0, 'beta', 1) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Abstract models and 'blank' (etc.) constraints
I have a need to define 2 models, both with a large number of fields in common, but where in once case these common fields are completely optional, and in the other case they are mandatory. class XYZTemplate(Model): field_a = TextField( blank=True) field_b = TextField( blank=True) field_c = IntegerField( blank=True) # other fields unique to this class Notice, in the XYZTemplate, the fields from A are all optional. class XYZ(Model): field_a = TextField( blank=False) field_b = TextField( blank=False) field_c = IntegerField( blank=False) # other fields unique to this class But in XYZ they must be filled in. My purpose is to allow "templates" (gee that's a bit of an overworked term ... I am *not* referring here to django html templates) of an object to be partially filled in and stored in the database as an XYZTemplate Then at a later time, many XYZ instances will be created based on the "default" values stored in an XYZTemplate instance. I was thinking along the lines of an abstract model like so: class A(Model): field_a = TextField( blank=True) field_b = TextField( blank=True) field_c = IntegerField( blank=True) class Meta: abstract=True app_label='...' Then define the other classes as: class XYZTemplate(Model, A): # other fields unique to this class class XYZ(Model, A): # other fields unique to this class But how do I make the XYZ field_a, field_b, field_c have blank=False. Without violating DRY, is there any way I can do this in Django? Can I fiddle with the attributes of the fields from class A in class XYZ? Any other solutions? Thanks for any advice, Richard --~--~-~--~~~---~--~~ 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: Abstract models and 'blank' (etc.) constraints
Ok, after looking through the django wiki entries for AuditTrail (http://code.djangoproject.com/wiki/AuditTrail) and DynamicModels (http://code.djangoproject.com/wiki/DynamicModels), I guess I can see that there is a potential solution there. But I'd still appreciate any comments on the desirability of doing this, and potential alternative solutions. Thanks, Richard On Jun 17, 8:03 pm, Richard Colley wrote: > I have a need to define 2 models, both with a large number of fields > in common, but where in once case these common fields are completely > optional, and in the other case they are mandatory. > > class XYZTemplate(Model): > field_a = TextField( blank=True) > field_b = TextField( blank=True) > field_c = IntegerField( blank=True) > # other fields unique to this class > > Notice, in the XYZTemplate, the fields from A are all optional. > > class XYZ(Model): > field_a = TextField( blank=False) > field_b = TextField( blank=False) > field_c = IntegerField( blank=False) > # other fields unique to this class > > But in XYZ they must be filled in. > > My purpose is to allow "templates" (gee that's a bit of an overworked > term ... I am *not* referring here to django html templates) of an > object to be partially filled in and stored in the database as an > XYZTemplate Then at a later time, many XYZ instances will be created > based on the "default" values stored in an XYZTemplate instance. > > I was thinking along the lines of an abstract model like so: > > class A(Model): > field_a = TextField( blank=True) > field_b = TextField( blank=True) > field_c = IntegerField( blank=True) > class Meta: > abstract=True > app_label='...' > > Then define the other classes as: > > class XYZTemplate(Model, A): > # other fields unique to this class > > class XYZ(Model, A): > # other fields unique to this class > > But how do I make the XYZ field_a, field_b, field_c have blank=False. > > Without violating DRY, is there any way I can do this in Django? Can > I fiddle with the attributes of the fields from class A in class XYZ? > Any other solutions? > > Thanks for any advice, > Richard --~--~-~--~~~---~--~~ 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: Abstract models and 'blank' (etc.) constraints
Thanks TiNo, Are there any caveats with this? e.g. to make syncdb etc. work correctly? On Jun 17, 10:13 pm, TiNo wrote: > You can acces a models field through Model._meta.fields. You can probably > loop through these fields in your Model's __init__ method, and change their > blank attribute to false. > > TiNo > > On Wed, Jun 17, 2009 at 13:32, Richard Colley wrote: > > > > > Ok, after looking through the django wiki entries for AuditTrail > > (http://code.djangoproject.com/wiki/AuditTrail) and DynamicModels > > (http://code.djangoproject.com/wiki/DynamicModels), I guess I can see > > that there is a potential solution there. > > > But I'd still appreciate any comments on the desirability of doing > > this, and potential alternative solutions. > > > Thanks, > > Richard > > > On Jun 17, 8:03 pm, Richard Colley wrote: > > > I have a need to define 2 models, both with a large number of fields > > > in common, but where in once case these common fields are completely > > > optional, and in the other case they are mandatory. > > > > class XYZTemplate(Model): > > > field_a = TextField( blank=True) > > > field_b = TextField( blank=True) > > > field_c = IntegerField( blank=True) > > > # other fields unique to this class > > > > Notice, in the XYZTemplate, the fields from A are all optional. > > > > class XYZ(Model): > > > field_a = TextField( blank=False) > > > field_b = TextField( blank=False) > > > field_c = IntegerField( blank=False) > > > # other fields unique to this class > > > > But in XYZ they must be filled in. > > > > My purpose is to allow "templates" (gee that's a bit of an overworked > > > term ... I am *not* referring here to django html templates) of an > > > object to be partially filled in and stored in the database as an > > > XYZTemplate Then at a later time, many XYZ instances will be created > > > based on the "default" values stored in an XYZTemplate instance. > > > > I was thinking along the lines of an abstract model like so: > > > > class A(Model): > > > field_a = TextField( blank=True) > > > field_b = TextField( blank=True) > > > field_c = IntegerField( blank=True) > > > class Meta: > > > abstract=True > > > app_label='...' > > > > Then define the other classes as: > > > > class XYZTemplate(Model, A): > > > # other fields unique to this class > > > > class XYZ(Model, A): > > > # other fields unique to this class > > > > But how do I make the XYZ field_a, field_b, field_c have blank=False. > > > > Without violating DRY, is there any way I can do this in Django? Can > > > I fiddle with the attributes of the fields from class A in class XYZ? > > > Any other solutions? > > > > Thanks for any advice, > > > Richard --~--~-~--~~~---~--~~ 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: How do I get a field value instead of in an admin selectbox?
The answer was given to you in the previous post.
Whatever __unicode__() returns from your model is what will be
displayed.
So, on your model, define a __unicode__ method:
e.g.
class Person(...):
def __unicode__(self):
return self.name
On Jun 18, 12:03 am, DaveB wrote:
> > Your question is very difficult to read - needs paragraphs.
>
> > But I think the answer to your problem is to define a __unicode__
> > method on the target model.
> > --
> > DR.
>
> I will try to be clearer and briefer:
>
> Django's built-in admin system automatically generates data-entry
> forms for the fields in a table. If those fields are ForeignKey types
> such as OneToOneField, the data entry system generates a box
> to allow the user to pick an entry from the ForeignKey table. I am
> getting these choices all displayed as the same
> literal " object".
>
> I would like them to be displayed instead as
> ".value" For instance, if the table I
> am doing data entry into has a field which is a OneToOneField pointer
> to a table named People which has a field called name, I want the
> generated to show as the values of each People
> record's People.name field. It currently (as a default behavior) seems
> to only display the same literal "People object" for every record in
> the drop-down selection box .
>
> Here is a minimal example of what I am doing:
> # = from admin.py ===
> class PersonInline(admin.TabularInline):
> model = Person
> class PersonAdmin(admin.ModelAdmin):
> list_display=('name',)
>
> class MomAdmin(admin.ModelAdmin):
> list_display=('myname','PTArole')
> def myname(self,obj):
> pname=Person.objects.get(personID=obj.personID_id).name
> if pname is None: myname="No Person found for %s"%str
> (obj.personID_id)
> return pname
>
> # == from models.py ==
> class Person(models.Model):
> personID=models.AutoField (primary_key=True)
> name=models.CharField(max_length=20)
>
> class Mom(models.Model):
> momID=models.AutoField (primary_key=True)
> personID=models.OneToOneField('Person',to_field='personID')
> PTA_roles=(('O','officer'),('C','on committee'),('A','active'),
> ('I','inactive'))
> PTArole=models.CharField(max_length=1,choices=PTA_roles)
>
> =
>
> When the admin interface goes to add/change Mom, it shows the
> PTA_roles correctly, but the PersonID field is shown as "Person
> object"
>
> What should I do to have the personId field selection display
> Person.name instead?
--~--~-~--~~~---~--~~
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: Abstract models and 'blank' (etc.) constraints
Yeah, I stripped out the nulls=True/False out of the example. I do want the database to enforce this constraint. I'll give it a try tomorrow and report back whether syncdb etc. are happy. If anyone has any wise words in the meantime... :) On Jun 18, 12:20 am, TiNo wrote: > On Wed, Jun 17, 2009 at 14:42, Richard Colley wrote: > > > > > Thanks TiNo, > > > Are there any caveats with this? e.g. to make syncdb etc. work > > correctly? > > I don't know, as I never tried, and I am not very experienced with messing > with the inner meta class, but: blank has nothing to do with syncdb, only > null does. So this means that you will end up with two tables in the > database that are the same, they will both allow NULL values. Only Django > will enforce a non-empty value on the fields of the XYZ class. I don't know > how you would change the null-attribute values before running syncdb. Maybe > you do require Dynamic Models then. > > > > > On Jun 17, 10:13 pm, TiNo wrote: > > > You can acces a models field through Model._meta.fields. You can probably > > > loop through these fields in your Model's __init__ method, and change > > their > > > blank attribute to false. > > > > TiNo > > > > On Wed, Jun 17, 2009 at 13:32, Richard Colley > >wrote: > > > > > Ok, after looking through the django wiki entries for AuditTrail > > > > (http://code.djangoproject.com/wiki/AuditTrail) and DynamicModels > > > > (http://code.djangoproject.com/wiki/DynamicModels), I guess I can see > > > > that there is a potential solution there. > > > > > But I'd still appreciate any comments on the desirability of doing > > > > this, and potential alternative solutions. > > > > > Thanks, > > > > Richard > > > > > On Jun 17, 8:03 pm, Richard Colley wrote: > > > > > I have a need to define 2 models, both with a large number of fields > > > > > in common, but where in once case these common fields are completely > > > > > optional, and in the other case they are mandatory. > > > > > > class XYZTemplate(Model): > > > > > field_a = TextField( blank=True) > > > > > field_b = TextField( blank=True) > > > > > field_c = IntegerField( blank=True) > > > > > # other fields unique to this class > > > > > > Notice, in the XYZTemplate, the fields from A are all optional. > > > > > > class XYZ(Model): > > > > > field_a = TextField( blank=False) > > > > > field_b = TextField( blank=False) > > > > > field_c = IntegerField( blank=False) > > > > > # other fields unique to this class > > > > > > But in XYZ they must be filled in. > > > > > > My purpose is to allow "templates" (gee that's a bit of an overworked > > > > > term ... I am *not* referring here to django html templates) of an > > > > > object to be partially filled in and stored in the database as an > > > > > XYZTemplate Then at a later time, many XYZ instances will be created > > > > > based on the "default" values stored in an XYZTemplate instance. > > > > > > I was thinking along the lines of an abstract model like so: > > > > > > class A(Model): > > > > > field_a = TextField( blank=True) > > > > > field_b = TextField( blank=True) > > > > > field_c = IntegerField( blank=True) > > > > > class Meta: > > > > > abstract=True > > > > > app_label='...' > > > > > > Then define the other classes as: > > > > > > class XYZTemplate(Model, A): > > > > > # other fields unique to this class > > > > > > class XYZ(Model, A): > > > > > # other fields unique to this class > > > > > > But how do I make the XYZ field_a, field_b, field_c have blank=False. > > > > > > Without violating DRY, is there any way I can do this in Django? Can > > > > > I fiddle with the attributes of the fields from class A in class XYZ? > > > > > Any other solutions? > > > > > > Thanks for any advice, > > > > > Richard --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Is it ok to super/save() twice in model.save()?
I have overriden the save method on my model, and want to use the id field (default autoincrementing pk) to set one of the other fields. Is this ok: class MyModel(models.Model): ... def save(self, *args, **kwargs): super(MyModel, self).save(*args, **kwargs) self.some_string_field = "Some text with id=%d" % self.id super(MyModel, self).save(*args, **kwargs) It seems to work, but I'm confused about some side effects. If I use obj, created = MyModel.get_or_create(...) then created is always False, even when a new object is created. Is that because of the 2 super.save() calls? I guess I could pull this behaviour out of the model, and place into the view that manipulates it, but I feel the functionality rightfully belongs in the model. Any help appreciated. Thanks, Richard -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Is it ok to super/save() twice in model.save()?
Exactly as you had described ... I wanted to upload images to paths with the model instance's id in it. Seemed easier for a human to relate to that way (in case of maintenance outside of django). However, the uuid approach or similar may be the way forward. On May 13, 10:58 pm, zinckiwi wrote: > > I have overriden the save method on my model, and want to use the id > > field (default autoincrementing pk) to set one of the other fields. > > > Is this ok: > > > class MyModel(models.Model): > > ... > > def save(self, *args, **kwargs): > > super(MyModel, self).save(*args, **kwargs) > > self.some_string_field = "Some text with id=%d" % self.id > > super(MyModel, self).save(*args, **kwargs) > > > It seems to work, but I'm confused about some side effects. If I use > > obj, created = MyModel.get_or_create(...) > > then created is always False, even when a new object is created. Is > > that because of the 2 super.save() calls? > > That seems a reasonable assumption, though I haven't looked at the > get_or_create() code. > > When I've needed to do something similar (like using the pk of a model > as a folder name for file uploads, to keep different objects' > filenames from colliding) I've opted instead for creating a surrogate > key (in that example, a uuid). > > Can you tell me a bit more about your use case? Obviously it must be > something a little more complex than simply storing a string that > contains the pk, or you would just have a method to calculate that > string. What exactly is it that requires access to the pk on create? > > Regards > Scott > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Is it ok to super/save() twice in model.save()?
Thanks Scott, that's more or less what we've finalised on. Appreciate your feedback! Richard On May 14, 10:28 pm, zinckiwi wrote: > Righto -- unfortunately that's the best solution I've come up with to > date. Here's the detailed version: > > # models.py > def get_upload_path(instance, filename): > return "%s/%s/%s" % (instance.__class__.__name__.lower(), > instance.uuid, filename,) > > def get_uuid(): > import uuid > return str(uuid.uuid4()) > > class MyModel(models.Model): > ... > pdf = models.FileField(max_length=200, upload_to=get_upload_path) > uuid = models.CharField(max_length=36, default=get_uuid, > editable=False) > > That results in //. > > I certainly did entertain a minimal-save-to-get-the-PK followed by the > "real" save, but didn't even get as far as discovering that it could > cause problems with shortcut functions. What turned me off at the > outset was needing to provide fake or default values for every other > field in the model, deleting that one if the "real" save failed, etc. > Seemed like a lot of busywork and prone to error. > > Regards > Scott > > On May 13, 10:52 pm, Richard Colley wrote: > > > Exactly as you had described ... I wanted to upload images to paths > > with the model instance's id in it. Seemed easier for a human to > > relate to that way (in case of maintenance outside of django). > > However, the uuid approach or similar may be the way forward. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To post to this group, send email to django-us...@googlegroups.com. > To unsubscribe from this group, send email to > django-users+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: How to execute some user defined codes (functions) when Django boot?
Why not call your "boot" code from settings.py? On Aug 18, 4:05 pm, Tang Daogang wrote: > hi, Emily, > > Let me introduce Scala/Lift as example. > > Every lift project has a file named 'Boot.scala', this file will only > be executed once when this project boots up. In this file, we can > write some initial codes to initial project and some userdefined > structures. > > Emm, that's it. I want to find one file acting like Boot.scala of Lift > within Django, but failed. If there is one file like that, I will put > my plugins registering codes into it, thus, when I type "python > manage.py runserver", it can be executed automatically and only once. > By it, my plugins can be registered when app boot up. > > Do you understand my meaning? Welcome suggestion. > > On 8月17日, 下午8时45分, Emily Rodgers wrote: > > > > > On Aug 17, 2:26 am, Tang Daogang wrote: > > > > Dear all, > > > > Recently, I have developed a plugin system for my app, and I want to > > > register those plugins when my app boot up, this need to execute some > > > user defined codes (functions) in app boot procedure, I don't know > > > where insert my registering codes to, anyone can help? > > > > Thank you. > > > Hi, > > > I don't know how to help you, but I think it is because you haven't > > explained what you want to do thoroughly enough. > > > What do you mean by a plugin system, and what do you mean by > > registering them with the app on boot up? Are you talking about > > including another python module in your code? Or perhaps including > > another django app in your code? > > > Can you give us a bit more information (and maybe examples) of what > > you are trying to do. > > > Cheers, > > Em -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
