Twig variable "back to root" ? (for offline documentation) about site-builder HOT 13 CLOSED

Hmm. You can do this now by manually defining that variable that in the front-matter of each article. But that's not ideal and I can see the benefit of having it defined by Sitebuilder itself.

Let me have a think about it. A couple of versions back there was an experimental site object that would be perfect for containing information like this (e.g. {{ site.root }}) and possibly other stuff. I want to avoid a situation in the future where we're defining too many variables and getting in the way of people's coding, so defining a single utility object seems best. But if we define a site object, I don't want to change it too much, which means thinking about what else it might one day contain and coming up with a structure that will accommodate that.

If that sounds alright to you, I'm happy to have a go at it.

from site-builder.

Thanks Matt for your reply.
Yes, using the front-matter works and that's how I solve my problem for the moment :)

I think that having a single utility object would be great. But the more I think about it, the more I get the impression that what we need is not really a site object but more something like a context or a page_context object, because this object will be different for each generated page depending on its name & location. I don't expect for a site object to change, but it's obvisous that a context object will.

For the moment, I see three variable that could be useful:

• the site root (dynamic!)
• the page name
• the page path

For example, for a page located at content/help/about.md

context:
    site_root: '../'
    page_name: 'about'
    page_path: 'help'

What do you think of it ?

from site-builder.

Precision: page_name and page_path could be used (at least) for tab/links/buttons toggling, for a nicer end user experience.

from site-builder.

I've been thinking along similar lines :)

I think there needs to be a ContextBuilder service which makes Context objects that the Transformers can access (e.g. to pass into Twig). I'm trying to figure out right now what part of the code has the responsibility for creating it, and how it should be passed to the Transformers.

I'm still thinking, but the rough plan right now is to have get/setContext() on the FileCopyEvent, and either have a listener listen for the creation of the event and inject the context into it, or use a factory to create the event and context. I don't want to put too much into the event, or make the transformers do too much work, or overcomplicate the copy method… and so on and so forth. Anyway, I'm mid-think; I'll get back to you. :)

P.S. wouldn't the page_name be about.html?

from site-builder.

I've published a feature-branch called context, and a test phar (which do you prefer?) with a test implementation of a context object; let me know what you think. You can get the site root like this:

<link rel="stylesheet" href="{{ context.siteroot }}css/style.css">

The implementation seems possibly overly complex to me (the copy event needs a context, so there's an event builder which uses a contextbuilder to create the event, create the context, add the context to the event, then hand it back…!) but the result is pretty straightforward. I guess :)

P.S. Twig strict variables are on, but so is debugging, so you should get helpful messages and access to the {{ dump() }} Twig function.

from site-builder.

Thanks a lot for this branch. I'll test it tomorrow and give you a feedback.

from site-builder.

I tried the new feature with {{context.siteroot}}, it works perfectly fine, thanks !

I also had a look at the code and I have a question: in the context object, why not let content_path and output_pathprivate ? They doesn't seem useful as such on a user point of view, even if they are of course essential for providing siteroot and others variables. For instance {{context.pagename}} or {{context.pagepath}} would be perfect for "breadcrumbs" generation in the page.

BTW, as soon as this feature will be closed, it will be my pleasure to give you a pull request about the README for this topic.

from site-builder.

I'm thinking of the breadcrumbs stuff... In fact for a really easy breadcrumb management (user point of view) what we would need would be an array, not just a path. So that we would be able to iterate on this object to create the breadcrumbs. However now that you put this context feature in place, I can tweak it to put anything I want in the context. So tell me if my specific needs don't match your vision, no big deal.

from site-builder.

My thoughts about the context object are that it's not just for user consumption, and that I'd like it to be extensible so that stuff like a breadcrumb generator or a debug panel might be hooked in. It's not there yet, though. I'm not yet convinced the way I've implemented it is the right way. I have a cold that makes it difficult to think clearly, and I didn't expect anyone would actually use site-builder :P

I think perhaps you could do a breadcrumb as a Twig extension that consumed the context? I'll have to consider how functionality can be added without bloating the project - not that a breadcrumb trail is bloat, but it's best to think ahead!

from site-builder.

OK I get the point. Let's think of it for a while, and discuss it again with fresh ideas.
(+ the fact that I'm trying to use it "for real" gives me new ideas quite often)

from site-builder.

I've made a context2 feature branch with an alternative method. The site root Twig variable in this case is {{ siteroot }}. The differences:

• the FileCopyEvent now has a data property (which is just a fancy array)
• added priorities to the listeners so we can set the order they run in
• added a listener which calculates and adds the siteroot to that data

I like this because it's a lot less complex, and hopefully a lot more flexible too. Unless you've got any objections, I'm probably going to go with this method and take it a little bit further (e.g. I already moved the frontmatter parsing out of the twigmarkdown/twightml transformers, for example, and I think I'll go further and separate twig out too). If nothing else, it'll make my tests require fewer mocks :)

from site-builder.

Wow, I love it ! I had a look at the code and I must admit that it's a lot more elegant.
All kind of transformations are now fully decoupled, so I can easily imagine how new features would be new transformers. I totally support the direction you're taking 👍

from site-builder.

Great! I've got some tests and docs to write, but I've released 3.3.0 anyway :)

from site-builder.