use_for_related_fields and filtering results - really a no-go?
hi, the documentation for use_for_related_fields states that it shouldn't be used for filtering results: http://docs.djangoproject.com/en/dev/topics/db/managers/#do-not-filter-away-any-results-in-this-type-of-manager-subclass i just wanted to know if this advice should always be followed (or when it makes sense not to follow it?) :) i have a reasonable simple 'Post' model in my forum software (http:// sct.sphene.net/) which has a property 'is_hidden' which is usually 0 for normal posts. but for example for drafts i create new Post objects with is_hidden = 1 - e.g. when a user uploads attachments which i require to link to the Post before the user is done writing and submitting his post.. (another example would be when an admin deletes a Post - it is not removed from the database, but instead set to be hidden) so .. if is_hidden != 0 it should be like the Post instance doesn't exist - and should never be returned - except in one or two places (like when changing from draft to published state) so what should i do? add a filter for is_hidden = 0 whereever i access a list of posts through a related field, or is that a case where i can ignore the advice in the documentation? thanks, herbert p.s. the problem came up here: http://code.google.com/p/sct-project/issues/detail?id=186 - code for my not so simple Post object is here: http://source.sphene.net/wsvn/sct/communitytools/trunk/sphenecoll/sphene/sphboard/models.py -- 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: Comparing discussion forum apps
hi, i have tried to fill out the table for my project (sphene community tools). but.. umm.. "500 Internal Server Error (Submission rejected as potential spam)" to sum it up: On Feb 25, 7:15 pm, akaihola <[EMAIL PROTECTED]> wrote: > - posting without registration yes, can be configured (if captures are enabled, anonymous users have to answer them) > - moderation before publishing the messages currently no - it is actually implemented in the models that messages can be set to be hidden and this is already honored when showing threads and posts - but a admin UI is missing so moderators could approve messages and it would require changes in the code to make newly created posts hidden by default .. > - e-mail notification (at least for the administrator) only for registered users hope this answers your questions ;) .. don't let that hinder you from trying out SCT yourself ;) cu, herbert p.s. this was my modification: http://sct.sphene.net/wiki/show/Board/"; title="Sphene Community Tools">Sphene Herbert Poul yes (including captures) email (for registered users) no --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Experimental port of Django to Java
On Jan 4, 9:28 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > newforms, etc.). I choose to use Hibernate and Freemarker for the > Model and Template but these could be easily switched out. since you are working with hibernate you might also be interested in my project where i tried to port the django auto admin interface to hibernate: http://hibernate.sphene.net/ - for an example see here: http://sphene.net:8080/HibernateAutoAdmin/ (demo/demo) it is still very experimental .. but most basic features work quite smoothly :) cu, herbert http://sct.sphene.net/ --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Extensible django applications
Hi,
a while ago i have written a similar question:
http://groups.google.com/group/django-users/browse_thread/thread/b42239bcfb85e21f/0ec972719fbde390#0ec972719fbde390
and beside an extensible view for profiles i have now also added a few
extension mechanisms for my forum application (http://sct.sphene.net)
- this allowed me to create a decoupled "link list" application which
is based on my forum - since i'm not really a python expert i would
love to get feedback if this is the best way to do it ..
there are basically four parts in this extension mechanism:
1. create a registry where applications can add their specific
extension classes (in my forum these are "Category Types")
2. add a hook to the post view to let the "category type" modify the
newforms-PostForm and add custom fields
3. add a hook to the post view to let the "category type" handle
saving of custom fields
4. add hooks to let the "category type" use different template files
a bit more description:
ad 1.) this is basically:
http://yourhell.com/wsvn/root/django/communitytools/trunk/sphenecoll/sphene/sphboard/categorytyperegistry.py
- all applications would then add their subclasses of 'CategoryType'
in their __init__.py file. the 'Category' model then has a
category_type field which contains the name of the CategoryType.
ad 2.) here is an example implementation:
http://yourhell.com/wsvn/root/django/communitytools/trunk/sphenecoll/sphene/sphlinklist/categorytype.py
which makes a linklist out of a forum category - the method
"get_post_form_class" would return a specific "LinkListPostForm" which
is extended from the forum's PostForm and simply adds a "link" field -
it also reorders the fields using:
self.fields.insert(1, 'link', self.fields['link'])
ad 4.) i simply have functions like "get_show_thread_template" which
would return the path and name of a template which should be
rendered.. this is usually extends from the default template and
overloads a few {% block %}'s
so .. my questions would be:
is this the right "django way" of allowing extensions for an
application ? is it useful to let applications add their classes from
an __init__.py file ? or would it be better to assume that every
extension would have a module named 'categorytype' in the
application's module ? ie. the forum would then iterate through all
applications to look for an 'categorytype' module ? would this be
better than to expect applications to register extensions themselves ?
- or simply using signals for extensions - as i've used for the
profiles: http://sct.sphene.net/wiki/show/Community/UserProfiles/
and for newforms: is this a "valid" usage ? simply modifying the
"fields" object .. or would it be better to create a complete separate
form for the extension ? - i guess it impacts performance a bit
because i _always_ modify "fields" for each instance, on every request
instead of just modifying "base_fields" once (would this be somehow
possible ? i guess not ?)
it would be great if anyone could give me a hint if this is a good
approach or if it has some fundamental problems i haven't thought of.
thanks in advance & cu,
herbert
http://sct.sphene.net/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Will there be a django 0.97 release ?
On Nov 9, 12:41 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> release, remain valid. It might sound harsh, but nothing's changed since
> then. It's very time consuming to go around again on this topic (in
> fact, it will slow down the next release, and I gather people in this
> thread want that as soon as possible).
sorry for bringing this up again, as i said .. i searched the forum
but couldn't a satisfieing thread (probably i didn't search long
enough)..
i didn't want to offend you by saying that i feel like the release
could take another year.. this is just what i think, since i don't
know any status.. and looking for information about it gets me the
same results as 4 months ago ("when it's done" as i understand it ..
maybe i'm misinterpreting .. but not deliberately ;) )
thanks again for your time,
herbert
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Will there be a django 0.97 release ?
On Nov 9, 2:58 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > work towards 1.0. Trust me on this: the maintainers want to get it out > the door as much as you do. i'm sure they do .. but my "fear" (or .. guess) is that it might be more important to be bug-free and stable for such a big milestone as a 1.0 release (especially if the promise is that it should be API-stable afterwards), that there won't be one for another year .. anyway, thanks for your responses, i'll simply recommend everyone to use the trunk version as long as there is no new django release .. cu, herbert --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Will there be a django 0.97 release ?
On Nov 8, 10:53 pm, RajeshD <[EMAIL PROTECTED]> wrote: > I understand the concern, but how does having a 0.97 release change > this for you? There would still be potentially backwards-incompatible > changes moving forward from 0.97 to the next official release. of course there will be backwards-incompatible changes afterwards .. but it would be much easier to keep up with those.. or support both.. i'm not sure when 0.96 was released, but probably >7 months ago .. if there would be an 0.97 release i could create a SCT release and probably stay compatible with django for a couple of months .. > If you just want to be able to announce which snapshot of the Django > trunk your application supports, you could point to the svn release > number (e.g. app supports Django trunk svn release #6650 and that > future releases are not guaranteed to work.) as far as i understand it, django applications are ment to be pluggable.. how big are the odds that you'll find two applications which would work with the same django trunk revision ? SCT is not (just) meant as a final product which runs separately, but as applications which can be integrated into a django project.. i can't force people to use a given revision .. having a release which holds for 2-4 months would make things easier imho .. cu, herbert --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Will there be a django 0.97 release ?
Hi, Sorry if these questions are getting boring since everyone wants to know when the next release (and 1.0) is released .. but i haven't found a answer by searching the forums... After so many backward incompatible changes it would be really nice if there would be a new django release. I want people to use my project (SCT: Sphene Community Tools) but i'm not able to keep up two versions and backport all new features.. it is kind of understandable that not everyone wants to use the latest trunk just to use SCT... (There are currently many problems - i managed to keep up with the newforms clean_data vs. cleaned_data change, but with dozen of other changes and new features i really want/need to use i gave up to support the latest django release.. I'm not asking that there are fewer API changes in django or whatever, just that there is a reasonable django release i can make SCT compatible with.) So are there any plans on releasing a 0.97 ? I hope you understand my concerns - django is really great and the trunk is stable but 1.) there are many users who don't want to use the latest development version from the trunk (or are too lazy to install a svn client - most of the times it is faster to simply click a download url) 2.) i can't create releases for my own software.. it would be ridiculous to create a release which has a dependency on 'the latest development version' .. since this dependency can break every time someone commits something into the django trunk.. thanks & cu, herbert http://sct.sphene.net --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django-based forum software?
hi, i'm the author of SCT (Sphene Community Tools: http://sct.sphene.net ) - it tries to be as easy to integrate and customizable as possible (and still to keep some kind of simplicity) - so it would be nice to hear the requirements from people. by default it basically looks like this: http://sct.sphene.net/board/show/0/ (It uses the default django auth system, but an extended user profiles model .. which is imo very nice (providing avatars & co) but not really necessary) cu, herbert On Aug 30, 6:47 pm, Aaron Maxwell <[EMAIL PROTECTED]> wrote: > Does anyone know of a django forum app? I.e., to build a site providing a > user forum. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: accessing id attribute of a ForeignKey without additional DB queries
On Aug 16, 1:42 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > This behaviour is valid, and will remain so. Django uses this feature > internally in many places, especially in the serializers. thanks, good to know :) > Any suggestions on how to improve the documentation of this issue are welcome. i would have expected it somewhere in the db-api documentation (http:// www.djangoproject.com/documentation/db-api/) similar to the "Extra instance methods" for files .. like 'Extra instance attributes': FOO_id for ForeignKey attributes.. cu, herbert --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
accessing id attribute of a ForeignKey without additional DB queries
Hi, I have a simple 'Post' model which has a 'author' ForeignKey linking to a 'User' object - is there a way to access post.author.id without django triggering a database query ? - i tried to use the db column name - post.author_id .. and it worked.. so the question remains - is this behavior i can count on, or just luck that it had the same name ? I couldn't find any documentation on it on djangoproject.com/ documentation/ but the inline documentation for fields read: "attname: The attribute to use on the model object. This is the same as "name", except in the case of ForeignKeys, where "_id" is appended" thanks, herbert http://sct.sphene.net --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
template inheritance - {% extends NEXTLOADER %}
hi,
is there a way to extend a template with the same name, but in another
template loader ?
more specific.. it would be nice if i could customize only specific
blocks of templates by simply adding a new template loader (or another
template directory) and creating a file with the same name as the
original template..
this way an application writer wouldn't have to worry about creating
customization layers for the templates..
just to create enough blocks.
the only way i know would be to create two files for every template..
like 'base.html' and 'base_customized.html' .. where the _customized
version only contains the {% extends .. %} statement so it can be
overloaded... but this makes the whole thing much more verbose and
possibly slower (?)
any thoughts ?
thanks & cu,
herbert poul
http://sct.sphene.net/
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Creating extensible views ?
Hi, I've found documentation on how to make applications to work together smoothly .. but is there also some documentation on how i could make an application (or views of an application) extensible.. For example like in eclipse having "extension points" where 3rd party applications could hook into .. and extend the original functionality .. in specific i need this (e.g.) for a user profile view.. my project consists of multiple applications and i want them all to be independent .. and also have personal settings on their own.. so i would have a community application which is responsible for registration & co .. and would also allow the user to change his profile and edit settings.. but what if i want to make it easily possible for my wiki and board applications to contribute additional settings to this view ? is there any django specific way to do something like it, or any thoughts on how i could implement a generic interface for such a problem ? i guess the signal API would be one possibility ? to simply send out specific signals like 'render_profile' and 'post_profile' where multiple application could listen to and respond accordingly ? i don't expect that there is any ready-to-use solution out there, so i would welcome any thoughts on that ;) .. thanks, herbert http://sct.sphene.net - Sphene Community Tools --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Created pluggable board and wiki applications
well.. i've only tried the myghtyboard once.. so i might be wrong.. but it seems to be very hard to integrate into a custom project.. into a custom website.. many templates would need to be modified & co before it would be usable in a default standard project (since you modded it that much . you've might encountered the same problems, but decided it would be worth modding.. instead of creating it from scratch ;) ) i wanted to create an application which can be used without any problems in any django project .. based 100% on django technology (django models, templates & co) and still beeing powerful enough to look like a default bulleting board (which zyons imho .. doesn't ... at least not at first sight.. and i didn't invested more time looking at it to be honest..) another... very important aspect for me .. was to have the possibility to host multiple virtual sites on one instace .. with one configuration .. so the sphene community tools (wiki/board) are based around 'Groups' which basically represent one website .. the main difference between the current 'Sites' middleware and sphene's 'Groups' is that Groups can be created by clicking 'Add' in the administration, while Sites would require custom configuration & co ... this is basically the same as i've done in java years ago (and i want to replace it by Sphene Community Tools) - http://galena.sphene.net ... this would be the group 'galena' .. create a group 'goim' and you've got http://goim.sphene.net ... or an alias http://goim.us .. or another group called 'gwtwidgets' and you've got http://gwtwidgets.sphene.net ... ie. with the click of a button ... i want to have a new website.. with the possibility of creating a new board, new wiki, new navigation, new themes (templates), etc. - Sphene Community Tools has a long way to get to that point .. especially since django template paths are currently globals (afaik) .. but.. that shouldn't be hard to resolve ;) cu, Herbert On Feb 22, 11:35 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Out of curiosity, what advantages do you see over the diamanda > project? > > I still think we need revive the django forums group, get all these > boards together and build the killer Django BB. By my last count, > there's zyons, myghtyboard (diamanda), SNAPboard, Sphene and maybe one > or two I'm forgetting. Heck, my install of myghtyboard is so modded > it's almost a branch at this point. > > On Feb 21, 2:15 pm, "kahless" <[EMAIL PROTECTED]> wrote: > > > Hi, > > > Since i haven't found any existing board / wiki applications which > > would fit my needs and are easy enough to integrate into a custom > > django project, i have created my own .. > > i tried to stick to > > thehttp://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters > > as much as possible.. and i see no reason it wouldn't fit into any > > project .. > > > i have created a sitehttp://sct.sphene.net(which.. of course uses > > exactly this wiki and board) describing it's functionality and how to > > use it -http://sct.sphene.net/wiki/show/Documentation) .. i've > > released it under the BSD license .. so if anyone is interested feel > > free to download the code and try it out.. > > Although it does not provide full functionality yet you would expect > > from a wiki / board (especially user permission handling is very > > minimal yet) .. it is still quite useful imho.. > > > Please let me know what you think .. > > > thx & cu, > > Herbert Poul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Created pluggable board and wiki applications
Hi, Since i haven't found any existing board / wiki applications which would fit my needs and are easy enough to integrate into a custom django project, i have created my own .. i tried to stick to the http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters as much as possible.. and i see no reason it wouldn't fit into any project .. i have created a site http://sct.sphene.net (which .. of course uses exactly this wiki and board) describing it's functionality and how to use it - http://sct.sphene.net/wiki/show/Documentation) .. i've released it under the BSD license .. so if anyone is interested feel free to download the code and try it out.. Although it does not provide full functionality yet you would expect from a wiki / board (especially user permission handling is very minimal yet) .. it is still quite useful imho.. Please let me know what you think .. thx & cu, Herbert Poul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Custom model initializers - getting logged in user in django models
altough i'm not sure if thread locals are that clean .. i guess it's a
better way ..
thanks .. i was searching for something like that .. i wonder why i
haven't found that site :(
it seems there are tons more documentation in the wiki as i've
thought ;)
cu,
herbert
On Feb 17, 3:22 pm, "Honza Král" <[EMAIL PROTECTED]> wrote:
> This doesn't seem very clean to me...
>
> I also need to have logged-in user available in my models, so I have
> written a custom middleware that stores the user in thread_locals:
>
> import threading
> _thread_locals = threading.local()
>
> def get_current_user():
> return getattr( _thread_locals, 'user', None )
>
> class RequestMiddleware( object ):
>
> def process_request( self, request ):
>
> _thread_locals.user = request.user
>
> then, I can use get_current_user() anywhere in my application and it
> will provide me with the current user, for some fields I even have
> something like:
>
> user = models.ForeignKey( User, default=get_current_user )
>
> I cannot take credit for this, I found it on
>
> http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser
>
> On 2/17/07, kahless <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > hi,
>
> > i am creating a very simple board and wanted to add a method to my
> > models which would check if there are any new posts in a thread /
> > forum for a given user.. for this to work .. i obviously need the
> > currently logged in user in my models ..
>
> > but i didn't want to iterate through all my models in my view, since i
> > used the django.views.generic.list_detail.object_list which does the
> > paging and everything for me ..
>
> > so i thought the easiest way would be to allow adding of custom
> > initializers.. which would be called once a model was created by
> > django.db.models.query.QuerySet .. so i played around a little until
> > it worked for me:http://yourhell.com/~kahless/query_initializers_patch.diff
>
> > the usage is quite simple:
> > class MyModelInitializer(object):
> > def __init__(self, request):
> > self.request = request
>
> > def init_model(self, model):
> > model.do_init( self, self.request.user )
>
> > (my models would have a 'do_init' method which takes the user and
> > stores it internally)
>
> > the object_list would then get a queryset argument in my view like:
> > queryset =
> > Post.objects.filter( . ).add_initializer( MyModelInitializer( request )
> > )
>
> > and my templates could simply call {% if thread.hasNewPosts %} ...
>
> > so .. is this a clean solution ? or can this be done differently ?
> > and .. would there any chance this patch could find it's way into
> > django or does it break any main design philosophy ?
>
> > - i'm very new to python and django alike .. so there might be an
> > obvious other solution.
>
> > thanks & cu,
> > Herbert Poul
>
> --
> Honza Kr?l
> E-Mail: [EMAIL PROTECTED]
> ICQ#: 107471613
> Phone: +420 606 678585
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Custom model initializers - getting logged in user in django models
hi,
i am creating a very simple board and wanted to add a method to my
models which would check if there are any new posts in a thread /
forum for a given user.. for this to work .. i obviously need the
currently logged in user in my models ..
but i didn't want to iterate through all my models in my view, since i
used the django.views.generic.list_detail.object_list which does the
paging and everything for me ..
so i thought the easiest way would be to allow adding of custom
initializers.. which would be called once a model was created by
django.db.models.query.QuerySet .. so i played around a little until
it worked for me: http://yourhell.com/~kahless/query_initializers_patch.diff
the usage is quite simple:
class MyModelInitializer(object):
def __init__(self, request):
self.request = request
def init_model(self, model):
model.do_init( self, self.request.user )
(my models would have a 'do_init' method which takes the user and
stores it internally)
the object_list would then get a queryset argument in my view like:
queryset =
Post.objects.filter( . ).add_initializer( MyModelInitializer( request ) )
and my templates could simply call {% if thread.hasNewPosts %} ...
so .. is this a clean solution ? or can this be done differently ?
and .. would there any chance this patch could find it's way into
django or does it break any main design philosophy ?
- i'm very new to python and django alike .. so there might be an
obvious other solution.
thanks & cu,
Herbert Poul
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Why not making RequestContext the default Context ?
hi, is there a reason why by default the render_to_response uses a Context and not RequestContext ? since it's the goal to make applications (and therefore templatetags & co) as independent as possible (afaik) so it would be possible to simply call templatetags from another application imho there should be by default the request object in the context and a way to add additional variables to the context (ie. "TEMPLATE_CONTEXT_PROCESSORS") i wonder if it wouldn't be better to have render_to_response by default use a RequestContext, or make it configurable.. or... at least add to the "Do's and Dont's for Application Writers"-page (http:// code.djangoproject.com/wiki/DosAndDontsForApplicationWriters) to always pass a RequestContext into render_to_response. or am i missing something important and it's not always a good idea to use RequestContext ? thanks & cu, Herbert Poul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Accessing the current request object in a template loader
hi, i want to make a simple template loader which loads from directories depending on the sub-site the user requests a page from. (or probably also from the user session - which theme he has set, etc.) so i would need to get the current request object but haven't found a solution for that problem in the documentation. Since i'm new to python, there might be some easy way .. e.g. like ThreadLocal's in java .. altough i guess mod_python and others don't use threads, but processes ? so i could simply put the request object in a globally accessible variable ? (i know, it's a bad design .. but i see no other way to get the request object ?) Another way would be to create a middleware and change the settings.TEMPLATE_DIRS tuple .. but this seems to be even more dirty .. (and the django documentation also discourages changing settings outside the main site's settings.py) tia, cu, Herbert Poul --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
