Re: Feature request for newforms: HTML 4
On 12/5/06, James Bennett <[EMAIL PROTECTED]> wrote:
> Now, I'm pretty picky about my markup, and I'm certainly willing to go
> to unusual lengths to get it just the way I want it, but it'd be
> awfully nice if there were some way to get HTML-style output from
> newforms without having to manually subclass all the widgets and
> override their rendering to remove trailing slashes.
+1 to this proposal. I found myself writing the code below, which is
quite scary but does the trick:
[[[
from django import template
"""
Remove XHTML endings from tags to make them HTML 4.01 compliant
Usage:
{% load html4 %}
{% html4 %}
My long template with {{ variables }} and
{% block whatever %} blocks {% endblock %}
{% endhtml4 %}
"""
def do_html4(parser, token):
nodelist = parser.parse(('endhtml4',))
parser.delete_first_token()
return Html4Node(nodelist)
class Html4Node(template.Node):
def __init__(self, nodelist):
self.nodelist = nodelist
def render(self, context):
output = self.nodelist.render(context)
return output.replace(' />', '>')
register = template.Library()
register.tag('html4', do_html4)
]]]
Cheers.
--
Antonio
--~--~-~--~~~---~--~~
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: Feature request for newforms: HTML 4
James Bennett wrote: > Now, I'm pretty picky about my markup, and I'm certainly willing to go > to unusual lengths to get it just the way I want it, but it'd be > awfully nice if there were some way to get HTML-style output from > newforms without having to manually subclass all the widgets and > override their rendering to remove trailing slashes. The question is where to stop. Pickiness may lead further to having an option to omit quotes around attribute values, have uppercase tag names, omit end tags of etc... This is all working HTML (even valid by DTD). Since all these things happily work in browsers the only difference between "/>" and the rest is that it is not DTD-valid HTML 4.01. However to my puristic point of view this is not a problem because DTD validation is effectively useless. The only user agent that does DTD validation is W3C's validator itself. No real browser ever considered HTML as SGML application and never used DTD for its validation. In fact what guys at WHAT WG[1] are doing now for HTML5 is specifying exactly the syntax that browsers use for parsing HTML. And "/>" will be valid HTML5. So from my point of view a real HTML purist would ignore HTML 4.01 validation altogether. :-) --~--~-~--~~~---~--~~ 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: Feature request for newforms: HTML 4
Ivan Sagalaev wrote: > > Since all these things happily work in browsers the only difference > between "/>" and the rest is that it is not DTD-valid HTML 4.01. In fact I'm wrong here... I just checked that W3C's validator doesn't object to ""s. This is a valid HTML 4.01: http://www.w3.org/TR/html4/strict.dtd";> Test So even "invalidness" is not a point. What's then? --~--~-~--~~~---~--~~ 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: Full text searches in Django
On 11/28/06, Jyrki Pulliainen <[EMAIL PROTECTED]> wrote: > > > On 11/28/06, John Sutherland <[EMAIL PROTECTED]> wrote: > > > > While this is MySQL fulltext specific, it may be of use when you start > > tinkering with the Django code: > > > http://www.mercurytide.com/knowledge/white-papers/django-full-text-search > > > > Thank you, the document seems extremely useful. I'll dig into it. You can try too the http://code.djangoproject.com/wiki/TextIndexingAbstractionLayer with Xapian backend -- SDM Underlinux http://stiod.wordpress.com Membro da equipe UnderLinux -- PEP-8 There is only 2 kinds of peoples in the world, who know English, and I. oO --~--~-~--~~~---~--~~ 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: Default representation of a Form
Lakin Wecker wrote: > as_dl() gets a +1 from me. I've used definition lists for forms and > prefer it over tables. :) Maybe there needs to be an easy hook for people to specify their own way of laying a form out. It seems the as_ methods are gonna keep growing and growing. -- Lach Personal: http://illuminosity.net/ --~--~-~--~~~---~--~~ 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: Re: Suggestion: Aggregate/Grouping/Calculated methods in Django ORM
On 12/4/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> I'm taking this to django-dev for more discussion; it'll get seen by more the
> right people there.
>
> Thoughts, anyone?
Ok; here's my thoughts.
1. Introduction
~~~
Consider the following pseudo-model:
class Book(Model):
name = CharField()
price = FloatField()
pub_date = DateField()
class Order(Model):
description = CharField()
time = DateTimeField()
books = ManyToManyField(Book)
Simple aggregation use cases would be questions like:
a) What is the cheapest book?
b) What is the average book price?
c) Find me all the books with a price greater than the average.
d) What is the total cost of order 1234?
These questions require that you query the database to obtain a single
aggregated value, or a object matching that aggregated value.
However, the more general class of problem is to generate a summary
statistic for each object in a query, with the summary stats coming
from the related objects. For example:
e) What is the total cost of _each_ order?
IMHO, what we need is the ability to annotate summary statistics onto
the results returned by a query set.
2. Proposal
~~~
Add an 'annotate()' modifier to QuerySets. The arguments of annotate()
describe the annotations that you want to be applied to the objects
that are returned by the Query Set.
annotate() returns a query set, so it can be used multiple times, be
combined with filters, etc. The argument handling strategy employed in
filter() is reused here; kwargs to annotate() can be decomposed on a
__ boundary to describe table joins, with the last part describing the
aggregate operator to be used. The syntax follows something like:
Model.objects.annotate(field1__field2__aggregate='annotation')
field1__field2 describes the path to get to the field that will be
ultimately aggregated; aggregate is the aggregation function (max,min
etc); the value of the argument is a string that is the name of the
annotate argument.
The objects that are returned when the queryset is executed will be
normal objects, but with additional attributes corresponding to the
annotations.
e.g.,
# Get order 1234, and annotate it a few different ways
>>> order = Order.objects.get(id=1234).annotate(
books__price__sum='total_cost',
books__count='item_count')
# Inspect the order
>>> order.description
"Dad's birthday"
# Annotated orders have a 'total_cost' attribute...
>>> order.total_cost
47.2
# ... and an 'item_count' attribute
>>> order.item_count
3
3. Just the facts, Ma'am
Ok; so what if you just want _the minimum_, or _the average_? For
this, I propose an aggregates() queryset modifier.
>>> Book.objects.aggregates(price__min='min_price', pub_date__max='last_update')
{'min_price':0.5, 'last_update': 2006-11-22}
aggregates() would expand queries in the same manner as annotate(),
but would be a terminal clause, just like the values() clause.
This is a more verbose notation than the simple 'max()/min()' . I have
discussed my problems with these operators previously; however, if
there is sufficient demand, I don't see any reason that min('field')
couldn't be included in the API as a shorthand for
Model.objects.aggregates(field__min='min')['min'].
4. Comparisons
~~
There is one additional requirement I can see; to perform queries like
(c), you need to be able to compare annotation attributes to object
attributes.
# Annotate a query set with the average price of books
>>> qs = Book.objects.annotate(price__average='avg_price').
# Filter all books with obj.avg_price < obj.price
>>> expensive_books = qs.filter(avg_price__lt=F('price'))
The F() object is a placeholder to let the query language know that
'price' isn't just a string, it's the name of a field. This follows
the example of Q() objects providing query wrappers.
This capability would also be beneficial to the query language in
general; at present, there is no easy way to pull out all objects
where field1 = field2.
5. Implementation
~
Now the mechanics: What does annotate() do to the SQL?
If there is an annotate clause in a query set:
- All of the base model attributes (the attributes that would normally
be returned by the queryset) are placed in a GROUP BY clause
- Any query on a base model attribute is placed in a HAVING clause
- Any query on the annotation field is placed in a WHERE clause
- If the annotation clause traverses joins, those tables are joined in
the same manner as they would be for filter().
6. Limitations/Problems
~~~
- This approach doesn't handle any particularly creative usage of the
GROUP BY clause. I'm open to suggestions, but I'm also happy to put
this problem subset into the 20% "do it in raw SQL" category.
- I'm not overly enamoured with the name aggregates() - it isn't a
particularly intuitive name for the functionality provided; summary()
is the only other option I could think of.
- I haven't tried to implement
Re: Suggestion: Aggregate/Grouping/Calculated methods in Django ORM
On 12/4/06, DavidA <[EMAIL PROTECTED]> wrote:
>
> Would I have to call queryset.groupby(account) three times: once for
> count(), once for sum(quantity) and once for sum(total_pnl)?
I hadn't even considered having a multi-parameter tuple-returning
"sum"; I was ok with either calling groupby thrice, or saving the
groupby and calling the different ops in sequence. In either case, a
database roundtrip per call.
> And what exactly does queryset.groupby() return?
quoting from itertools.groupby: «an iterator that returns (key,
sub-iterator) grouped by each value of key(value)»
I had thought that queryset.groupby should behave in the same way
itertools.groupby would behave, i.e. that there would only be
implementation (and performance) differences between
queryset = Position.objects.filter(date=today)
account_summary = itertools.groupby(queryset, operator.attrgetter('account'))
and
account_summary = Position.objects.filter(date=today).groupby('account')
this makes it very easy to explain, and to understand what you'll be
getting from groupby()
> In my case, if account
> is a ForeignKey from a Position model to an Account model, can I
> dereference fields from the result?
>
> account_summary =
> Position.objects.filter(date=today).groupby(account)
> for summary on account_summary:
> print summary.name### would this work? Is this the name
> property of an Account?
in view of the above: no. To do the above, you'd do this instead:
for account, positions in account_summary:
print account.name
> And how would I dereference the aggregate fields in the groupby
> results? By index? (is account_summary[0][2] the quantity sum of the
> first account summary row?)
positions would be the (lazy) iterator for that purpose, already set
up for you (by this I mean, I don't expect it to be a performance
gain, just a convenience).
> My idea was a queryset.groupby() could return some sort of dynamic
> Django model class where the attributes where the aggregated fields
> plus the fields you were grouping by and if you were grouping by a
> relation field, it would magically work like any other model relation.
that sounds way too magic for my taste :)
--
John Lenton ([EMAIL PROTECTED]) -- Random fortune:
The trouble with a lot of self-made men is that they worship their creator.
--~--~-~--~~~---~--~~
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: Default representation of a Form
On 12/5/06, Lachlan Cannon <[EMAIL PROTECTED]> wrote: > Lakin Wecker wrote: > > as_dl() gets a +1 from me. I've used definition lists for forms and > > prefer it over tables. :) > > Maybe there needs to be an easy hook for people to specify their own way of > laying a form out. It seems the as_ methods are gonna keep growing and > growing. That already exists -- you can subclass the Form and add your own methods. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
FloatField representation
Hi, all.
I have a following error when i try to display an object list in the
admin panel:
"TypeError at /admin/report/code/
float argument required"
My model:
class Code(models.Model):
tarif= models.FloatField(_('Tarif'), decimal_places=2, max_digits=3)
class Admin:
list_display = ('tarif',)
It works only with this small patch:
[EMAIL PROTECTED] trunk]$ svn diff
django/contrib/admin/templatetags/admin_list.py
Index: django/contrib/admin/templatetags/admin_list.py
===
--- django/contrib/admin/templatetags/admin_list.py (revision 4159)
+++ django/contrib/admin/templatetags/admin_list.py (working copy)
@@ -152,7 +152,7 @@
# FloatFields are special: Zero-pad the decimals.
elif isinstance(f, models.FloatField):
if field_val is not None:
-result_repr = ('%%.%sf' % f.decimal_places) % field_val
+result_repr = ('%%.%sf' % f.decimal_places) %
float(field_val)
else:
result_repr = EMPTY_CHANGELIST_VALUE
# Fields with choices are special: Use the representation
Is it a my bug or it`s a django bug ?
--
Best regards,
Vladimir Ponarevsky
--~--~-~--~~~---~--~~
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: Feature request for newforms: HTML 4
On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > In fact I'm wrong here... I just checked that W3C's validator doesn't > object to ""s. This is a valid HTML 4.01: > > "http://www.w3.org/TR/html4/strict.dtd";> > > Test > > > > So even "invalidness" is not a point. What's then? If XHTML-style tags are valid in HTML 4 strict, then I don't see a point in creating a separate output format for each widget. If you want to be religious about whether there's a slash in your HTML tag, clearly you care about it enough to have the (minimal) energy to write a custom method on your Form. Or, write a custom Form subclass once and subclass it for each form you use. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature request for newforms: HTML 4
James Bennett wrote: > So I've been poking around in the newforms code, and it appears that > the pre-defined widgets will be producing XHTML-style output. I had the same thought but I wrote a quick test with an HTML 4 strict doc-type, put an input tag in it like this: , and it was still valid. I'd like to see agnostic HTML from Django too, but if it isn't producing anything that breaks HTML 4, I'm happy. One of my worries is that the W3C, from what I've read, is going to re-invigorate HTML and work on HTML5 as well as XHTML2. If these two diverge enough, Django may need support for both. Somewhere I think I suggested the possibility of passing in a template string to the forms on how they should render, but the only purpose of this would be to remove the "/", and requires knowledge of the local variables. Last I looked the forms stuff is pretty flexible with adding attributes (ie: class names) and things. So there's not a lot of benefit doing that. -Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature request for newforms: HTML 4
James Bennett wrote: > Unfortunately, I don't really have a good proposal for how to handle > this, except maybe to further break down the Widget API to include > 'as_html' and 'as_xhtml'. Any ideas? build up the output using a light-weight DOM with a nice Python-level syntax, and serialize it on the way out, using either a standard XHTML serializer, or a user-provided alternative serializer. (should I duck now?) --~--~-~--~~~---~--~~ 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: Re: Feature request for newforms: HTML 4
On 12/5/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > If XHTML-style tags are valid in HTML 4 strict, then I don't see a > point in creating a separate output format for each widget. They are valid but have a completely different meaning which browsers don't interpret correctly; in HTML4, the closing slash is a form of SGML SHORTTAG syntax, and '' in HTML4 is meant to be interpreted as a 'br' element followed by a literal greater-than sign. WHAT-WG's HTML5 will do away with this and make the closing slash semantically meaningless in HTML, but that's still a ways off in the future. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Feature request for newforms: HTML 4
James Bennett wrote: > They are valid but have a completely different meaning which (most) > browsers don't interpret correctly; in HTML4, the closing slash is a > form of SGML SHORTTAG syntax, and '' in HTML4 is meant to be > interpreted as a 'br' element followed by a literal greater-than sign. full details: http://www.cs.tut.fi/~jkorpela/html/empty.html --~--~-~--~~~---~--~~ 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: Re: Feature request for newforms: HTML 4
On 12/5/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: > full details: > > http://www.cs.tut.fi/~jkorpela/html/empty.html Also, there is a valid problem here; if I produce HTML4, and just say "it validates, I don't care if it's correct", then my HTML will work in browsers, but actual SGML parsers (which do exist and do get used on occasion) will produce a different document tree when they parse my HTML, because they'll read the SHORTTAG syntax correctly. I haven't yet had a moment to verify that the standard Python sgmllib will do this, but I know for a fact that nsgmls will. Also, we're the framework for "perfectionists"; let's get this right ;) -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Re: Feature request for newforms: HTML 4
On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > The question is where to stop. Pickiness may lead further to having an > option to omit quotes around attribute values, have uppercase tag names, > omit end tags of etc... This is all working HTML (even valid by DTD). Yup. And in fact, I do that (quite deliberately). But I'm not asking for that; mostly that's a matter of templating and doing some deep hacking in markdown.py (at least in my case), and I'm willing to put in that work. I'm just asking for a simple way to get form inputs without trailing slashes, because even though it's a nitpicky thing and maybe there aren't very many people who actually care about the difference between XML empty-element syntax and SGML SHORTTAG, there are potential issues with things like SGML parsers, and (above all) it's just not "right" :) On IRC a moment ago, Jacob suggested an 'html4' template filter which would just strip trailing slashes from empty tags; I'd be happy with that (and willing to put in some time to implement it), provided we advertise clearly that the Django forms system is going to produce XHTML and that if you want HTML4 you'll need to use the filter. > Since all these things happily work in browsers the only difference > between "/>" and the rest is that it is not DTD-valid HTML 4.01. However > to my puristic point of view this is not a problem because DTD > validation is effectively useless. The only user agent that does DTD > validation is W3C's validator itself. No real browser ever considered > HTML as SGML application and never used DTD for its validation. Steps to reproduce: 1. Put together an HTML4 document with valid DOCTYPE declaration and everything. 2. Drop a closing slash into a BR, IMG or INPUT element somewhere. 3. Run through nsgmls and look at how it gets parsed There's a real-world difference there. You may say that nobody's ever used a real SGML parser on HTML4, but I actually have (in fact, I once ran into a situation where it was the only way to find a bug that the standard W3C validator settings couldn't catch), and I know for a fact that you get different output from an SGML parser than you do from a web browser. That's an interoperability problem :) > In fact > what guys at WHAT WG[1] are doing now for HTML5 is specifying exactly > the syntax that browsers use for parsing HTML. And "/>" will be valid HTML5. Yup. I'm subscribed to their mailing list and I've been following the discussion of that, and the proposal to allow 'xmlns' in HTML, with some trepidation. These things are necessary now because for years people have been doing stuff that was demonstrably incorrect but still "worked". I don't want Django to become part of that crowd. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Re: Re: Feature request for newforms: HTML 4
On 12/5/06, James Bennett <[EMAIL PROTECTED]> wrote: > On IRC a moment ago, Jacob suggested an 'html4' template filter which > would just strip trailing slashes from empty tags; I'd be happy with > that (and willing to put in some time to implement it), provided we > advertise clearly that the Django forms system is going to produce > XHTML and that if you want HTML4 you'll need to use the filter. I posted a tag earlier in this thread that does what you ask (it's pretty trivial). Are my messages coming through, anyway? -- Antonio --~--~-~--~~~---~--~~ 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: Feature request for newforms: HTML 4
James Bennett wrote: > There's a real-world difference there. You may say that nobody's ever > used a real SGML parser on HTML4, but I actually have (in fact, I once > ran into a situation where it was the only way to find a bug that the > standard W3C validator settings couldn't catch), and I know for a fact > that you get different output from an SGML parser than you do from a > web browser. That's an interoperability problem :) the Planet RSS aggregator used to use an SGML parser (sgmllib?) to clean up embedded HTML, which caused rather interesting output when people used crappy blog tools that inserted all over the 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Feature request for newforms: HTML 4
James Bennett wrote: > Yup. And in fact, I do that (quite deliberately). Nice to meet a like-minded person :-) > I'm just asking for a simple way to get form inputs without trailing > slashes As you said the problem is how to make it simple enough... What about a middleware that seeing 'text/html' content type would htmlize content? > There's a real-world difference there. You may say that nobody's ever > used a real SGML parser on HTML4, but I actually have In the near future I think The Right Thing would be to use a real HTML parser for such things. There were many messages on WHATWG list from people writing such tools in many languages including Python: http://code.google.com/p/html5lib/ --~--~-~--~~~---~--~~ 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: Re: Feature request for newforms: HTML 4
On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > In the near future I think The Right Thing would be to use a real HTML > parser for such things. There were many messages on WHATWG list from > people writing such tools in many languages including Python: > http://code.google.com/p/html5lib/ Well... define "near future" ;) Whenever HTML5-the-specification is finished and HTML5-the-cross-browser-implementation is available, then yeah, that'll work. In the meantime, HTML4 with SGML tools is all I've got available to me, and every once in a while that catches things the W3C validator's default settings won't notice. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Have a look at django.newforms
On 12/1/06, Gábor Farkas <[EMAIL PROTECTED]> wrote: > what about the following change?: > > if not isinstance(output, basestring): > > -return str(output) > > +try: > > +return str(output) > > +except UnicodeEncodeError: > > +return unicode(output).encode(settings.DEFAULT_CHARSET) > > elif isinstance(output, unicode): > > return output.encode(settings.DEFAULT_CHARSET) > > from the python docs (http://docs.python.org/lib/built-in-funcs.html) > unicode() technically should not work in this case, but it somehow works :) > > this change would not introduce any backward incompatibility, > because this new code is only triggered when the old one failed. > > another (independent from this change) enhancement would be to add an > __unicode__ method to the Form object. This is an interesting problem. That template fix would be OK by me, but it's sort of a hack. I think we're going to run into similar issues with Form.__str__() returning a Unicode object. Maybe, as you suggest, Form.__str__() should return a bytestring according to DEFAULT_CHARSET, and we could add a Form.__unicode__() that would return it as Unicode. Thoughts? And would that approach mix well with the upcoming Python 3000 changes? I thought I read something about __unicode__ and __str__ merging... Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Help to translate
Hi, I'm a Spanish native speaker from Chile. I use django in productions systems and I've seen the po files. Some msgid's are not translated and I want to help with that. Also, there's an es_AR but not es_CL, I'd like to help with that to :-) is ok with you? -- http://www.advogato.org/person/mgonzalez/ --~--~-~--~~~---~--~~ 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: Feature request for newforms: HTML 4
James Bennett wrote: > Well... define "near future" ;) When the library will be usable. > Whenever HTML5-the-specification is finished and > HTML5-the-cross-browser-implementation is available, then yeah, > that'll work. You don't have to wait for this because html5lib would work with existing content which is pretty much the point of the whole spec. --~--~-~--~~~---~--~~ 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: Help to translate
2006/12/5, Mario <[EMAIL PROTECTED]>: > > Hi, I'm a Spanish native speaker from Chile. I use django in > productions systems and I've seen the po files. Some msgid's are not > translated and I want to help with that. Also, there's an es_AR but > not es_CL, I'd like to help with that to :-) > > is ok with you? > Hello Mario, It's great that you want to start this effort, I am starting too a Spanish translation (es_MX) but my question is why we need to have es_AR, es_CL or es_MX is because we speak a little bit different the Spanish or it's because we haven't put enough effort to coordinate a single Spanish translation or maybe is because of both? Good luck ! + Un saludo. -- Iván Alemán --~--~-~--~~~---~--~~ 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: Have a look at django.newforms
Adrian Holovaty wrote: > On 12/1/06, Gábor Farkas <[EMAIL PROTECTED]> wrote: >> what about the following change?: >>> if not isinstance(output, basestring): >>> -return str(output) >>> +try: >>> +return str(output) >>> +except UnicodeEncodeError: >>> +return unicode(output).encode(settings.DEFAULT_CHARSET) >>> elif isinstance(output, unicode): >>> return output.encode(settings.DEFAULT_CHARSET) >> from the python docs (http://docs.python.org/lib/built-in-funcs.html) >> unicode() technically should not work in this case, but it somehow works :) >> >> this change would not introduce any backward incompatibility, >> because this new code is only triggered when the old one failed. >> >> another (independent from this change) enhancement would be to add an >> __unicode__ method to the Form object. > > This is an interesting problem. That template fix would be OK by me, > but it's sort of a hack. I think we're going to run into similar > issues with Form.__str__() returning a Unicode object. > Maybe, as you > suggest, Form.__str__() should return a bytestring according to > DEFAULT_CHARSET, and we could add a Form.__unicode__() that would > return it as Unicode. hmmm.. i agree :) > > Thoughts? And would that approach mix well with the upcoming Python > 3000 changes? I thought I read something about __unicode__ and __str__ > merging... strings in py3000 will be unicode strings (there will be byte-arrays to handle byte-related things), so if __str__ keeps his "return a string-based representation of the object" function, he will probably return unicode strings (because there won't be any other strings) gaobr --~--~-~--~~~---~--~~ 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: Have a look at django.newforms
Adrian Holovaty wrote: > This is an interesting problem. That template fix would be OK by me, > but it's sort of a hack. I think we're going to run into similar > issues with Form.__str__() returning a Unicode object. Maybe, as you > suggest, Form.__str__() should return a bytestring according to > DEFAULT_CHARSET, and we could add a Form.__unicode__() that would > return it as Unicode. +1 This will work until unicodification when we could get rid of __str__ version because the whole template will be processed as unicode anyway. > Thoughts? And would that approach mix well with the upcoming Python > 3000 changes? I thought I read something about __unicode__ and __str__ > merging... At that time it would be a simple act of renaming all '__unicode__' to '__str__'. --~--~-~--~~~---~--~~ 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: Help to translate
> Hello Mario, > > It's great that you want to start this effort, I am starting too a > Spanish translation (es_MX) but my question is why we need to have > es_AR, es_CL or es_MX is because we speak a little bit different the > Spanish or it's because we haven't put enough effort to coordinate a > single Spanish translation or maybe is because of both? > Well, we could have the 'es' translation in 100% completed first and then start to think in another countries. The 'es' file is about 80% translated so if you let me I'll do my best to translate all the file. So, why we need differents locales to the same language? IMO, there are some differents words for the same language. 'Computer' for example. In Spain is 'Computadora' but in my Chile we say 'Computador'. Yeah, it's only 1 byte!! but 'Computadora' sounds weird and it isn't "normal" say that. I don't know if you can understand what I'm trying to say. > Good luck ! + Un saludo. Saludos :-) > -- --~--~-~--~~~---~--~~ 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: Have a look at django.newforms
On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Adrian Holovaty wrote: > > This is an interesting problem. That template fix would be OK by me, > > but it's sort of a hack. I think we're going to run into similar > > issues with Form.__str__() returning a Unicode object. Maybe, as you > > suggest, Form.__str__() should return a bytestring according to > > DEFAULT_CHARSET, and we could add a Form.__unicode__() that would > > return it as Unicode. > > +1 > > This will work until unicodification when we could get rid of __str__ > version because the whole template will be processed as unicode anyway. OK, I've made the change in newforms [4163]. I also applied Gabor's patch to make the template system handle objects whose str() returns a Unicode object with non-ASCII characters [4161]. This is coming along nicely! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Help to translate
> Well, we could have the 'es' translation in 100% completed first and > then start to think in another countries. The 'es' file is about 80% > translated so if you let me I'll do my best to translate all the file. > This is my little help http://media.forestal.udec.cl/django/ > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
django.contrib.formtools: High-level abstractions of common form tasks
I've just checked in a new bit of Django functionality I've been developing for the past couple of days (extracted from some production code). It's an abstraction of the workflow "Display an HTML form, force a preview, then do something with the submission." If you're familiar with the forced-preview workflow of the django.contrib.comments app, you'll see it's a generic version of that. You pass it a Form object (using the django.newforms API), define a short subclass to tell the framework what to do if the data is valid, and point your URLconf at it. You can define some optional templates, too. There's no official documentation yet, but check out the docstrings in django/contrib/formtools/preview.py for a start. Comments welcome! Also, this is only the beginning of django.contrib.formtools, which I intend to be a collection of common high-level form operations such as this one. What other sorts of things can we make abstractions for, given a Form? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Help to translate
> Well, we could have the 'es' translation in 100% completed first and > then start to think in another countries. The 'es' file is about 80% > translated so if you let me I'll do my best to translate all the file. > Where is this 'es' file perhaps you mean es_CL ? > So, why we need differents locales to the same language? IMO, there > are some differents words for the same language. 'Computer' for > example. In Spain is 'Computadora' but in my Chile we say 'Computador'. > Yeah, it's only 1 byte!! but 'Computadora' sounds weird and it isn't > "normal" say that. I don't know if you can understand what I'm trying > to say. > Is not my intention to start a flame war LOL but in Spain the correct word for 'Computer' is 'Ordenador' AFAIK :) Trust me I really understand what you're trying to say and it's fine. Un saludo. -- Iván Alemán --~--~-~--~~~---~--~~ 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: Help to translate
2006/12/5, mario__ <[EMAIL PROTECTED]>: > This is my little help > http://media.forestal.udec.cl/django/ > Perhaps you want to use Django I18N mailing list for this kind of affairs. Regards. -- Iván Alemán --~--~-~--~~~---~--~~ 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: Suggestion: Aggregate/Grouping/Calculated methods in Django ORM
Russell Keith-Magee wrote:
> annotate() returns a query set, so it can be used multiple times, be
> combined with filters, etc. The argument handling strategy employed in
> filter() is reused here; kwargs to annotate() can be decomposed on a
> __ boundary to describe table joins, with the last part describing the
> aggregate operator to be used. The syntax follows something like:
>
> Model.objects.annotate(field1__field2__aggregate='annotation')
[snip]
> e.g.,
> # Get order 1234, and annotate it a few different ways
> >>> order = Order.objects.get(id=1234).annotate(
> books__price__sum='total_cost',
> books__count='item_count')
> # Inspect the order
> >>> order.description
> "Dad's birthday"
> # Annotated orders have a 'total_cost' attribute...
> >>> order.total_cost
> 47.2
> # ... and an 'item_count' attribute
> >>> order.item_count
> 3
I like making the aggregate function a part of a keyword argument. It
seems consistent with the Django DB API and offers a lot of
flexibility. Better, in my opinion than individual functions for each
aggregator. The 'annotate' name is a little indirect. Maybe something
like 'calc_fields'?
> 3. Just the facts, Ma'am
>
> Ok; so what if you just want _the minimum_, or _the average_? For
> this, I propose an aggregates() queryset modifier.
>
> >>> Book.objects.aggregates(price__min='min_price',
> >>> pub_date__max='last_update')
> {'min_price':0.5, 'last_update': 2006-11-22}
>
> aggregates() would expand queries in the same manner as annotate(),
> but would be a terminal clause, just like the values() clause.
>
> This is a more verbose notation than the simple 'max()/min()' . I have
> discussed my problems with these operators previously; however, if
> there is sufficient demand, I don't see any reason that min('field')
> couldn't be included in the API as a shorthand for
> Model.objects.aggregates(field__min='min')['min'].
This seems good, too, but maybe call it 'calc_values' or something with
the 'values' name in it to be consistent with the existing values()
method. The shortcut is nice but I could live without it.
> 4. Comparisons
> ~~
> There is one additional requirement I can see; to perform queries like
> (c), you need to be able to compare annotation attributes to object
> attributes.
>
> # Annotate a query set with the average price of books
> >>> qs = Book.objects.annotate(price__average='avg_price').
> # Filter all books with obj.avg_price < obj.price
> >>> expensive_books = qs.filter(avg_price__lt=F('price'))
>
> The F() object is a placeholder to let the query language know that
> 'price' isn't just a string, it's the name of a field. This follows
> the example of Q() objects providing query wrappers.
To make it more like Q(), would it be better to do
F(avg_price__lt='price') so you could combine them with | and &?
--~--~-~--~~~---~--~~
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.contrib.formtools: High-level abstractions of common form tasks
Adrian Holovaty wrote: > What other sorts of things can we make abstractions for, > given a Form? First thing that comes to mind is the same thing you describe but without preview. In other words it's what update_object generic view does now but it works only on models and often it is desired to work this way with arbitrary form. But I'm sure you've already thought about 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: Aggregate/Grouping/Calculated methods in Django ORM
John Lenton wrote:
>
> I hadn't even considered having a multi-parameter tuple-returning
> "sum"; I was ok with either calling groupby thrice, or saving the
> groupby and calling the different ops in sequence. In either case, a
> database roundtrip per call.
I'm often grouping thousands of rows for my cases so doing multiple
round trips per field would be painful.
> I had thought that queryset.groupby should behave in the same way
> itertools.groupby would behave, i.e. that there would only be
> implementation (and performance) differences between
>
> queryset = Position.objects.filter(date=today)
> account_summary = itertools.groupby(queryset, operator.attrgetter('account'))
>
> and
>
> account_summary = Position.objects.filter(date=today).groupby('account')
I'm confused. Where do you specify the aggregate functions for
aggregating the specific columns (sum, avg, etc.)? Or am I
misunderstanding what this does?
> in view of the above: no. To do the above, you'd do this instead:
>
> for account, positions in account_summary:
>print account.name
I see. Works for me.
>
> > And how would I dereference the aggregate fields in the groupby
> > results? By index? (is account_summary[0][2] the quantity sum of the
> > first account summary row?)
>
> positions would be the (lazy) iterator for that purpose, already set
> up for you (by this I mean, I don't expect it to be a performance
> gain, just a convenience).
But would there be aliases for these aggregate expessions? That is, the
equivalent of
select sum(quantity) as tot_quantity ...
> > My idea was a queryset.groupby() could return some sort of dynamic
> > Django model class where the attributes where the aggregated fields
> > plus the fields you were grouping by and if you were grouping by a
> > relation field, it would magically work like any other model relation.
>
> that sounds way too magic for my taste :)
True.
--~--~-~--~~~---~--~~
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.contrib.formtools: High-level abstractions of common form tasks
On 12/5/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote: > Adrian Holovaty wrote: > > What other sorts of things can we make abstractions for, > > given a Form? > > First thing that comes to mind is the same thing you describe but > without preview. In other words it's what update_object generic view > does now but it works only on models and often it is desired to work > this way with arbitrary form. But I'm sure you've already thought about > it... Yes, *definitely*...That one is next on the list. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: django.contrib.formtools: High-level abstractions of common form tasks
Adrian Holovaty wrote: > Yes, *definitely*...That one is next on the list. I just wanted to make sure :-). I'm about to create a forum for my site and am waiting for this bit to use it and test 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Install issue wity MySQL on Windows
I'm trying to get MySQL to work with Django. (I'm new to Django.) My installation runs successfully until I attach a database connector. PROBLEM: An error occurs when running *Python manage.py syncdb* after setting DATABASE_ENGINE = 'mysql' in settings.py. (I've omitted the other settings here for brevity). The error is "Error loading MySQLdb module: No module named MySQLdb" (I've omitted the rest of the error stack.) ENVIRONMENT: Windows XP Pro Python 2.4 Apache 2.2 mod-python 3.2.10 MySQL 5.0 ANAYLYSIS The Python code in django\db\backends\mysql\base.py appears to be looking for a DB connector in the django/db/backends/mysql folder named MySQLdb. There is no Python file (.py) of this name in either the MySQL or the Django installations. Nor is there a DLL or PYD file in the DLLs folder that looks MySQLish. Any suggestions? Thanks, Ed --~--~-~--~~~---~--~~ 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: Install issue wity MySQL on Windows
On 12/5/06, edelberry <[EMAIL PROTECTED]> wrote: > > ENVIRONMENT: > Windows XP Pro > Python 2.4 > Apache 2.2 > mod-python 3.2.10 > MySQL 5.0 Did you install a Python Mysql module? I use this one: http://sourceforge.net/projects/mysql-python -- Julio Nobrega - http://www.inerciasensorial.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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: RadioFieldRenderer support for __getitem__?
On 11/14/06, shaunc <[EMAIL PROTECTED]> wrote: > "__getitem__" in > django.forms.__init__.RadioSelectField.render.RadioFieldRenderer > > In this inner class (line 546), I have found it useful to have: > > def __getitem__( self, item ): > return self.datalist[ item ] Hey Shaun, Check out django.newforms, which is going to replace django.forms in the near future. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Install issue wity MySQL on Windows
No I didn't. I'll take a look, Thanks. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
active tickets with patches
hi, while I really appreciate all of django's exciting new developments, I wonder how some of workload could possibly be taken off the core developers' shoulders by helping them wade through the currently 175 active tickets with patches found on [1]. While it might be that someday I will encounter one of those already "solved" problems as well and then happily patch my local django trunk, this is most propably not the most effective way. Quite a number of those tickets are marked as enhancements, but there are also way more than a handful of patches for defects. So I guess my question ultimately is: will this list just keep growing until noone will find anything in there anymore? What do you suggest to help you wade through these tickets and to put those efforts already made to work? Should people who are willing to help you just start tackling those with the lowest ticket numbers? Should we "market" the solutions we found on this mailinglist parallel to submitting the patch to trac? (while this might be perfectly reasonable for critical defects, it might be considered spamming for some other cases..) and yes, I have submitted one that I can't wait to catch someone's attention and hopefully get merged with trunk ;) [1] http://code.djangoproject.com/report/12 -- cheers, Nikl --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How to run unittest on django effectivly
as the title and is there a written code about unittest on django? plz share me. write me with gtalk --~--~-~--~~~---~--~~ 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: How to run unittest on django effectivly
On 12/6/06, Riquelme <[EMAIL PROTECTED]> wrote: > > > as the title > and is there a written code about unittest on django? > plz share me. This question should be directed to the users mailing list. The developers list is for discussion of development of Django itself, not for answering end-user questions. Asking for off-list replies won't help your cause, either. However, that said - Django has a unit test framework; some features are still under development, but for details of what is currently available, see: http://www.djangoproject.com/documentation/testing/ Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: active tickets with patches
I am also interested in helping with this situation. I've run into quite a few patches that are reportedly working for some people.How do we help get these triaged? Lakin On 12/5/06, Nikolaus Schlemm <[EMAIL PROTECTED]> wrote: > > > hi, > > while I really appreciate all of django's exciting new developments, I > wonder > how some of workload could possibly be taken off the core developers' > shoulders by helping them wade through the currently 175 active tickets > with > patches found on [1]. While it might be that someday I will encounter one > of > those already "solved" problems as well and then happily patch my local > django trunk, this is most propably not the most effective way. Quite a > number of those tickets are marked as enhancements, but there are also way > more than a handful of patches for defects. > > So I guess my question ultimately is: will this list just keep growing > until > noone will find anything in there anymore? What do you suggest to help you > wade through these tickets and to put those efforts already made to work? > Should people who are willing to help you just start tackling those with > the > lowest ticket numbers? Should we "market" the solutions we found on this > mailinglist parallel to submitting the patch to trac? (while this might be > perfectly reasonable for critical defects, it might be considered spamming > for some other cases..) > > and yes, I have submitted one that I can't wait to catch someone's > attention > and hopefully get merged with trunk ;) > > [1] http://code.djangoproject.com/report/12 > -- > cheers, > > Nikl > > > > --~--~-~--~~~---~--~~ 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: Session renewal: want a patch?
On 11/8/06, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > Currently, sessions are renewed only if 1) they're modified or 2) every > request. > > There's a middle ground that's useful: renew the session and cookie if > it's within X days of the session's current expiration. This keeps > cookies for unmodified sessions from expiring while not sending out a > cookie on every request. > > Would you like a patch for that? Something like: I personally don't use sessions enough to have a strong opinion on this, but I could see how some might find it useful. Any other thoughts? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: another ticket: related-object window is missing query ...
On 10/26/06, patrickk <[EMAIL PROTECTED]> wrote: > when doing a search in the related-object window in the admin- > interface and using the link "xxx total" after that search, the query > is missing. > because "pop=1" is in the query, the header is shown ... Hi patrickk, I've fixed this in trunk in [4165]. Thanks for reporting! I almost missed your bug report, though, because it was posted to the list rather than Trac. Give Trac another shot from now on; I think we've fixed the eager spam-block issues. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: enable trac's ticket_show_details option?
On 10/27/06, Gary Wilson <[EMAIL PROTECTED]> wrote: > The ticket_show_details option [1] adds the ability for users to view > ticket detail changes in the timeline view. I think this would be nice > to have. > > [1] http://trac.edgewall.org/wiki/TracIni#timeline-section I've made the change to our Trac instance. Thanks for the good idea! Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: active tickets with patches
On 12/6/06, Lakin Wecker <[EMAIL PROTECTED]> wrote: > I am also interested in helping with this situation. I've run into quite a > few patches that are reportedly working for some people.How do we help > get these triaged? Yes, there are 175 active tickets with patches in the database. However, many (if not most) of these tickets don't make it easy to apply the patch provided. A well triaged patch has the following characteristics: - A clear, consise description of the problem - A clear, concise set of conditions and instructions for consistently replicating the problem - A brief discussion of the merits of any alternatives for fixing the problem - A patch that meets Django's coding guidelines - If the patch is non-trivial [1], evidence that there has been discussion on django-developers on the alternatives. - A regression test to prevent the problem in the future If any of these are missing, it means that I have to pick up the slack. While I would love to be able to stand up and say "Django has no known bugs", if I'm faced with an incomplete, possibly incorrect bug report (with or without a patch) in an area of Django that is edge case (for me, at least), the incentive for me to spend my spare time hunting down the underlying problem is quite low. So - if you want to help, jump right in. Pick a problem and triage it. Make sure the ticket has all the characteristics above, and mail django-developers indicating that you have triaged a ticket, and recommend a course of action (with reasoning). At first, this may require you to be persistent - if you find that your pet ticket isn't gettng attention, occasional polite requests for eyeballs may be necessary. Once that problem has been resolved and committed, pick another problem. As you earn a reputation for good triage work, your 'triage complete' messages will work their way closer to the top of my (and other committer) to-do lists, and you should find that less pestering is required to get the attention of a committer. So - there's 175 bugs with patches, and the only way to kill them is one at at time. Have at it :-) Yours, Russ Magee %-) [1] Note that 'non-trivial' doesn't just mean 'only affects 1-2 lines of code' - it also includes the fact that the lines that are being modified don't have a significant follow-on effect on the overall design of Django. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: active tickets with patches
On 12/6/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 12/6/06, Lakin Wecker <[EMAIL PROTECTED]> wrote: > > I am also interested in helping with this situation. I've run into quite a > > few patches that are reportedly working for some people.How do we help > > get these triaged? > > Yes, there are 175 active tickets with patches in the database. > However, many (if not most) of these tickets don't make it easy to > apply the patch provided. > > A well triaged patch has the following characteristics: > > - A clear, consise description of the problem > > - A clear, concise set of conditions and instructions for consistently > replicating the problem > > - A brief discussion of the merits of any alternatives for fixing the problem > > - A patch that meets Django's coding guidelines > > - If the patch is non-trivial [1], evidence that there has been > discussion on django-developers on the alternatives. > > - A regression test to prevent the problem in the future > > If any of these are missing, it means that I have to pick up the > slack. While I would love to be able to stand up and say "Django has > no known bugs", if I'm faced with an incomplete, possibly incorrect > bug report (with or without a patch) in an area of Django that is edge > case (for me, at least), the incentive for me to spend my spare time > hunting down the underlying problem is quite low. > > So - if you want to help, jump right in. Pick a problem and triage it. > Make sure the ticket has all the characteristics above, and mail > django-developers indicating that you have triaged a ticket, and > recommend a course of action (with reasoning). At first, this may > require you to be persistent - if you find that your pet ticket isn't > gettng attention, occasional polite requests for eyeballs may be > necessary. > > Once that problem has been resolved and committed, pick another > problem. As you earn a reputation for good triage work, your 'triage > complete' messages will work their way closer to the top of my (and > other committer) to-do lists, and you should find that less pestering > is required to get the attention of a committer. > > So - there's 175 bugs with patches, and the only way to kill them is > one at at time. Have at it :-) > > Yours, > Russ Magee %-) > > [1] Note that 'non-trivial' doesn't just mean 'only affects 1-2 lines > of code' - it also includes the fact that the lines that are being > modified don't have a significant follow-on effect on the overall > design of Django. > All above are aimed to submitter, I think that are very good. But I hope that the developers of django team should do something. For example simply close them, it means that these tickets be reviewed. -- I like python! UliPad <>: http://wiki.woodpecker.org.cn/moin/UliPad My Blog: http://www.donews.net/limodou --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
