Proposal: Widget Templates
Hello folks! Django cares about model-view-controller separation, but the HTML for the widgets is hardcoded in the render method. I would propose to have overridable templates for the widgets, so every project could have specific presentation of widgets in the system (render method should take a template from the file system and render that with some field- specific variables passed). This would allow developers to add specific attributes, javascripts or html containers for all widgets in the project. For example, we had a project, where 4 elements with specific css classes had to be added around each input field to make resizable widgets with rounded corners. Another use case would be to change all select fields to combo boxes (some JavaScript libraries only allow that if you add specific attributes to the select tag). Or adding additional CSS classes to different input types so that all checkboxes could be styled differently than all text input fields. The templates for each widget could be cached somewhere, so the accessing the file system shouldn't be a big performance issue. What's your opinion about that? --~--~-~--~~~---~--~~ 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: Proposal: Widget Templates
On Sat, Aug 23, 2008 at 9:54 PM, Aidas Bendoraitis <[EMAIL PROTECTED]> wrote: > > Hello folks! > > Django cares about model-view-controller separation, but the HTML for > the widgets is hardcoded in the render method. I would propose to have > overridable templates for the widgets, so every project could have > specific presentation of widgets in the system (render method should > take a template from the file system and render that with some field- > specific variables passed). ... > What's your opinion about that? As with all suggestions for enhancements at the moment, the opinion is "please wait". We're currently in the process of finalizing the v1.0 release, and not really in a position to give a good analysis of feature proposals. If you wait a few weeks until the dust has settled on v1.0, we will be able to give your proposal the attention it deserves. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ 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: Oracle IntregrityError and get_or_create test case
On Aug 22, 5:56 pm, Justin Bronn <[EMAIL PROTECTED]> wrote: > FYI, r8471 fixed my problems and all Oracle GeoDjango tests pass > again. Thanks. That's good news, Justin--thanks for verifying! (I have access to 9i and 10g servers--not just XE--but spatial isn't licensed for any of them so I had to cross my fingers.) To follow up on the get_or_create failure, where the cx_Oracle driver raises a more generic DatabaseError instead of an IntegrityError when trying to INSERT a row lacking a required column value: Anthony Tuininga, cx_Oracle's author, agreed that ORA-01400 should map to IntegrityError and already commited that change to his trunk C code. (Thanks, Anthony!) So now we can fix the test case in theory by checking the backend and driver version, and if it's 4.4.0 or earlier, we can continue to fail with "Fail: this version of cx_Oracle incorrectly raises DatabaseError" or the like. However, I grep'ed the Django source and found two cases where we catch IntegrityError specifically. cx_Oracle probably misbehaves there currently, but I'm not sure how common these code paths are and what errors could result. Currently, our docs say we require cx_Oracle version 4.2.1 or later. It's not reasonable to expect Django users--especially ISPs and corporations-- to upgrade to svn trunk and build the driver. We could ask Anthony to do a hurry-up 4.4.1 release with this fix in it, but even so it's a lot to ask everyone to upgrade to a brand-new driver version. On the other hand, we're not talking about a large number of Django/Oracle users currently, but that should change when we have an official 1.0 release. Opinions? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
#7443, #8453 and the timesince filter
Hi all, In [8481], I committed a fix for #7443, dealing with a problem with the timesince filter. About 20 minutes after I committed it, I became aware of #8453, which is the same problem - except that #8453 suggests that there has been a bigger discussion, and the ticket was closed 'invalid'. I've reverted [8481] while we sort this out. In the ticket for #7443, Andrew makes some reasonable points. As the filters currently stand (using earlier,now,later as 1 week prior, present and 1 week future): earlier|timesince: 1 week earlier|timesince:now: 0 minutes earlier|timeuntil: 0 minutes earlier|timeuntil:now: 0 minutes later|timesince: 0 minutes later|timesince:now: 1 week later|timeuntil: 1 week later|timeuntil:now: 1 week There are two interesting features of these results: * mydate|timesince:now is equivalent mydate|timeuntil:now. * mydate|timesince should be equivalent to mydate|timesince:now The docs suggest that if you provide an argument to timesince, that argument will be used as the point of comparison; if you don't, 'datetime.now()' will be used as the point of comparison. However, if you use 'datetime.now()' as the argument, you don't get the same behavior as if you had omitted the argument and got the default value. I had a quick chat with James Bennett on IRC before I committed [8481], and he came to the same conclusion that I did - the current behavior is an error, and while the change required is a backwards compatible one, it would be better to fix it, rather than have to try and explain the discrepancies. My reading is that the 'correct' results should be: earlier|timesince: 1 week earlier|timesince:now: 1 week earlier|timeuntil: 0 minutes earlier|timeuntil:now: 0 minutes later|timesince: 0 minutes later|timesince:now: 0 minutes later|timeuntil: 1 week later|timeuntil:now: 1 week Can anyone fill me in on the rest of the discussion that I have evidently missed? Russ %-) --~--~-~--~~~---~--~~ 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: validator_list still in docs
On Sat, 2008-08-23 at 16:02 +0200, Alex Rades wrote: > Hi, > validator_list in model fields (and maybe in form fields too) isn't > working at the moment. > > Could we remove it from the docs? It will be removed eventually, when all the remaining oldforms stuff is removed (before 1.0). Also, there's a temporary freeze on docs changes at the moment until the docs refactor lands. Regards, Malcolm --~--~-~--~~~---~--~~ 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: Be explicit about which reverse lookup failed after r8211
It is quite common to be hit by the insufficiently verbose reporting that #8221 and #7524 fix -- e.g. see the duplicates that have popped up. As I already said, #8221 is only needed because the patch I provided in #8177 and that got commited fixed only the most burning issue I was directly hit with. Now that I looked around in urlresolvers, I found other places where similar improvements were needed. #8221 covers all them and supersedes #8177. I personally think both should make it into 1.0, but James seems to oppose, so can we discuss this a bit further? Regards, Mart Sõmermaa --~--~-~--~~~---~--~~ 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: Be explicit about which reverse lookup failed after r8211
On Sat, 2008-08-23 at 10:46 -0700, mrts wrote: [...] > I personally think both should make it into 1.0, but James seems to > oppose, so can we discuss this a bit further? The ticket is open. It will either be committed, postponed or closed as a dupe of something else. Let's leave it at that and get some other work done in the interim. Malcolm --~--~-~--~~~---~--~~ 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: Be explicit about which reverse lookup failed after r8211
http://code.djangoproject.com/ticket/7524 is tagged as post-1.0. http://code.djangoproject.com/ticket/8221 was closed as duplicate of #7524, which it is not. On Aug 23, 9:40 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2008-08-23 at 10:46 -0700, mrts wrote: > > [...] > > > I personally think both should make it into 1.0, but James seems to > > oppose, so can we discuss this a bit further? > > The ticket is open. It will either be committed, postponed or closed as > a dupe of something else. Let's leave it at that and get some other work > done in the interim. > > Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
MySQL and Autocommit
Recently I noticed a bunch of queries I was executing by hand (one's which the ORM didn't support) were not being committed. I dug into the docs, and it clearly states that the default transaction mode is autocommit, and mysql's default transaction mode is autocommit. So, my question is, what's going on? I ended up doing set autocommit=1 at the beginning of the queries, but this is a pretty big gotcha. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers
Dear Django developers, The code importing urls.py has a flaw that is easy to fix but has the potential to cause a lot of frustration especially for inexperienced developers -- which I do hope will try out Django in large numbers soon :) The problem is this: When importing urls.py _any_ exception is caught and then re-raised as an ImproperlyConfigured exception, not giving the traceback. This was not that big of an issue until we started to tell people to put admin.autodiscover() in their urls.py. Now a lot of code can get executed from there and if you get an exception you have no clue where it originated. This is especially true if you port a large project to 1.0. I, at least, keep running into it ... but don't take my word for it. I just found a thread [1] on django users on the issue (#7524). To cite Karen Tracey: > I agree that the way ImproperlyConfigured is swallowing traceback > information is not good. It may not have been much of an issue before, but > with admin.autodiscover() now recommended to be placed in urls.py, we are > seeing a lot of confusion resulting from real errors in admin.py being > hidden and the message seeming to imply something is wrong in urls.py. I > don't have time right now, but you might want to search the tracker and see > if there are any already-logged tickets about this less-than-helpful > behavior and if not, open one. Luckily the solution is quite easy. Just let the exception bubbly up (see my patch [2]). It's changing nothing. We don't add any value by wrapping the exception in an ImproperlyConfigured one because we do not know anything about the error in this particular case. Django swallows exceptions at multiple places and it is clear that we need a unified solution. But in this case I think it's special. The code does the wrong thing here. Cheers, Jonas P.S.: I should have brought this up here earlier instead of causing a somewhat lengthy discussion on IRC, sorry for that. I hope James doesn’t hate me after this ;) [1] http://groups.google.de/group/django-users/browse_thread/thread/487d8c3c28eee5f8 [2] http://code.djangoproject.com/attachment/ticket/7524/01-url-import-exception.patch --~--~-~--~~~---~--~~ 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: '"%s/" % var' preferred to 'var + "/"'?
a python string is immutable using the + operation on it causes strings to be copied into memory and made into another immutable string... which doesn;t save much... but the next uses of + requires another copy, and the next so on... where as using % does copy once On Aug 22, 4:49 am, Joost Cassee <[EMAIL PROTECTED]> wrote: > Thanks for all the great info. Usually articles refer ''.join(...) as > the fastest concat operation, but it won't do type coersion of course. > I was interested whether there was a Django standard for this sort of > thing. In any case the '+' operator is discouraged by all. > > Regards, > > Joost --~--~-~--~~~---~--~~ 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: Exception swallowing in urls.py + admin.autodiscover() == a lot of frustration for developers
On Sun, Aug 24, 2008 at 12:53 AM, Jonas Pfeil <[EMAIL PROTECTED]> wrote: > P.S.: I should have brought this up here earlier instead of causing a > somewhat lengthy discussion on IRC, sorry for that. I hope James > doesn't hate me after this ;) I stand by what I said in the dev channel yesterday: this is one instance of a more general issue (there are lots of places where -- because we need to import or check something -- we can end up "swallowing" exceptions in this fashion), one which will require time and thought to deal with, and which should not be tackled piecemeal. Given that, and the fact that there's a lot of much more critical work to do, I think the appropriate time to do that is **after** Django 1.0. This is simple prioritization (and, as others have pointed out to you, the fact that there hasn't been a big flood of bug reports/support problems related to this probably indicates it's not as critical as you're making it out to be). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
