Re: Django Test framework commits (r3658-r3661)
Hi Russ, Nice work! FYI I submitted a patch (#2490 [1] ) a while ago to get runtests.py to produce an error if no DJANGO_SETTINGS_MODULE is in the env. Not sure if this is something you want, but I've updated it to work post r3661 - it does make it a little bit easier to work out how to run the tests! Next - I'm getting failures with an SQLite database on: FAIL: Doctest: modeltests.many_to_many.models.__test__.API_TESTS FAIL: Doctest: modeltests.many_to_one.models.__test__.API_TESTS Both of these look like they're failing due to SQLite not being able to handle COUNT(DISTINCT(fieldname)). Cheers, Simon [1] http://code.djangoproject.com/ticket/2490 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
3 patches I've added
Django dev, Not trying to bypass normal process but I would appreciate some feedback on the following 3 patches I've submitted recently: This one adds a button to edit the current object to the admin interface: http://code.djangoproject.com/ticket/2569 This is a fix for a bug with inline editing files: http://code.djangoproject.com/ticket/2413 This is a (probably partial) fix for a bug with inline editing when you have multiple foreign keys referencing the same object: http://code.djangoproject.com/ticket/1939 I have noticed there is a great number of patches like mine that don't ever seem to be reviewed and all seemed to be assigned to Adrian but he seems to be concentrating on new features at the moment. As someone who wants to contribute to Django and is happy to fix these bugs should I just keep going submitting these patches or is there someone I should enter into a dialogue with about getting them committed? Joel --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Q
Ian Holsman wrote: > all of these types of things should get as much info as possible out > of the database/models that exist > having to retype the relationships sounds yuko to me. > > but hey... I'm not a ruby guy.. maybe they like doing these kind of > things. This is a limitation of supporting multiple databases (not to start a flame war, but many more databases than Django). Really, though, if you have a legacy schema of several hundred tables, it does get to be a pain. Less aggravating, though, than rekeying EVERY field in Django if introspection fails. So, I guess it depends on your philosopy: should schemas be written in code (Django), or written by your database architect in SQL(Rails). --~--~-~--~~~---~--~~ 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: [Fw]The Python Web Framework
On 8/23/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> * The template system being "dumbed down" for designers? Going to call
> BS on that too. The real complaint here seems to be that the template
> system doesn't include a programming language, and personally I don't
> think it should. If there are things that someone runs into that they
> find themselves needing to use the same custom template tag over and
> over again in many different projects, then that needs to be submitted
> for possible inclusion in the default tags.
>
I don't think this reflects the way django and custom tags are really
used. Looking at the admin code much of it has stuff like {%
output_all "blah" %}. Its all well and good to say that templates
should be pure and should not have a programing language but the
reality is that many people work around this by creating a very tight
coupling between their code and the templates to the point where the
templates no longer specify the layout or styles at all - and piece
together all the objects that the code has assembled. Of course it
greatly depends on the project but I believe that calling tags with
arguments in templates would allow for complex templates that still
stand alone.
Joel
--~--~-~--~~~---~--~~
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: URLField says all links to Wikipedia are invalid
Ian Holsman wrote: > I would be +1 on this if it included the site domain in the user-agent. > having it this way will just cause wikipedia to block it when a > single badly behaving django-bot uses it. +1 on including the domain in the User Agent... good idea. --~--~-~--~~~---~--~~ 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: [patch] URLField says all links to Wikipedia are invalid
On 8/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Akismet thinks this bug is spam, so I cannot submit it to Trac. If you're being locked out due to the spamfilter (and this goes for anyone else), please email me with your IP (or IP range) or, if you have a wide dynamic IP range, the longest part of your hostname that will stay the same. I'll get you whitelisted ASAP. --~--~-~--~~~---~--~~ 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: 3 patches I've added
On 8/28/06, Joel Heenan <[EMAIL PROTECTED]> wrote: > > I have noticed there is a great number of patches like mine that don't > ever seem to be reviewed and all seemed to be assigned to Adrian but > he seems to be concentrating on new features at the moment. As someone > who wants to contribute to Django and is happy to fix these bugs > should I just keep going submitting these patches or is there someone > I should enter into a dialogue with about getting them committed? http://www.djangoproject.com/documentation/faq/#i-submitted-a-bug-fix-in-the-ticket-system-several-weeks-ago-why-are-you-ignoring-my-patch In summary: the core devs are really busy, and if they haven't done anything with your ticket it just means that they haven't gotten a chance to go over it in detail. If a ticket is definitely unsuited for Django, they would have closed it immediately. >From my own experience watching Django's timeline, the core developers tend to go on "rampages" every so often and address many tickets at once; if you submitted these tickets recently, there's a good chance they'll get some love next time that happens. :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
On MEDIA_URL
I posted a reply to a wontfix bug and thought I'd also post it here for discussion. See bug: http://code.djangoproject.com/ticket/2532 Here's the copy/paste of my argument: I agree that this should be there by default. I can understand the slippery slope argument, but this makes sense. Other settings being viewable at the template level do not. I can see that either a person is going to make their own context processor, or they're going to repeat themselves and list the absolute URL in their templates as well as in the settings (which violates the DRY principle). I checked what the Django website does currently and it's confusing. In settings.py, MEDIA_URL is set to a broken URL: MEDIA_URL = "http://www.djangoproject.com.com/m/"; # <- 2 .com's in there But in the templates, it's hard coded as http://media.djangoproject.com/. What's the point of setting MEDIA_URL if you can't use it in the templates? Where does it ever get used? It being broken on the Django website makes me think it doesn't get used anywhere. I'd much prefer setting it once and having an easy way to use it in the templates. Thanks, Rob PS: My apologies if doing this is bad etiquette but I wasn't sure if my bug reply on a closed bug would be noticed. --~--~-~--~~~---~--~~ 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: Row level permission problem in admin for inline edited objects
Hi, With the select list, I am hoping for some general public opinion on how to handle this. If the user does not have change permissions on this, does this mean they can not see the object in the select list? I'm not sure if that would be a workable solution. A proposal: Create an additional "admin" permission called "view_object" that would handle this case. It would work just as a read does, the only problem with this is that it might conflict with the change permission. To handle this, we will just check for one or the other permission (if the user is changing/editing something, then it is a change, otherwise it is a view). In the admin interface, this will probably only be used in the above case. Any thoughts? Chris --~--~-~--~~~---~--~~ 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: On MEDIA_URL
On Mon, 2006-08-28 at 11:27 -0700, [EMAIL PROTECTED] wrote: > I posted a reply to a wontfix bug and thought I'd also post it here for > discussion. > See bug: http://code.djangoproject.com/ticket/2532 > > Here's the copy/paste of my argument: > > I agree that this should be there by default. I can understand the > slippery slope argument, but this makes sense. Other settings being > viewable at the template level do not. Not true. Different settings make sense in different circumstances. Your circumstances are that you happen to want the access to that particular setting. It isn't a special setting, really. > I can see that either a person is going to make their own context > processor, Yes. Exactly. Or use one that somebody else wrote and posted to the Wiki or made available elsewhere. We just don't want to put a "retrieve settings" processor in core because we are making a judgement call about the security and usability implications (if it's in core, people won't think as carefully before using it, for a start). > What's the point of setting MEDIA_URL if you can't use it in the > templates? Where does it ever get used? It being broken on the Django > website makes me think it doesn't get used anywhere. Grep through the code and have a look. It's used. One use is to retrieve the URL for media that are uploaded via models. > I'd much prefer setting it once and having an easy way to use it in the > templates. Which you can, as explained in the bug and as you appear to understand: using a context processor. It's easy to make the case that a particular setting should be universally exposed, but it's never really 100% valid: I don't use MEDIA_URL for my static files such as images and CSS, for example -- my uploaded stuff goes to a different location to my CSS files, so MEDIA_URL is only useful for uploaded files. Regards, Malcolm --~--~-~--~~~---~--~~ 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: On MEDIA_URL
Malcolm Tredinnick wrote: > Yes. Exactly. Or use one that somebody else wrote and posted to the Wiki > or made available elsewhere. We just don't want to put a "retrieve > settings" processor in core because we are making a judgement call about > the security and usability implications (if it's in core, people won't > think as carefully before using it, for a start). >From my reading of context processors, it seems like you have to make a context and also change the urls.py to tell the view to use your context rather than the default. Is that right? > Grep through the code and have a look. It's used. It's only used in 1 file as far as I can see: db/models/base.py I'm making the assumption that "MEDIA_URL" is where you put your static media (style sheets, javascript, images, etc.) but the use case you describe, and what the code seems to show, is that it's simply for uploaded media so Django knows where to put it in the filesystem and what URL to reference it as. For file uploads that looks good to me. For general media, I'm not sure what to do. If I had both in my project (static media and uploaded files), I'd want to avoid putting the two in the same place, personally. In that case, where would I put my media setting so I could refer to it from the templates? Make up my own setting in settings.py and write a context processor to make it available to the templates? If I only had static media, using a setting that is intended for file uploads and addng a context to it doesn't seem right either. That kind of dual purpose variable scares me. Thanks, -Rob --~--~-~--~~~---~--~~ 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: On MEDIA_URL
On Mon, 2006-08-28 at 11:58 -0700, [EMAIL PROTECTED] wrote: [...] > In that case, where would I put my media setting so I could refer to it > from the templates? Make up my own setting in settings.py and write a > context processor to make it available to the templates? If it was something that was likely to change and you didn't want to hard code it, yes. Whether you need to do this or not depends on how you are intending to use your application. I find that I can usually get away with putting all my static stuff under a /static/ URL so that it remains hostname independent and I only have to specify that URL for things like stylesheets in one place anyway (typically the base template). If I was writing an application that had a lot of templates and was intended to be installed all over the place, I would go the context processor route without a second thought, because then having a configurable static media setting for those templates would be appropriate. > If I only had static media, using a setting that is intended for file > uploads and addng a context to it doesn't seem right either. That kind > of dual purpose variable scares me. Which is why a lot of us are not using it for that dual purpose. I think you are arriving at an understanding of why universally exposing MEDIA_URL is not always the right thing. Regards, Malcolm --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django and psycopg2 problems
Howdy folks -- So it appears that the Django psycopg2 has a few issues that make it operate differently than any other of the db backends. There's a paste of the django test suite output at http://django.pastebin.com/ 778189 which shows 6 failures, but actually there's only two things wrong: 1. The psycopg2 backend returns strings as unicode objects instead of raw strings. So for example:: File "/Users/jacob/WO/code/brave-new-world/django.trunk/tests/ modeltests/custom_columns/models.py", line ?, in modeltests.custom_columns.models.__test__.API_TESTS Failed example: p.last_name Expected: 'Smith' Got: u'Smith' 2. The backend returns datetimes with attached timezone info instead of naieve datetimes:: File "/Users/jacob/WO/code/brave-new-world/django.trunk/tests/ modeltests/basic/models.py", line ?, in modeltests.basic.models.__test__.API_TESTS Failed example: Article.objects.get(id__exact=8).pub_date Expected: datetime.datetime(2005, 7, 31, 12, 30, 45) Got: datetime.datetime(2005, 7, 31, 12, 30, 45, tzinfo=) Now, I know that both behaviors are actually more correct than the other backends, but these subtle differences between the psycopg2 adaptor and the other ones is really driving me nuts. Are the any objections to changing the psycopg2 backend to behave the same was as the other ones (knowing that it's actually a step backwards)? Eventually the right thing to do would be to make the *other* backends behave this way, but that's all caught up with unicodification, and I'd like to move towards consistency first, and then correctness when it's ready. 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: Django and psycopg2 problems
On 8/28/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > Are the any objections to changing the psycopg2 backend to behave the > same was as the other ones (knowing that it's actually a step > backwards)? Eventually the right thing to do would be to make the > *other* backends behave this way, but that's all caught up with > unicodification, and I'd like to move towards consistency first, and > then correctness when it's ready. It's definitely a step backward, but it's probably better to be consistent than "more correct" in this case. Fine by me -- 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: Django and psycopg2 problems
On Aug 28, 2006, at 2:50 PM, Adrian Holovaty wrote: > On 8/28/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: >> Are the any objections to changing the psycopg2 backend to behave the >> same was as the other ones (knowing that it's actually a step >> backwards)? Eventually the right thing to do would be to make the >> *other* backends behave this way, but that's all caught up with >> unicodification, and I'd like to move towards consistency first, and >> then correctness when it's ready. > > It's definitely a step backward, but it's probably better to be > consistent than "more correct" in this case. Fine by me -- Yeah, it sucks, but consistancy seems important to me, too. I've checked in the "fix" as [3675]; it's pretty easy to remove later. 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: [patch] URLField says all links to Wikipedia are invalid
On 8/27/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > I would be +1 on this if it included the site domain in the user-agent. > having it this way will just cause wikipedia to block it when a > single badly behaving django-bot uses it. Great idea, Ian. I agree that this patch should use the site domain in the user-agent. However, that's a slight problem, because the patch is to the validator framework, which knows nothing about Web requests. We could change it to be a validator class, rather than a function, taking the domain in its __init__() -- but that would be backwards-incompatible. We could use settings.SITE_ID, but that relies on that being set (and activated), plus it's coupled to the database layer/site app. Any other ideas? 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: Support for Native XML Database (NXD)
[EMAIL PROTECTED] wrote: > GinTon wrote: > > > I think that would be a big step if we could implement a NXD in Django, > > but I don't speak of substitute a RDBMS by NXD else of using NXD when > > it was really necessary. > > I think you'd first have to go 'up' a layer, and define an API onto > semi-structured data, and then you could plug in some other database > system. For example Zope's ZODB, or an NXD storing as XML. In fact if > you use ZODB in Django you could also use Zope Page Templates and > then No, I wont go there. > ZODB is a powerful OO-db that allows you to store objects without the need for any schema definition whatsoever. What do you think about Durus (the interface is simpler) and Schevo? http://www.mems-exchange.org/software/durus/ http://schevo.org/trac/ --~--~-~--~~~---~--~~ 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: On MEDIA_URL
> I think you are arriving at an understanding of why universally exposing > MEDIA_URL is not always the right thing. Yes. My big assumption was that it was intended for static media only. Which I think a lot of new Django users make based on the name of the setting. MEDIA_URL and MEDIA_ROOT still confuse me. For a FileField you are required to specify the "upload_to" path. Do you specify upload_to=settings.MEDIA_ROOT and use MEDIA_URL in the get_absolute_url method? Knowing what I know thanks to Malcolm's clarifications and seeing others confused by this as well, it seems like MEDIA_URL could be better explained somewhere with common use cases. For my case I think I've arrived at the following as what best matches what I need: 1. Create a new setting variable specifying the path to my static media (STATIC_MEDIA_URL?) 2. Create a context to get this setting from my templates for building URLs to media. --~--~-~--~~~---~--~~ 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: On MEDIA_URL
On Mon, 2006-08-28 at 13:55 -0700, [EMAIL PROTECTED] wrote: [...] > MEDIA_URL and MEDIA_ROOT still confuse me. For a FileField you are > required to specify the "upload_to" path. Do you specify > upload_to=settings.MEDIA_ROOT and use MEDIA_URL in the get_absolute_url > method? The upload_to setting is a relative path giving the sub-directory underneath MEDIA_ROOT in which to store the uploaded files. For example, if MEDIA_ROOT is /uploads and upload_to = 'tmp/', then the files will go to /uploads/tmp/ . This is documented in the model-api documentation for the upload_to parameter. Sounds like we need to explain MEDIA_URL a little better, though. Probably just a slight clarification to the comment in the settings file should do it. Cheers, Malcolm --~--~-~--~~~---~--~~ 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: db_index not creating indexes with syncdb
Russell Keith-Magee wrote: > You are correct (and it's not just with MySQL). This is a bug born of > the way that syncdb installs applications. For some reason, it doesn't > defer to install - it duplicates the install logic, but doesn't include > indexes. > > I intend to refactor this code when I get into the installation of > fixtures for the testing framework (#2333). However, if you want to > ensure that this bug doesn't get missed, open a new ticket (do a quick > search first to check that it isn't already logged). There's a related bug already opened for it here: http://code.djangoproject.com/ticket/1828 Thanks, Rob --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Too Much Custom SQL
Hi, it seems like I'm constantly writing custom SQL code for everything because the django ORM cannot handle a lot of my requirements (which is perfectly understandable). Would it be such a bad idea to add an api to the django orm that's similar to SQLAlchemy? I don't like having to create cursors all of the time. I also don't like the fact that there are so many ways to access/manipulate information in the database: I create the model via django's orm. Then, to access the database I can either use the ORM, sql from within my django app, or within the database (via stored procedure). So, when I need to find or change the way I retrieve/manipulate data from the db... it can be in any of those places or forms. Something doesn't seem right about this. --~--~-~--~~~---~--~~ 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: Too Much Custom SQL
Out of interest, what types of things are you having trouble with in Django? I know there's a lack of support for aggregate functions and GROUP BY's etc Aggregate functions could be easily patched in ( e.g. [1], [2] ), but I believe this is waiting for query.py to be refactored. [1] http://code.djangoproject.com/ticket/1435 [2] http://code.djangoproject.com/ticket/2479 --Simon --~--~-~--~~~---~--~~ 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: 3 patches I've added
Tom Tobin wrote: > From my own experience watching Django's timeline, the core developers > tend to go on "rampages" every so often and address many tickets at > once; if you submitted these tickets recently, there's a good chance > they'll get some love next time that happens. :-) Here's to the next Django-Developer-Rampage! Maybe we should start a collection fund for caffiene products :-) --Simon --~--~-~--~~~---~--~~ 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: Too Much Custom SQL
Yes, GROUP BY and aggregate functions were at the top of that list. Others include complex joins, UPDATE FROM, temporary tables (not that often), sequences, and more (but those are the most common), especially stuff that is specific for just postgresql (the database that I happen to be using). Another question: Can django do and UPDATE without selecting all objects first? I didn't know about those tickets, so thanks; that should help some. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
allow simple_tag to set context?
simple_tag and inclusion_tag make writing simple template tags much more
convenient.
As the document says, "Another common type of template tag is the type that
displays
some data by rendering another template", e.g.
{% for choice in choices %}
{{ choice }}
{% endfor %}
But if there are many places in which you need to use inclusion_tag , it
gets annoying that you have to
extract all these *short and simple* snippets into separate template files.
If simple_tag can also
set context, that will be more convenient. Something like:
@register.simple_tag(sets_context=True)
Just some thoughts. any comments are welcome.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
