ddfreyne changed the topic of #nanoc to: 3.7.5 (January 12th) | web http://nanoc.ws/ | repo http://bit.ly/XE6e3G | issues http://bit.ly/VfXaSV | forum http://ho.io/n-discuss | irclog http://irclog.whitequark.org/nanoc
pkunc1 has joined #nanoc
pkunc1 has quit [Quit: Leaving.]
smkelly has quit [Ping timeout: 264 seconds]
smkelly has joined #nanoc
guardian has joined #nanoc
<guardian> o/
<guardian> so
<guardian> how do you guys typically use the snapshot feature?
drops has joined #nanoc
drops has quit [Quit: drops]
pkunc has joined #nanoc
VitamineD has joined #nanoc
pkunc1 has joined #nanoc
pkunc has quit [Ping timeout: 276 seconds]
alerante has joined #nanoc
VitamineD has quit [Quit: mi dormas]
cDlm has joined #nanoc
alerante has quit []
cDlm has quit [Ping timeout: 264 seconds]
cDlm has joined #nanoc
cDlm has quit [Ping timeout: 240 seconds]
cDlm has joined #nanoc
cDlm has quit [Ping timeout: 256 seconds]
cDlm has joined #nanoc
VitamineD has joined #nanoc
cDlm has quit [Ping timeout: 276 seconds]
VitamineD has quit [Ping timeout: 256 seconds]
srbaker has quit [Ping timeout: 245 seconds]
srbaker has joined #nanoc
VitamineD has joined #nanoc
VitamineD has quit [Ping timeout: 245 seconds]
VitamineD has joined #nanoc
tantalum has joined #nanoc
opatry has joined #nanoc
<opatry> hi all
<opatry> I'm already using nanoc
<opatry> I'm trying to improve my layout parts
<opatry> to do so, I tried to call layout 'mylayout' with extra parameters hash in my compile rule as follow:
<opatry> compile '*'
<opatry> layout 'mylayout', :do_nav => true
<opatry> end
<opatry> but I get this error "ArgumentError: wrong number of arguments (2 for 1)"
<opatry> the #layout method allows several parameters (http://nanoc.ws/docs/api/Nanoc/Layout.html) but I assume this is not the layout method being called within this context
<opatry> any idea to send extra parameters to layout from compile rule ?
prxq has joined #nanoc
<bobthecow> opatry: the thing you linked to isn't a layout method, it's a layout class.
<opatry> yes, I finally find out the involved layout parts
<bobthecow> yep.
<bobthecow> i was just going to point you to that.
<opatry> it might be nice to allow extra params in the layout method of the compile rule, no?
<opatry> (as the filter one)
<bobthecow> you could do `rep.layout ...`
<bobthecow> since the dsl `layout` method just passes through to rep.layout, which takes the additional args.
<bobthecow> so call rep.layout directly :)
<bobthecow> but yeah, that should prolly be consistent.
<bobthecow> open an issue on the github repo?
<opatry> I'll try that and if it works open an issue yes
irsol has quit [Ping timeout: 252 seconds]
<opatry> I didn't understand how I can retrieve the given parameters, @my_param doesn't seems to be working
<opatry> (using erb in my layout file)
<bobthecow> oh, those options aren't for adding variables to your file.
<bobthecow> those options are for the renderer.
<bobthecow> just like the options in filter.
<bobthecow> let's try this again. ask about what you're trying to accomplish, not about how you think you should be able to accomplish it ;)
irsol has joined #nanoc
FabianB_ has joined #nanoc
<opatry> sure
<opatry> the initial goal is to mutualize the layout of a single item between several use cases
<opatry> - list of excerpt of items
<opatry> - standalone item
<opatry> a list of items' excerpt can be required for home page or more generally pagination pages and for tag pages
<opatry> when inside a list I need to add link to item specific page at several places (and only layout the excerpt)
<opatry> when inside a single item layout, I need to add prev/next links
<opatry> everything work like a charm for now
<opatry> but with duplication of item HTML layout between tag, home and single item page
<opatry> giving some extra parameters from the compile Rule might help me to share all this stuff in the same layout and customize some part according to those parameters
<opatry> (doing a for each loop on targeted items, excerpt management, adding the link_to when needed, next/prev when needed, …)
<opatry> applying consecutive layout might help for some situation
<opatry> calling render with some parameters might help in some other situations
<opatry> I succeed in isolating common parts using partial layout rendered when needed
<opatry> but at the price of ugly parameters forwarding from layout to partial
<opatry> which seems not satisfying
<opatry> <%= render '_article', :article => item, :content => yield, :list => false %>
<opatry> <% page.each do |article| %>
<opatry> <li class="timelineElement clearfix">
<opatry> <%= render '_article', :article => article, :list => true %>
<opatry> <% end %>
<opatry> </li>
<bobthecow> opatry: your answer is likely nested layouts rather than options to a single layout.
<bobthecow> my blog, for example, has something like 12 different layouts total.
<opatry> using render + partial ?
<bobthecow> no, using multiple layout calls.
<opatry> yes, that what I started
<opatry> but get stuck when dealing with pages referencing several items as a list
<opatry> I can't call the layout for each items of the list and merge them before giving them to the next layout
<bobthecow> that's the guts of one of my more complicated rules.
<bobthecow> it's applied to articles and various other pages.
<bobthecow> so if something's an article, it gets either a content-type specific layout or a generic 'post' layout.
<bobthecow> then it gets snapshotted as :guts
<bobthecow> then it gets an 'article' layout that wraps the content-type specific layout.
<bobthecow> then i apply typographic enhancements
<bobthecow> add 'content' layout, which almost everything on my site uses, and around that 'default', which everything but chromeless pages use.
<bobthecow> <default><content><article><post>...</post></article></content></default>
<opatry> I understand the logic of consecutive layout applied
<bobthecow> or <default><content><article><quote>...</quote></article></content></default>
<bobthecow> etc.
<bobthecow> so my list pages have default and content layouts, plus one more called list.
<opatry> but how to layout a list of items computed from another item
<bobthecow> and the list layout doesn't render items, but calls their :guts snapshot instead.
<opatry> ohh
<bobthecow> so that's the important bit.
<opatry> that's it!
<opatry> here is the magical part I missed ;)
<bobthecow> which is why guts is after filters, and after the first content-specific layout, but before the generic ones.
<opatry> I think I get your point, I'll try it
<bobthecow> cool :)
<opatry> I've seen snapshot but didn't seen the link
<opatry> now, it's obvious ><
<bobthecow> if you have items that should render differently when they're in a list than when they're standalone, you can use reps as well.
<bobthecow> i use a combination.
<bobthecow> for example, here's how the guts of an atom feed entry is rendered: https://gist.github.com/bobthecow/bc1d165218feeb7ad325
<bobthecow> because it needs to have syntax highlighting rendered with inline styles rather than css.
<bobthecow> between snapshots and reps, you should have everything you need to make this all work :)
<opatry> I already use reps to handle image size when inside list/excerpt and inside full post
<opatry> all this stuff requires the compilation of items referenced in a list to be done **before** the item aggregating them
<opatry> am I right?
tantalum has quit [Quit: Leaving]
prxq has quit [Remote host closed the connection]