4 ms·
To me, this: _table_achievement_column=instance&ascending:true is less clear than: table[achievement][column]=instance&table[achievement][ascending]=
by adeelk 15y ago
To me, this:
_table_achievement_column=instance&ascending:true
is less clear than:
table[achievement][column]=instance&table[achievement][ascending]=true
which also has the benefit of being parsed properly by most web frameworks.
- vjeux 15y agoThe URL strings are mostly read only. Once generated, they are not going to be edited by the users anymore. I find it better to have less readable output as long as there is a win in term of length. Because no one likes big urls. Also, what is less visible in URLON is the object structure. But usually when you want to edit something, you are only interested in changing the values, not the structure itself.
- adeelk 15y agoIf you want to optimize length over readability, then how about: col=instance&asc=1 Or even better: c=instance&a=1 :)
- vjeux 15y agoIt is still possible to make such small structure with URLON URLON.stringify({c: 'instance', a: 1}) == '_c=instance&a:1' We also benefit from the typing: 1 is a number an not a string :)
- adeelk 15y agoBut URLON.stringify({c: 'instance', a: '1'}) == '_c=instance&a:1' as well, right?
- vjeux 15y ago@adeelk: 1, the number, is converted to :1, but "1", the string, is converted to =1. This way I can tell whether it's a string or number upon reconstruction. You can actually run this on the blog page URLON.stringify({c: 'instance', a: '1'}) == '_c=instance&a:1' It will return false
- stanleydrew 15y agoMost web frameworks will never parse this because it's intended to be used within the fragment part of the URL which is never sent to the server.
- drdaeman 15y ago> table[achievement][column]=instance&table[achievement][ascending]=true Which is way too verbose than some sort of table[achievement[column=instance&ascending=true]]