<ddfreyne>
aktau: I'd suggest creating an <%= image_link('/assets/images/blah/') %> helper that finds the item (using @items['/assets/…']), gets the default item rep (.rep_named(:default)), then passes that to some tool that can read the width/height, then finally output an <img> tag with the width/height set
<aktau>
ddfreyne: I'd actually want the width/height of the :thumbnail rep
<aktau>
ddfreyne: I really like the way it works right now, very unobstructively, I can just include the image in my markdown, it gets filtered to html, then in the imagesize filter it gets parsed out by nokogiri, which select every <img> tag and adds width/height
<aktau>
ddfreyne: the only real problem being that the image does not exist in the /output directory yet
<aktau>
ddfreyne: did you see the source of my page?
alerante has quit [Remote host closed the connection]
<bobthecow>
prxq_: you can also get items out of @items by using their identifier as an index...
<bobthecow>
prxq_: link_to @items['/foo/bar/']
<bobthecow>
guardian: everything in your thing makes sense except the factory.
<bobthecow>
why not put a 'common' submodule in the top level instead of factory...
<bobthecow>
could have `common/content`, `common/rules`, `common/layouts`
<bobthecow>
then make a datasource for that.
<bobthecow>
and have a rules file in the top level that imports the common rules
<bobthecow>
(would also mean you could override / extend rules in any given project as needed)
alerante has joined #nanoc
<guardian>
bobthecow: I envision factory as a "nanoc framework" which rules, layouts, helpers, css and js won't change in isolation since the goal is to share a same visual design and behavior between products
<guardian>
bobthecow: what you suggest is that each product has a its own nanoc site (in the doc/ subfolder) that reuses some common rules and layouts etc
<bobthecow>
yeah. that makes a bit more sense to me.
<bobthecow>
fwiw, you don't need your monkeypatch regardless.
<guardian>
bobthecow: but that would mean copy/paste the part that reuses common/content, common/rules and common/layouts between projects
<bobthecow>
just set up the relative directory in config.
<guardian>
in the first place, monkey patching nanoc == something more robust than symlinks which don't play well with git
<guardian>
I'm not sure it's a win to duplicate the part that imports common/content, common/rules, common/layouts, common/libs etc between products
<bobthecow>
you don't need to monkeypatch nanoc.
<guardian>
I thought that doing the way I suggests puts few people in control of the "nanoc framework" while others could focus on writing .md files in product1/doc/content/
<bobthecow>
just tell it that its content directory isn't in factory/content
<bobthecow>
that's a config option.
<guardian>
that's a config option for the static data source only
<bobthecow>
oh, right. we never got around to fixing filesystem
<bobthecow>
ugh.
<bobthecow>
i think there's been an issue open for doing that for about two years.
<guardian>
even if it's an option, our approachs still differ :)
<guardian>
I appreciate the debate, I'll think more about what you suggest
<bobthecow>
i'm not debating.
<bobthecow>
i see the value of your approach. i was just saying that you shouldn't monkeypatch nanoc.
<bobthecow>
it turns out that you have a valid reason, thanks to an inflexible data source.
<bobthecow>
i'd extend the data source, personally, rather than monkeypatching.
<bobthecow>
or send a pull request to make the content directory respect config :)
<guardian>
ok let aside the part about patching or configuring or extending
<guardian>
the approach you just suggested is still different
<bobthecow>
i know.
<guardian>
I see value: having specific rules per product
<guardian>
I need to consider how much I need/want that
<guardian>
compared to the approach I was about to take so far
<bobthecow>
my approach would make it more like traditional inheritance... each project would have a docs site, which extends a base site's rules, layouts, etc.
<guardian>
and I appreciate you took time to have a look at that pastebin and think about it :)
<bobthecow>
and in most cases you wouldn't need to extend layouts... but in some cases you would :)
<bobthecow>
i'm just thinking about the reality of every project i've ever worked on. someone always needs to hack on something.
<guardian>
can an additional data source populate layouts? I didn't have the impression the static datasource could for instance
<bobthecow>
yeah.
<bobthecow>
it doesn't, but it can.
<guardian>
I have the impression the static datasource can populate items only
<bobthecow>
it's part of the datasource api.
<bobthecow>
static doesn't.
<guardian>
ok
<bobthecow>
but if you make a common datasource, you could load your common content and layouts...
<guardian>
sure, that common datasource could load content and layout from ../content and ../layout
<guardian>
that would keep my approach
<guardian>
and remove the patching
<bobthecow>
as i see it, you'd have a rules file in each docs directory that just includes the common rules. a lib file in each docs directory that includes the common libs. and a config file that points at the common datasource.
<bobthecow>
that way you could put a rule above that include to override, or a rule after that include to extend.
<guardian>
could be handy indeed
<bobthecow>
the more i code, the more boring i get. i like explicit includes and being able to trace everything that happens :)
<guardian>
so practically, if I create a brand new site
<guardian>
how do I make it use common/lib/ the way it uses lib/ ?
<guardian>
you said "include" but I guess I need to code something that globs into common/lib and "include/evaluate" common helpers right?
<bobthecow>
probably?
<guardian>
that was a practical question :) I'm not enough fluent in nanoc/ruby to do so. Could you e.g. give me a pointer into nanoc's source? Where nanoc does it for the lib/ folder?
<bobthecow>
(they're stored in code snippets to deal with dependency tracking)
<guardian>
I guess lib/common.rb could do that
<guardian>
if the directory structure is site/lib and site/common/lib then maybe site/lib/common.rb could load and execute snippets in site/common/lib/**/*.rb
<bobthecow>
possibly. it looks like code snippets are fairly hardcoded... i'm not sure what implications that would have. you'd have to ask ddfreyne.
VitamineD has quit [Quit: VitamineD]
<guardian>
yes please ddfreyne
VitamineD has joined #nanoc
<ddfreyne>
aktau: Yeah
<ddfreyne>
aktau: That is why I'd recommend having a tag that references the item identifier for the image instead
<ddfreyne>
aktau: This way, you can tell nanoc to compile the image first (i.e. create it in the output directory)
<ddfreyne>
aktau: Simply by referencing the raw_path, it will generate a dependency, but you still need to make sure th eimages are compiled first, by calling .depend_on(my_image_items) in the image_size filter
relix has quit [Ping timeout: 246 seconds]
relix has joined #nanoc
<guardian>
re
<aktau>
ddfreyne: from a high-level, I get what you mean, though I have no idea how to achieve this (I'm supposing the item identifier is just the path as seen from /content, don't know what "tag" means in this context)
<ddfreyne>
I have to apologise for not documenting that on the site properly. The dependency generation is not 100%.
<aktau>
As they say, "gene stress"
<ddfreyne>
Heh :)
<ddfreyne>
Where are you from?
<aktau>
Close to Antwerp
<guardian>
ddfreyne: did you follow the end of my conversation with bobthecow? does it fly to have site/lib/common.rb that instantiates other code snippets found in site/common/lib/**/*.rb?
<ddfreyne>
guardian: I haven't followed the conversation tbh, could you summarise?
<ddfreyne>
aktau: I'm from Ghent originally, but I live in Berlin now
<guardian>
ddfreyne: the idea is to have a nanoc site in site/ and have a git submodule in site/common that contains common stuff: items, layouts, rules and helpers
<guardian>
ddfreyne: a custom datasource would populate items from site/common/content, site/Rules would "import" rules from site/common/Rules
<ddfreyne>
guardian: Loading items/layouts from site/common is something you can do from a data source
<ddfreyne>
Rules is also no problem
<guardian>
ddfreyne: and site/lib/common.lib would instantiate code snippets from site/common/lib/**/*.rb
<ddfreyne>
lib... is difficult
<ddfreyne>
(dependency issues)
<ddfreyne>
guardian: what about a submodule site/lib/common ?
<guardian>
well the idea was: have a "nanoc framework" that is reused among different products: http://pastebin.com/YBtd7pB9
<guardian>
and bobthecow mentioned another solution that would allow each product to customize Rules and helpers
<guardian>
and having too many submodules will complicate things further
<guardian>
ddfreyne: is there a way to have have site/lib/common.lib to "import/include/mix" what's in site/common/lib/**.*.rb or even site/common/lib/common.rb?
<guardian>
ddfreyne: at first I thought about replicating what site.rb does: load and instantiate code snippets. But I clearly don't see the implications with dependency issues
<ddfreyne>
guardian: Ahh, that also works, actually
<ddfreyne>
(and handles dependencies well)
<guardian>
good to know
<guardian>
I'll play with this idea
<guardian>
thx for listening and answering :)
<aktau>
ddfreyne: looks nice, but I'd have to write my posts in .erb instead of .md, no?
<ddfreyne>
aktau: You can combine both (have a filter for :erb, then a filter for markdown)
<guardian>
ddfreyne: do we need both soft and hard dependencies?
<guardian>
on my site I'm doing: raise Nanoc::Errors::UnmetDependency.new(rep) unless rep.compiled?
<guardian>
but I wasn't aware of soft dependencies
<ddfreyne>
guardian: A soft dependency from A on B means that if B changes, A should be recompiled
<ddfreyne>
guardian: A hard dependency from A on B means that B needs to be compiled first
<guardian>
ok
<guardian>
I'm adding the soft thing to my helper right now
<ddfreyne>
guardian: Soft dependencies are useful when an attribute changes in B that is used in A
<aktau>
ddfreyne: by the way, by accident I viewed a presentation of yours where you mentioned pygments.rb was faster than plain pygments. This did not seem obvious to me (why would a wrapper be faster) so I had never done it and was content to just use pygments and have one gem less
<aktau>
ddfreyne: but since changing, my compiles have go from 10s to 0.5s, which makes all the difference in the world
<aktau>
So thanks for that ;)
<ddfreyne>
aktau: It is faster because pygments.rb invokes the Python interpreter directly as opposed to spinning up a Python instance every time
<ddfreyne>
I don't know the detail about how it works though
<aktau>
ddfreyne: yea, once changing I reasoned it must be something like that as well
<aktau>
I think it might help to put that more prominently in the docs if it isn't already
<bobthecow>
and fairly easy to follow. you should check out the source.
<guardian>
I plan to add syntax highlighting to a future site. So you're discussing using pygments.rb gem? And then does nanoc have a builtin filter for that? Because I was looking into Kramdown's CodeRay support