Re: [arch-general] [arch-dev-public] Developer reports
On 30 April 2011 04:26, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Apr 29, 2011 at 7:23 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
2- The report for large packages should list the sizes in MB instead of bytes. That would make the generic nature of these reports a lot harder, and/or involve me sinking quite a bit of time into making something generic that formats sizes. Deal with it for now. :)
filesizeformat [1] built-in filter to the rescue. However, I'm not sure if it'll mess up the jQuery sort thingy. To run this filter for the package compressed/installed size, the template code [2] might be modified to something like this: {% for attr in column_attrs %} <td> {% if attr == 'compressed_size' or attr == 'installed_size' %} {{ pkg|attribute:attr|filesizeformat }} {% else %} {{ pkg|attribute:attr }} {% endif %} </td> {% endfor %} [1] http://docs.djangoproject.com/en/1.3/ref/templates/builtins/#filesizeformat [2] http://projects.archlinux.org/archweb.git/tree/templates/devel/packages.html...
On Fri, Apr 29, 2011 at 9:24 PM, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 30 April 2011 04:26, Dan McGee <dpmcgee@gmail.com> wrote:
On Fri, Apr 29, 2011 at 7:23 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
2- The report for large packages should list the sizes in MB instead of bytes. That would make the generic nature of these reports a lot harder, and/or involve me sinking quite a bit of time into making something generic that formats sizes. Deal with it for now. :)
filesizeformat [1] built-in filter to the rescue. Trust me, I knew it existed as we use it on the package details page. :)
However, I'm not sure if it'll mess up the jQuery sort thingy. I am sure of this, thus my reasoning above that I didn't fully explain- I didn't think anyone would actually challenge me on it, but I'm glad you did. In this case, I think the only two endings you will see are MB and GB, but those will then incorrectly sort if I'm guessing correctly.
To run this filter for the package compressed/installed size, the template code [2] might be modified to something like this: I guess this is what qualifies in my book as "dirty"- I don't like having these two attributes hardcoded here. Yes, I know this extra stuff only ever comes into play with them now, but what if we move flag_date to extra, etc.- do we continue adding {% if %} blocks?
The correct solution to me would be: 1. add another custom tablesort ordering; see archweb.js for our current listing of them. http://projects.archlinux.org/archweb.git/tree/media/archweb.js#n5 2. Make the "attribute" template tag itself smarter and always return a smartly formatted string rather than the raw attribute value (or perhaps make a format_attribute filter or something). hopefully it depends more on types than on attribute names for what it does. E.g. dates go through the "date" filter, integer fields that end in "size" always get filesizeformat treatment, etc. Then the template won't change much at all. 3. ??? 4. Profit
{% for attr in column_attrs %} <td> {% if attr == 'compressed_size' or attr == 'installed_size' %} {{ pkg|attribute:attr|filesizeformat }} {% else %} {{ pkg|attribute:attr }} {% endif %} </td> {% endfor %}
[1] http://docs.djangoproject.com/en/1.3/ref/templates/builtins/#filesizeformat [2] http://projects.archlinux.org/archweb.git/tree/templates/devel/packages.html...
On 30/04/11 08:47, Dan McGee wrote:
The correct solution to me would be: 1. add another custom tablesort ordering; see archweb.js for our current listing of them. http://projects.archlinux.org/archweb.git/tree/media/archweb.js#n5 2. Make the "attribute" template tag itself smarter and always return a smartly formatted string rather than the raw attribute value (or perhaps make a format_attribute filter or something). hopefully it depends more on types than on attribute names for what it does. E.g. dates go through the "date" filter, integer fields that end in "size" always get filesizeformat treatment, etc. Then the template won't change much at all. 3. ??? 4. Profit
Sounds very reasonable. I did however use another solution in place of (2), and added the formatting to the view. In my opinion, it's simpler and just as elegant. Can you please review my patch [1] and see if anything is amiss? Thanks. [1] http://ompldr.org/vOGhtOQ/0001-Add-filesizeformat-filter-to-sizes-in-reports...
participants (2)
-
Dan McGee
-
Evangelos Foutras