Getting "pages" from different collection with Assemble - handlebars.js

Let's say I have a page from a collection where I want to list every yaml tag from a different pages collection.
If they were in the same collection this would do the trick:
<section class="see-also">
<header>Related Contents:</header>
{{#each tags}}
<p>In <span class="tag">{{tag}}</span>:</p>
{{#each pages}}
<li>{{data.title}}</li>
{{/each}}
{{/each}}
</section>
But since im trying to access this collection from a page on a different one, how could this be achieved?

I would recommend creating a custom helper for this. Since there is no easy way to write a helper that will work the way you're describing for your specific setup, here is a great example of how a custom helper was used to solve a similar problem: https://github.com/assemble/assemble/issues/254

If I had this use case I would probably put the 'pages' yaml in a separate yml file instead of embedded on the page.
If in your gruntfile you include a path to data files:
assemble: {
options: {
data: ['<%= site.data %>', 'data/*.yml']
}
}
And your file structure includes:
── data
│ └── page1.yml
│ └── page2.yml
You can access {{#each page1.pages}} from anywhere.
Or you could have a shared.yml file that includes information like the pages collection referred to, and the rest of the data stays on each page.
Further resources:
http://assemble.io/docs/Data.html
http://assemble.io/docs/YAML-front-matter.html

Related

How to create recursive hbs code in ember?

I have a hbs file that contains following
//some ohter code
-------------------------------------
{{#each items}}
<li>
{{name}}
{{#if items}}
<ul>
//partial should go here
</ul>
{{/if}}
</li>
{{/each}}
---------------------------------------------------
And I want to use same section recursively replacing //partial should go here. How can I do that? Appreciate any help
Ember used to have parital, render and include template tags, which they are trying to get rid of however.
Now, probably the best way is to make use of components. If you are on ember-cli, just open your terminal and type ember g component my-include. It generates a *.js and a *.hbs file (naming depending on whether you are using pods or not).
Then you put the template code you want to use multiple times in the newly created *.hbs file, and then in your existing template code:
{{#if items}}
<ul>
{{my-include}}
</ul>
{{/if}}
You might want to take a look at: https://guides.emberjs.com/v2.9.0/components/defining-a-component/ for more information
You can also look at this sample working twiddle.

Foundation: Root variable in links not working for pages in subdirectories

On the Foundation site I am working on, there is a dropdown topbar in a navigation partial that populates its links from several YML files in src/data (one per dropdown category). Each entry looks something like this:
link:
text: "Example Link"
url: "beta/page2.html"
external: false
The piece of the partial that generates each menu entry is as follows:
{{#each category}}
<li><a href="{{#unless external}}{{root}}{{/unless}}{{url}}" {{#if external}}target="_blank"{{/if}}>{{text}}</a></li>
{{/each}}
The goal is for the link to be relative to the site's root if external is false, and used as-is (and open a new tab) if external is true.
The problem is that internal links don't seem to generate properly when the page I am navigating from is in a subdirectory. For example, if I am on example.com/alpha/page1.html, the menu link above points to example.com/alpha/beta/page2.html instead of example.com/beta/page2.html.
How can I change my code to properly generate the links for the pages?
I figured out the issue. Inside the {{#each}} block, the Handlebars context changes, making variables like {{root}} only accessible through the parent context. The issue can be fixed by replacing {{root}} with {{../root}}.
From the Handlebars documentation:
The exact value that ../ will resolve to varies based on the helper that is calling the block. Using ../ is only necessary when context changes, so children of helpers such as each would require the use of ../ while children of helpers such as if do not.

Change some html in layout template when on a certain route (with iron-router and meteor.js)

I have a template I have set up as my layout using iron-router:
Router.configure({
layoutTemplate: 'main'
});
Within this layout, I have a line of html that I would like to be changed on certain routes.
My ideas is doing something like:
{{#if landing }}
<div id="page-wrapper">
{{/if}}
However, how do I implement this for a certain route? I want this variable to be true on every route except for 1.
I think that this kind of "change the template based upon what route I'm on" logic fits best into the use of a template for that route (and any others that will make this same change. Depending on the change required, you may be able to call in your base Template into the modified template.
Example:
Router.route('/yourSpecialRoute', function(){
this.layout('OtherLayout');
});
See the Layout docs - I borrowed the syntax of Setting Region Data Contexts
Having said, if you prefer not to switch layouts per route, consider setting a data on your route (something like {data: item} as shown here in the iron:route readme which can then be read by a global helper (Template.registerHelper syntax) - this will at least make it consistent across your routes / templates.

How to split templates into separate files in Meteor

I am using Meteor.js as well as router.js (the package) in order to render other pages of my website. However, all my templates (the other pages) are in one html file. How can I split my templates into different html files and still use router.js?
One sample router configuration for a template is:
Router.route('/events',
function(){
this.render('eventsPage');
},
{
onAfterAction: function() {
document.title = 'Events';
}
});
Where /events is the url associated with the template 'eventsPage'. How can I put the eventsPage template into a separate html file?
Thanks in advance.
You can have each template in separate file, Meteor detects all of your html code.
HTML files in a Meteor application are treated quite a bit differently from a server-side framework. Meteor scans all the HTML files in your directory for three top-level elements: , , and . The head and body sections are separately concatenated into a single head and body, which are transmitted to the client on initial page load.
Read more: http://docs.meteor.com/#/full/whatismeteor
So your HTML file structure depends mostly on your preference.
You should also take a look at:
http://meteortips.com/first-meteor-tutorial/structure/

How to use assemble to add a directory of markdown files to my index

I'm trying to add static site generation to a site in order to make it more organised and easier to contribute to. The index file has a section with with an unordered list and a number of list items that all share the same formatting. I would like to dynamically load these list items from a folder of markdown files.
I'm trying to do something like
{{forEach file in the folder}}
<li>
<div class="container">
<div class="display">
{{markdown content of the file}}
</div>
<div class="code">
<pre>
<code class="language-javascript">
{{ string from YFM in markdown file }}
</code>
</pre>
</div>
</div>
</li>
{{/forEach}}
I don't actually want each markdown file to be assembled into it's own page in my dist folder, just used as a dynamic collection of partials for my index file.
Is this possible?
These two parts of an apparently never finished tutorial explain how to use markdown files as a dynamic collection of partials to integrate on the index site:
http://www.andismith.com/blog/2014/02/getting-started-with-assemble/
http://www.andismith.com/blog/2014/02/creating-a-list-of-posts-in-assemble/
Inside the loop that's iterating the md files I used this construct to get the yfm-stripped content "included" as content on the index site (took me quite a while to figure out):
{{#markdown}}
{{page}}
{{/markdown}}
Also refer to the documentation on Collections on http://assemble.io, but careful, there's some conflicting information out there as to the options hash for collections (name: posts vs. name: post, that is, singular vs. plural and autoinflection vs. inflection: post, but bottom line: stick with the variant in the links above :))

Resources