<ddfreyne>
Still very much a WIP because the big ToC looks a bit crappy.
VitamineD has quit [Ping timeout: 246 seconds]
jarr0dsz has joined #nanoc
VitamineD has joined #nanoc
jarr0dsz has quit [Remote host closed the connection]
alerante has joined #nanoc
<tom[]>
ddfreyne: i'm working again on my documentation project. toc generation is key and not easy for me as a non-rubyist. it currently looks like http://docos.spinitron.com/ which is not too bad but i think i need open/closed sections like http://docs.vagrantup.com/v2/
<tom[]>
ddfreyne: do you think your toc generator might make it into nanoc's helpers?
<ddfreyne>
tom[]: I don't really create additional helpers anymore. Perhaps basic ones could work, but I find that quite often, helpers are too generic and don't work well in real-world situations, where you need slightly modified code anyway
<tom[]>
perhaps sitemap is what i should call what i need
<tom[]>
ddfreyne: thanks for the link
<ddfreyne>
yw
jugglinmike has joined #nanoc
<ddfreyne>
jugglinmike: btw, a Nanoc::Item has a #children method which you can use to find subpages
<jugglinmike>
ddfreyne: Ah, interesting!
<jugglinmike>
ddfreyne: I'm still getting ready to write a message to the mailing list, but while you're here, maybe I can ask you a more conceptual question first
<ddfreyne>
↑ anybody give a :+1: if you think the code is good or leave remarks otherwise
<jugglinmike>
This project is getting kind of large, and I'm worried that it's too easy to write redundant/inefficient Ruby code inside the layouts. I would like to switch from filtering everything through ERB to filtering through Mustache, but I was reading some old threads where you were saying that it may not be that simple
<jugglinmike>
the thread was years old, though, so I'm wondering if you think it's a viable option today
<jugglinmike>
especially since nanoc's documentation suggests that using Mustache in place of ERB is a tenable option
<ddfreyne>
jugglinmike: I don't have a lot of recent experience with Mustache. It is possible to use it, but there are some limitations
<ddfreyne>
the stuff inside {{ }} can be yield (which means the page content) or an item attribute
<ddfreyne>
There's no way to access layout attributes, the current item rep, call helpers etc
<ddfreyne>
That's not necessarily a limitation of Mustache; it's more about the integration between nanoc and mustache
<jugglinmike>
ddfreyne: yeah, I was looking at that
<ddfreyne>
One idea I had was to use e.g. {{ item.someattribute }} {{ yield }} {{ layout.blahattribute }} etc
<ddfreyne>
But it is still fairly limited
<jugglinmike>
ddfreyne: The other thing I would need is to access globals, since I'm setting up non-item data structures in my site's `preprocess` block
<jugglinmike>
That works right now with ERB, but I don't think that would work with Mustache
<ddfreyne>
jugglinmike: right
<jugglinmike>
hrm
<ddfreyne>
jugglinmike: Have you check whether erb is the bottleneck?
<ddfreyne>
It may be worth trying erubis
<jugglinmike>
ddfreyne: Actually, speed is probably the last of my motivations
<jugglinmike>
ddfreyne: This is a bit of a hot-button issue among developers, but I think that logicless templates would really help maintain this project
<ddfreyne>
jugglinmike: yep, I agree
<ddfreyne>
That's possible with ERB too obviously (if you have appropriate helpers), but ERB tends to evolve into a bit of a mess
<jugglinmike>
yes!
<jugglinmike>
That's what I'm trying to avoid--otherwise I feel like I'm just constantly plugging leaks as redundant/inefficient Ruby makes its way into layouts
<ddfreyne>
jugglinmike: I think Mustache is a good way to go, but the Mustache filter needs to be improved greatly
<jugglinmike>
ddfreyne: Okay, that's encouraging to hear from you! I couldn't tell if this goal was doomed because I was missing something or it was incompatible with nanoc's design
<ddfreyne>
jugglinmike: If you want to take a stab at implementing that, be my guest. I don't think I'll get to it on time, and I think you have a better understanding of what you need and where you want to go anyway.
<jugglinmike>
ddfreyne: Alrighty! I'm also quite busy, but I'll put it in my queue as well. One of us will get to is someday :)
<jugglinmike>
ddfreyne: Is there a document (or source file) that I can read to learn about `@config` ?
<ddfreyne>
jugglinmike: @config is a hash that contains the stuff in config.yaml/nanoc.yaml, basically
<jugglinmike>
and it's safe to insert data into it during `preprocess` ?
<ddfreyne>
jugglinmike: I'd prefert o have a seprate syntax for attributes and "methods" (built-in attributes, maybe)... e.g. {{ item.title }} vs {{ item._path }}
<jugglinmike>
{{ item.:title }} vs {{ item.path }}
<jugglinmike>
mine's grosser
<jugglinmike>
{{ item.meta.title }}
<jugglinmike>
ddfreyne: namespace all the metadata under a `meta` hash? ^^
<ddfreyne>
jugglinmike: Hmmm... I kinda like item.:title
<jugglinmike>
ddfreyne: I think that means we need to define some sort of getter on the context object. If the requested attribute name begins with a ":", then it should translate it to a Ruby symbol and return that
<jugglinmike>
well, not return the symbol
<ddfreyne>
Yup
<jugglinmike>
but use the symbol to dereference the context object and return *that*
<jugglinmike>
ddfreyne: Can we do this generally? What if the object has nested symbol attributes?
<jugglinmike>
foo.:bar.:baz
<jugglinmike>
we can't translate "foo.:bar" to foo[:bar] and simply return that object
<jugglinmike>
we'll have to wrap what we return, too...
<ddfreyne>
It's one of the reasons why I like statically typed languages, and especially languages with "tiny types"
<bobthecow>
how do you even know if you did it already?
<bobthecow>
i'm over statically typed languages.
<ddfreyne>
I have no clue what I was thinking.
<bobthecow>
so was the problem that skipped items never got that Time.now - rep_time stored?
<ddfreyne>
Statically typed languages with "tiny types" allow you to have types like "title" (string alias) and "first name" (string alias) and never get those messed up, because the type system will tell you
<ddfreyne>
bobthecow: yup
<bobthecow>
so it was just the original timestamp.
<ddfreyne>
bobthecow: I’m sorry ;)
<ddfreyne>
yeah
<ddfreyne>
Off to sleep. gnight!
<bobthecow>
g'night!
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
pavelkunc has quit [Client Quit]
jarr0dsz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]