lektor / lektor-tags

For each tag on your site, build a list of pages with that tag. This can be used for standard tag-based blog navigation.
MIT License
27 stars 6 forks source link

Add tag weights #19

Closed paternal closed 2 years ago

paternal commented 4 years ago

Closes #18.

paternal commented 4 years ago

~Almost done. The remaining features to add are (1) don't precalculate the tag cloud unless it's used somewhere and (2) if it's used, don't calculate it more than once per build.~ ~I can do it by caching the tag count somewhere (where?). Then, when needed, if the cache exists, use it; if not calculate it. At the end (or beginning) of each build, remove cache. This would solve both points, but I do not know if it is the "lektor way" to do it? Is there already a mechanism implemented in lektor to cache plugin data?~ Done 2a59bce4d7246322c0a0f6ffd49db68e874abbf4

@runfalk, @goanpeca ?

paternal commented 4 years ago

It works.

~What do you think?~

Done : 2a59bce4d7246322c0a0f6ffd49db68e874abbf4

paternal commented 4 years ago

Everything is OK for me. @runfalk: Waiting for your review/merge. :smiley:

runfalk commented 4 years ago

@nixjdm would have to do that since this is his private project. I and other Lektor maintainers don't have access to this repo.

paternal commented 4 years ago

@nixjdm : Would you review this, or give @runfalk or @goanpeca (if they agree) the rights to accept this pull request and publish a new version on pypi? Thanks

paternal commented 2 years ago

I am still interested in this pull request being merged. @yagebu, if I resolve conflicts, and ensure that it still works with latest versions of lektor and lektor-tags, would you review and maybe merge it?

This pull request counts tags (how many pages are tagged with "foo"?), and assign a weight to them. It can be used in templates to produce a list of tags (with number of occurrence), or produce a tag cloud (this page is generated using the code of this pull request).

The changes in this pull request are documented.

Regards, paternal

dairiki commented 2 years ago

My 2¢ on API: Have you considered, instead of TagWeights providing a bunch of methods that produce mappings, making the TagWeights instance be a mapping that maps tag names to TagWeight objects, which, in turn, provide methods or attributes that provide the various weights.

This seems cleaner to me, and would make it easier to do things that are interested in multiple weight-types at the same time, like:

<ul>
{% for tag, weight in tagweights %}
  <li style="{{ weight.log(100, 200)|round|int }}%;">
    {{ tag }} ({{ weight.count }} articles).
  </li>
{% endfor %}
</ul>

The TagWeight values would be orderable (by count), so ordering tags via dictsort would still work.

paternal commented 2 years ago

My 2¢ on API: Have you considered, instead of TagWeights providing a bunch of methods that produce mappings, making the TagWeights instance be a mapping that maps tag names to TagWeight objects, which, in turn, provide methods or attributes that provide the various weights.

[…]

I agree 95e0f25

runfalk commented 2 years ago

The changes look good to me but I haven't tested anything. If @dairiki also think it looks OK I think we can merge.

EDIT: I renabled CI and it seems there are some minor styling issues to fix but that should be it.

paternal commented 2 years ago

I've pushed a proposed tests/test_tagweights.py to your branch. (I hope you don't mind.)

No problem. Thanks! :)

dairiki commented 2 years ago

Merged and released as lektor-tags 0.5.0.

Thank you @paternal!

paternal commented 2 years ago

Thank you for your careful reviews!