Re: Using filters with {% trans %} tag
Ok I put it up.
It does not affect the _() syntax at all, except for allowing the use
of _() within a trans tag... But I don't feel that it is a problem.
The patch includes a backwards-compatiblity workaround. Again I bring
up the single/double quote issue, but since {% trans %} works with
single quotes and FilterExpression does not, I had to add a few lines
of code to fix strings surrounded with single quotes so they would be
surrounded with doubles instead :)
There are still some issues around that actually, for example if the
user has something like this:
{% trans 'Please select an "object"' %}
It will be broken with the new patch since the single quotes will be
replaced with doubles. I am working on some ideas on how to combat
this since simply escaping the quotes with two \\ does do the trick
because FilterExpression interprets them literally...
Now it's time for bed.
//D
On Nov 18, 4:09 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2007-11-17 at 17:47 -0800, Dmitri Fedortchenko wrote:
> > Once again I return with my whacky ideas.
>
> > I want to apply filters to my translations in the templates. So.
> > I have created a patch which allows use of the following syntax:
>
> > {% trans "username"|capfirst|slice:"2:" noop %}
> > {% trans somevar|slice:"2:" %}
>
> > The filters are applied on the result of the translation, and not the
> > translation id string.
>
> > While this is already possible by using the {{ _("username")|filter }}
> > syntax, I think that {% trans %} is more "django-ish" and looks nicer
> > too...
>
> > Does anyone think this is useful?
>
> +1 from me, providing it doesn't break the existing usage with _().
> Create a ticket and attach the patch.
>
> Malcolm
>
> --
> The sooner you fall behind, the more time you'll have to catch
> up.http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: setup_environ question
Gary Wilson wrote: > Is there a reason why setup_environ adds the parent directory of the project > directory to the path, imports the project module, and then removes the parent > directory from the path? The imported project module is also not used > afterwards. Adrian, do you know? --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: django.template.TokenParser inconsistent when it comes to filters...
On Sat, 2007-11-17 at 19:55 -0800, Dmitri Fedortchenko wrote:
> Great.
>
> Here are the tickets:
> http://code.djangoproject.com/ticket/5971
> http://code.djangoproject.com/ticket/5972
>
> And while we're on the subject of tickets:
> I've been digging around in the jungle of template parsing while
> working on this patch and and the trans patch, and a thought occured
> to me.
> Why can't the Variable class handle processing of filters instead of
> FilterExpression.resolve?
Because Variable was introduced only very recently and
FilterExpression.resolve() has been there since about day one. The
incremental changes haven't got that far.
> A Variable in a template is either a literal or a variable from the
> context, and those can in most cases have filters applied to them.
> Wouldn't it be nice if a Variable would simply have a "filters" list
> and the resolve method would be the one doing the application of said
> filters? (with the option to simply NOT apply the filters)
It's that last point that points to why the current design might have
some benefits. At times we need to differentiate between the variable's
value itself and the variable after all filters have been applied.
There's still a possibility of folding things in together, but the
current version is completely silly either. It's mostly just a naming
issue (do you call the method on this object or that object?) ,though.
The functionality isn't likely to change too much.
> Obviously it's a pretty daring idea and I don't have much to back it
> up right now, but my thought is that there seems to be way too many
> steps involved in parsing a single token and there are many datatypes;
> hard to keep track of everything.
>
> If we look at it in the scope of tags and {{}} (what would I call
> that?), then they can basically contain only a few datatypes:
> literals, context variables, filters and parameters.
>
> So why not make it a little more "defined" and give Variables the
> power they deserve! ;)
I suspect you're really just talking about folding FilterExpression into
Variable, for the most part. Might be worth it eventually. The nice
thing is that this sort of stuff can all be done incrementally and
without too much external disruption. We don't want to go nuts and break
everybody's code needlessly, so any changes *must* bring very real
benefits and not just count as rearranging the deck chairs to make them
look nicer, because that's asking external filter writers to make
changes for no actual benefit.
Still, I agree with your thinking in general. Some of those internals
could do with a broader look now that we've got a couple years more
experience in how things are being used. We could encourage wider use of
TokenParser (and document it). We can incorporate Tom Tobin's ideas for
making it easier to write template tags. We can possibly tidy up some of
the internal interfaces (as you've no doubt seen,
django.templatetags.i18n does a lot of duplicate work that smells a bit
unnecessary and that's for historical reasons: more helper code has been
added since it was first written).
By all means, dive in and try some things out. Be very aware of
backwards compatibility. Or, rather, then pain inflicted when you break
it, so have a really good reason if you must do so. Try to work in
smallish incremental stages, as much as possible, so that our heads
don't explode when we try to review the patches.
Regards,
Malcolm
--
No one is listening until you make a mistake.
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: django.template.TokenParser inconsistent when it comes to filters...
Great.
Here are the tickets:
http://code.djangoproject.com/ticket/5971
http://code.djangoproject.com/ticket/5972
And while we're on the subject of tickets:
I've been digging around in the jungle of template parsing while
working on this patch and and the trans patch, and a thought occured
to me.
Why can't the Variable class handle processing of filters instead of
FilterExpression.resolve?
A Variable in a template is either a literal or a variable from the
context, and those can in most cases have filters applied to them.
Wouldn't it be nice if a Variable would simply have a "filters" list
and the resolve method would be the one doing the application of said
filters? (with the option to simply NOT apply the filters)
Obviously it's a pretty daring idea and I don't have much to back it
up right now, but my thought is that there seems to be way too many
steps involved in parsing a single token and there are many datatypes;
hard to keep track of everything.
If we look at it in the scope of tags and {{}} (what would I call
that?), then they can basically contain only a few datatypes:
literals, context variables, filters and parameters.
So why not make it a little more "defined" and give Variables the
power they deserve! ;)
It's 5am, so my thoughts are not coming out clearly. But if the above
makes you think "hmm, interesting", I can write up something more
detailed, maybe with some code examples...
//Dmitri
On Nov 18, 4:08 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Sat, 2007-11-17 at 18:27 -0800, Dmitri Fedortchenko wrote:
> > The django.template.TokenParser has a little problem.
>
> > I am not sure if this is a problem actually, but it is inconsistent
> > when parsing filters that follow constant strings or variables.
>
> > Meaning that:
> > {% tag thevar|filter sometag %} will produce:
> > self.value() = "thevar|filter"
> > self.tag() = "sometag"
>
> > However:
> > {% tag "a value"|filter sometag %} will produce:
> > self.value() = "a value"
> > self.tag() = "|filter"
> > self.tag() = "sometag"
>
> > This does not seem like correct behaviour...
> > I made a very simple patch for this, thus the outcome of the above:
>
> > {% tag "a value"|filter sometag %} will produce:
> > value = "a value"|filter
> > tag = sometag
>
> I think this is probably the right idea, yes. TokenParser is a bit of an
> odd duck. Nothing in core uses it except the i18n template tags, so it
> hasn't gotten as much attention during the recent Variable refactoring.
> When I do work in the i18n template tags I realise that the API of
> TokenParser really isn't particularly handy (it kind of cries out for an
> iterator, for example). Fortunately, most changes can be made
> incrementally and without backwards incompatibilities.
>
> I've kind of been holding off on doing much work here since it currently
> "mostly works" and Tom Tobin had some good ideas about making template
> tag creation a bit easier. I've been hoping to work with him at some
> point to get that polished up and into trunk. One of the places it would
> help simplify is django.templatetags.i18n.
>
> For now, I'd be happy if you'd create a ticket with your patch to make
> the above change. It's slightly backwards incompatible, but not in a
> hard-to-fix way for downstream developers (normally, the result of any
> such expression is going to be passed to compile_filter() anyway and
> this makes that easier).
>
> Regards,
> Malcolm
>
> --
> Remember that you are unique. Just like everyone
> else.http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: i18n missing feature ... continued (proposed solution for the upcoming sprint)
Sorry, I made a (hopefully obvious) mistake in my example, see below:
On Sun, 2007-11-18 at 04:33 +0100, Mark Green wrote:
> ---
>
> Template:
>
> -
> {% blocktrans with value|filter as number %}
> This will have [[]]one item[[]] inside
> {% plural %}
> This will have [[]]%{number} items[[]] inside
> {% endblocktrans %}
> -
>
> Translation strings:
>
> * This will have one item inside
> * This will have %{number} items inside
>
> Translated strings (english=>english for the sake of this example):
>
> * This will have one item inside
> * This will have %{0}%{number} items%{1} inside
This is wrong, the first translated string should read:
* This will have %{0}one item%{1} inside
Ofcourse the original string would still have worked
but there would be no hyperlink.
-mark
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: i18n missing feature ... continued (proposed solution for the upcoming sprint)
Hi,
On Fri, 2007-11-16 at 02:11 -0800, alain D. wrote:
> Hi,
>
>Following up on a previous discussion about an important but
> complex i18n missing feature :
> http://groups.google.com/group/django-developers/browse_thread/thread/c88b582fa4764aaa
>
> I've been thinking over and over about the problem and came up with
> an idea of a proposed syntax that I want to submit to the django
> community. Maybe the sprint coming up could be a chance for me to
> implement it under the wise patronage of a senior django fellow.
>
> Let say I want to print this (taken from django i18n manual page) :
> {% blocktrans with value|filter as number %}This will have
> {{ number }} items inside.{% endblocktrans %}
>
> But I want to have the words "{{ value }} items" to be a link on
> something (another page).
> Here is the proposed syntax (this may sound complex but I think it
> adresses a pretty complex [but frequent] problem ).
>
> {% blocktrans %}This will have
> {% insideblocktrans as link_items %}
>
> {% blocktrans with value|filter as number %}{{ number }}
> items{% endblocktrans %}
>
> {% endinsideblocktrans %}
> inside.
> {% endblocktrans %}
>
> This way, the string to translate would be :
> - "This will have %(link_items)s inside"
> - "%(number)s items"
I generally agree with your approach to the problem but the syntax
you propose is, sorry, horrible. It counts no less than 8 lines
with obscure markup, only to mark a oneliner for translation!
How about a less headache-inducing syntax, I'm thinking
along the lines of:
---
Template:
-
{% blocktrans with value|filter as number %}
This will have [[]]one item[[]] inside
{% plural %}
This will have [[]]%{number} items[[]] inside
{% endblocktrans %}
-
Translation strings:
* This will have one item inside
* This will have %{number} items inside
Translated strings (english=>english for the sake of this example):
* This will have one item inside
* This will have %{0}%{number} items%{1} inside
---
Notes:
* I'm not sure if and to what extent this may clash with existing
i18n syntax or semantics. I hope it doesn't contain fundamental
problems that cannot be solved with minor modification. Ofcourse,
turning double square brackets into a magic token presents a
problem in itself but that can be solved in the usual ways;
either with escaping or by equipping the blocktrans-tag with
a boolean "i really need verbatim double-square-brackets
in here"-parameter. Last not least the square brackets
can obviously be anything. Square, curly, dots,
dashes.. whatever.
* The square brackets basically exclude parts of the string
from translation. Other template substition (such as {% url %})
should still be performed on the excluded parts.
The so excluded parts are then, after translating the
remaining string, re-substituted into that, at the
marker positions (%{0}, %{1} etc.), in order of
appearance.
sorry, i hope that last sentence is somewhat legible.
i kinda struggled here! ;)
* Parsing of this syntax should be fairly trivial.
Both in code and (most importantly!) for the human
reading the template.
* As a pleasant side effect this can still function properly
even in the case when no translated string is found and django
has to fall back to the translation token itself.
* I think this should deal naturally with variations in
sentence structure.
* This obviously ties the translation strings very closely
to the order of "[[..]]"-tokens in the template markup.
This could be avoided by offering named tokens and there
may indeed be use-cases for that. Very wierd use-cases I guess,
but still use-cases...
Well, I deliberately left it out above to keep the example simple.
* For kicks, one could think about translating even the "excluded"
strings separately. Although I can't imagine a use-case
for this that couldn't be solved in a better way...
Just as the other participants in the thread you cited I'd be very
glad if this, or something similar, could get into django asap.
And ofcourse I'm open to all comments and discussion.
(does this even make sense or did I manage to totally
mess up something critical...)
-mark
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Using filters with {% trans %} tag
On Sat, 2007-11-17 at 17:47 -0800, Dmitri Fedortchenko wrote:
> Once again I return with my whacky ideas.
>
> I want to apply filters to my translations in the templates. So.
> I have created a patch which allows use of the following syntax:
>
> {% trans "username"|capfirst|slice:"2:" noop %}
> {% trans somevar|slice:"2:" %}
>
> The filters are applied on the result of the translation, and not the
> translation id string.
>
> While this is already possible by using the {{ _("username")|filter }}
> syntax, I think that {% trans %} is more "django-ish" and looks nicer
> too...
>
> Does anyone think this is useful?
+1 from me, providing it doesn't break the existing usage with _().
Create a ticket and attach the patch.
Malcolm
--
The sooner you fall behind, the more time you'll have to catch up.
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: django.template.TokenParser inconsistent when it comes to filters...
On Sat, 2007-11-17 at 18:27 -0800, Dmitri Fedortchenko wrote:
> The django.template.TokenParser has a little problem.
>
> I am not sure if this is a problem actually, but it is inconsistent
> when parsing filters that follow constant strings or variables.
>
> Meaning that:
> {% tag thevar|filter sometag %} will produce:
> self.value() = "thevar|filter"
> self.tag() = "sometag"
>
> However:
> {% tag "a value"|filter sometag %} will produce:
> self.value() = "a value"
> self.tag() = "|filter"
> self.tag() = "sometag"
>
> This does not seem like correct behaviour...
> I made a very simple patch for this, thus the outcome of the above:
>
> {% tag "a value"|filter sometag %} will produce:
> value = "a value"|filter
> tag = sometag
I think this is probably the right idea, yes. TokenParser is a bit of an
odd duck. Nothing in core uses it except the i18n template tags, so it
hasn't gotten as much attention during the recent Variable refactoring.
When I do work in the i18n template tags I realise that the API of
TokenParser really isn't particularly handy (it kind of cries out for an
iterator, for example). Fortunately, most changes can be made
incrementally and without backwards incompatibilities.
I've kind of been holding off on doing much work here since it currently
"mostly works" and Tom Tobin had some good ideas about making template
tag creation a bit easier. I've been hoping to work with him at some
point to get that polished up and into trunk. One of the places it would
help simplify is django.templatetags.i18n.
For now, I'd be happy if you'd create a ticket with your patch to make
the above change. It's slightly backwards incompatible, but not in a
hard-to-fix way for downstream developers (normally, the result of any
such expression is going to be passed to compile_filter() anyway and
this makes that easier).
Regards,
Malcolm
--
Remember that you are unique. Just like everyone else.
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
django.template.TokenParser inconsistent when it comes to filters...
The django.template.TokenParser has a little problem.
I am not sure if this is a problem actually, but it is inconsistent
when parsing filters that follow constant strings or variables.
Meaning that:
{% tag thevar|filter sometag %} will produce:
self.value() = "thevar|filter"
self.tag() = "sometag"
However:
{% tag "a value"|filter sometag %} will produce:
self.value() = "a value"
self.tag() = "|filter"
self.tag() = "sometag"
This does not seem like correct behaviour...
I made a very simple patch for this, thus the outcome of the above:
{% tag "a value"|filter sometag %} will produce:
value = "a value"|filter
tag = sometag
So now we can simply pass the "value" into a FilterExpression to parse
the filters...
Am I on the wrong track here?
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Using filters with {% trans %} tag
Once again I return with my whacky ideas.
I want to apply filters to my translations in the templates. So.
I have created a patch which allows use of the following syntax:
{% trans "username"|capfirst|slice:"2:" noop %}
{% trans somevar|slice:"2:" %}
The filters are applied on the result of the translation, and not the
translation id string.
While this is already possible by using the {{ _("username")|filter }}
syntax, I think that {% trans %} is more "django-ish" and looks nicer
too...
Does anyone think this is useful?
PS: the patch is not too complicated, it replaces about 10 lines of
code and adds 10 extra. but the results are magnificent! ;-)
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Problems with FileFields/ImageFields
Thanks a lot guys, I like many of your methods for solving the problem, and probably I'll implement one by now. But, I think that discusion should be about if it'll be good to change django itself in any way. May be form_for_model is behaving as expectly, but then, which method has Django for allowing outside admin to edit model information? In my opinion that's something very common. For example... For previous Person model, I want to allow in my website users to allow its own data. How can I do that? form_for_model doesn't work properly when editing existing data for FileFields (alse for ManyToManyFields). Not sure if creating my own form would work, but it would be a lot of repetitive work. Thanks! Marc On Nov 17, 8:30 pm, Thomas Steinacher <[EMAIL PROTECTED]> wrote: > Hello, > > Maybe the snippet which I created today can help you. It displays a > delete checkbox next to the type="file">:http://www.djangosnippets.org/snippets/469/ > > However, I'm not sure if it will work in admin. > > tom > > On 16.11.2007, at 18:12, Marc Garcia wrote: > > > > > There are a couple of things about FileFields that I want to comment. > > > First one is about how to delete content in a FileField. With a > > example: > > > I've a model: > > > class Person(model.Model): > >name = models.CharField(maxlength=32) > >[...] > >picture = models.ImageField(upload_to='pictures', blank=True) > > > Imagine that I've created a person record with a picture of anoother > > person, and I want to delete it (the picture). How can I do? I think > > that in admin it should be a checkbox for FileFields to remove > > content. > > > Second problem that I have. With an example as well. > > > In last application I want my users to upload its own data, so I > > create a page with a form generated with form_for_model for previous > > model. > > > When displayed, for a user that already exists, and already has a > > picture, an empty is displayed for picture > > field. User can't see it's own picture with admin's link, and when > > saved, old picture is dropped. I think that it should work like in > > admin (with delete checkbox). > > > Please, comment me what you think about and if necessary I'll develop > > fixing patches. > > > Thanks! > > Marc --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Problems with FileFields/ImageFields
Hello, Maybe the snippet which I created today can help you. It displays a delete checkbox next to the : http://www.djangosnippets.org/snippets/469/ However, I'm not sure if it will work in admin. tom On 16.11.2007, at 18:12, Marc Garcia wrote: > > There are a couple of things about FileFields that I want to comment. > > First one is about how to delete content in a FileField. With a > example: > > I've a model: > > class Person(model.Model): >name = models.CharField(maxlength=32) >[...] >picture = models.ImageField(upload_to='pictures', blank=True) > > Imagine that I've created a person record with a picture of anoother > person, and I want to delete it (the picture). How can I do? I think > that in admin it should be a checkbox for FileFields to remove > content. > > Second problem that I have. With an example as well. > > In last application I want my users to upload its own data, so I > create a page with a form generated with form_for_model for previous > model. > > When displayed, for a user that already exists, and already has a > picture, an empty is displayed for picture > field. User can't see it's own picture with admin's link, and when > saved, old picture is dropped. I think that it should work like in > admin (with delete checkbox). > > Please, comment me what you think about and if necessary I'll develop > fixing patches. > > Thanks! > Marc --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Problems with FileFields/ImageFields
> I've a model: > > class Person(model.Model): > name = models.CharField(maxlength=32) > [...] > picture = models.ImageField(upload_to='pictures', blank=True) > > Imagine that I've created a person record with a picture of anoother > person, and I want to delete it (the picture). How can I do? I think > that in admin it should be a checkbox for FileFields to remove > content. You van override the delete() method, with something like: class Person(model.Model): name = models.CharField(maxlength=32) [...] picture = models.ImageField(upload_to='pictures', blank=True) def delete(self): import os from mysettings import MEDIA_ROOT os.remove(MEDIA_ROOT+self_picture) super(Person, self).delete() ... or something like that. p.s. you might wanna put os.remove in a try...except statement, just in case. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Multiple Database Status Update
On Nov 17, 8:06 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > All you're doing is asking the same questions as in previous threads. > How does that inject clarity? We will disagree about the accuracy of that statement but your response is by far the most clear and succinct response to this question yet. Thank you. --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Multiple Database Status Update
On Fri, 2007-11-16 at 18:03 -0500, Elegantly Subtle wrote: > There's no real decisive answer to this recurring question so > hopefully this will inject some clarity into the discussion... All you're doing is asking the same questions as in previous threads. How does that inject clarity? > What is the current status of Multiple Database support in Django? Unknown. From time to time somebody pops up and says they are interested in supporting it. We always give them the same answer: support it as a third-party branch for a while until we're convinced they're serious. So far, nothing seems to have happened. > What is the timeline for integration of Multiple Database support in > the trunk? There isn't one. Currently multiple database support is essentially unmaintained. Unmaintained code has no chance of being merged. > The current ticket lists documentation as being the only outstanding > issue--Is this accurate? No. Regards, Malcolm -- Why can't you be a non-conformist like everyone else? http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Multiple Database Status Update
There's no real decisive answer to this recurring question so hopefully this will inject some clarity into the discussion... What is the current status of Multiple Database support in Django? What is the timeline for integration of Multiple Database support in the trunk? The current ticket lists documentation as being the only outstanding issue--Is this accurate? Just ordered the Django Book if that helps to get my question answered... ;) --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Patch polishing
> Jeremy Dunck wrote: >> As for close rates and other useful metrics, yeah, those should be >> more visible. :) Marty Alchin wrote: > I've wondered about building a Trac plug-in to monitor those types of > things and provide reports. There's a wealth of information in Trac > just waiting to be mined. Those Twisted guys have done it again: ;-) [Twisted-Python] Weekly Bug Summary http://twistedmatrix.com/pipermail/twisted-python/2007-November/016308.html and again: [Twisted-Python] Keeping track of what you're doing http://twistedmatrix.com/pipermail/twisted-python/2007-November/016328.html -- Nicola Larosa - http://www.tekNico.net/ Most users don't care about the distinction between GET and POST (sadly, neither do many developers), but I think there is an understanding that links just lead to another page, whereas buttons perform an action. I see no reason to violate this. -- Chris Shiflett, December 2006 --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
