|
Posted by cwurld  |
|
|
Hi,
I just turned on some of my middleware and it is not working well with the sphene middleware. I have middleware that calls a "process_request". This middleware can call the RequestContext function. That executes the context processors, one of which is 'sphene.community.context_processors.navigation'. This processor expects request to have the attribute called "attributes". But the attribute request.attributes does not get created until the middleware 'sphene.community.middleware.GroupMiddleware' executes. Because this middleware is a "process_view", it does not get called until all the "process_request" middleware gets called. So I cannot solve this problem by re-arranging the middleware. For now, I have solved it by adding the code: if not hasattr(request,'attributes'): return to the sphene context processor. Your thoughts? Chuck |
|
|
Posted by Herbert Poul  |
|
|
hmm... that's a good point, haven't thought about that ..
when exactly is this middleware directly returning a RequestContext ? what happens then ? is the normal site displayed with an error or something ? would you need the information in the templates provided by the 'navigation' context processor ? (like the 'group' object, or the loaded navigation, ...) ? Hey, we have Signatures !!! Great, isn't it ? ;) |
|
|
Posted by cwurld |
|
I am not sure I understand your question. I have middleware that has the code:
return render_to_response("an_error.html", {'date':'an error message'}, context_instance=RequestContext(request)) that is executed when certain conditions are not met. To make that template work, I need to run my context processor. That's when I run into problems with the sphene context processor.
I think it is best for everything outside of sphene to not try to access items that are internal to sphene. So I would not depend on the sphene navigation context for anything outside of sphene. That's why effectively skipping the sphene context processor ( with "if not hasattr(request,'attributes'): return") seems like the way to go. By the time items that need this context are run, "request.attributes" should be defined. As an aside, adding the attribute called "attributes" to request seems a little dangerous to me, especially with dictionary keys like "group". With names like that, it seems too likely that other apps could use these names as well and conflict with sphene. Its probably a lot of work to change this. But it might be worth it if you want sphene to be widely used. Thanks, Chuck |
|
|
Posted by Herbert Poul |
|
|
i don't think it would be much of a problem to change the name of 'attributes' .. IIRC it is only used as a mean to communicate between the middleware and the context processor .. and i only use it since i haven't had thread locals added at that time.. i guess now it would be easier to just call get_current_group() instead of relying on the 'attributes' dictionary ...
i see that different.. the community application contains a couple of general purpose functionality which might be useful even outside of sphene .. i don't see a reason why it wouldn't be possible to use the navigation for anything on your site .. (of course.. the navigation is very simple and has basically no useful features.. but it fits my needs for now.. if you need more let me know...) i also think the templatetags could be useful for other applications .. like sph_date .. or sph_fullusername so this stuff is always displayed the same on your whole page.. especially once i get to add user settings so users can chose their date format/timezone and stuff.. or viewing a users profile .. i don't see the community application as just sphene-internal .. because quite a few things make only sense if they look the same on the whole page.. Hey, we have Signatures !!! Great, isn't it ? ;) |
|
|
Posted by cwurld |
|
So you would drop the reqest.attributes dict? It seems like that would solve the problem I am running into. Would you also have to modify the line:
'urlPrefix': request.attributes.get('urlPrefix', ''),
Ok - thanks for clarifying. Chuck |
|
|
Posted by Herbert Poul |
|
actually.. the urlPrefix is also deprecated ;) .. (sorry, SCT is more or less my first django project.. so .. quite a few things changed while i learned about django ;) )
i now use get_absolute_url() & co which would use 'permalink' to resolve to a URL .. so i don't see a reason to keep urlPrefix.. i've did a quick grep through the templates and haven't found a single occurrence .. so.. this line could be removed without any replacement .. the only problem that remains is that the thread local get_current_group() won't be set either.. so if you would need any navigation (or other group-specific settings) on this ?error? page - or whatever your middleware would display - we have a problem.. otherwise.. it should be solvable without too much hassle .. btw. couldn't you modify your middleware to be a process_view(..) middleware ? i guess it would be a bit slower (by 0.001 secs or so ;) ) but other than that.. i can't think of any disadvantages .. ? Hey, we have Signatures !!! Great, isn't it ? ;) |
|
|
Posted by cwurld |
|
I think process_request() is what I need. The processing I am doing is based on the request not the view.
The problem is the combination of process_request() and RequestContext(request). I think that combination could be pretty common because the middleware is going to either pass thru or return an HttpResponse. If you want to throw some data into the html, then RequestContext comes into play. It seems to me that ultimately it would be best if sphene did not put unnecessary constraints on the middleware for other apps. You know your code much better than I, so I'm not sure it makes sense for me to suggest how to accomplish this. Sorry to be such a pain. I appreciate your willingness to share your code and your openness to discussing your code. Thanks, Chuck |
|
|
Posted by Herbert Poul |
|
i don't think this is possible. i require a process_view middleware to extract the 'groupName' from the view's request parameters. It is not accessible in process_request middlewares, because the groupName is defined in the URL configuration. Hey, we have Signatures !!! Great, isn't it ? ;) |
|
|
Posted by cwurld |
|
I solved the problem by adding another middleware module that is the first one that is run. Here is the content:
class SpheneSetup(object): def process_request(self, request): request.attributes = { } This allows me to run all my middleware as is. I also do not have to edit any of the sphene code, which should make updating sphene easier. |
|
|
Posted by Zeke Harris |
|
|
This ended up being a problem for me, too. Sphene got in the way of some of the other apps I was using, such as flatpages and databasetemplateloader. cwurld's \SpheneSetup fixed it. Maybe this fix should be integrated into Sphene natively so that we can not worry about screwing up other middleware? --- Last Edited by thalin at 2007-06-07 23:27:42 --- What? You wanted a sig? |
Please login to post a reply.
