alerante has quit [Remote host closed the connection]
_whitelogger has joined #nanoc
canton7 has joined #nanoc
number-six has joined #nanoc
<ddfreyne>
guardian`: Just the Bundler fix
<ddfreyne>
Ah damn, I'm spending the entire day mentoring on saturday.
<ddfreyne>
I think I need to just do nothing for a while!
alerante has joined #nanoc
alerante has quit [Ping timeout: 255 seconds]
<guardian`>
just the bundler fix :(
guardian` is now known as guardian
<ddfreyne>
guardian: What else would you like to be in there?
Keltia_ is now known as Keltia
alerante has joined #nanoc
alerante has quit [Ping timeout: 272 seconds]
<guardian>
#463 for sure which is a bug fix
<guardian>
I would have hoped we could discuss #466
<guardian>
also, #458 looks harmless
cDlm has quit [Quit: Computer has gone to sleep.]
cDlm has joined #nanoc
cDlm has quit [Quit: Computer has gone to sleep.]
alerante has joined #nanoc
jugglinmike has joined #nanoc
alerante has quit [Ping timeout: 255 seconds]
cDlm has joined #nanoc
alerante has joined #nanoc
darix has joined #nanoc
<darix>
ddfreyne: http://dillinger.io/ - did anyone try to use this with nanoc already?
<guardian>
I don't really see the purpose
<guardian>
the essence of a tool like nanoc is to have a programmer workflow: edit markdown in e.g. vim, then compile, then commit
<darix>
guardian: non tech savvy content contributors
<guardian>
one would argue if the contributors are not tech savvy, then you need a CMS
<darix>
guardian: and something like dilliger+nanoc would make a really good one
<guardian>
that just doesn't work imho
<guardian>
so your non tech savy users would use dillinger to preview their mardown then what?
<guardian>
the point of markdown is that somehow you don't really have to get it rendered to know what you wrote is correct
<darix>
they would get a preview at least
<darix>
server side it would be stored in a WC per user e.g.
<darix>
and then git commit -a
<darix>
e.g.
<guardian>
just had a brief look at dillinger.io
<guardian>
it seems to be a site
<guardian>
not a component you can integrate into a web app
<darix>
guardian: right
<darix>
it is not 100% there yet
<darix>
but it has save to github
<darix>
guardian: the whole discussion started because someone started planning a project for a tutorial page for photo workflow with opensource
<guardian>
you're better off building that with Adobe's brackets + server side code if you're really into that
<darix>
and i suggested nanoc instead of joomla
<guardian>
but e.g. my tech writers coworker know how to spawn Ubuntu in Virtual Box, launch a shell, commit markdown and launch nanoc compile and nanoc view
<guardian>
suggesting a static site generator instead of a CMS - those are different beats even though they both get you a website
<darix>
really all you need is something that does something like i said above
bobthecow has joined #nanoc
bobthecow has joined #nanoc
bobthecow has quit [Remote host closed the connection]
<darix>
anyway
<darix>
later
<guardian>
well then maybe brackets + server side code
<guardian>
will get you to that
bobthecow has joined #nanoc
bobthecow has quit [Changing host]
bobthecow has joined #nanoc
ics has quit [Ping timeout: 255 seconds]
ics has joined #nanoc
alerante has quit [Remote host closed the connection]
ics has quit [Ping timeout: 245 seconds]
ics has joined #nanoc
alerante has joined #nanoc
alerante has quit [Changing host]
alerante has joined #nanoc
cDlm has quit [Ping timeout: 260 seconds]
ics has quit [Ping timeout: 240 seconds]
ics has joined #nanoc
<ddfreyne>
darix: Building some sort of GUI on top of nanoc has been on the wishlist for a while
<ddfreyne>
darix: It's a difficult problem to solve properly
<ddfreyne>
darix: For example, the markdown interpreter in the browser is different from the one used by nanoc
<darix>
well
<ddfreyne>
darix: You could let it ask nanoc to compile it, but nanoc currently is not ready for that, and it'd be slow
<ddfreyne>
darix: It would be great to have a WYSIWYG editor where you don't have to deal with markdown at all
<ddfreyne>
But even that's difficult, because you're editing the HTML, and it's hard to transfer back to Markdown that way
<darix>
ddfreyne: i think the markdown would be close enough
<ddfreyne>
darix: The users of that GUI will judge whether or not it is close enough. Gut feeling says no :)
<ddfreyne>
There's also the problem that the live preview should match the site as close as possible.
<ddfreyne>
So you'd need some way of fetching a precompiled layout with a marker where to insert content
<darix>
ddfreyne: for a moment lets leave the preview thing aside
<ddfreyne>
darix: You'd also need a way to edit metadata of a page, such as the title, and have that inserted into the layout as well
<ddfreyne>
Many different problems to solve :)
<darix>
as it could be solced with a simple sinatra app using the same renderer
<darix>
ddfreyne: i know form fields are really hard!
<darix>
ddfreyne: you know what i see as a bigger problem
<darix>
accessing storage
<darix>
how to define "what to commit now"
<darix>
e.g. how to add images
<darix>
and only commit the whole change in one go maybe
<darix>
what if you edit one site
<darix>
switch to another
<darix>
and then only want to commit the 2nd edit
<darix>
way more challenging than the preview thing
<ddfreyne>
darix: Yup, I wasn't even getting to that point
<ddfreyne>
darix: What if you have multiple people editing at the same time?
<darix>
ddfreyne: my first thought would be "one WC per person"
<ddfreyne>
darix: Yes. I think git would not be a bad solution for this, but I haven't investigated it in full yet
<ddfreyne>
(only using the basic git stuff. Not the weird funky CLII.)
<darix>
one could handle my 2 change scenario with a gui feature that wraps git stash + branch
<ddfreyne>
darix: It's a big effort and I am not sure what benefit nanoc would have over existing systems that serve web content
<darix>
ddfreyne: we could also just consider the single user case
<darix>
because having nanoc as backend would still solve many things :)
<ddfreyne>
The wor on nanoc 4 is meant to solve some of the problems of using nanoc as a backend
<ddfreyne>
wor = work
<ddfreyne>
Unfortunately, there's some very difficult problems to solve as well, which make it hard to use in a GUI
<ddfreyne>
For example, ERB/HAML/… allow arbitrary ruby code to be evaluated, and there's almost no way to find out what this code does or on what input data it depends
<ddfreyne>
This makes it really hard to track dependencies efficiently (it is possible to do it correctly easily, but not efficiently)
<ddfreyne>
Adding a new page => site is recompiled
<ddfreyne>
Having a restricted query language and forbidding erb/haml would solve that issue, but it's not the right thing for many people
<darix>
luquid
<darix>
liquid
<ddfreyne>
Liquid is annoying to use.
<ddfreyne>
But conceptually what I am looking for, yes
<ddfreyne>
Or mustache/handlebars + pure functions (filtering, mapping)
<bobthecow>
ddfreyne: i think really the only answer where you get a GUI plus the full power of nanoc is if you compile the site server-side
<darix>
i think preview is optional
<ddfreyne>
Those functions must be pure and they must also be analysable
<bobthecow>
so ultimately what you're saying is you should rewrite nanoc in clojurescript.
<ddfreyne>
e.g. {{ for item in filter(items).where(kind = article) }} … {{ end }}
<ddfreyne>
This way you can know when a new item is added whether it matches that predicate, and decide whether or not to recompile that page if the items array changes
<ddfreyne>
bobthecow: :X
<bobthecow>
that solves all your problems. pure functions, immutable data, works in a browser.
<bobthecow>
and if anyone wants to customize it, they just have to learn clojure.
<ddfreyne>
I'd like to prototype something nanoc-like that works like that.
<ddfreyne>
The nice thing is that you can share code between server and client
<ddfreyne>
Could also be icky rather than nice :)
<ddfreyne>
ANyway, sleep time, need to get up early tomorrow for an early meetig
<bobthecow>
i was almost 100% kidding.
<ddfreyne>
bobthecow: That 1% of not kidding is just inspiring enough for me to consider it
<ddfreyne>
None of the ideas that solve the erb/haml issue are production worthy though :(
<bobthecow>
is the haml issue "haml is awful and ugly and nobody should ever use it"? because the solution to that is to kill it with fire.
<ddfreyne>
Haha
<ddfreyne>
I've used it, but always switched back to erb
<ddfreyne>
But nanoc supports it because people use it
<bobthecow>
i really really like mustache.
<ddfreyne>
+1
<ddfreyne>
nanoc's mustache support is bad though
<bobthecow>
it is.
<bobthecow>
really, there should be support for a viewmodel per item if you're going to do legit mustache.
<ddfreyne>
Hm, I had some mustache brainstorming around