Re: Revisiting multiline tags
Hallöchen!
Carl Meyer writes:
> On 02/17/2012 11:04 PM, Glenn Washburn wrote:
>
>> I'd like to reopen discussion on the multiline tag issue (see:
>> https://code.djangoproject.com/ticket/8652) which was closed 3
>> three years ago as "won't fix". The last comment notes that this
>> won't happen as the decision has been made many times. But there
>> is no link to any discussion on this topic, so I can only assume
>> mtredinnick's point two is the supposed reason for not fixing
>> this.
>
> Here's a discussion linked from #3888 in which Malcolm lays out in
> brief why multiline tags have been rejected:
> https://groups.google.com/forum/?fromgroups#!topic/django-developers/A17TJWd3YJU
Thank you! Still, does anybody have a link where the technical
problems (in constrast to the aesthetical ones) are discussed?
> Personally I'd be -0 at worst on multiline tags, but I also don't see
> any compelling use-cases. I think tags on a single line are
> significantly easier to parse visually.
I've made the same observations as in the parallel posting: I18n
becomes awkward with single-line tags. We have dozens of lines like
{% blocktrans with originator=entry.originator|get_really_full_name:"mailto"
link=entry.get_metadata.link task_id=entry.task.id
process_name=entry.task.process_class|contenttype_name %}
Another use case, however less frequent in our code:
href="{% url samples.views.sample.export sample_name=sample.sample.name
%}?next={{ sample.sample.get_absolute_url|urlquote_plus }}"
Tschö,
Torsten.
--
Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.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
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: ModelForms and the Rails input handling vulnerability
Hallöchen! Luke Plant writes: > [...] > > == Options == > > There were three main courses of action that we talked about on > django-core. > > [...] > > = Option 2: Deprecate Meta.exclude, but still allow a missing > Meta.fields attribute to indicate that all fields should be > editable. For our use cases, this would be very unfortunate. We have many models in our app, and many fields in most of them. We "exclude" most foreign key relationships, and sometimes fields which the user must not be allowed to change. Option 2 would mean that we would have huge name list in 80% of the ModelForms. Moreover, they needed to be kept up-to-date, which is very error-prone. Granted that it's worse if security is affected, but legibility and DRY would be reduced too drastically in my opinion by option 2. People in a similar situation like us WILL use fields = [f.name for f in MyModel._meta.fields if f.name not in ["blah", "blubb"]] but Django should not compel its users to such things. If you add a new field, your automatic next thought should be how (and whether) to expose it to the user. The other way round: If a developer adds a sensitive field and doesn't look at the code where the model is made editable to the user, this shows a careless attitude a library cannot prevent anyway. Moreover: > The policy here is essentially this: if any fields the model are > sensitive, assume all are potentially, and require whitelisting, > not blacklisting. I doubt that this is sufficiently frequently true so that it would justify the reduce of legibility and DRY. The sensitive fields usually are special cases, e.g. administrative or internal. If you add further fields to a model, however, they are "ordinary" ones. Well, at least this is my humble assessment and experience. Therefore, "exclude" does a sensible job for its use case, and is a reasonable compromise between security and comfort in my opinion. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ModelForms and the Rails input handling vulnerability
Hallöchen! Alex Ogier writes: > [...] > > That suggests an idea to me. Perhaps the best way to check this > isn't on the way out in the template renderer, but rather on the > way back in in the form validation. If the form doesn't get back > exactly those fields it sent out then you know that for whatever > reason, the field was unable to make a round trip. But can one guarantee that fields rendered in the browser are also sent back in the POST request? Even worse, how about non-browser requests? Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: ANN: Django website redesign launched
Hallöchen! Jannis Leidel writes: > We're incredibly proud to share with you the new design of the > Django website, the documentation and the issue tracker. It's certainly beautiful but may I suggest to add contrast a bit? For my laptop monitor / my eyes, e.g. "Note" boxes or source code snippets have almost the same bright background as the rest. Tschö Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/87tx0vl8se.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: ANN: Django website redesign launched
Hallöchen! Daniele Procida writes: > [...] > > In the meantime I have removed you from our email lists, since > your tone is not welcome here. Please don't come back unless you > can communicate in a more acceptable way. Is this customary procedure on this mailing list in such cases? Normally one simply ignores postings/authors one doesn't like. I hope that banned users don't have the answers to my questions. ;-) Besides, a sock puppet is made in minutes ... Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/87iohalgcl.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: Easier to use natural keys.
Hallöchen! Brian Faherty writes: > [...] > > The solution I propose is a meta field on the model that allows > you to set natural keys there. FWIW, we currently have attached to our models class MyMeta: identifying_field = "number" as a means to set something like "poor man's primary key". Thus, I think we would benefit from such a setting. (By the way, we did use natural keys first -- but it was slower, didn't allow for introspection, and resulted in uglier code.) I could explain our use case if asked for. Django discourages to set explicit primary keys. In case of MT inheritance, it didn't even work for us (maybe we were too stupid). There is nothing wrong with that. But then, it would be helpful to have this poor man's PK instead. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.com -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/87wq5lnkkg.fsf%40physik.rwth-aachen.de. For more options, visit https://groups.google.com/d/optout.
Re: JsonField
Hallöchen! Tom Evans writes: > On Sat, Nov 5, 2011 at 11:48 AM, Ric wrote: > >> this is my proposition to have custom data inside a model field >> >> a json data field, the code is simple as this, and it works with >> lastest django release > > The problem with something like this is that it is rarely a good > idea to stick opaque data into the database that cannot then be > queried upon. [...] > > Adding this to core would suggest that bad design choices are a-ok > in Django, which is why I expect many people are -0/-1 on this. While I appreciate that Django core is supposed to enforce good design practices, one must be careful with that if some practice may have valid use cases. You cannot prevent the user from shooting in the foot anyway. While we make extensive use of the relational model in our project, I remembered to have a couple of JSON fields (though we don't have a field class them them so far), so I skimmed through our code to see why we did this. In our code, a JSON field is an application of the KISS principle. I see at least two valid use cases for such fields: 1. You say that you will never query for the content of a field. For example, we store user preferences in a JSON field. I'll never be interested in all users who set their page skin to "classic". (And if I would, I could still do a "manual" query or do the schema and data migration. This is okay as long as its probability is sufficiently small.) Moreover, in some cases, realising the JSON field explicitly in the relational model would have led to many tiny models. This may also be bad for performance, but it is certainly bad for readability and maintenance. 2. Dynamic typing. In one case, we simply don't know a priori how the data structure in the JSON field will look like. The Python code interprets its content depending on another field value of the model instance. The alternative would have been extensive use of multi-table inheritance. Tschö, Torsten. -- Torsten BrongerJabber ID: torsten.bron...@jabber.rwth-aachen.de or http://bronger-jmp.appspot.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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
