drop down box in django-admin interface UI?
hi i want to make one of my field taking value as drop down box on django-admin UI. how can i define a field in model such that it takes value from a specific set of values in django-admin interface. i am using django-admin interface for one of my database. in a certain table in a particular field i want that field to be like example- my field is lanuage which takes value only from 'hindi,english,french,german' so i need one drop down box for the same. what modification are required for the same in model. thanks ravindra --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: drop down box in django-admin interface UI?
On May 22, 4:02 pm, "ravindra goyal" <[EMAIL PROTECTED]> wrote: > hi > i want to make one of my field taking value as drop down box on django-admin > UI. > how can i define a field in model such that it takes value from a specific > set of values in django-admin interface. > i am using django-admin interface for one of my database. > in a certain table in a particular field i want that field to be like > > example- my field is lanuage which takes value only from > 'hindi,english,french,german' > > so i need one drop down box for the same. > > what modification are required for the same in model. This is a list dedicated for the development of django and not for general usage questions. Please take your discussion to the django- users mailing list. -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
{GSoC 2008}Django-Newcomments : A preview
Hello folks, My exams got done in the first week of May. I was feeling quite bored and so started working on the project. I completed a few items from the Todo list but need to complete the documentation and write more tests. The code for my project is at http://code.google.com/p/django-newcomments/ and at http://gitorious.org/projects/django-newcomments I also have put up the four demos in the source at: Demo-1: Using django-newcomments as a standalone app. http://sandbox.thejaswi.info/example1/authors/ Demo-2: Using django-newcomments placing it in django.contrib.comments (after removing the current django.contrib.comments) http://sandbox.thejaswi.info/example2/books/ Demo-3: A simple threaded comments demo (inspired from Eric Florenzano's project). http://sandbox.thejaswi.info/example3/comics/ Demo-4: A custom comments demo http://sandbox.thejaswi.info/example4/messages/ Current Problems faced: * Abstract models don't allow custom managers. Tickets 7154 and 7252 handle that (I am running trunk patched with ticket 7154). * Abstract models don't allow the inheritance of the inner admin class. After a discussion on IRC, I was assured that this was a small issue that newforms-admin would cover after it supports model- inheritance. Till then an abstract model designer cannot pass on a neat admin UI to the user :( Please do let me know of any suggestions/criticisms and/or feedback. -- Cheers Thejaswi Puthraya http://thejaswi.info/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
I have to admit I'm slightly worried about the multi-database proposal, because at the moment it doesn't seem to solve either of the multi-db problems I'm concerned about. The proposal at the moment deals with having different models live in different databases - for example, the Forum application lives on DB1 while the Blog application lives on DB2. I can see how this could be useful, but the two database problems that keep me up at night are the following: 1. Replication - being able to send all of my writes to one master machine but spread all of my reads over several slave machines. Thankfully Ivan Sagalaev's confusingly named mysql_cluster covers this problem neatly without modification to Django core - it's just an alternative DB backend which demonstrates that doing this isn't particularly hard: http://softwaremaniacs.org/soft/mysql_cluster/en/ 2. Sharding - being able to put User entries 1-1000 on DB1, whereas User entries 1001-2000 live on DB2 and so on. I'd love Django to have built-in abilities to solve #1 - it's a really important first-step on scaling up to multiple databases, and it's also massively easier than any other part of the multi-db problem. I wouldn't expect a magic solution to #2 because it's so highly dependent on the application that is being built, but at the same time it would be nice to see a multi-db solution at least take this in to account (maybe just by providing an easy tool to direct an ORM request to a specific server based on some arbitrary logic). I may have misunderstood the proposal, but I think it's vital that the above two use cases are considered. Even if they can't be solved outright, providing tools that custom solutions to these cases can be built with should be a priority for multi-db support. Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: {GSoC 2008}Django-Newcomments : A preview
Hello,
I was checking out the project.. So far it looks very good =)
A question though:
I noticed the comments retreived by {% get_comment_list ... %} are
ordered by pk. Is there any plan to include custom ordering? I believe
the default ordering should include replies to old comments after the
objet it refers since I dont see any case in which it would make sense
to have the replies away from the objects being replied upon.
I'll try to play around with your project when I get the time :)
good luck,
On Thu, May 22, 2008 at 10:36 AM, Thejaswi Puthraya
<[EMAIL PROTECTED]> wrote:
>
> Hello folks,
> My exams got done in the first week of May. I was feeling quite bored
> and so started working on the project.
>
> I completed a few items from the Todo list but need to complete the
> documentation and write more tests.
>
> The code for my project is at
> http://code.google.com/p/django-newcomments/
> and at
> http://gitorious.org/projects/django-newcomments
>
> I also have put up the four demos in the source at:
>
> Demo-1: Using django-newcomments as a standalone app.
> http://sandbox.thejaswi.info/example1/authors/
>
> Demo-2: Using django-newcomments placing it in django.contrib.comments
> (after removing the current django.contrib.comments)
> http://sandbox.thejaswi.info/example2/books/
>
> Demo-3: A simple threaded comments demo (inspired from Eric
> Florenzano's project).
> http://sandbox.thejaswi.info/example3/comics/
>
> Demo-4: A custom comments demo
> http://sandbox.thejaswi.info/example4/messages/
>
> Current Problems faced:
> * Abstract models don't allow custom managers. Tickets 7154 and 7252
> handle that (I am running trunk patched with ticket 7154).
> * Abstract models don't allow the inheritance of the inner admin
> class. After a discussion on IRC, I was assured that this was a small
> issue that newforms-admin would cover after it supports model-
> inheritance. Till then an abstract model designer cannot pass on a
> neat admin UI to the user :(
>
> Please do let me know of any suggestions/criticisms and/or feedback.
>
> --
> Cheers
> Thejaswi Puthraya
> http://thejaswi.info/
> >
>
--
Nicolas Lara
Linux user #380134
Public key id: 0x152e7713 at http://keyserver.noreply.org/
# Anti-Spam e-mail addresses:
python -c "print '@'.join(['nicolaslara', '.'.join([x for x in
reversed( 'com|gmail'.split('|') )])])"
python -c "print '@'.join(['nicolas', '.'.join([x for x in reversed(
've|usb|labf|ac'.split('|') )])])"
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---
Re: Multiple database support
Hi all, I've now re-applied Daryls patch (which was against qsrf) to a clone of django trunk in a mercurial repo. It's available at http://hg.woe-beti.deand there's a trac set up for it at http://trac.woe-beti.de. Feel free to make use of both of these. Although I've disabled to ability to create tickets perhaps the wiki might be a good place to discuss the API? Anyone can clone from the hg repo, give me a shout if you would like push access and I'll sort it out. Cheers, Ben -- Regards, Ben Ford [EMAIL PROTECTED] +447792598685 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
Simon Willison wrote: > Thankfully Ivan Sagalaev's confusingly named mysql_cluster BTW does anyone have a suggestion how to rename it? I've picked mysql_cluster simply because I didn't know that there exists the thing named "MySQL Cluster" (no kidding :-) ). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Manager-model reassignment on abstract subclassing
> > > There's a similar ticket to this at 7154 (http:// > > > code.djangoproject.com/ticket/7154). It has a patch that works > > > but I am not sure if it is the most elegant method. I am the author of #7154 and its patch. I thought first that it is possible to fix this problem with less code if this is your understanding of elegant. But I had to note that it isn't. ;-P Look at #7252. The patch of this ticket adds only 2 lines. But it is just an ugly hack. As Eric already noted it does not gets to the root of the problem. The descriptor object's __get__ method is not the place to handle such a case. The contibute_to_class method is the way to go. But because of when contribute_to_class is called for the abstract base model, we can not yet add the manager to the derived models. We have to store the attribute name of the manager in the model options. So the metaclass can handle this when deriving from an abstract model with custom managers. It think this is the most clean and reliable way to solve this problem. But improvement purposes are welcome. ;) > > Whoops! Sounds like we're talking about the same thing. I thought > > based on the summary that it was a different problem, because the > > manager actually _does_ get copied over, but it just needs a slight > > modification. As far as I know it was only present in derived models because of derived models inherits all managers from the parent abstract model. But it is no "copied" as done by _copy_to_model, which was the reason for the behavior of inherited managers. > > I do tend to like the implementation on that ticket better, as it > > gets closer to the root of the problem. Are there any > > disagreements about whether that patch should be applied? Thanks. Although I wrote this patch, I have a disagreement. ;-P Tests are still missing. But I think I can wrote some test cases at the weekend or during next week. Regards Sebastian Noack signature.asc Description: PGP signature
Re: HTML in Admin.fields 'description'
Hi Luke, On Mon, May 19, 2008 at 2:38 PM, Luke Plant <[EMAIL PROTECTED]> wrote: > > The 'description' option in Admin.fields is currently broken with > respect to the documentation, due to autoescape. See: > > http://www.djangoproject.com/documentation/model-api/#description > > I propose fixing the documentation, not the code, since you can just > use 'mark_safe' if you don't want it to be escaped. > > If anyone disagrees, let me know, otherwise I'll fix it and add it to > BackwardsIncompatibleChanges. > Sorry for not seeing your email message before. When I saw changeset 7545 I tried searching Trac for some related open ticket that could be closed. What I found instead was changeset [1]7078. Doesn't it make the part about using mark_safe() of your change to model-api.txt a bit unnecesary or misleading?. Regards, -- Ramiro Morales 1. http://code.djangoproject.com/changeset/7078 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: HTML in Admin.fields 'description'
On Thursday 22 May 2008 19:46:34 Ramiro Morales wrote: > Hi Luke, > > When I saw changeset 7545 I tried searching Trac for some related > open ticket that could be closed. > > What I found instead was changeset [1]7078. > > Doesn't it make the part about using mark_safe() of your change to > model-api.txt a bit unnecesary or misleading?. Hmm, something funny here... I didn't actually check the template code, but was simply noticing that my HTML was being escaped. But why...? ...ah, because I'm using a custom override for one of my admin templates, which hadn't merged in changeset 7078! My bad. Thanks for catching this. I'll revert my change to the docs. Cheers, Luke -- There was a young man from Peru Whose limericks stopped at line two. Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: QuerySet.update improvement.
On Wed, 21 May 2008 21:12:05 +0800 "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > What do I think? The code doesn't look fundamentally bad, but I'm not > going to take a serious look until there are some test cases. > > Consider this from my point of view. I need to validate that your code > works as advertised. As your patch currently stands, I need to write > my own test cases, including coming up with some models, some test > data, and thinking about the edge cases that need to be checked. This > takes time - time that could be spent looking at someone else's code, > merging someone else's patch. Given that my time is limited, and there > are multiple demands on my time, it makes sense for me to concentrate > on those patches that make my life easy, and enable me to process as > many tickets as my limited time allows. > > Like I said last time, test cases are how you prove you are serious. > It's how you prove to me that you've done more than a trivial analysis > of the problem. It's how you prove to me that you've considered the > edge cases. And for your own sanity, it's how you prove to yourself > than when you make one of those "minor, this couldn't possibly affect > anything" changes, that it actually doesn't change anything. I know that tests are essential and if you look at the ticket, you will see that I have added a new version of my patch including doc tests. ;) I know what you think about patches adding new functionality but don't providing test cases. And I completely agree. But you should see my previous patches on this ticket just as proof of concept to help as to discuss the functionality, its implementation and API. During writing the tests i came up with a few bugs and fixes: (1) I figured out that <<, >> (left and right shift) and ~ (inversion) is (at least in MySQL) not supported, when selecting from tables. So I decided to drop support for this corner case. (2) I ensured that when using update(), get_db_prep_save() is called. get_db_prep_lookup() is called anyway, but for example when using DateTimeField and MySQL, get_db_prep_save() (as opposed to get_db_prep_lookup) truncates microseconds because of missing support in MySql of microseconds, so this must be done also on update. (3) I added a sanity check to update(), preventing updating sliced query sets, because of calling update() on a sliced query set will update all objects. Do not think about implemeting this feature. Although some DBMS might supports UPDATE with LIMIT and OFFSET, many don't or support only LIMIT (as MySQL for example). Note that (2) and (3) are bugs not introduced, but fixed by my patch. Another reason for merging it. ;) Regards Sebastian Noack signature.asc Description: PGP signature
Re: QuerySet.update improvement.
I just updated to your latest patch and there appears to be 2 test failures: http://dpaste.com/52137/ , the first one appears to be caused by the fact that different database engines do the rounding differently, my suggestion would be to change to something that divides evenly for the integer value. Also instead of using eval, I would take a look at the operator module, and use operator.add, etc... . The second test failure looks to be caused by something being changed in the ORM, unfortunately, I'm not sure what caused it. Alex On May 22, 3:01 pm, Sebastian Noack <[EMAIL PROTECTED]> wrote: > On Wed, 21 May 2008 21:12:05 +0800 > > > > "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > > What do I think? The code doesn't look fundamentally bad, but I'm not > > going to take a serious look until there are some test cases. > > > Consider this from my point of view. I need to validate that your code > > works as advertised. As your patch currently stands, I need to write > > my own test cases, including coming up with some models, some test > > data, and thinking about the edge cases that need to be checked. This > > takes time - time that could be spent looking at someone else's code, > > merging someone else's patch. Given that my time is limited, and there > > are multiple demands on my time, it makes sense for me to concentrate > > on those patches that make my life easy, and enable me to process as > > many tickets as my limited time allows. > > > Like I said last time, test cases are how you prove you are serious. > > It's how you prove to me that you've done more than a trivial analysis > > of the problem. It's how you prove to me that you've considered the > > edge cases. And for your own sanity, it's how you prove to yourself > > than when you make one of those "minor, this couldn't possibly affect > > anything" changes, that it actually doesn't change anything. > > I know that tests are essential and if you look at the ticket, you will > see that I have added a new version of my patch including doc tests. ;) > > I know what you think about patches adding new functionality but don't > providing test cases. And I completely agree. But you should see my > previous patches on this ticket just as proof of concept to help as to > discuss the functionality, its implementation and API. > > During writing the tests i came up with a few bugs and fixes: > > (1) I figured out that <<, >> (left and right shift) and ~ (inversion) > is (at least in MySQL) not supported, when selecting from tables. So I > decided to drop support for this corner case. > > (2) I ensured that when using update(), get_db_prep_save() is called. > get_db_prep_lookup() is called anyway, but for example when using > DateTimeField and MySQL, get_db_prep_save() (as opposed to > get_db_prep_lookup) truncates microseconds because of missing support > in MySql of microseconds, so this must be done also on update. > > (3) I added a sanity check to update(), preventing updating sliced > query sets, because of calling update() on a sliced query set will > update all objects. Do not think about implemeting this feature. > Although some DBMS might supports UPDATE with LIMIT and OFFSET, many > don't or support only LIMIT (as MySQL for example). > > Note that (2) and (3) are bugs not introduced, but fixed by my patch. > Another reason for merging it. ;) > > Regards > Sebastian Noack > > signature.asc > 1KDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Multiple database support
I think there is a third issue. Usage of several RDBMS in one django application simulatneously For example we maintain two RDBMS: monetdb and postgresql. The latest and most accessed data is stored in monetdb for performance. After one month data is moved to posgresql which holds the full archive. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: QuerySet.update improvement.
On Thu, 22 May 2008 14:20:26 -0700 (PDT) "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > I just updated to your latest patch and there appears to be 2 test > failures: http://dpaste.com/52137/ , the first one appears to be > caused by the fact that different database engines do the rounding > differently, my suggestion would be to change to something that > divides evenly for the integer value. Can you tell me which db engine you was using when the test failed? > The second test failure looks to be caused by something being changed > in the ORM, unfortunately, I'm not sure what caused it. I am pretty sure that this is not related to my patch. I get the same failure, and as far as I know I got it even before I wrote the patch. Thanks for testing. Regards Sebastian Noack signature.asc Description: PGP signature
Re: QuerySet.update improvement.
I'm testing on SQLite, and I don't get that failure when running on vanilla trunk. On May 22, 6:57 pm, Sebastian Noack <[EMAIL PROTECTED]> wrote: > On Thu, 22 May 2008 14:20:26 -0700 (PDT) > > "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > I just updated to your latest patch and there appears to be 2 test > > failures:http://dpaste.com/52137/, the first one appears to be > > caused by the fact that different database engines do the rounding > > differently, my suggestion would be to change to something that > > divides evenly for the integer value. > > Can you tell me which db engine you was using when the test failed? > > > The second test failure looks to be caused by something being changed > > in the ORM, unfortunately, I'm not sure what caused it. > > I am pretty sure that this is not related to my patch. I get the same > failure, and as far as I know I got it even before I wrote the patch. > > Thanks for testing. > > Regards > Sebastian Noack > > signature.asc > 1KDownload --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: {GSoC 2008}Django-Newcomments : A preview
Hi Thejaswi. A couple of suggestions: Any reasons for having CommentFlag.flag being a string, and not a foreign key to a FlagType model ? Having them as strings makes it easier to end up with bad data (misspelling and so forth). Of course there is always the performance penalty, but it seems worth it. Also, many times it is useful to keep a "raw" body for a comment (as the user sent it), but also for performance reasons, a "processed" version such as html (from markdown or something else). Maybe keeping both in the db allows for speedier rendering. Then an application can define somewhere (maybe a settings) which function to process the comment (markdown, textile, some home made tag removing routine), and have that run and then persisting both at the database. Thanks Arthur --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: {GSoC 2008}Django-Newcomments : A preview
> Any reasons for having CommentFlag.flag being a string, and not a > foreign key to a FlagType model ? Having them as strings makes it > easier to end up with bad data (misspelling and so forth). Of course > there is always the performance penalty, but it seems worth it. You can do both :-) Have a FlagType model with a string as a primary key, so you only need to set flag_id if you already know what string you want. I have to say, I don't usually mess with custom primary keys in django, and have no idea if there are downsides in using them. Feel free to correct me if this isn't a good idea for whatever reason. Having said that I like the flexible approach of just having a string; unless you need to store other attributes, there are no great benefits. Bad data could be seen as more of a usability problem than a technical one. Cheers, -- Will Hardy w: http://www.willhardy.com.au --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
