Ticket #2773: django.views.defaults.server_error should use RequestContext
Just a quick note to say I've added a ticket and patch to modify django.views.defaults.server_error to use RequestContext instead of Context, thus making context-processor-generated context available to 500 pages. Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket #2773: django.views.defaults.server_error should use RequestContext
> 500 errors are bad; it's bail out time when they happen. I disagree. For background, I have a context processor which simply pushes a dictionary of standard items, such as URLBASE for media and links, to all templates. It's very unlikely that an error will have occurred which makes this a bad thing to do. Most of the errors that go out of my server are KeyErrors or ValueErrors and such that I've missed. Local errors to the view or the model, these do not affect the context processors. Some context processors could suffer from the same errors that affect the view and model code. Wouldn't it be better to make sure that context processors are written more robustly and fail elegantly? At the same time middleware such as the session mechanics are still invoked, performing complex actions. Why are these safer than the context processors? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Ticket #2773: django.views.defaults.server_error should use RequestContext
Ivan, you're right to note that I can supply my own view. I will do that. James, why are context processors not able to handle exceptions and fall back to basic output, i.e. return an empty dictionary? I don't mean to waste anyone's time with this, I should have looked harder for the previous discussion before filing the ticket. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Using test.client.Client.post with body?
> Client.raw_post(path, payload, payload_type='text/json') +1 I have a testing apparatus, which I built for a pre-MR project, I use it to submit SOAP-style XML requests and all kinds of stuff. I'm looking to port the project to MR and the tests to your test framework at some point in the future, I would need this method to correctly exercise all my views. I'd be happy to help write it, if that would be useful, but I don't think I'll be moving versions for at least a month or two. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
We are definitely interested in sharing, that was our initial intention. The code is by no means finished, but my colleague Tom will post an interim version and some notes on our design soon. Hopefully it will be interesting. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Handling exceptions raised while processing requests from django.test.client.Client
Currently any exception raised by a view or other request machinery while handling a request from the test client is hidden from the requesting test case by Django's exception views (500, error debug). I have created a patch and a ticket for an enhancement which reraises exceptions with the original stack information after request processing has completed. The exception bubbles back up to the test case, which allows the cause to be found and fixed easily. As test cases provide a regression safety net, it is useful to be able to do this. Without the option to inspect exceptions raised during the test run, developers have to recreate the test themselves to get to all the contextual information required to isolate the cause, slowing the testing process significantly. The current patch introduces the code outright, but it could also be made into an option, perhaps with a parameter passed to the Client constructor. http://code.djangoproject.com/ticket/3162 Again, I've assigned the ticket to Russ, as he is the original author of the test client. Ben --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Client.raw_post
A little while ago there was a discussion[1] about test cases that post raw data such as XML or JSON to a view. Russ suggested adding a raw_post method to the test Client to facilitate such tests. I've created a ticket and uploaded a patch that does just this. http://code.djangoproject.com/ticket/3160 I've assigned it to Russ, as he suggested it originally. Ben [1] http://groups.google.com/group/django-developers/browse_thread/thread/273dec9b25569216/d16994bdadf127e8 --~--~-~--~~~---~--~~ 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: Feature request for newforms: HTML 4
This seems a long way to go for the want of removing a few forward-slashes. XHTML has become the defacto standard for Django, which is great, but the vast majority of pages are still HTML 4. So if there's to be one standard it should be 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: Client.raw_post
OK, I've added tests and documentation to the patch and removed the default for the type argument to raw_post. All tests pass with this patch applied to the current Django SVN version. Please let me know if any more changes are needed. Ben --~--~-~--~~~---~--~~ 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: Handling exceptions raised while processing requests from django.test.client.Client
I've attached a new patch and got to the bottom of the test case that failed. I'm not 100% comfortable with my diagnosis and remedy however and I'm happy to look at it again if the solution is problematic. If a ticket master is able to take a quick look at the patch and the notes that would be greatly appreciated! http://code.djangoproject.com/ticket/3162 --~--~-~--~~~---~--~~ 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: Handling exceptions raised while processing requests from django.test.client.Client
Also, I forgot to say, a quick grep of the Django code reveals that the db rollback code is currently the only listener for the got_request_exception signal. I've moved the signal dispatch line outside of the if statement in the base handler with the effect that it is now always dispatched as you suggest. The assumption here is that a DB rollback is not a problematic thing to do when in debug mode. As for the resetting of __builtin__._, what is the expected value during the execution of django.contrib.auth.forms? Is it the standard gettext or django.utils.translation.gettext_lazy? --~--~-~--~~~---~--~~ 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: Some kind of django.contrib.stats?
The problem of server and application level stats is that they are fairly easy to implement and attractive, but they're hideously inaccurate. First you have to ignore robot traffic, then you have to accurately sessionise, then build the reporting interface, which must be very powerful if it is to be useful. Basic stats might keep people happy, but they won't actually help them run a better site. I ran a (tiny) analytics startup for 18 months and I would definitely conclude it makes much more sense to leave it to the big boys! Accuracy is very difficult to test and verify and analytics as a whole takes on a life of it's own compared to the work of developing the application itself. This is a wheel that has been pretty well invented already. --~--~-~--~~~---~--~~ 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: newsessions
> 2. I have an ethernet connection @home and I sometimes log in to our > private web apps from home. Any 'c00l hacker' is able to scan network > traffic, get my session id and use it to join to my session too just > because there is absolutely no checking who uses session. We added ip > checking at our application level code but why don't implement this at > django side as an option ? Noone says this is 100% guarantee of > getting rid of man-in-the-middle, but at least it prevents from > successful hacks from kiddies when using untrusted networks (ie public > wi-fi, ethernet, etc). This is what SSL is for. Tying the session to IP is a usability nightmare, what if I'm half way through a long application process when my wifi goes out of range for a moment and the DHCP server gives me a new IP, or I move from wifi to my cable because I'm moving to my desk, or my DSL provider decides it's time to give me a new IP or I'm browsing from my phone and my IP changes each time I connect? Tying the session to IP provides no extra security and degrades the experience in the common case. Applying SSL adds security and does not degrade the experience. Entropy: Could the RNG be re-seeded when a new session is created? Is it an expensive operation? Could the entire request header be used as entropy? Does not necessarily tie the session model to the request, as the entropy could be an argument to get_new_session_key, and I would imagine 99% of calls to this method come from the process_response method of SessionMiddleware. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Automatic password creation
Hi, After the move to SHA-1 there was a conversation on django-users about the admin interface not being able to generate passwords for new users. http://groups.google.com/group/django-users/browse_thread/thread/ 9fab7fbc34c1575/1dc5c952d8c094cf?rnum=1#1dc5c952d8c094cf Are there any plans to move on this? I looked back through the Trac tickets, but can't find a ticket for this. Adrian said it's in there, so it's just me being bug-blind. If anyone knows the ticket please let me know. For context, I'm currently building a site which will have ~1,000 users. Access is controlled centrally and there's some churn in userbase, so a non-developer will have to create and modify users regularly. Do I have to tell them that Django can't do this? ____ Afternoon, man about the Internet -- http://aftnn.org/
Re: Automatic password creation
Great, thanks. On 1 Dec 2005, at 20:27, Wilson wrote: Here's the ticket you're looking for: http://code.djangoproject.com/ticket/61 ____ Afternoon, man about the Internet -- http://aftnn.org/
Ticket #714
I'd like to have a go at creating a fix for ticket #714: access to id of current user on admin. I have no idea what I'm doing though. Could anyone offer some guidance on how I might go about solving this problem? ____ Afternoon, man about the Internet -- http://aftnn.org/
Re: "Magic" model module change proposal
On 6 Dec 2005, at 20:54, Robert Wittams wrote: 1) For the model class defined by the user to 'just work' for everything This is probably useless cruft in a very involved debate, especially as newbiedom has become slightly politicised, however... As a very green Django programmer, I'd like to +1 everything working in a totally predictable Pythonic way. I'm neither a Python newbie or a web app newbie however and I think newbie web coders who don't understand Python completely should learn the rules right first time and should be able to turn to the body of literature on Python to do that. It will make it easier for them to do everything else they need to do, instead of having one rule for Django and one for Python. The biggest gotcha however is the django.models.* magic IMHO, so it will be great to move away from that anyway. ____ Afternoon, man about the Internet -- http://aftnn.org/
Re: Ticket #714
Was thinking about #714 - access to id of current user on admin - in the context of the auto_now_now and auto_add options on DateField. The meta options auto_creator and auto_editor could be added. auto_creator sets the value of a field to the current admin user on INSERT, auto_editor sets that value on INSERT and UPDATE. However, auto_now and auto_now_add work because they're part of the DateField type and a user field is just a ForeignKey to User. Extending ForeignKey in this way would be wrong. Would the best way to add this feature be to create a new Field type, called something like UserForeignKey, which can then accept the new options? Would this be a good place to put anything else? Afternoon, man about the Internet -- http://aftnn.org/
Re: Django Ajax Redux
On 10 Dec 2005, at 13:49, hugo wrote: Let's try something different and first provide problem solutions, and _then_ extract a framework out of them. +1 Afternoon, man about the Internet -- http://aftnn.org/
Re: Potentially confusing urlconf error messages
On 12 Dec 2005, at 3:20, pbx wrote: I thought someone else might have a more clever approach. Not particularly clever, but in a Django request context you could argue that "//" == "//" == "/" and change the url pattern logic appropriately. ____ Afternoon, man about the Internet -- http://aftnn.org/
Re: HttpResponseRedirect and relative URLs
I have a similar problem, app dev is at http://localhost/myapp/, deployment is at http://mywebsite.com/. I have added an URLBASE to settings.py and that's imported and used throughout my app. It would be nice for this to be created automatically by Django and made available through the API. Then again, I do use it in model get_absolute_url methods, which it wouldn't be exposed to if it goes through the request. On a related point, how does get_absolute_url fit with the notion that models don't know about requests? This seems a violation of the oft-upheld principal to me. How come _pre_save can't know about the current user in the admin, but the same object is expected to know where the user should send requests to view this object? Is another layer required, one that handles all model functions for request contexts. The underlying model can be kept "pure" but better request- model interaction can be facilitated, taking inspiration from Zope3 adaptors perhaps. On 13 Dec 2005, at 12:53, Amit Upadhyay wrote: Hi, I am developing an application and am soon going to deploy on another server but the URLs won't be exactly the same. There are many places I have to construct URLs, for linking to other pages in my application as well as for redirecting, and it is not clear to me how to do it in a portable fashion. One solution is to put a setting in settings.py, but is there another more standard way to specify what relative location my application will be deployed? I use 'include' and put my urls in my apps urls.py, and documentation says: At any point, your urlpatterns can "include" other URLconf modules. This essentially "roots" a set of URLs below other ones. If I could get this "root", it would be much more DRY than to define the 'root' and use another setting. Run the 'root' through s/ \^/\// before using it. More concrete proposal: Request contains a member: request.root, this contains urlregex encountered when an include was called; after a match has been found. This poses a problem of what to do if more than one includes are called as I believe its technically possible, and one solution might be either to make request.roots a list of strings, or django itself passes them through s/\^/\// and concatenates them together, which can directly be used by views to generate absolute URLs. -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9867-359-701 ** Cohack ** Pay-per-click campaign measurement, dashboard and analysis tools for online businesses. Customised Excel performance reports regularly emailed to key stakeholders. http://www.cohack.com/?src=bgsig
Context.__contains__
I wanted to do "blah" in context in a custom tag and found it didn't work. I patched django.core.templates.Context, adding a __contains__ method. The patch is below. I didn't want to raise a ticket for this as I'm not familiar with the other bits that are going on with the class, or even sure that I've patched the right class. Should this go in DjangoContext, for example? Anyway, hope this is helpful. Index: django/core/template/__init__.py === --- django/core/template/__init__.py(revision 1612) +++ django/core/template/__init__.py(working copy) @@ -183,6 +183,12 @@ return dict[key] return '' +def __contains__(self, key): +for dict in self.dicts: +if dict.has_key(key): +return True +return False + def __delitem__(self, key): "Delete a variable from the current context" del self.dicts[0][key] Afternoon, man about the Internet -- http://aftnn.org/
Re: Admin URLs in magic-removal branch
On 15 Dec 2005, at 3:15, Adrian Holovaty wrote: /admin/myproject/blog/entry/add/ +1, most readable, most compact, most guessable. The problem with "/admin/myproject.blog.models.entry/", though, is I'm not sure it's possible to get the Python path *to* an object. For example, given a model Entry, how do we get the string "myproject.blog.models.entry"? obj.__module__ + "." + obj.__class__.__name__ Another solution could be "/admin/blog/entry/", where "blog" is the app name (blog/models.py) and "entry" is a lowercased version of the model class name. The disadvantage of this is (obviously) the app namespace is only one-level deep. Granted, these disadvantages have been present in the old system and haven't bitten us. As Django matures and more apps arrive, namespace clashes are going to becoming more likely, I think it's important to build namespace scope in now. I fully support making everything namespaced to the project and the app. Afternoon, man about the Internet -- http://aftnn.org/
Re: Admin URLs in magic-removal branch
On 15 Dec 2005, at 3:59, Adrian Holovaty wrote: Clearly we would want to avoid that. Before importing, it could check that the module is in INSTALLED_APPS. By going with /admin/project/app/model/add/ stick with more normal looking urls, you can do the checking at quite a fine-grained level, plus you get a few nice things such as the ability to add pages at intermediate points. You could stick a handy status page at /admin/ project/ for example. /admin/project/app/ would look like the current admin home page, but with only models defined in the specified app. Useful for bigger sites, actual admins go to /admin/ and can control a bunch of stuff. Lesser admins, e.g. content editors, could just be pointed at /admin/mycmsproject/cms/. Afternoon, man about the Internet -- http://aftnn.org/
Re: django.shortcuts (was Re: Proposal: Django namespace simplification)
from django.core.exceptions import ObjectDoesNotExist, PermissionDenied ? I raise this if somebody GETs to a POST-only view or vice-versa. On a related note (but probably on the wrong list), what exceptions do people raise to push errors back to the browser? I have a RESTful application with no interface, what's the best way to send out a 500 error in the event of a missing query parameter for example? Another example might be a database failure. On 18 Jan 2006, at 0:23, Joseph Kocherhans wrote: from django.http import Http404, HttpResponse, HttpResponseRedirect from django.core.exceptions import ObjectDoesNotExist from django.template import Template from django.template.context import Context, RequestContext from django.template.loader import get_template, select_template, render_to_string from django.forms import FormWrapper from django.core.extensions import render_to_response, get_object_or_404, get_list_or_404 Afternoon, man about the Internet -- http://aftnn.org/
