Closed paternal closed 2 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 ?
It works.
lektor build
: weights are not calculated, unless needed, and the results are cached, and they are calculated only once.lektor serve
: same thing, but they are not calculated again if tags are changed. I see three solutions:~
lektor serve
is only used for development purpose, and we explain this limitation in the documentation;~lektor serve
is used instead of lektor build
, tags are never cached (and re-calculated for each new page where they are used).~~What do you think?~
Done : 2a59bce4d7246322c0a0f6ffd49db68e874abbf4
Everything is OK for me. @runfalk: Waiting for your review/merge. :smiley:
@nixjdm would have to do that since this is his private project. I and other Lektor maintainers don't have access to this repo.
@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
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
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.
My 2¢ on API: Have you considered, instead of
TagWeights
providing a bunch of methods that produce mappings, making theTagWeights
instance be a mapping that maps tag names toTagWeight
objects, which, in turn, provide methods or attributes that provide the various weights.[…]
I agree 95e0f25
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.
I've pushed a proposed
tests/test_tagweights.py
to your branch. (I hope you don't mind.)
No problem. Thanks! :)
Merged and released as lektor-tags 0.5.0.
Thank you @paternal!
Thank you for your careful reviews!
Closes #18.