On Thursday 08 June 2017 20:01:24 Bernd Wechner wrote: > Bad idea? A subjectivity at best to be honest.
True. In HTTP there is only data (through forms) and state (through cookies). Ordering of data is under (malicious) user control. Now, if the scope of ordering is fixed and not dynamic, then perhaps it's worth writing the code. But the more parameters are added, the more complex it becomes, so keeping input validation to "just" verifying presence and sanity of data is preferable. This is a complex enough task as is. > But yes, I was thinking > I could pull it from the querystring but also would rather not > reparse something already done, let alone in a framework I and many > jumped on because it's DRY ;-) > > The problem I'm solving is not a mission critical thing by any > measure, only a nicety for completeness. Sometimes (often) the order > of events makes a difference (code being a classic and ubiquitous > example ;-) and that applies to commands, and to requests (which are > in the family of commands). But I can resolve it also by: > > a) forcing a consistency on the incoming parameters (rejecting daft > things with an error) > b) forcing a priority on the parameters I receive through GET (i.e. > having a defined result no matter how daft the parameters are) , or > c) passing a single parameter that is an ordered string with another > delimeter (not &), thus passing an order in. d) Use a formset and let the ordering work out by itself (under the hood via incremental naming of form elements, which you get back as an (ordered) list). > Arguably a) is ideal, which leads to you "bad idea" observation but > there are loads of options really, it just surprised me in a sense > that an ordered string comes in and some of that information is > discarded and not made easily available is all. This may come as a surprise, but there is no standard for the format of the query string, beyond it should start with a question mark and is terminated by the fragment separator (#). The only guarantee of ordering you get is that a browser shall order the form elements in "tree order"[1]. With a static DOM tree, that's not an issue. When it's dynamic, then you need to put ordering logic in both the frontend and backend bit. When it's a link, it won't modify what is there. Hence, this gets back to scope as mentioned above. The interpretation of duplicate keys is yet another topic of confusion[2]. Thus frameworks have learned to use either c) or d) or to avoid the query string all together using JSON as transmission format with POST as request method. P.S. If you're building this query string over the course of several requests, consider using sessions (though that's not a guarantee it becomes less complex, just a different way of doing it). -- Melvyn Sopacua -------- [1] https://www.w3.org/TR/html5/forms.html#constructing-the-form-data-set [2] https://stackoverflow.com/questions/1746507/authoritative-position-of-duplicate-http-get-query-keys -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1867973.XK4gdVIMHs%40devstation. For more options, visit https://groups.google.com/d/optout.
