<summatusmentis>
huh, I just tried route '/' do '/item/path/' end
<summatusmentis>
which doesn't work
<summatusmentis>
I'm not sure I understand why
alerante has joined #nanoc
alerante has quit [Ping timeout: 272 seconds]
relix has joined #nanoc
kourier has joined #nanoc
<ddfreyne>
summatusmentis: Do you mean redirect, or do you want content/index.html to be routed to output/index.html?
<ddfreyne>
summatusmentis: Your routing rule should point to a file rather than a directory. The value of the block is the filename where it will be written to, so route '/' do '/index.html' end will work
<guardian>
hi denis
<guardian>
ddfreyne: using @ to denote an instance variable in a helper implemented as a plain function, that doesn't make much sense right? which is the class that evaluates lib/*.rb in which those "instance variables" end up being?
<guardian>
(asked yesterday, not sure you saw it)
alerante has joined #nanoc
<ddfreyne>
Oh yeah
<ddfreyne>
guardian: The instance variable is set in a Nanoc::Context and the context in which functions (i.e. not methods) are executed remains the same, so the instance variables are available everywhere
<ddfreyne>
So if you use @variables in your own helper function, then those are also available globally
<guardian>
ddfreyne: another question, are items sorted? if I name them 01-xxx.md, 02-xxx.md, do you sort them or do I have to sort them after e.g. @items.select?
<ddfreyne>
guardian: They are not sorted
<ddfreyne>
guardian: Even though they are an Array... but in nanoc 4.x they won't be an array anymore (cannot access them with @items[0] anymore etc)
<guardian>
hmm I'm facing a weird behavior
<guardian>
need to debug
<guardian>
do you happen to know whether uglify_js can change functions order upon optimizing?
<ddfreyne>
guardian: No clue
<ddfreyne>
and I have to go to work now :)
<ddfreyne>
AFK!
<guardian>
ok
<guardian>
o/
pavelkunc has joined #nanoc
VitamineD has quit [Quit: VitamineD]
VitamineD has joined #nanoc
alerante has joined #nanoc
alerante has quit [Ping timeout: 272 seconds]
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
alerante has joined #nanoc
jugglinmike has joined #nanoc
<guardian>
ddfreyne: on nanoc.ws, yard is a separate step?
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
relix has joined #nanoc
<narq>
/cl/cl
<narq>
:(
<guardian>
what's best practice? @item[:content_for_summary] or content_for(@item, :summary)?
VitamineD has quit [Quit: VitamineD]
VitamineD has joined #nanoc
<ddfreyne>
guardian: the latter
<ddfreyne>
guardian: the YARD stuff is a data source
<guardian>
and what's the yardoc/ folder in the top level dir?
<guardian>
sorry I don't know YARD
<ddfreyne>
Oh yikes
<ddfreyne>
Thatshould have been excluded from git
<ddfreyne>
It's been there... for a year. Heh
<ddfreyne>
(i have it ignored in my editor)
<guardian>
:) ok
<guardian>
I'm exploring my options for defining a sidebar from within an item
<guardian>
the way you do your navigation
<guardian>
there's something I'm totally uncomfortable with with capturing
<guardian>
since I'm using foundation for this proof of concept project, the side-nav class needs to be put on the <ul>
<guardian>
therefore, the way you do it in nanoc.ws, that is generating <ul><li>...</li><li>...</li></ul> is impractical
<guardian>
because I don't want "foundation to leak" into each item where I do capturing
<guardian>
see what I mean?
<guardian>
or maybe I could gsub on the captured content to inject the foundation specific class, in the layout
<ddfreyne>
guardian: Hmm, so you really want some sort of capturing of non-HTML data?
<ddfreyne>
(but still structured)
<guardian>
not sure how I want it to happen
<guardian>
capturing haml knowing it goes straight to the layout is ok++
<guardian>
it doesn't hurt eyes much at least
<summatusmentis>
ddfreyne: so, even route '/index.html/' do '/item/index.html' end doesn't seem to work either
<summatusmentis>
I'd like to not have to setup a re-direct on the webserver side, but this feels like it hsould be doable from within nanoc
<ddfreyne>
summatusmentis: the argument to #route needs to be an identifier, so '/' will work because it is the identifier of content/index.html
<summatusmentis>
wait, so something like route '/' do '/item/index.html' end ?
<ddfreyne>
summatusmentis: yes, that will cause content/index.html to be written to output/item/index.html
VitamineD has quit [Quit: VitamineD]
<summatusmentis>
oh, I want it to go the other way
<summatusmentis>
I want content/item/index.html to become output/index.html
<summatusmentis>
roughly a "default path" sub-directory
<ddfreyne>
summatusmentis: route '/item/' do ; '/index.html' ; end
VitamineD has joined #nanoc
<summatusmentis>
that structure is sort of unintuitive
<summatusmentis>
also doesn't seem to be loading properly
<summatusmentis>
/item/ is a blog with sub-posts though
<summatusmentis>
oh, :erb filter
<ddfreyne>
summatusmentis: THe idea around identifiers is that they should not be paths (and definitely not contain an extension) because the content is not necessarily tied to the path
<summatusmentis>
hrm, I'll have to play with this some more this evening
<bobthecow>
summatusmentis: how is the structure counterintuitive?
<ddfreyne>
It doesn't always work out that well though :)
<summatusmentis>
bobthecow: the term "route" to me didn't sound like "route thing to a different output"
<bobthecow>
do you ruby?
<summatusmentis>
but instead "route path to the thing"
<bobthecow>
in general?
<summatusmentis>
not generally
<bobthecow>
okay. that's a super common ruby idiom.
<summatusmentis>
it feels backwards from the way I was expecting
<bobthecow>
but i could see it from both directions.
<summatusmentis>
I mean, I'm willing to accept "convention" as an answer
<bobthecow>
one reason it makes more sense to do route -> from -> to, as it does, is that it matches the compile
<bobthecow>
compile input file do; ... end
<bobthecow>
route input file do; path; end
<summatusmentis>
I mean, I can understand that, but I guess compile strikes me that output should work from input file to outcome
<bobthecow>
but then how would you compile something that doesn't have an output file?
<summatusmentis>
whereas, in english, that's not what "routing" something means
<summatusmentis>
no no, I'm agreeing with the structure for compile
<bobthecow>
if you read it as "route from to" the routing rules make sense.
<ddfreyne>
summatusmentis: Hmm... in nanoc 4.x I am getting rid of routing rules and instead you will be able to have a compilation rule that ends in e.g. write "/index.html"... do you think that is more clear?
<ddfreyne>
(Functionally the same, just a bit nicer I think)
<bobthecow>
ddfreyne: that's definitely more clear :)
<summatusmentis>
ddfreyne: that makes way more sense to me
<ddfreyne>
\o/
<summatusmentis>
bobthecow: I agree that this description clarifies
<ddfreyne>
Sadly nanoc 4.x is not quite ready for prime time yet
<summatusmentis>
might be something to call out in the docs
VitamineD has quit [Quit: VitamineD]
VitamineD has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
relix has joined #nanoc
VitamineD has quit [Quit: VitamineD]
VitamineD has joined #nanoc
<guardian>
re
<guardian>
does it sound like a good idea to fake overloading for a link_to helper?
<guardian>
so that you can do link_to(target) and link_to(title, target)?
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
<guardian>
ddfreyne: is there a way to filter captured content?
<guardian>
bobthecow: to pursue the discussion, I think I'll settle on putting navigation info in metadata, as a YAML array
summatusmentis has left #nanoc [#nanoc]
pavelkunc1 has joined #nanoc
<guardian>
bobthecow: 1) basing the nav on parent/children + number prefix is a mess and too rigid, 2) I hoped I could do http://pastebin.com/y4g69m77 but trying to capture haml and eval it as part of the layout doesn't fly
<guardian>
bobthecow: that leaves option 3) add an array in the item metadata
<guardian>
if others followed the discussion or want to jump in, you're more than welcome