Hi there,
we have models like this:
1. A car database with freely assignable attributes.
2. An attribute-type table (ex: color, engine, seats)
3. Car attributes (ex: color:red, seats: 5) variable car by car
We have to display a matrix of cars (rows) with different attributes
(columns), but not
Tomasz Zieliński wrote:
> How about something like this (should work, although I haven't checked
> it):
>
> Author.objects.annotate(article_num=Count('articles')).filter
> (article_num=0)
>
> - where articles=ManyToManyField('Article')
>
This is so elegant, so i have to upgrade to 1.1 now... :)
Please help me in orm level filtering many-to-many relations.
I have to filter all "authors" who does not belongs to any "articles".
Or the opposite of this, list of orphaned articles...
I dont want to write sql in the model if possible.
Thank you,
Charlie.
--
You received this message
Is there anybody out there using mptt?
'full_tree_model' tags and filters are working correctly, but i was
unable to use a 'drilldown_tree_for_node'.
Does anybody have a working example or detailed instructions?
tia,
Charlie.
--
"s minden mestert kinevettem, ki nem nevetett önmagán."
GPG
Steven Armstrong írta:
>Instead of writing a patch, I've extended/wrapped djangos model and form
>fields. This way you can update django without having to reapply patches.
>
>You can find the code and instructions under [1].
>
>Just for the record. I'm totally with Malcolm that this is not a
Malcolm Tredinnick írta:
>This is the sort of thing that maybe starts crossing the line between
>representation and presentation a bit too much. You are putting a lot of
>presentation information into the data model description and they
>should, as much as possible be separate. That is why I
Steven Armstrong írta:
>I've extended some of django's built in model and form fields to accept
>an additional kwarg named 'html_attributes'.
>
>It works like this:
>
>class Whatever(models.Model):
> ...
> title = models.CharField(maxlength=128,
> html_attributes={
> 'size': 15,
>
Malcolm Tredinnick írta:
>Sorry, that came across a bit more negatively than I intended: it almost
>certainly will be accepted (see the threads linked from the bug). So
>it's not a roll of the dice -- the solution isn't ideal, but barring a
>better solution, it is a reasonable idea.
>
>
The
Matt the Destroyer írta:
>size=30 simply tells the browser to make the input field a size of 30
>characters wide. it has no bearing on input data or transmission.
>
>in the past, i have simply hard-coded my own input fields into my
>templates so I can directly control the size and other
patrickk írta:
>maxlength is not a size-attribute.
>you probably don´t want size=200, just because maxlength is 200.
>
>
Probably. But i don't want "size=30" either.
Is "30" hard-wired or reflects to something?
Charlie.
--
"...s minden mestert kinevettem, ki nem nevetett önmagán."
GPG
Is it a desired behaviour of templating system to equalize text input
widgets?
Although in my model two fields are different sizes (maxlength=20 and
maxlength=200), inserting into template it generates with "size=30" tag
equally.
I can manually control it, but why should i do if it knows
I have a tree model data and a foreign key is defined with a null=True.
Generated db table is correct (field is NULL instead of NOT NULL), but
in the admin interface i cannot add an object with empty parent. (With
not null parent it works.)
And obviously i cannot add first one at all.
What was i
We are starting a new project soon (within a month, after closing a
research phase).
Django V1.0 means (as far as i can recall from wiki) "do not expect
backward compatibility before 1.0".
Obviously major design elements and data models are not affected later,
but (watching django version number
13 matches
Mail list logo
