Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

post.url as a shortcut for {{ url_for("post", slug=post.slug) }} #29

Closed
semente opened this issue Feb 21, 2021 · 8 comments
Closed

post.url as a shortcut for {{ url_for("post", slug=post.slug) }} #29

semente opened this issue Feb 21, 2021 · 8 comments
Labels
enhancement New feature or request

Comments

@semente
Copy link
Contributor

semente commented Feb 21, 2021

I have multiple directories containing posts and I want to be able to generate a RSS feed for the posts of all these directories, and not just individually. And I could achieve this using the following route:

(weblorg-route
 :name "feed"
 :input-pattern "*/*.org"
 :input-aggregate #'weblorg-input-aggregate-all-desc
 :template "feed.xml"
 :output ".build/feed.xml"
 :url "/feed.xml")

The problem is that I can't set a proper item.link or item.guid for the RSS entry because it can't guess what is the route of some post. url_for requires a route name and I can't do something like <link>{{ url_for(post.route.name, slug=post.slug) }}</link>.

So I propose a post.url attribute to make this possible. It will also help those who want to reuse a feed.xml template between different "posts directories".

(by the way, would be interesting to support post.route.name as well)

@clarete clarete added the enhancement New feature or request label Feb 21, 2021
@clarete
Copy link
Collaborator

clarete commented Feb 21, 2021

Thanks for bringing this up @semente, and thanks for the insight on both providing direct access to the post's fully baked URL but also to notice that we currently don't have an edge between the post and its route, though we already support the opposite edge. I think both points should be addressed.

The only thing that I'd suggest changing in your proposal is that maybe I'd keep post.url and introduce something like post.full_url (please chime in on the name if you think this is a good idea). the way it is for two reasons:

  1. we get to keep backward compatibility
  2. then people can still have access to what they typed in the route rendered

What do you think?

@semente
Copy link
Contributor Author

semente commented Feb 21, 2021

  1. we get to keep backward compatibility

hmm but do we already have a post.url? I couldn't use this in templates... Or I didn't understand why it would make a backward compatibility.

Anyway I'm fine in using another name. Perhaps absolute_url? full_url looks good too.

@clarete
Copy link
Collaborator

clarete commented Feb 21, 2021

  1. we get to keep backward compatibility

hmm but do we already have a post.url? I couldn't use this in templates... Or I didn't understand why it would make a backward compatibility.

Anyway I'm fine in using another name. Perhaps absolute_url? full_url looks good too.

I have no idea why I thought we had anything in post.url I guess I made that up. I guess we should go with that name. Sorry about the confusion here.

clarete added a commit that referenced this issue Mar 4, 2021
It is now possible to access the rendered `:url` property of each Org
file by using `{{ post.url }}` instead of the usual:

   `{{ url_for("route-name", param=value, ...) }}`

That's possible to be done automatically because we have all the
values that might be needed to fill up the `:url` property before
rendering the `:template` property.  That makes it more convenient for
theme authors to type less and get the same outcome.

Behind the scenes, it took adding a new helper function for rendering
a string within a template environment (weblorg--render-route-prop)
and also add a template environment for the (weblorg-copy-static)
routes.  This feature required the bumping of templatel to 0.1.5
because we needed `templatel-env-remove-template', which was just
added to allow this task to be completed.

Refs #29
@clarete
Copy link
Collaborator

clarete commented Mar 4, 2021

I just pushed a commit with the feature implemented. I didn't really close the ticket because I didn't really document it yet!
Anyway, let me know if you have any feedback on it 😄
Thank you for opening this issue with such a cool idea 🙇🏾

@semente
Copy link
Contributor Author

semente commented Apr 4, 2021

opa @clarete, looks like this is not working. I get an undefined value instead the URL.

@clarete
Copy link
Collaborator

clarete commented Apr 7, 2021

opa! Thanks for testing it out, @semente!!! I'll take another stab at it!

@clarete
Copy link
Collaborator

clarete commented Sep 19, 2021

hi hi hello @semente 👋🏾 finally got to take another look at this issue and I'm now using this feature in weblorg's website itself! So if it breaks it will probably be more visible to me 😅

Please feel free to either reopen this issue or to open a new one if this doesn't work as expected and once again, thanks for both the suggestion and for all the time taken testing this out! 🙇🏾

@semente
Copy link
Contributor Author

semente commented Sep 27, 2021

@clarete was testing this today and it worked partially. Post objects from weblorg-input-aggregate-all-desc's posts list returns the current page URL instead object's URL.

post.html:

{{ post.url }} <- this works!

posts.html:

  {% for post in posts %}
  {{ post.url }} <- this returns current page URL instead post's URL
  {% endfor %}

routes:

(weblorg-route
 :name "log"
 :input-pattern "log/*.org"
 :template "post.html"
 :output ".output/log/{{ file_slug }}.html"
 :url "/log/{{ file_slug }}.html")

(weblorg-route
 :name "log/"
 :input-pattern "log/*.org"
 :input-aggregate #'weblorg-input-aggregate-all-desc
 :template "posts.html"
 :output ".output/log/index.html"
 :url "/log/")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants