django web site css missing
Hi, just in case it hasn't been noted: The css on the web site is missing - /css/homepage.css gives 404. wiki pages render black on black. etc. Michael --~--~-~--~~~---~--~~ 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: Integrating Django and SQLAlchemy
I noticed on the SQLAlchemy web site that there is "developmental support" for MS SQL. Would this help hasten support for MS SQL in Django? --~--~-~--~~~---~--~~ 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 web site css missing
On Sep 1, 2006, at 5:06 AM, Michael Radziej wrote: > just in case it hasn't been noted: > > The css on the web site is missing - /css/homepage.css gives 404. > wiki pages render black on black. etc. Thanks for the heads-up, Michael; it's been fixed. Jacob --~--~-~--~~~---~--~~ 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: name of test database
On 9/1/06, Michael Radziej <[EMAIL PROTECTED]> wrote: I can work around this, sure, but I'd propose to allow tooverwrite the default test database name for the test suite somehow, preferably on the command line of runtests.py.Thanks for the feedback. These are reasonable concerns. I have just committed (r3706) a TEST_DATABASE_NAME setting; by default, this has a value of None, which will cause the test database to use the same 'test_' + DATABASE_NAME scheme; however, if you provide a value, that name will be used instead. This setting is then used by runtests; settings.TEST_DATABASE_NAME is hardcoded to 'django_test_db', just as it was with the old runtests.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 -~--~~~~--~~--~--~---
Re: name of test database
On 9/1/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > These are reasonable concerns. I have just committed (r3706) a > TEST_DATABASE_NAME setting; by default, this has a value of None, which will > cause the test database to use the same 'test_' + DATABASE_NAME scheme; > however, if you provide a value, that name will be used instead. > > This setting is then used by runtests; settings.TEST_DATABASE_NAME is > hardcoded to 'django_test_db', just as it was with the old runtests. Hey Russ, Any particular reason you used a setting instead of a simple command-line parameter? In my view, we should only be adding settings if absolutely necessary. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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: Automatic-manipulator, very slow..... design-decision/bug/misunderstanding?
Yea, 'follow' was a new feature of sorts put into the new-admin branch way back when, by (sadly absent these days) Robert Wittams. I don't believe it was ever fully documented even after new-admin was merged to trunk (which was around or before 0.91, I believe). Regards, Jeff Gary Wilson wrote: > I'm not sure if it's up to date, but there is mention of the follow > here: > http://code.djangoproject.com/wiki/NewAdminChanges#Manipulatorsandinlineediting --~--~-~--~~~---~--~~ 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: Filters no longer parsed for unresolved variables
On 9/1/06, SmileyChris <[EMAIL PROTECTED]> wrote:
I believe the last line of that patch should have been:+obj = settings.TEMPLATE_STRING_IF_INVALIDbut I just wanted to check that the functionality change isn't intendedfirst.
This was intentional; the original problem was that {% if var %} would evaluate as true if var was undefined. This was having immediate problems in the admin view; if you had TEMPLATE_STRING_IF_INVALID set, the admin view had some major rendering problems (because blocks were getting included or ignored inappropriately).
The fix you describe would exhibit a different variety of the same problem. If you use the default value for TEMPLATE_STRING_IF_INVALID (which is ''), then your patch would be fine; an invalid value would get passed to filters like default and be processed as expected. However, if you set TEMPLATE_STRING_IF_INVALID to be non-empty, (
e.g., '--INVALID--'), the default filter will think that the variable has a value ('--INVALID--) and do nothing. Similar problems would exist for other filters.
I think a better solution would be something like:def resolve(self, context, ignore_failures=False): try: obj = resolve_variable(self.var, context) except VariableDoesNotExist: if ignore_failures:
obj = None else: if settings.TEMPLATE_STRING_IF_INVALID: return settings.TEMPLATE_STRING_IF_INVALID else: obj = settings.TEMPLATE_STRING_IF_INVALID
for func, args in self.filters: This way, - If/For nodes can ignore any setting for TEMPLATE_STRING_IF_INVALID and pass a value of None straight to the filters- For other nodes, if you have an empty TEMPLATE_STRING_IF_INVALID, the empty value will be passed to the filter, which can be processed in a meaningful way
- If you actually have a TEMPLATE_STRING_IF_INVALID setting, you shortcut the filtering process (since there is no point passing '--INVALID--' to a filter).Does this make sense? Have I missed anything here?
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 -~--~~~~--~~--~--~---
Re: generic-auth and per-object-permission integration
Once (gen-auth/pop) are merged, what are the major barriers in getting that branch merged into trunk? Thanks! --Nick --~--~-~--~~~---~--~~ 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: name of test database
On 9/1/06, Adrian Holovaty <[EMAIL PROTECTED] > wrote: Any particular reason you used a setting instead of a simplecommand-line parameter? In my view, we should only be adding settingsif absolutely necessary.I agree that a command line argument would probably be viable if the problem was restricted to just runtests.py, but it struck me as an example of a bigger problem.In Michael's case, it sounds like test_myapplication would never be a viable database name (due to some name clash). Given that he knows this, and it will be a persistent condition, asking him to type './manage.py --test_db_name="no_clash_db_name" test' every time he runs his test suite seems a little onerous. He isn't expected to do the same for DATABASE_NAME - a setting lets him configure his preferred name permanently on a per-app basis. I suspect most users will never need the setting - the default naming policy should be enough. However, the same could be said for other settings, too (e.g., EMAIL_SUBJECT_PREFIX)As a bonus, the TEST_DATABASE_NAME setting provides a clean mechanism to avoid running the Django system tests in an application's test database. Does that sound reasonable?On a related, cross thread note: any comment on the test system signaling benchmarks and the solutions proposed? 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 -~--~~~~--~~--~--~---
Re: Re: generic-auth and per-object-permission integration
On 9/1/06, Linicks <[EMAIL PROTECTED]> wrote: > > Once (gen-auth/pop) are merged, what are the major barriers in getting > that branch merged into trunk? Probably just review by Jacob and Adrian. There are several branches from summer of code that will be competing for their attention over the next few months. The best thing people can do to speed up the process is test the branches and report your successes and problems. Joseph --~--~-~--~~~---~--~~ 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: name of test database
On 9/1/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > In Michael's case, it sounds like test_myapplication would never be a viable > database name (due to some name clash). Given that he knows this, and it > will be a persistent condition, asking him to type './manage.py > --test_db_name="no_clash_db_name" test' every time he runs > his test suite seems a little onerous. He isn't expected to do the same for > DATABASE_NAME - a setting lets him configure his preferred name permanently > on a per-app basis. > > I suspect most users will never need the setting - the default naming policy > should be enough. However, the same could be said for other settings, too > (e.g., EMAIL_SUBJECT_PREFIX) > > As a bonus, the TEST_DATABASE_NAME setting provides a clean mechanism to > avoid running the Django system tests in an application's test database. > > Does that sound reasonable? OK, cool -- sounds reasonable. I just wanted to make sure it was essential / thought-through. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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: Test framework and dispatching benchmarks
On 8/29/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > Personally, I find myself leaning towards option 3 - outside of testing, I > can't see any use case for a template-rendering signal, and I don't like > special cases. Instrumentation of the rendering system as part of the test > framework setup seems an appropriate solution. Yes, option 3 is my preference as well. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Admin breaks if unicode data is put into PostgreSQL ascii encoded database
Hi django-users, I developed an application locally and used it with my postgres database, which used unicode as the server_encoding. Everything worked fine. Recently I deployed it onto a system where the postgres server_encoding is sql_ascii. After install, I started admin and added an object to the database which contained an `ä`. Django did not warn me and wrote the object into the database. But Django is unable to retrieve the object now and crashes with a UnicodeDecodeError. Furthermore I can not access the admin because of admin's `last change` list. Clearing the tables brought me back to the start. Is there an elegant way to solve this not making me overwrite every save method and changing the databases encoding? Regards, -Justin --~--~-~--~~~---~--~~ 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: Integrating Django and SQLAlchemy
If you need MSSQL support today, you might want to take a look this ticket: http://code.djangoproject.com/ticket/2358. It hasn't been officially accepted, but I've been able been able to successfully use MSSQL with Django after applying it. Using ticket 2358, I wrote this patch http://code.djangoproject.com/ticket/2563 (introspection functionality for MSSQL backends). Again, this is another patch that hasn't been accepted, but if you really need to use Django with MSSQL like me, these tickets are certainly a good place to start.From what I've read, pagination might not work yet. but everything else that I've tried seems to work just fine. Sean On 9/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I noticed on the SQLAlchemy web site that there is "developmentalsupport" for MS SQL. Would this help hasten support for MS SQL inDjango? --~--~-~--~~~---~--~~ 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: POST data is corrupted, or is it really?
On 8/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >method="post" enctype="text/plain"> . [...] > Now here is the problem: print request.POST['tag_str'] in function > views.info prints the following: > > tag1, tag2 title_str=This is the title caption_str=Some random > paragraph > > and print request.POST['title_str'] returns error because key > 'title_str' is not found. > > What am I doing wrong? Why are the keys and their respective values in > tag_str? Hi Bala, Remove the 'enctype="text/plain"' from your tag, and it'll work. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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: POST data is corrupted, or is it really?
Hi Adrian, Thank you for the prompt response. And, sorry for posting this to the developers group. Your suggestion works! Thanks again. Should this also be added to the list of newbie mistakes? What a wonderful framework you have built. I wish such frameworks could be built for the EDA (electronic design automation) industry! Oh, well. Regards, Bala. Adrian Holovaty wrote: > On 8/31/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > method="post" enctype="text/plain"> > . [...] > > Now here is the problem: print request.POST['tag_str'] in function > > views.info prints the following: > > > > tag1, tag2 title_str=This is the title caption_str=Some random > > paragraph > > > > and print request.POST['title_str'] returns error because key > > 'title_str' is not found. > > > > What am I doing wrong? Why are the keys and their respective values in > > tag_str? > > Hi Bala, > > Remove the 'enctype="text/plain"' from your tag, and it'll work. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
