New lines in tags and bug etiquette
lakin
our own sanity we'd prefer to use a newline within the tag.
<a href="{% url project.course.views.CourseClassView
model_instance_name=courseclass.id,page_number=next_page_number %}">
We went looking for this bug report and I was very surprised at the
content seen therein:
http://code.djangoproject.com/ticket/1147
As it stands, In order to get discussion on this use case I
(supposedly) have to subscribe to Django users and talk about it
there. Django users is a high-noise list and in my opinion isn't the
place to be having development discussions. Maybe we need a bug
status of "needs information", and then developers can ask for a valid
use case within the report?
Is this a reasonable use case for asking that tags include newlines?
Or is there a way we can shorten this tag that doesn't include
shortening our variable names?
Lakin
Jacob Kaplan-Moss
> As it stands, In order to get discussion on this use case I
> (supposedly) have to subscribe to Django users and talk about it
> there. Django users is a high-noise list and in my opinion isn't the
> place to be having development discussions. Maybe we need a bug
> status of "needs information", and then developers can ask for a valid
> use case within the report?
Sorry - that should have read "post it to django-dev", not "-users".
The general principle is that once one of the core developers (Malcolm
in this case) has marked a ticket as closed, it means that any further
discussion should take place on the developers list. Nothing's more
annoying than a fight over a ticket's state, so we prefer to discuss
controversial topics over in django-dev.
Please feel free to post this question over there.
Jacob
lakin
On Mar 29, 10:20 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:
Aaaah . That makes much more sense. It completely changes the way I
interpret that ticket. Thanks for clarification.
Lakin
Malcolm Tredinnick
> We have the following tag. It's well over 80 characters long, and for
> our own sanity we'd prefer to use a newline within the tag.
>
> <a href="{% url project.course.views.CourseClassView
> model_instance_name=courseclass.id,page_number=next_page_number %}">
One technical problem with allowing newlines in there is that error
detection (and reg-exp efficiency) deteriorates. If you make a mistake
and leave off the closing tag, it will have to scan many lines of the
document before trying to recover.
I have a lot of sympathy for people using 80-character wide terminals.
It's a very comfortable reading width and allows working with multiple
windows on the screen at once. So I'm not about to dismiss your concerns
as groundless, since I also work at that width. But I also manage to
keep on rocking on the rare cases when my lines wrap. Most editors are
able to do a soft linebreak on whitespace in any case, so it should
display properly.
Sometimes long lines occur. This happens not just in Django, but in
programming languages and even in HTML -- for example, IE has, in the
past, been very sensitive to whitespace placement and some HTML required
long lines with no spaces outside of tags to avoid engine bugs.
Fortunately, they are rare. I'm of the opinion (and I gather at least
Adrian is, too) that the occasional time you will need to have a line
wrap at 80 columns outweighs the benefits we get from not allowing
newlines inside tags. It's not a no-brainer, obviously, but every system
has judgement calls involved and we made one in this case. I still think
it's a judgement call and I still think I prefer the current behaviour.
> We went looking for this bug report and I was very surprised at the
> content seen therein:
> http://code.djangoproject.com/ticket/1147
>
> As it stands, In order to get discussion on this use case I
> (supposedly) have to subscribe to Django users and talk about it
> there. Django users is a high-noise list and in my opinion isn't the
> place to be having development discussions. Maybe we need a bug
> status of "needs information", and then developers can ask for a valid
> use case within the report?
Well, since I was the second person who closed that ticket, I can
explain my reasoning fairly easily:
Presumably you mean high-volume, rather than high-noise: the vast
majority of posts on this list are on-topic as far as helping Django
users goes. :-)
Asking people to participate in a mailing list discussion if they want
some information is hardly a hardship. Although it is high-volume, you
don't have to receive all the mail -- you can just track your particular
thread via the web interface. That's clear when you sign up to the group
(Google asks you which subscription method you want).
Development discussions happen on django-developers. The comment in that
ticket to start a thread on django-users was because the last poster
there was having trouble understanding how HTML parsing worked -- it
wasn't a problem with Django, so I was pointing him to the right
location for his particular set of problems.
To avoid having constant open/close cycles going on with tickets, we ask
people who think a ticket has been unreasonably "wontfixed" to bring up
the case on django-developers -- including their good example -- rather
than reopening. This is documented in the contributing.txt document
(which is online as well). Trac isn't a very good place to have a
conversation -- certainly no more convenient than a mailing list and a
lot less convenient in many ways. So if there does need to be a general
discussion, the mailing list(s) are a better place. People will often
then go back and insert a reference to the thread in the ticket for
future reference, if it's useful.
In this particular case, #1147 has been marked as "wontfix" by two core
developers. If we had wanted more information prior to making that
decision, we would have left it open and asked for more information in
the comment -- we do that quite a lot.
> Is this a reasonable use case for asking that tags include newlines?
> Or is there a way we can shorten this tag that doesn't include
> shortening our variable names?
Shortly (within 48 hours, I would guess), the development code will
include a change so that view functions can be named with whatever
string you like. This is actually being included for other reasons, but
will help you some here. It won't completely shorten your line -- it'll
probably still be a bit over 80 characaters -- but for the reasons
mentioned above, I still think it's worth not including newlines as
permissible whitespace in tags.
Regards,
Malcolm
Frank
I am new to django and python.
I have experience in .net and php and jsp.
Are there more tutorials other than the one on the djangoproject site?
Looking to use forms and how to fill dropdrown boxes from a database.
Thanks
Frank
Jeremy Dunck
> Are there more tutorials other than the one on the djangoproject site?
> Looking to use forms and how to fill dropdrown boxes from a database.
There are many here:
http://code.djangoproject.com/wiki/Tutorials
http://blixtra.org/blog/2006/07/17/top-30-django-tutorials-and-articles/
However, that's a fairly narrow request, and newforms is replacing
oldforms soon. newforms are better and here in the long term, but not
well-documented yet because they are a work in progress.
In any case, you want something like this:
from django import newforms as forms
from your.models import YourModel
class MyForm(forms.Form):
the_choice =
forms.ChoiceField(choices=YourModel.objects.filter(foo__exact='bar'))
In a view, you'd do this:
form = MyForm()
t = #your template
t.render(Context({form:form}))
And In your template, you'd have something like this:
{{ form.as_table }}
When round-tripping, you'd construct the form bound, like this:
form = MyForm(request.POST)
(MyForm expects a dictionary and binds any field to values in the dict
which match the field's name, and ignores any extra keys in the dict.)
If your head just exploded, sorry. :)