Re: RequestContext not working?
Did you overwrite TEMPLATE_CONTEXT_PROCESSORS ?
>I made the mistake once, because I didn't knew this variable is filled
>by default. You have to write something like:
>
>TEMPLATE_CONTEXT_PROCESSORS = >DEFAULT.TEMPLATE_CONTEXT_PROCESSORS +
>('my.preprocessor',)
>
>Took me some time to figure out why admin was not working anymore :)
>
>The difference of Context and RequestContext is not a deep one, so I
>don't think its a python issue here.
Actually, I did not overwrite TEMPLATE_CONTEXT_PROCESSORS, but still it
breaks with mod_python in apache2, where it works with the development
server.
I began tweaking the TEMPLATE_CONTEXT_PROCESSORS, and it seems, that
django.core.context_processors causes some problems, since the other
default processors (debug, request and i18n) seem to do their job.
I try to dig deeper into this, which is quite hard since there are no
errormessages at any point :(
I would be glad, if anyone could point out to any possible issue here
--
Andreas Neumeier
lovebox.ath.cx
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Logic error in forms/__init__.py?
Take line 378-381 in django/forms/__init__.py
Why on earth does it have:
raise validators.ValidationError, ngettext("Ensure your text is less
than %s character.",
"Ensure your text is less than %s characters.", self.maxlength) % self.maxlength
Given how the single form would be "1 character", can it ever trigger
to say: "Ensure your text is less than 1 character."?
At the moment I'd consider this flawed and it is another line in the
individual .po files that translators need to translate.
--
Jeroen Ruigrok van der Werven
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
introduction
hey all, i'm derek, one of the SoC selectees. just thought i'd pop my head in and say hi. :) -- derek anderson http://kered.org/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Switching SITE_ID's on a per-request basis
hi. I've got a situation where I only have a single process available to process requests, and would like to switch SITE_ID's based on the HTTP_HOST header. I can make it so that the settings.SITE_ID is changed, but that doesn't seem to affect everything.. specifically it seems that the site limit manager's filter gets set up on the first request and doesn't take notice of the changed site-id. any hints? and rewriting all my code isn't an answer I want to hear ;-) --Ian --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Issues on making the firebird backend working
Hi there,
I've started working on firebird's backend and Adrian is also
refactoring for the oracle support, so it's a good time to discuss this
:)
First, field and constraint names can't be bigger than 31 chars.
In the creation.py declared for PositiveIntegerField
integer CHECK("%(column)s" >= 0)
NOT NULL must be declared first than the CHECK.
Declaring NULL is invalid must be DEFAULT NULL.
The LIMIT, OFFSET problem like oracle.
Perhaps to fix this some sort of default functions could be defined in
django.db.backend or django.db.schema which backend could overwrite or
not.
Another thing is if it could be created something like
"pre_create_table" and "post_create_table" with the dispatcher
framework to create triggers, sequences, domains etc, thoughts?
I'm a python and firebird newbie so i could missing something .. if are
any django and firebird devs out there some sort of help would be nice
:)
David
--~--~-~--~~~---~--~~
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: [AUDIT] Enable Django Quick Start / Database Evolution Support
Joseph Kocherhans wrote: > On 5/25/06, lazaridis_com <[EMAIL PROTECTED]> wrote: >> At this point, Django's persistency layer seems intresting, but the >> evaluation uncovered a few weaknesses, most importantly the lack of >> schema evolution support: >> >> http://case.lazaridis.com/multi/wiki/DjangoProductEvaluation > > Schema evolution support has already been discussed at length. See: > http://code.djangoproject.com/wiki/SchemaEvolution but it's not > implemented yet. I've overflown the document and will provide some feedback within a seperate thread. > You also may want to add SqlAlchemy to your list. It's pretty cool, ok, done: http://case.lazaridis.com/multi/wiki/Persist > although in the early stages of development. There's a Google Summer > of Code project just starting to add schema evolution support to > SqlAlchemy as well. The two projects should cooperate a little (in context of their schema evolution subsystems): http://dev.lazaridis.com/base/wiki/CooperationProcess#SubsystemLevel >> Overview of resulting simplification issues: >> >> * Replace command "django-admin.py" by "django-admin" or "django" >> * Replace command "manage.py" by "django" > > These are kind of appealing to me, but my inner skeptic just screams > "name churn". I have created additionally a fictional django product. It should become clear that Simplicity and Product-Identity (of the django product) would be increased by this name change: http://case.lazaridis.com/multi/wiki/DjangoProductFictional > Adrian Holovaty is the final word on things like this though. I assume "Adrian Holovaty" is the Django Project Lead? Is there a Team Overview available? >> * Enable sqlite3 database / filename by default > > I personally wouldn't want this. Where do you propose putting the > database file? I *always* use absolute paths for sqlite db's. If you > use relative paths, it's relative to your current directory, not > relative to the location of the settings file. This could get really > confusing for newbies if they execute manage.py from a different > working directory. The setup for Newcomers and Evaluators would be simplified this way. The resulting possible problems can be solved by several ways (e.g. syncdb creates folder /db/default.db and and absolute path to this file, if necessary). Note: solution suggestion is just given as an example. >> * Externalize database settings (e.g. dbdefault.py) > > You can do this already... that's the beauty of using python for > settings. Just import * or whatever from the appropritate module in > your main settings file. Ok, I understand that I can do it. But my main intrest is, to have this as a default, thus the definition of multiple databases is possible (dbdevelope, dbtest, dbdeployed). An alternative would be, to allow multiple database configurations within the existent config file. >> * Enable Admin application by default > > This has been discussed and dismissed serveral times already. Comparing with other systems, this admin interface is one of the strongest points of Django. Remember that not every user is able to take all the setup barriers. >> * Create a superuser by default (e.g. user:admin / pass:django) > > -1. The slight convenience doesn't make up for the security implications IMO. The implementation could be e.g. with an command-line option "-s": http://case.lazaridis.com/multi/wiki/DjangoProductFictional#CreatetheDatabase >> * Rename "startapp" to "createapp" > > Once again, name churn. ok >> Solving those Issues would allow to produce a Django-Quick-Start which >> could be taken within 5 minutes (+ Installation Effort), which would >> allow intrested parties to come quickly in contact with Django. > > You could provide your own project skeleton that would take care of > all of this. There's no real need to change Django to accomplish any > of the items above. I'd argue that splitting out the database config > makes things *more* complicated. Part of the beauty of django is that > it doesn't (in the paraphrased words of someone else, I forget who) > "shit all over your filesystem like rails" Of course I could provide an own project skeleton. But my goal is, to select products/projects that care a lot about simplicity/usability and especially "low barrier to entry". An possibility would be, to allow multiple project templates (or skeletons) for "django-admin startproject", e.g. by a 2nd parameter (which would default to the existent project template, thus no breakage is introduced). - As to my "Selection Case Project": "This Project is Committed to Users of Open Source Products." http://case.lazaridis.com/multi/wiki/ProjectOverview >> I would be intrested to creat a skeleton for the "Database Schema >> Evolution" (I have implemente a very simply one for a Ruby ORM). > > See the link above. > >> To do so, I would need some feedback from the developers list. >> >> Can I rely on this? > > People are generally pretty hel
django-as-framework + https handling problems
hi,
today i was implementing some RSS feeds.
i did the standard
class ArticleFeed(Feed):
link = "https://bla.com/feeds/articles";
and for some reason it did not work. it kept appending the link-field to
the domain-name that was stored in the site object.
i checked the documentation, that said that the feed-framework checks if
the link is a full url or just the path and acts depending on it.
some further digging found the culprit in django.contrib.syndication.feeds:
def add_domain(domain, url):
if not url.startswith('http://'):
url = u'http://%s%s' % (domain, url)
return url
this of course does not work too well with https urls :-(
for my problem it was easy to fix it by adding an OR to the if clause
(later i'll submit a ticket regarding it) (btw. is there any way to
server rss from https using django, without patching django?)
but the general problem is imho that the django framework on many places
just assumes that the url starts with "http://";. just a quick grep shows:
http://django.pastebin.com/740049
(i know that some of these might be false alarms)
so, how should we proceed from here? should all these places be fixed to
also-support https? or to formulate differently, if patches will be
submitted that simply add an or-https clause to these cases, will those
be accepted?
or a different approach maybe?
for example, couldn't the site-framework's model also store the
protocol? or just a boolean to be able to differentiate between
http/https. what do you think about such idea?
gabor
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
A bug in reverse url lookup? (and a possible patch)
Hi
Reverse URL lookup
(http://groups.google.com/group/django-developers/browse_thread/thread/a5d12bc4fb073f24/83d7e4cb5f35ed08)
is one of the things that I am interested in in django.
The way I see myself using this will be roughly as follows: each
application will have a 'root' view. Using reverse URL lookup, it will
get its 'root' URL, and then the application will construct its
internal URLs using this root URL as a prefix. (of course this can
still be used for multiple 'root' URLs, the application will still know
its root views)
I was trying RegexURLResolver.reverse to accomplish that but it seemed
that (1) it did not go into included urls.py, and (2) even if it did it
will not add the prefix url from the including urls.py. I have a patch
to fix both of these problems.
I know that probably a ticket would be the best place to submit the
patch, I just wanted more people to look at it first, since I still
consider myself new with django, and I wanted to make sure that I did
not miss something, or if people will planning on using this
differently.
--
Thanks!
Medhat
Index: urlresolvers.py
===
--- urlresolvers.py (revision 2996)
+++ urlresolvers.py (working copy)
@@ -23,6 +23,25 @@
dot = callback.rindex('.')
return callback[:dot], callback[dot+1:]
+def reverse_helper(regex, *args, **kwargs):
+"""
+Does a "reverse" lookup -- returns the URL for the given
args/kwargs.
+The args/kwargs are applied to the regular expression in this
+RegexURLPattern. For example:
+
+>>> RegexURLPattern('^places/(\d+)/$').reverse_helper(3)
+'places/3/'
+>>>
RegexURLPattern('^places/(?P\d+)/$').reverse_helper(id=3)
+'places/3/'
+>>>
RegexURLPattern('^people/(?P\w\w)/(\w+)/$').reverse_helper('adrian',
state='il')
+'people/il/adrian/'
+
+Raises NoReverseMatch if the args/kwargs aren't valid for the
RegexURLPattern.
+"""
+# TODO: Handle nested parenthesis in the following regex.
+result = re.sub(r'\(([^)]+)\)', MatchChecker(args, kwargs),
regex.pattern)
+return result.replace('^', '').replace('$', '')
+
class MatchChecker(object):
"Class used in reverse RegexURLPattern lookup."
def __init__(self, args, kwargs):
@@ -108,24 +127,8 @@
return self.reverse_helper(*args, **kwargs)
def reverse_helper(self, *args, **kwargs):
-"""
-Does a "reverse" lookup -- returns the URL for the given
args/kwargs.
-The args/kwargs are applied to the regular expression in this
-RegexURLPattern. For example:
+return reverse_helper(self.regex, *args, **kwargs)
->>> RegexURLPattern('^places/(\d+)/$').reverse_helper(3)
-'places/3/'
->>>
RegexURLPattern('^places/(?P\d+)/$').reverse_helper(id=3)
-'places/3/'
->>>
RegexURLPattern('^people/(?P\w\w)/(\w+)/$').reverse_helper('adrian',
state='il')
-'people/il/adrian/'
-
-Raises NoReverseMatch if the args/kwargs aren't valid for the
RegexURLPattern.
-"""
-# TODO: Handle nested parenthesis in the following regex.
-result = re.sub(r'\(([^)]+)\)', MatchChecker(args, kwargs),
self.regex.pattern)
-return result.replace('^', '').replace('$', '')
-
class RegexURLResolver(object):
def __init__(self, regex, urlconf_name):
# regex is a string representing a regular expression.
@@ -180,10 +183,23 @@
def resolve500(self):
return self._resolve_special('500')
+def reverse_helper(self, viewname, *args, **kwargs):
+try:
+sub_match = self.reverse(viewname, *args, **kwargs)
+result = reverse_helper(self.regex, *args, **kwargs)
+return result + sub_match
+except NoReverseMatch:
+raise NoReverseMatch
+
def reverse(self, viewname, *args, **kwargs):
for pattern in self.urlconf_module.urlpatterns:
-if pattern.callback == viewname:
+if isinstance(pattern, RegexURLResolver):
try:
+return pattern.reverse_helper(viewname, *args,
**kwargs)
+except NoReverseMatch:
+continue
+elif pattern.callback == viewname:
+try:
return pattern.reverse_helper(*args, **kwargs)
except NoReverseMatch:
continue
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Template code: `and` as well as `or` in if statement
I have implemented `and` for if statements.
`and` and `or` cannot mix (because it would be ambiguous)
In this template:
{% if 1 and 1 %}good 1 and 1{% endif %}
{% if 1 and 0 %}bad 1 and 0{% endif %}
{% if 0 and 1 %}bad 0 and 1{% endif %}
{% if 0 and 0 %}bad 0 and 0{% endif %}
{% if 1 or 1 %}good 1 or 1{% endif %}
{% if 1 or 0 %}good 1 or 0{% endif %}
{% if 0 or 1 %}good 0 or 1{% endif %}
{% if 0 or 0 %}bad 0 or 0{% endif %}
{% if 1 and 1 or 1 %}error 1 and 1 or 1{% endif %}
all the 'good' lines would print, all the 'bad' lines would not print,
and the 'error' line would cause a TemplateSyntaxError (because and
mixed with or).
http://django.pastebin.com/740106
--~--~-~--~~~---~--~~
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: introduction
Guess I'll just continue this thread. My name is Chris, another one of the SoC students. I'm working on per row permissions, so if anyone has any ideas on it, please let me know. I have my own idea, but what I think works might be horribly wrong for everyone else. Not to say that my idea sucks. ;) So I want to get an idea of what other developers and users of Django are thinking for this feature. Otherwise, a bit about me, I'm Canadian, living outside Toronto. Entering my last year of University in Computer Science with a math minor. Really looking forward to this summer and the project. Cheers, Chris [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: introduction
Hi Chris. why not post your idea onto the list. it's much easier to critique something than wave hands around. you might also want to set up a wiki page on say http:// code.djangoproject.com/wiki/RowLevelPermissions or something I've my own thoughts, but I'd rather see what you have than dictate it. regards Ian On 27/05/2006, at 11:15 AM, Chris L wrote: > > Guess I'll just continue this thread. My name is Chris, another one of > the SoC students. > > I'm working on per row permissions, so if anyone has any ideas on it, > please let me know. I have my own idea, but what I think works > might be > horribly wrong for everyone else. Not to say that my idea sucks. ;) So > I want to get an idea of what other developers and users of Django are > thinking for this feature. > > Otherwise, a bit about me, I'm Canadian, living outside Toronto. > Entering my last year of University in Computer Science with a math > minor. > > Really looking forward to this summer and the project. > > Cheers, > > Chris > [EMAIL PROTECTED] > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
