The collation for other languages than English is not that simple.
e.g. the German Umlaut "ä" is often seen equivalent to "ae" when
ordering lists. Thus a list like [u'baf', u'bäx', u'baz'] would be
sorted [u'bäx', u'baf', u'baz']. There are even some collations that
just treat 'ä' as an 'a' and
Some time ago I came up with a decorator to enable rendering jinja2
templates easily. The decorator 'monkey patches' the request object by
providing a __getattr__ method and adding some new methods.
https://labs.pyrox.eu/common/jinja2/tree/django.py
This could be easily adapted for django templa
Hi Alex,
mp> I've found it to be way more practical to just store the request object
mp> inside a threading.local object and let my functions access it directly.
mp> (...)
Alex> Quite simply, no. Storing anything in a threadlocal instead of
Alex> passing it around is indicative of bad coding pr
Jeremy Dunck wrote:
> Alex just spent a bunch of time adding multi-db support; part of the
> effort involved in that work was removing the
> request=thread=connection assumption that tied django to a single DB.
Untying the database session from the request response cycle makes sense
for multi-db
James Bennett wrote:
> Setting aside async concerns, making the request available implicitly
> would be both counter to that overall design (and I'm very much a fan
> of that design, and I suspect its simplicity and understandability is
> part of why Django's popular), and feels like an attempt to
> There is a templatetags {% include 'x.html' %}, it's very nice. may a
> templatetags like {% include no-parse "x.html"} is needed. It's so
> powerful to improve the speed of include some static files which has
> no variable,and it's so easy for you guys, isn't it?
It'd be very easy to add an t
I'd like to propose a new field lookup __neq which could be used to
negate a single parameter. It is not ment to make exclude() obsolete, as
they both have a different scope:
filter(x__neq=1, y__neq=2) would translate to "(x <> 1 AND y <> 2)"
while exclude(x=1, y=2) translates to "NOT (x = 1 AND
rm> exclude(x=1).exclude(y=2) translates to NOT (x=1) AND NOT (y=2)
So why do we have __gt, __ge, __lt, __le then? It would be as simple to
have only __le and get rid of the rest as it can easily expressed using
exclude and filter. I know, it's picky, but you get my point.
I don't see why all co
I've written something called a 'CompositeField' which basicly does what
you're looking for by grouping fields together. Assume you want to have
an AddressField you could define it the following way:
class AddressField(CompositeField):
def __init__(self, blank=False):
super(AddressFie
> How can I cache the sub-template witch is included in the main
> template? And how can I ensure it won't be render(parse) the next
> request?
If you look at django.template.loader_tags.do_include you'll notice an
if statement that checks if the given argument was a string. If so it'll
use a Con
Quite often I find myself in the need of fields composed of other
fields. e.g.
class AddressField(CompositeField):
addressee = models.CharField(max_length=50)
street = models.CharField(max_lenght=50)
zipcode = models.CharField(max_lenght=10)
# ... more fields he
On 2009-12-24 19:45, Stephen Crosby wrote:
> In your address example, I'm not sure what advantage this
> CompositeField has over just creating an address model/table and
> using a regular foreign key to reference it. You mentioned the need
> to create a field composed of other fields which to me so
On 2009-12-26 05:17, Andy Mikhailenko wrote:
> Maybe I'm missing something, but I don't understand how is this
> different from having a bunch of separate fields. The CompositeField
> adds a namespace, but foo.bar_x=1 seems to be no harder to read than
> foo.bar.x=1. I must admit that this field
I just implemented [1] the ComplexNumberField using the CompositeField
class. It also shows that it is possible to change subfield attributes
inside the __init__ method since the subfields are deep copied for every
instance.
I hope that the test cases are mostly complete. I plan on writing down
th
Some time ago I proposed a new field type called "CompositeField". It's
basicly a way of doing composition in Django models.
Its usage looks like:
class CoordField(CompositeField):
x = models.FloatField()
y = models.FloatField()
class Place(models.Model):
name =
Please check out the repacked and slightly refactored implementation of
CompositeField:
http://bitbucket.org/mp/django-composite-field
I'm currently lacking ideas how to get that into admin without having to
specify all subfields in the fieldsets.
--mp
--
You received this message beca
About one year ago I wrote a CompositeField implementation, which I
proposed as a clean way of grouping fields together, while making it
easy to reuse that composition of field:
https://bitbucket.org/mp/django-composite-field
It's a slightly different approach and is centered around defining a
fi
17 matches
Mail list logo
