Re: ./manage.py loaddata calls .save() on all models... should it?
On Wed, Mar 30, 2011 at 2:21 PM, George Karpenkov wrote: > If we'll look into core/management/commands/loaddata we'll see the > line > "obj.save(using=using)" which saves the data. ... and if you dig a little deeper, you'll find that "obj" in that context is a "DeserializedObject", and calling save() on a deserialized object invokes a "raw save" on the underlying object's base save. That is, the save() method on the object *shouldn't* be invoked as a result of loading a fixture. That's what was reported in #4459, and fixed in r5658. If you can provide a test case that demonstrates otherwise, please open a ticket. 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ./manage.py loaddata calls .save() on all models... should it?
Oh okay, apparently there is a ticket from 4 years ago http://code.djangoproject.com/ticket/4459 On Mar 30, 5:21 pm, George Karpenkov wrote: > If we'll look into core/management/commands/loaddata we'll see the > line > "obj.save(using=using)" which saves the data. > > *however* consider the case when application has some custom database- > altering logic in .save method. The common thing that comes to mind is > timestamp, or something similar. What would happen is that instead of > loading data the data from the fixture will be partly changed, which > is really not what you want. > > That's not the worst case though - I've just spent 40 minutes loading > the database from a fixture which contained data in django-tagging, > which inserts it's own "INSERT" SQL statements into save. So loaddata > was consistently crashing with "column blah is not unique" while the > data from the dump was perfectly fine. It made me quite sad. > > so coming to think of it i can't really think of a use case where > you'd want the custom logic in .save() to be executed. All the data is > already there, and we *know* that it is valid data - so what else we > might possibly want to do with it? (unless our application > communicates over network with different services and it uses .save() > to maintain integrity with them, but I haven't seen a single django > website like that) > So I think that some lower-level logic should be called instead. > > Any comments on why loaddata was implemented this way in the first > place? -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
./manage.py loaddata calls .save() on all models... should it?
If we'll look into core/management/commands/loaddata we'll see the line "obj.save(using=using)" which saves the data. *however* consider the case when application has some custom database- altering logic in .save method. The common thing that comes to mind is timestamp, or something similar. What would happen is that instead of loading data the data from the fixture will be partly changed, which is really not what you want. That's not the worst case though - I've just spent 40 minutes loading the database from a fixture which contained data in django-tagging, which inserts it's own "INSERT" SQL statements into save. So loaddata was consistently crashing with "column blah is not unique" while the data from the dump was perfectly fine. It made me quite sad. so coming to think of it i can't really think of a use case where you'd want the custom logic in .save() to be executed. All the data is already there, and we *know* that it is valid data - so what else we might possibly want to do with it? (unless our application communicates over network with different services and it uses .save() to maintain integrity with them, but I haven't seen a single django website like that) So I think that some lower-level logic should be called instead. Any comments on why loaddata was implemented this way in the first place? -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: switch to HTML5 for bundled templates
Maybe start thinking in other way.
Most of users has JS enabled browsers, if so, modernizr works.
Otherwise jQuery will not work either.
I can't remember when someone who has IE6 hit one of my django based
sites.
Maybe convert django to html5, and those who has to care about ie6
support should overwrite doctypes in templates and think about special
widgets. Give them {% block doctype %}{% endblock %}.
As far as I know ie6 won't recognize difference if there is doctype
specified, it is specified invalid, or there is none. Therefore it
should not crash.
Probably for 1 developer who needs to support ie6, there is 20 who
does not need to.
For me, this situation is like minority terrorizing the whole nation.
Overwriting admin templates is easy, providing widgets to fallback
html5 input types to text fields seems not to be complicated.
Consider this:
from django.forms.widgets_legacy import *
and we're free to go, providing support for forgotten browsers.
Google on its search main page is using , hence IMHO it
is nothing wrong with doctype.
BTW. Who is using proper mimetype with current django doctype in
cotrib admin?
I think that sticking with support for browser that even its creator
wants to die is wrong.
Django should go further and further, not stay in one place, because
of support for legacy features.
Django 1.3 is good, even very good, if someone wants to create django
based webapp with support ie6, should stick to 1.3 version.
Therefore 1.4 should have one of key feature: render with html5 by
default.
BTW. whatwg dropped from HTML5 its 5 in the name
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024477.html
In that case IE6 is not HTML complaint and browser specific hacks
should not be a official and main part of framework.
There should be point of no return for this. And I think that 1.3 is
very good release to end support for legacy browsers.
Otherwise why not to support lynx and table based design?
I use terminal browsers from time to time. I think it is even more
important, because google bot which greatly influence on our potential
revenue sees pages like lynx does.
If not support html5 features now before the 1.4 release, then mark
support for ie6 like the XMLField, obsolete and on an accelerated
deprecation schedule.
I rest my case ;}
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: FOR template tag improvement
I think it's not that pythonic as it's just another syntax to do a thing that we are already able to do with the current syntax. -1. -- Vinicius Mendes Globo.com On Tue, Mar 29, 2011 at 9:19 PM, Alex Gaynor wrote: > > > On Tue, Mar 29, 2011 at 7:19 PM, Russell Keith-Magee < > russ...@keith-magee.com> wrote: > >> On Tue, Mar 29, 2011 at 10:32 PM, Mikoskay wrote: >> > It's rather difficult to provide specific use case for something that is >> a >> > convenience-related proposal. :) >> >> The opposite should be true. If this is a proposal that is so >> convenient, there must be many ways in which it could be used. >> >> To me, this smells like an attempt to introduce business logic into >> your templates, which is something Django discourages. >> >> A clear use case that demonstrates otherwise might help to counter >> this argument; absent of such an example, I'm -1 to this as well. >> >> 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 >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> >> > I don't see how this is business logic. I do however see how it's totally > extraneous. -1. > > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > > -- > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Django Lines of Code
Sorry for that, but thanks for the answer. On Mar 28, 1:36 pm, Jacob Kaplan-Moss wrote: > On Mon, Mar 28, 2011 at 3:29 PM, Andrea Zilio wrote: > > I was just wondering if anyone knows the total number of lines of code > > of Django. > > Hi Andrea -- > > This question's off-topic for this list. Django-dev is for discussion > development of Django itself, and the length isn't really relevant. In > the future please help us try to keep the signal-to-noise ratio high > around here, OK? > > Jacob > > PS: 66,045 lines of code plus 51,174 lines of tests. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: FOR template tag improvement
On Tue, Mar 29, 2011 at 7:19 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Tue, Mar 29, 2011 at 10:32 PM, Mikoskay wrote: > > It's rather difficult to provide specific use case for something that is > a > > convenience-related proposal. :) > > The opposite should be true. If this is a proposal that is so > convenient, there must be many ways in which it could be used. > > To me, this smells like an attempt to introduce business logic into > your templates, which is something Django discourages. > > A clear use case that demonstrates otherwise might help to counter > this argument; absent of such an example, I'm -1 to this as well. > > 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 > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > I don't see how this is business logic. I do however see how it's totally extraneous. -1. Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
On Tue, Mar 29, 2011 at 8:17 PM, Luke Plant wrote: > On 28/03/11 13:04, Julien Phalip wrote: >> On Mar 28, 10:49 pm, Karen Tracey wrote: >>> +1 on having a distinction between bug, feature, and optimization. >>> >>> I don't think both "Uncategorized" and "Other" are necessary. >> >> My reasoning for "Other" was that there might be things that are >> neither a bug, a feature or an optimisation. I admit that I can't >> think of any specific example for it right now > > I've thought of some things that might go in 'Other', or perhaps could > go in a category of their own: > > "Cleanup", which would include: > * removing unused code and imports > * removing support code for older Python versions. > * converting doctests to unittests > * some refactorings like removing duplication. Personally, I could live with optimizations being included in this "Cleanup" group (or cleanups being included in "optimizations"... or a "cleanup and optimization" group... or a bikeshed). We're not looking to have a complex, fine grained ontology; we're just looking for a rough labels that lets us broadly categorize the stuff we have to do. Bug/Feature is the really important distinction. So, current proposal stands at 4 categories: * Uncategorized * Bug * New Feature * Cleanup/Optimization And 2 severities: * Normal * Release blocker Barring objection, I'll try to find some time this afternoon to introduce the new flags. (and, implicit in that -- I'm volunteering to spend some time processing backlog, too). 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: FOR template tag improvement
On Tue, Mar 29, 2011 at 10:32 PM, Mikoskay wrote: > It's rather difficult to provide specific use case for something that is a > convenience-related proposal. :) The opposite should be true. If this is a proposal that is so convenient, there must be many ways in which it could be used. To me, this smells like an attempt to introduce business logic into your templates, which is something Django discourages. A clear use case that demonstrates otherwise might help to counter this argument; absent of such an example, I'm -1 to this as well. 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
Am 29.03.2011 um 20:46 schrieb Shawn Milochik: > They can create a custom manager on the abstract class that would > return an iterable, perhaps using itertools.chain() of the querysets. > > It depends on what they expect to do with the output of this custom > manager, and they'd obviously lose the ability to treat this output as > a queryset by using additional sorts & filters and such. But if the > goal is to be able to get instances from all subclasses at once then > this is a viable solution, FWIW. FWIW, here is an implementation that does just that: https://github.com/emulbreh/shrubbery/blob/master/shrubbery/db/union.py __ Johannes -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
On 03/29/2011 02:46 PM, Shawn Milochik wrote: > I'm not proposing a change to Django itself or suggesting that this > should be a standard practice. I do think that this is a fairly clean > solution for an individual to use to solve this problem if they have > it. > > They can create a custom manager on the abstract class that would > return an iterable, perhaps using itertools.chain() of the querysets. Ah, I didn't realize that's the direction you were headed. Yeah, you can do this, and I've done it; it starts to hurt as soon as you want, say, sorting + pagination without pulling all of both tables into memory. > It depends on what they expect to do with the output of this custom > manager, and they'd obviously lose the ability to treat this output as > a queryset by using additional sorts & filters and such. But if the > goal is to be able to get instances from all subclasses at once then > this is a viable solution, FWIW. Yup. Carl -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
On Tue, Mar 29, 2011 at 2:21 PM, Carl Meyer wrote: > Hi Shawn, > > What you've outlined here is certainly possible (and yes, you'd need to > subclass the ModelBase metaclass). I haven't looked at the abstract > inheritance stuff recently, but I think there would be some alternative > ways for the abstract base to know about its children that wouldn't > require the metaclass assignment. However: getting the list of > subclasses is (less than) half the battle; the trickier part is giving > the ORM the capability to do UNION queries on similar tables, so you can > get results from multiple tables in a single QuerySet. Carl, Thanks for the explanation. That does make sense and I see where it gets really tricky when you delve into the ORM. I'm not proposing a change to Django itself or suggesting that this should be a standard practice. I do think that this is a fairly clean solution for an individual to use to solve this problem if they have it. They can create a custom manager on the abstract class that would return an iterable, perhaps using itertools.chain() of the querysets. It depends on what they expect to do with the output of this custom manager, and they'd obviously lose the ability to treat this output as a queryset by using additional sorts & filters and such. But if the goal is to be able to get instances from all subclasses at once then this is a viable solution, FWIW. Shawn -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
Hi Shawn, On 03/29/2011 01:28 PM, Shawn Milochik wrote: > Hopefully someone on the core dev team can let me know if this is > possible in Django. If so, it will solve this problem. > I am not familiar with custom metaclass stuff done within models.Model. > > 1. Create a custom metaclass as described in "Pro Python," page 124. > > 2. Add this metaclass to the abstract model. > > This would allow the base-class to be aware of its subclasses and have > a class method that returns a queryset of them. > > Further detail: > This simply amounts to creating a list object in the abstract base > class. Each time a subclass is instantiated, that class is added to > the parent class's list. That's all. That list could be used in a > custom manager to get the desired queryset. > > What I don't know is how nicely this will play with the existing > metaclass work in Django. It seems that a metaclass can be easily made > by subclassing the one used for models.Model instead of the default > 'type,' but this is beyond my experience level. Is this a reasonable > approach? What you've outlined here is certainly possible (and yes, you'd need to subclass the ModelBase metaclass). I haven't looked at the abstract inheritance stuff recently, but I think there would be some alternative ways for the abstract base to know about its children that wouldn't require the metaclass assignment. However: getting the list of subclasses is (less than) half the battle; the trickier part is giving the ORM the capability to do UNION queries on similar tables, so you can get results from multiple tables in a single QuerySet. Carl -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
On Tue, Mar 29, 2011 at 11:40 AM, Carl Meyer wrote: > On 03/29/2011 12:40 PM, Jeremy Dunck wrote: >> What about keeping abstract inheritance in this case, but allowing >> Document.objects.* to work by returning instances of the subclasses. >> Filtering, etc. would only work based on the Document base class. >> >> It would mean doing some unions, but would still fit the use case >> pretty well, I think. > > I'd certainly be intrigued to look at a patch that implemented that. I made a ticket; hopefully I'll get around to it some day: http://code.djangoproject.com/ticket/15711 -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
Hopefully someone on the core dev team can let me know if this is possible in Django. If so, it will solve this problem. I am not familiar with custom metaclass stuff done within models.Model. 1. Create a custom metaclass as described in "Pro Python," page 124. 2. Add this metaclass to the abstract model. This would allow the base-class to be aware of its subclasses and have a class method that returns a queryset of them. Further detail: This simply amounts to creating a list object in the abstract base class. Each time a subclass is instantiated, that class is added to the parent class's list. That's all. That list could be used in a custom manager to get the desired queryset. What I don't know is how nicely this will play with the existing metaclass work in Django. It seems that a metaclass can be easily made by subclassing the one used for models.Model instead of the default 'type,' but this is beyond my experience level. Is this a reasonable approach? Shawn -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
Cool. Well, maybe I can look into how abstract base classes are currently implemented and see if there's a way to generate query sets for all derived classes from the parent. Thanks for the insight! On Mar 29, 12:40 pm, Carl Meyer wrote: > On 03/29/2011 12:40 PM, Jeremy Dunck wrote: > > > What about keeping abstract inheritance in this case, but allowing > > Document.objects.* to work by returning instances of the subclasses. > > Filtering, etc. would only work based on the Document base class. > > > It would mean doing some unions, but would still fit the use case > > pretty well, I think. > > I'd certainly be intrigued to look at a patch that implemented that. > > Carl -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
+1 on blocker being a severity, -0 on "other" as an option here. +0 on the others. Happy to donate a couple hours reviewing a chunk of tickets in a coordinated way if we decide to do that. - Gabriel -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
On 03/29/2011 12:40 PM, Jeremy Dunck wrote: > What about keeping abstract inheritance in this case, but allowing > Document.objects.* to work by returning instances of the subclasses. > Filtering, etc. would only work based on the Document base class. > > It would mean doing some unions, but would still fit the use case > pretty well, I think. I'd certainly be intrigued to look at a patch that implemented that. Carl -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal for Template Engine Refactoring
Hi, On Mar 29, 3:54 pm, Jacob Kaplan-Moss wrote: > Can you speak a little more about how you'd see the workflow working > with this new library? It seems a bit complex to have a library that's > *copied* between Django and Jinja: I'd worry about patches getting > lost. I think that problem can mostly be avoided. The interpreter / compiler / ast combo library is probably very minimal in size. I don't see a big problem having to copy them into the Django svn every once in a while. That could even be automated. > For context, this has happened a few times with the simplejson and > elementtree libraries in core Python: patches made to the upstream got > "lost" before merging into Python's stdlib, and patches made against > the stdlib didn't make it upstream. stdlib is a more complex problem because it's tightly tied into the Python release cycle and has a separate set of developers. Even if I'm not a django developer I am never far from the project so it will be the same developer doing it during GSOC and afterwards. The extra work involved in making this work with both Jinja2 and Django and merging every once in a while should be minimal. The only problem would be other people doing changes to the codebase directly in the Django SVN. Which is why I would recommend having a dedicated separate repository for this thing (might as well be subversion if you want) where I and all Django developers have access for bugfixes if necessary. And also, once that thing is stable I don't think there is a lot to be done on the actual compiler. The Django specific stuff will not end up in that backend anyways. Regards, Armin -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
On Tue, Mar 29, 2011 at 11:11 AM, Carl Meyer wrote: > Hi Jordan, > > On 03/29/2011 11:40 AM, Jordan MacDonald wrote: >> I have three models, structured like so: >> >> Document >> -Presentation >> -Spreadsheet ... >> I'd like to be able to write >> Document.objects.all(). I'd then like to be able to iterate over this >> enumerable and have each object cast to its proper class. ... > I'm not sure I'd want to have yet another variety of inheritance as a > first-class feature of the Django ORM; the array of existing options > with MTI, abstract inheritance, and proxy models is quite confusing > enough to new users! What about keeping abstract inheritance in this case, but allowing Document.objects.* to work by returning instances of the subclasses. Filtering, etc. would only work based on the Document base class. It would mean doing some unions, but would still fit the use case pretty well, I think. -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Single Table Inheritance
Hi Jordan, On 03/29/2011 11:40 AM, Jordan MacDonald wrote: > I have three models, structured like so: > > Document > -Presentation > -Spreadsheet > > Document is never instantiated on its own; a prime candidate for an > abstract base class. However, there are times where I want to list/ > search across all documents, and I'd like to be able to write > Document.objects.all(). I'd then like to be able to iterate over this > enumerable and have each object cast to its proper class. > > This is something accomplished with single table inheritance in Rails; > why don't we have the equivalent in Django? > > I know I could just use the Document class and have a type field, but > then I have to do all of the type checking legwork manually. I was > hoping Django would handle normalizing/denormalizing as part of the > ORM. In essence, creating its own type field automatically in the back- > end and casting each object to the appropriate class based on the > string value in this field. > > Does anyone know why this isn't available? Is there an equally > efficient method of modeling this approach of which I am unaware? I agree with you that there are cases where single-table inheritance is the nicest model. We don't have it in Django because multi-table inheritance covers a wider array of use cases with a cleaner database schema, and allows you to e.g. have required fields on subclasses enforced by your database schema, which is not possible with STI. I'm not sure I'd want to have yet another variety of inheritance as a first-class feature of the Django ORM; the array of existing options with MTI, abstract inheritance, and proxy models is quite confusing enough to new users! I do, however, think an STI implementation for the Django ORM would be a great candidate for an external utility app (if someone hasn't done it already). I _think_ it'd be possible to do it without any modifications to Django itself (although it would probably require poking at some internal undocumented APIs), and might see significant uptake. Carl -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Single Table Inheritance
I'm sure this subject has been beaten to death, but I haven't found an answer to a simple scenario and I'm wondering why this hasn't been addressed before. I have three models, structured like so: Document -Presentation -Spreadsheet Document is never instantiated on its own; a prime candidate for an abstract base class. However, there are times where I want to list/ search across all documents, and I'd like to be able to write Document.objects.all(). I'd then like to be able to iterate over this enumerable and have each object cast to its proper class. This is something accomplished with single table inheritance in Rails; why don't we have the equivalent in Django? I know I could just use the Document class and have a type field, but then I have to do all of the type checking legwork manually. I was hoping Django would handle normalizing/denormalizing as part of the ORM. In essence, creating its own type field automatically in the back- end and casting each object to the appropriate class based on the string value in this field. Does anyone know why this isn't available? Is there an equally efficient method of modeling this approach of which I am unaware? -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Fwd: FOR template tag improvement
-1
I dislike the new proposed syntax.
2011/3/29 Mikoskay
> There are reasons.
>
> 1. It's handy and quick to type.
>
> {% for x in lst %}
> {% if x.is_something %}
> {{ x }}
> {% endif %}
> {% endfor %}
>
> vs
>
> {% for x in lst if x.is_something %}
> {{ x }}
> {% endfor %}
>
> I really believe it is a common task. For me it is.
>
> 2. It's pythonic. It wouldn't be some Django-specific weird syntax. Python
> list comprehensions already work this way.
>
> {% for x in lst if x.is_something %}
> {{ x }}
> {% endfor %}
>
> [x for x in lst if x.is_something]
>
> 3. It looks better and makes the template code more readable. See reason 1
> examples.
>
> --
> Mikołaj Siedlarek
>
>
>
> On Tue, Mar 29, 2011 at 3:50 PM, Jacob Kaplan-Moss wrote:
>
>> Hi Mikołaj --
>>
>> On Tue, Mar 29, 2011 at 8:45 AM, Mikołaj S. wrote:
>> > I've came up with an idea of improving default FOR template tag:
>> > {% for ... in ... %}
>> > By adding something similar to list comprehension syntax:
>> > {% for ... in ... if ... %}
>>
>> Can you give us some context for this request? What was the problem
>> you tried to solve that could only be solved by adding new syntax to
>> the template language?
>>
>> Without some context, this just sounds like adding syntax just because
>> we can, and I'm always going to be pretty against that. Simplicity is
>> a feature.
>>
>> 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
>> django-developers+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-developers?hl=en.
>>
>>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: FOR template tag improvement
Mikoskay, I understand Jacob. > It's rather difficult to provide specific use case for something that is a > convenience-related proposal. :) If its dificult to have a use case, may is not a good idea for a Open Source project trunk. And if its a "convenience-related proposal", its not a case to change template tags syntax. For me, django template tags are just fine. Less is more in this case. I see template tags, in some cases, almost as a "workaround" to do something very simple and quickly then change my view (for instance), or create a another view, url or another object_list etc... And I believe, templates are not made to have any logic inside. -- __ Carlos Leite www.znc.com.br __ -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
New messages API: regressions ?
Greetings hackers, Django offered a feature to add messages to offline users, or to add messages to users in slots (if that's the pythonic name for "functions connected to signals"). It is still possible before 1.4, to call myuser.message_set.create() which doesn't need the request object. In 1.4, it will only be possible to add messages to online users and only in code which has the request object in its scope. That means: - no more adding messages to offline users - no more adding messages to users in slots A django hacker insisted that I should post on the list about this change, in case you were not aware about the consequences which might be seen as a regression. Cheers -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: FOR template tag improvement
It's rather difficult to provide specific use case for something that is a
convenience-related proposal. :)
Let's make an analogy - why do we have AND boolean operator in IF tag,
though we could just write:
{% if first_condition %}
{% if second_condition %}
{{ x }}
{% endif %}
{% endif %}
instead of
{% if first_condition and second_condition %}
{{ x }}
{% endif %}
--
Mikołaj Siedlarek
On Tue, Mar 29, 2011 at 4:23 PM, Jacob Kaplan-Moss wrote:
> Sorry, but without a specific use-case I'm just not convinced.
>
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: FOR template tag improvement
Sorry, but without a specific use-case I'm just not convinced. 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: switch to HTML5 for bundled templates
I think it would be helpful here to clearly distinguish three distinct varieties of "using HTML5," two of which are clear wins and one which I don't see any reason to do: 1. Switching to the HTML5 doctype in those few places where Django actually renders a full page with doctype (the admin, databrowse, CSRF failure page). This is fully backwards and forwards compatible, and there is no reason (AFAICS) why we should not simply do it. It gives people writing custom admin widgets more flexibility, without losing anything. IMO "configurability" here is overkill; the admin (and databrowse) are standalone apps: they just need to be internally consistent and work well in all browsers. 2. Providing HTML5 form widget types (email, date, etc) in django.forms. These are very useful in newer browsers, and fall back gracefully to input type="text" in older browsers, so again I don't see a downside. Unlike HTML5-only elements (see #3), these input types don't cause a problem with CSS in IE. 3. Introducing HTML5-only elements (nav, section, footer, etc) anywhere in Django-provided templates. This requires Javascript help to work with most IE versions. Given that the current markup in Django works fine and is already valid HTML5, I don't see why we would want to do this, short of possibly in a full admin redesign later on. My understanding is that Luke is proposing 1 & 2, but not 3 - and I agree with that. Like others, I'm interested in hearing from Idan on this. Carl -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal for Template Engine Refactoring
Hi Armin -- Can you speak a little more about how you'd see the workflow working with this new library? It seems a bit complex to have a library that's *copied* between Django and Jinja: I'd worry about patches getting lost. For context, this has happened a few times with the simplejson and elementtree libraries in core Python: patches made to the upstream got "lost" before merging into Python's stdlib, and patches made against the stdlib didn't make it upstream. For a while there the json library in the stdlib was ever so slightly different from the simplejson library of supposedly the same version. Do you have ideas about how we could avoid this problem? (For the record, I wouldn't be opposed to having your proposed library be an external dependency. At some point the Python packaging ecosystem will be good enough that we can stop bundling, and I think we're getting pretty close to that point. But understood if that's a battle you don't want to fight :) 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: FOR template tag improvement
There are reasons.
1. It's handy and quick to type.
{% for x in lst %}
{% if x.is_something %}
{{ x }}
{% endif %}
{% endfor %}
vs
{% for x in lst if x.is_something %}
{{ x }}
{% endfor %}
I really believe it is a common task. For me it is.
2. It's pythonic. It wouldn't be some Django-specific weird syntax. Python
list comprehensions already work this way.
{% for x in lst if x.is_something %}
{{ x }}
{% endfor %}
[x for x in lst if x.is_something]
3. It looks better and makes the template code more readable. See reason 1
examples.
--
Mikołaj Siedlarek
On Tue, Mar 29, 2011 at 3:50 PM, Jacob Kaplan-Moss wrote:
> Hi Mikołaj --
>
> On Tue, Mar 29, 2011 at 8:45 AM, Mikołaj S. wrote:
> > I've came up with an idea of improving default FOR template tag:
> > {% for ... in ... %}
> > By adding something similar to list comprehension syntax:
> > {% for ... in ... if ... %}
>
> Can you give us some context for this request? What was the problem
> you tried to solve that could only be solved by adding new syntax to
> the template language?
>
> Without some context, this just sounds like adding syntax just because
> we can, and I'm always going to be pretty against that. Simplicity is
> a feature.
>
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: FOR template tag improvement
Hi Mikołaj --
On Tue, Mar 29, 2011 at 8:45 AM, Mikołaj S. wrote:
> I've came up with an idea of improving default FOR template tag:
> {% for ... in ... %}
> By adding something similar to list comprehension syntax:
> {% for ... in ... if ... %}
Can you give us some context for this request? What was the problem
you tried to solve that could only be solved by adding new syntax to
the template language?
Without some context, this just sounds like adding syntax just because
we can, and I'm always going to be pretty against that. Simplicity is
a feature.
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal for Template Engine Refactoring
Hi, On Mar 29, 2:23 pm, Jonathan S wrote: > Are you planning on keeping the API for registering template tags > compatible? (django.template.Library.register.tag) It will be supported because otherwise upgrading won't be possible, but how well this works in detail would have to be investigated and what a cleaner implementation looks like. Jinja2 has an expression parser and encourages people to create a AST that does what they want in extensions. However in Jinja2 I never encouraged people to write custom tags so the API is very limited there. Regards, Armin -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Complains about FileField not deleting files in 1.3.
Hi Alex, On 03/29/2011 01:36 AM, Alex Kamedov wrote: > I think, cron jobs is an overhead in many simple cases where old > behaviour was useful and more simpler. > Why you don't want include DeletingFileField[1] in django? > > [1] https://gist.github.com/889692 Because, as mentioned above, it is known to cause data loss in certain situations (rolled-back transactions, overlapping upload-to directories), and we are not very fond of including things in Django that cause some Django users to lose their data. If you understand those risks and want to use DeletingFileField in your projects, it's not hard to do so. Carl -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: switch to HTML5 for bundled templates
On 29/03/11 04:29, Julien Phalip wrote: > Since the patch is small, then it would be very quick to test it in > all browsers right away, no? :-) I've spent 20 minutes testing out the admin with this patch and IE6, and haven't found any issues (at least, none that aren't already present without the patch - I found that the list of deleted objects is not indented as in other browsers in IE6, and I got the dreaded 'broken pipe' error several times, with or without the patch). I also found a handful of validity errors - at least according to validator.nu, which happens to be very crashy when running on my machine, making validation a bit tricky. Finding more issues than this will only happen by putting it out there in the wild, because so few people are using IE6, especially developers. Luke -- If you can't answer a man's arguments, all is not lost; you can still call him vile names. (Elbert Hubbard) Luke Plant || http://lukeplant.me.uk/ -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
FOR template tag improvement
Hi,
I've came up with an idea of improving default FOR template tag:
{% for ... in ... %}
By adding something similar to list comprehension syntax:
{% for ... in ... if ... %}
Filtering through looping is so common task that I'm sure many people would
find this syntax quite handy.
I'll be happy to implement it if only you give me your green light.
And sorry if this matter has already been discussed. It seems like a good
idea someone had to came up before, but I just couldn't find anything on it.
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal for Template Engine Refactoring
+1 on this. Are you planning on keeping the API for registering template tags compatible? (django.template.Library.register.tag) I think this may be required for backwards-compatibility, but personally, I'd like to see a cleaner API for this, which doesn't expose the parser details. (Writing template tags should not involve any token manipulation.) On 29 mar, 13:55, Armin Ronacher wrote: > Great. Google groups decided to reflow my mail. Here in actually > readable version:http://paste.pocoo.org/show/362024/ > > Regards, > Armin -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
On 28/03/11 13:04, Julien Phalip wrote: > On Mar 28, 10:49 pm, Karen Tracey wrote: >> +1 on having a distinction between bug, feature, and optimization. >> >> I don't think both "Uncategorized" and "Other" are necessary. > > My reasoning for "Other" was that there might be things that are > neither a bug, a feature or an optimisation. I admit that I can't > think of any specific example for it right now I've thought of some things that might go in 'Other', or perhaps could go in a category of their own: "Cleanup", which would include: * removing unused code and imports * removing support code for older Python versions. * converting doctests to unittests * some refactorings like removing duplication. Luke -- If you can't answer a man's arguments, all is not lost; you can still call him vile names. (Elbert Hubbard) Luke Plant || http://lukeplant.me.uk/ -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
On 29 March 2011 22:42, Luke Plant wrote: > As for the gardening, there are about 1700 open tickets that need the > type setting. Those needing the severity field changing to 'Blocker' can > be found more easily here: > > > http://code.djangoproject.com/query?status=assigned&status=new&status=reopened&keywords=~regression&col=id&col=summary&col=keywords&col=status&col=owner&col=component&order=priority > > Can we get 20 volunteers to do this, and someone to volunteer to > organise us all? > > I'm happy to spend time doing, say, 100 tickets. We could perhaps divide > up by ticket number to avoid duplicating work, remembering that there > are far more open tickets with higher numbers. Remember we can use the > batch modify plugin to avoid sending 1000s of e-mails, but if you are > not a Trac admin you'll need some permissions adding, probably > temporarily, to use that feature. > If we decide to do a massive refresh of all tickets, then count me in as a volunteer to help out. However, I'm not sure that we actually need to do this. I've been thinking about this and I tend to think that it's probably just good enough to catch up with the backlog bit by bit and update the attribute for new tickets and other tickets that we browse during our routine rounds. If some tickets never get updated, then it means that nobody cares enough about them, so they're probably OK to leave as-is and not worry about. Just a thought. Julien -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal for Template Engine Refactoring
Great. Google groups decided to reflow my mail. Here in actually readable version: http://paste.pocoo.org/show/362024/ Regards, Armin -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Proposal for Template Engine Refactoring
Hi, I would like to participate in this year's Google Summer of Code by introducing a new backend for the Django (and Jinja2) templating language. As the author of Jinja2 I recently decided to rewrite the code generation of the engine to better support alternative Python implementations like PyPy and restricted environments like Google's Appengine. The Jinja2 backend is already usable for other templating engines as well for as long as the sematics are compatible with the ones from Jinja2. However with a better backend design the Django semantics should be possible to implement in there as well. As such as I am proposing to keep this backend independent of either Django and Jinja2. I would maintain inside a separate repository and with each release of Jinja2 and Django port fixes into their respective code bases. This could also be used as a basis for other template engines or domain specific languages if necessary. The reason I don't want to keep this a separate package but actually copy the code over to Django and Jinja2 are twofold. First of all I don't want to introduce a new dependency for the template engines themselves. Secondly I really want to keep this an implementation detail for Jinja2 at the very least. In Django we don't want to see dependencies either. Reasons (coming from the current Jinja2 backend) for a new version: 1. implement a drop-in interpreter as alternative to the template compilation for better error reporting during development. 2. implement an ast.py based compiler in order to avoid the debug traceback hackery that is currently in place to support debugging of templates with accurate line numbers. 3. Better support for jit interpreted Python installations like PyPy by removing the need to call locals() or sys._getframe which is currently required by Jinja2 in order to implement includes. 4. Python generating compiled for GAE. This one would not have the same error handling capabilities as the interpreter and the AST based compiler, but has the advantage of running everywhere and would allow module based importing like the one currently in use in Jinja2. Reasons why this is interesting for Django: 1. It would greatly speed up execution of core tags. The idea is to use code generation for the builtin tags and to generate a context as necessary when droppping into old-style custom tags. 2. Provide a new API that can be used for new tags that allow code generation behind the scenes. 3. Better debugging capabilties by providing actual Python tracebacks for errors in templates. How much speedup will we see in Django? Probably not as much as people are hoping as Django's current semantics just cannot be sped up to Jinja2 levels by keeping the extension API unchanged. However because there are already some abstractions in place we can probably achieve a significant speedup for certain common template types that it reduces the need to switch to Jinja2. Why am I proposing this as a GSOC Django project instead of hacking on this under the umbrella of the PSF for Jinja2 alone? First of all, speeding up Jinja2 is a boring task right now as it is very close to raw Python performance already. Secondly there was a proposal by Alex last year and there is already a proposal here about template engine compilation backends and if I am going to do this for Jinja2 anyways, I can keep it generic enough to also support Django. Regards, Armin -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Suggestion: a new "nature" field in Trac
On 28/03/11 16:22, Luke Plant wrote: > On 28/03/11 15:50, Russell Keith-Magee wrote: > >> However, I accept your point about splitting bug into two categories. >> Making it two different flags was a suggestion for expediency of >> implementation, but I can see how it will complicate your life with >> reports. So I suppose we'll just have to hunt down someone with access >> to the server to add the 'blocker' flag, and as an interim, continue >> to use keywords. > > An alternative would be to use the 'Severities' category, adding just > 'normal' (the default) and 'blocker'. Having looked at it, that seems like a sensible way to go, so to keep this momentum, can I suggest the following. Enable the 'type' field: with: * Uncategorized (default) * Bug * New Feature * Optimization Enable the 'severities' field, with: * Normal (default) * Blocker As for the gardening, there are about 1700 open tickets that need the type setting. Those needing the severity field changing to 'Blocker' can be found more easily here: http://code.djangoproject.com/query?status=assigned&status=new&status=reopened&keywords=~regression&col=id&col=summary&col=keywords&col=status&col=owner&col=component&order=priority Can we get 20 volunteers to do this, and someone to volunteer to organise us all? I'm happy to spend time doing, say, 100 tickets. We could perhaps divide up by ticket number to avoid duplicating work, remembering that there are far more open tickets with higher numbers. Remember we can use the batch modify plugin to avoid sending 1000s of e-mails, but if you are not a Trac admin you'll need some permissions adding, probably temporarily, to use that feature. Regards, Luke -- If you can't answer a man's arguments, all is not lost; you can still call him vile names. (Elbert Hubbard) Luke Plant || http://lukeplant.me.uk/ -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Trac milestones
On 29/03/11 03:29, Julien Phalip wrote: > Hi, > > Since we've recently been discussing a few ways to improve Trac, I'm > suggesting to move the discussion which started a few minutes ago in > #5833 here so as not to pollute the ticket with too many meta > conversations. I'd also like to apologise for the confusion I seem to > have stirred by changing the milestone attribute of that ticket to > 1.4... It was probably just as much my fault for changing it back, no need to apologise. I think we have been inconsistent with our use of this field, and my point in removing it was to make it clear that, despite what some people on that ticket no doubt believe, adding yourself as a CC to a ticket does nothing to make it happen, and neither does setting the milestone. Your e-mail makes me question the usefulness of the field too. One case it is useful when we near a release and there are some bugs that we need to get fixed. But perhaps that is overlapping with 'blocker' status. Another case is when we decide, as we did at least for 1.1 to 1.3, that certain features are going to get a lot of attention, including a core developer who commits to either developing or managing the feature into Django. Perhaps we should clear the milestone flags on all tickets, and add them only when a core developer commits to getting a ticket in. However, although a commitment from a core developer has usually been pretty meaningful, it is still possible that the feature won't arrive if it's simply not ready (I don't know what our record is like on this front - I suspect it has been pretty good, but not perfect). So what does the milestone flag actually tell you? The people developing the feature will know that they are doing so, and for other people looking on, the milestone flag may be taken as some kind of guarantee that it gets in. In reality, as Alan Kay said, "the best way to predict the future is to invent it", and maybe the lack of a milestone flag would actually encourage involvement. Thanks for opening the discussion, Luke -- If you can't answer a man's arguments, all is not lost; you can still call him vile names. (Elbert Hubbard) Luke Plant || http://lukeplant.me.uk/ -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: switch to HTML5 for bundled templates
On 29/03/11 05:52, Gabriel Hurley wrote: > Switching to the HTML5 doctype won't hurt IE6 rendering (having dealt > with this myself several times). To the best of my knowledge--from my > own tests and third-party sources--using the new input attributes also > doesn't hurt IE6. However, if we start delving deeper into HTML5 and > using the new HTML5 elements, etc. we will definitely hit problems very > quickly. Techniques for solving those problems are pretty readily > available these days, but I don't think we have any reason to go there > right now. > > All the same, I'd still rather give people the choice and ability to > change output rendering rather than simply making a unilateral change. > I'd love for our default to be the modern choice as long as it's an > easily changeable option! I don't think we can talk about "output rendering", as if internally to Django we had an output agnostic document tree which we just have to render. The reality is that in Django we've got XHTML markup. I think that supporting multiple doctypes by rendering different output, depending on the choice of the developer putting the site together, is actually a bad idea - a bug not a feature. My reasons are: * every attempt I've seen to get this working in Django has been as ugly as sin, and incurs performance and API overhead. * in reality, re-usable apps are going to go for one doctype or another, thus fragmenting the app ecosystem. * For those targeting HTML5, you *still* have to choose your features very carefully in line with browser support, and for those targeting older browsers you still have to be careful to work around browser bugs. In short, I think it it neither realistic nor worthwhile to go for the multiple doctype approach. Instead, I think we should think about the ultimate goal, which is compatibility with old browsers. And to address that, we should take the same approach as HTML5, and the approach that we *have* to take even with the very newest browsers, which is to carefully select features that have good browser support, providing graceful degradation for those that don't - and do this from a *single* output. As Django is a framework and is used in many situations, we're going to be pretty conservative. I think we need to support IE6 for some time, which at least means everything that works now continues to work correctly, although I'd allow for any older browser to suffer degradation in user experience in new features, relative to newer browsers. For an example of the kind of thing I mean, a new feature in the admin might make use of spin boxes: http://diveintohtml5.org/examples/input-type-number-min-max-step.html We'd certainly have server-side validation, and ideally we'd have a javascript fallback, but I would be happy for the feature to go in even without the javascript fallback. But I think we should argue those things out on a case-by-case basis. > But hey, aren't we starting to stray into... ::gasp:: front-end > territory here?! Where's our Benevolent Designer For Life ;-) I for one would definitely like Idan's input here, I'm sure he has more experience than me! Luke -- If you can't answer a man's arguments, all is not lost; you can still call him vile names. (Elbert Hubbard) Luke Plant || http://lukeplant.me.uk/ -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
GSoC Student and Mentor Applications Open
Hi everyone, Just a reminder that student and mentor applications for GSoC are now open on the SoC website (middle column, at the bottom): http://www.google-melange.com/gsoc/homepage/google/gsoc2011 Students, you have until 7pm GMT on April 8th to get your submissions in; if you want more information on how we run GSOC here, see my previous post to this list: http://groups.google.com/group/django-developers/msg/4e754d25010dbe03 Remember, we ask that you post any proposal to django-developers for discussion _before_ you submit it to GSoC - undiscussed applications are likely to get rejected. Mentors, make sure you're also entered at the top of the wiki page (you also have longer to sign up - until April 22nd, when we'll need to have assigned all successful projects mentors): http://code.djangoproject.com/wiki/SummerOfCode2011 Andrew -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: switch to HTML5 for bundled templates
Using HTML5 tags in IE _will_ break it at some point. There is ofcourse the
work around with "document.createElement('article')" etc used by modernizr
But:
1. This will not work for IEs' that have JS disabled
2. Will break if you insert HTML5 tags by javascript into the "innerHTML"
attribute of tags (even those that were created with the workaround above).
Point 2 hit mit just a few weeks ago and is even valid for IE 8. The problem
is that even jQuery is using the innerHTML attribute in it's .append() method
and others which are very common to must jQuery users.
To be honest, there is a workaround for this as well. But it requires either
patching jQuery or to change ALL YOUR CODE that uses .innerHTML (including
all your uses of jQuery.fn.append()). [1]
Input types are not effected by this bug afaik.
Gregor
[1] http://jdbartlett.github.com/innershiv/
2011/3/29 Matt Harasymczuk :
> How about delivering http://www.modernizr.com/ library.
> In my case it solves all problems with non existing tags (nav,
> section, header, article, footer) in such browsers as IE.
>
> We ship jQuery with admin, why not use modernizr to support legacy
> browsers.
>
> I am positive, about input types fallback to text.
> I have tested this for a long time and it works.
>
> Generally speaking converting contrib apps to html5 would be a very
> good idea! Most django deployments does not depend on whether it has
> html4 or 5.
> Those who stick with 4, should have the same functionality provided by
> fallback in their browsers, however the largest part of the remaining
> group should benefit from transition.
>
> Google dropped support for IE6 legacy browsers more than year ago!
> http://googleenterprise.blogspot.com/2010/01/modern-browsers-for-modern-applications.html
>
> Even microsoft wants IE6 dead
> http://ie6countdown.com/
>
> I think we should join this movement, and provide modernizr, for
> example in conditional css tag
>
>
> It works for me, hence all should benefit from it.
>
>
> --
> Matt Harasymczuk
> http://www.matt.harasymczuk.pl
>
> --
> 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
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Proposal: switch to HTML5 for bundled templates
How about delivering http://www.modernizr.com/ library. In my case it solves all problems with non existing tags (nav, section, header, article, footer) in such browsers as IE. We ship jQuery with admin, why not use modernizr to support legacy browsers. I am positive, about input types fallback to text. I have tested this for a long time and it works. Generally speaking converting contrib apps to html5 would be a very good idea! Most django deployments does not depend on whether it has html4 or 5. Those who stick with 4, should have the same functionality provided by fallback in their browsers, however the largest part of the remaining group should benefit from transition. Google dropped support for IE6 legacy browsers more than year ago! http://googleenterprise.blogspot.com/2010/01/modern-browsers-for-modern-applications.html Even microsoft wants IE6 dead http://ie6countdown.com/ I think we should join this movement, and provide modernizr, for example in conditional css tag It works for me, hence all should benefit from it. -- Matt Harasymczuk http://www.matt.harasymczuk.pl -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Template Compilation
Maybe. We solved that use-case by adding another custom directory to
TEMPLATE_DIRS when we had to override the base template. But I can
imagine that someone wants to be able to dynamically change the base
template, from inside a view or context processor.
This was a choice we made, because almost all the other features
depend on this. Having dynamic inheritance means having {% block %}
tags processed during rendering, and it means not being able to
process any of the HTML/css/js at compile time. For now, I have no
intension to change this behaviour, but of course anyone is welcome to
contribute.
Somehow, I'm still not really convinced of dynamic inheritance. It
feels like doing this in Python:
class A(random.choice([list,dict])): pass
On 28 mar, 18:13, Jacob Kaplan-Moss wrote:
> On Mon, Mar 28, 2011 at 11:04 AM, Dan Fairs wrote:
> > We don't have a core site base template. Each client on our system gets
> > their own, as IA/branding etc. varies considerably (and indeed includes
> > chunks of markup that the client supplies directly).
>
> ... and congratulations, you've successfully reversed-engineered the
> very use-case that led us to create this feature in the first place!
>
> 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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
