About assets...

[h3raLd]

One thing I still can't figure out about Nanoc since version 2 is
assets. Even in version 3, if I place a css file (test.css) in /
contents "as is", Nanoc complains that it's not a "nanoc item".

Fair enough, I add the following at the top:
-----
-----
...and the site compiles, but it creates a test folder and an
index.html inside it (I'm using the filesystem_combined data source).
Why's that?
Well, that's the standard behavior, after all in my Rules file I have
the following:

route '*' do
item.identifier + 'index.html'
end

My question is: how am I supposed to handle assets? As a temporary
workaround, I placed all the css, javascript etc. in another folder
and I use a rake task to copy them to /output.

Suggestions?

[Alexander Mankuta]

A snippet from my Rules file.

### Compilation #####################################################

compile '/assets/styles/*' do
filter :sass, {
:load_paths => [File.expand_path('content/assets/styles')],
:full_exception => true,
:line_numbers => true
}
end

compile '/assets/*' do
# do nothing
end

# [skipped]

### Routing #########################################################

route '/assets/styles/*' do
item.identifier.gsub(/\/$/, '') + '.css'
end

route '/assets/fonts/eot/*' do
item.identifier.gsub('/eot/', '/').gsub(/\/$/, '') + '.eot'
end

route '/assets/fonts/otf/*' do
item.identifier.gsub('/otf/', '/').gsub(/\/$/, '') + '.otf'
end

route '/assets/fonts/ttf/*' do
item.identifier.gsub('/ttf/', '/').gsub(/\/$/, '') + '.ttf'
end

route '/assets/*' do
dir = File.join('content', item.identifier)
base = File.basename(dir)
regexp = /^#{base}\.(?!yaml)(.*)/

file_name = Dir.entries(dir).sort.find do |d|
d.match(regexp)
end

if file_name
ext = file_name.match(regexp)[1]
File.join(File.dirname(item.identifier), "#{base}.#{ext}")
else
nil
end
end

# [skipped]

[h3raLd]

Rules, of course! Thanks!

One last thing, is there any way to access the extension of the files
in /contents? It would simplify my rules a lot...

[Denis Defreyne]

On 04 Sep 2009, at 16:03, h3raLd wrote:

> One last thing, is there any way to access the extension of the
> files in /contents? It would simplify my rules a lot...

Hi,

Not directly; a Nanoc3::Item does not store the extension of the file
where it was created from. A Nanoc3::Item can be created from
arbitrary data, not just files on the disk, so this makes sense (e.g.
a database table containing items wouldn't store file extensions
either).

There is a way around this, if you feel like hacking a bit. You could
make the filesystem data source that you use (filesystem,
filesystem_combined, filesystem_compact) store the extension as an
attribute. For example, in lib/nanoc3/data_sources/
filesystem_compact.rb in the #items method, you have this:

attributes = meta.merge(:file =>
Nanoc3::Extra::FileProxy.new(content_filename))

Replace this line with something like

attributes = meta.merge({
:file => Nanoc3::Extra::FileProxy.new(content_filename),
:extension => File.extname(content_filename)
})

Now you will be able to access item[:extension] for all items. The
extension will be in the format ".md" or ".html"; if you want to get
rid of the dot, use File.extname(...)[1..-1] or so.

Note that the :file and :extension attribute will override any
existing metadata; if you want the automatically determined extension
to have lower priority, you could use something like this:

attributes = {
:file => Nanoc3::Extra::FileProxy.new(content_filename),
:extension => File.extname(content_filename)
}.merge(meta)

Hope this helps!

Denis

--
Denis Defreyne
denis.d...@stoneship.org

[h3raLd]

Thanks Denis for telling me exactly how to monkey-patch this... :-)

This would greatly simplify my rules, more than anything. I understand
your "philosophy" of extreme flexibility, and I do believe it's one of
Nanoc's main selling points (stay tuned for an upcoming in-depth
article on how I migrated h3rald.com from Typo to Nanoc), but in this
case is there any chance to have this TINY modification right in the
core?

It wouldn't change a lot overall (at worst it would be left blank if
no extension is available), but it could GREATLY simplify rule logic
for someone like me!

Cheers,

Fabio

> denis.defre...@stoneship.org

[Denis Defreyne]

On 14 Sep 2009, at 08:53, h3raLd wrote:

> This would greatly simplify my rules, more than anything. I understand
> your "philosophy" of extreme flexibility, and I do believe it's one of
> Nanoc's main selling points (stay tuned for an upcoming in-depth
> article on how I migrated h3rald.com from Typo to Nanoc), but in this
> case is there any chance to have this TINY modification right in the
> core?
>
> It wouldn't change a lot overall (at worst it would be left blank if
> no extension is available), but it could GREATLY simplify rule logic
> for someone like me!

Yep, you're right. I've made the necessary changes to the filesystem
data sources; see <http://projects.stoneship.org/hg/nanoc/rev/eb379813b7d9
> for details. The 'extension' attribute will always be overrideable
in the metadata itself, if necessary.

Regards,

[h3raLd]

That's awesome, thanks a lot!

> denis.defre...@stoneship.org