hakyll 3 too hard ?
Simon Michael
from following the last few months of discussion I have the impression that hakyll 3 is too hard too use unless you
wrote it, and/or it's not fully documented yet.
Since I've been meaning for a long time to upgrade to hakyll 3, and to be more adventurous with hakyll, this concerns
me. Hopefully I'm wrong ? But if not, is there something we can do to help ?
Thanks for hakyll!
-Simon
Jasper Van der Jeugt
I'm aware that Hakyll 3 is possibly more difficult to use than Hakyll
2. However, it's better ;-)
There's a lot of info in haddocks, but I'm aware that a tutorial is
probably more accessible.
My current plan is to rewrite the tutorial [1] (and maybe split it up
in a few parts) based on which questions arose on the mailing list. If
anyone has any pointers as to what should certainly be included, I'd
be glad to hear it!
[1]: http://jaspervdj.be/hakyll/tutorial.html
Cheers,
Jasper
Miikka Koskinen
Many people have published the source of their Hakyll websites, on GitHub and elsewhere. How about adding a list of those to the site? "Look at how these guys did it!"
Also, it might be handy to have some kind of organised collection of smaller, more general Hakyll snippets. Think of xmonad-contrib. For example, I have lying around code for adding to a page its Git changelog, and a module for generating HTML5 app cache manifests. They might be useful for others, too, but I don't quite know where to put them.
--
Miikka Koskinen
http://twitter.com/arcatan + http://vapaus.org/
Jasper Van der Jeugt
I've already added a few examples to the site now [1]. Topics like [2]
make me think the new tutorial(s) certainly need an elaborate section
on "how to write a custom Compiler arrow". If there's any other ideas
on what needs to be included, your feedback is most welcome!
[1]: http://jaspervdj.be/hakyll/examples.html
[2]: https://groups.google.com/d/topic/hakyll/pIQH_4Vz4qQ/discussion
Cheers,
Jasper
Benedict Eastaugh
> from following the last few months of discussion I have the impression that
> hakyll 3 is too hard too use unless you wrote it, and/or it's not fully
> documented yet.
Hi Simon,
there are definitely more moving parts in Hakyll 3, but by and large
I've found it more modular and thus more pleasant to use. It's
definitely a pro tool in a way something like Jekyll isn't, but the
level of control that comes with that is very welcome.
As far as learning how to use it goes, my recommendation would simply
be to read the source code of other people's Hakyll files. The
examples page on the Hakyll site lists several websites which have
their source code publicly available.
http://jaspervdj.be/hakyll/examples.html
Cheers,
Benedict
Donald Ephraim Curtis
1) the syntax language leaves much to be desired in my opinion. I believe the controller (hakyll.hs in this case) should do two things, define what is to be processed, and expose the data layer (the markdown source files) to the presentation layer (the templates). as an example, consider dates which are displayed in templates, there doesn't look like an easy way to format the dates from the templates, rather they have to be formatted in the processing code?
2) As far as templates and rendering go, I don't see Hakyll as being hierarchical, which I will discuss a bit more below. If you refer to a recent post from me,
http://groups.google.com/group/hakyll/browse_thread/thread/e1fcaa67e8718484
you can see that there are some issues with rendering (unfortunately i do call them an issue even though there is a fix). And I think for being something implemented in a functional language, to me this is counter-intuitive. I know that it's probably annoying to compare this to Jekyll but I think that they have done something fairly interesting here by default and while I haven't read the Jekyll source, this is the way I see it,
If i have a file "Y-m-d-post.md" with a section specifying "template: post.html" and "post.html" specifies "template:default.html", the following happens when "Y-m-d-post.md" gets processed,
Y-m-d-post.md gets parsed, its results get put into "content"
post.html gets processed and its results get put into "content"
default.html gets processed and its results get output.
The latter part, where content is defined as processing of the previously processed template is missing to me. The fact that "body" is a *special* field in the Page structure is somewhat counterintuitive to me also. Also, I like that the "template" is specified in the file itself and the date is extracted from the posting filename. I will give my resolve to this in #3
3) I think the bigger issue is that Hakyll 3 is new and documentation is sparse. I picked the exact wrong time it seems to start hacking on it! However, i think the first priority for Hakyll should be to provide a based hakyll.hs file that mimics the Jekyll process at least partially. This is important for people like me who were going to choose Jekyll but wanted to get my hands dirty in Haskell.
One of the interesting aspects of Jekyll is that it generates a structure "posts" (i think) that contains all data from the postings in the "_post" directory and is available to any template. Thus, items in "_posts" are thought of *the* data for a site.
Realize that I'm not saying Hakyll should BE Jekyll. Hakyll provides much more freedom because I can go in an modify the functionality of the program and taylor it to how i want it to run and can hopefully learn some Haskell on the way. So generating a base Haykll.hs is not giving up on that freedom, it's just making Haykll more accessible.
I know I can get long winded in my explanations of things so please excuse me, but I am just currently frustrated because I had hoped to start using Hakyll right away, THEN go through the hard work of tweaking and writing Haskell code. I saw the play on names, Jekyll ~~ Hakyll and just thought that they would get me started quickly to put together a static site and maybe later I could improve it. Unfortunately I've had to dive right in to coding with it and it's been a little rough.