Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Lektor – A Static File Content Management System For Python

lucumr.pocoo.org

Post reply on HN
Print view View original

61–70 of 94 posts

Re: Introducing Lektor – A Static File Content Management System For Python

#61

Post by the_mitsuhiko »

rcarmo wrote: post #59

Very neat. Static site generators are hard to get right (I've been hacking away at a hybrid solution at http://sushy.no-bolso.com / http://blog.carmo.io - same engine, different themes). I do have two questions, though. Why the new file extension (.lr) and the field separator? Jekyll's front matter format is easier for most people - and my engine uses a plain newline to separate front matter from text, and supports m…

The .lr format is easy to explain: it conforms to data models and is easy to parse and generate. Frontmatter does not fit into these requiements. I tried it quite a bit but it makes everything more complex. Not worth it.

Re: Introducing Lektor – A Static File Content Management System For Python

#62

Post by scotchio »

hanniabu wrote: post #60
currysausage wrote: post #46

Earlier quoted context omitted.

Let's not forget that Lektor solves actual problems. Show me another CMS that offers: - Static HTML export with elegant dependency tracking by design (reducing attack vectors and maintenance cost on the frontend server) - Admin interface (I can't tell a non-techie to connect via SSH, fire up vi and run Jekyll) - Flexible content structure (Title/Author/Content doesn't really scale beyond a simple blog) - Elegant desi…

A few alternatives.... http://getgrav.org/ http://getcockpit.com/ http://harpjs.com/

Checkout SpudPress - Static WordPress hosting. All the same except you can use WordPress theming and Admin. If you know how to distinguish between static and dynamic. It's insanely useful

http://spudpress.com

Re: Introducing Lektor – A Static File Content Management System For Python

#63

Post by tedmiston »

pkd wrote: post #4

I love Armin's work, especially Flask, but this seems like lot of other products out there. I have no incentive to switch to this from the generator I'm already using, and for non-techy people I think it's still a big jump in terms of just opening up a tumblr blog.

> ...just opening up a tumblr blog

[I run a Tumblr software blog at http://sandpaper.io.]

A related idea on my mind lately is using Tumblr just as a backend CMS. Then pull the content via their API to display to end users on a separate site. For example, with a bot that automates publishing to a gh-pages branch.

The motivation is that their editing tools and app are so nice, but their presentation makes a site feel less professional. (Also because of the limited abilities to tweak CSS, use JS, and optimize performance can be a bit frustrating.)

Re: Introducing Lektor – A Static File Content Management System For Python

#64

Post by isoos »

scotchio wrote: post #62
hanniabu wrote: post #60

Earlier quoted context omitted.

A few alternatives.... http://getgrav.org/ http://getcockpit.com/ http://harpjs.com/

Checkout SpudPress - Static WordPress hosting. All the same except you can use WordPress theming and Admin. If you know how to distinguish between static and dynamic. It's insanely useful http://spudpress.com

I think a lot of people who would love to use a self-hosted version of this. However, paying for $20/m is usually not worth for a hobby/blog site.

Re: Introducing Lektor – A Static File Content Management System For Python

#65

Post by the_mitsuhiko »

hanniabu wrote: post #60
currysausage wrote: post #46

Earlier quoted context omitted.

Let's not forget that Lektor solves actual problems. Show me another CMS that offers: - Static HTML export with elegant dependency tracking by design (reducing attack vectors and maintenance cost on the frontend server) - Admin interface (I can't tell a non-techie to connect via SSH, fire up vi and run Jekyll) - Flexible content structure (Title/Author/Content doesn't really scale beyond a simple blog) - Elegant desi…

A few alternatives.... http://getgrav.org/ http://getcockpit.com/ http://harpjs.com/

Correct me if I'm wrong but they are either hosted CMS solutions (Grav, Cockpit) or static website generators (Harp) like Jekyll and friends.

Re: Introducing Lektor – A Static File Content Management System For Python

#67

Post by rcarmo »

the_mitsuhiko wrote: post #61
rcarmo wrote: post #59

Very neat. Static site generators are hard to get right (I've been hacking away at a hybrid solution at http://sushy.no-bolso.com / http://blog.carmo.io - same engine, different themes). I do have two questions, though. Why the new file extension (.lr) and the field separator? Jekyll's front matter format is easier for most people - and my engine uses a plain newline to separate front matter from text, and supports m…

The .lr format is easy to explain: it conforms to data models and is easy to parse and generate. Frontmatter does not fit into these requiements. I tried it quite a bit but it makes everything more complex. Not worth it.

Well (and this is only an opinion) having to separate each field makes it harder to edit manually, and a new file extension will be a hassle for non-technical users who want to use their favorite editor.

(I went with .txt/.md/.textile to support multiple markup engines and make it easier for people to edit with literally anything)

Re: Introducing Lektor – A Static File Content Management System For Python

#68

Post by the_mitsuhiko »

rcarmo wrote: post #67
the_mitsuhiko wrote: post #61

Earlier quoted context omitted.

The .lr format is easy to explain: it conforms to data models and is easy to parse and generate. Frontmatter does not fit into these requiements. I tried it quite a bit but it makes everything more complex. Not worth it.

Well (and this is only an opinion) having to separate each field makes it harder to edit manually, and a new file extension will be a hassle for non-technical users who want to use their favorite editor. (I went with .txt/.md/.textile to support multiple markup engines and make it easier for people to edit with literally anything)

> Well (and this is only an opinion) having to separate each field makes it harder to edit manually, and a new file extension will be a hassle for non-technical users who want to use their favorite editor.

A non technical user would use the admin interface.

Obviously a custom file extension is not particularly nice but there is really not that much one can do around that. Renaming the file to `.md` will not magically make things better because the contents are just wrong and the Markdown format just does not do what Lektor needs.

Re: Introducing Lektor – A Static File Content Management System For Python

#69

Post by currysausage »

rcarmo wrote: post #59

Very neat. Static site generators are hard to get right (I've been hacking away at a hybrid solution at http://sushy.no-bolso.com / http://blog.carmo.io - same engine, different themes). I do have two questions, though. Why the new file extension (.lr) and the field separator? Jekyll's front matter format is easier for most people - and my engine uses a plain newline to separate front matter from text, and supports m…

> Why the new file extension (.lr) and the field separator?

This made me chuckle. Many comments seem to fall into two categories: 1) How is it different from SSG_X? 2) Why is it different from SSG_X? (Both are valid questions, no doubt.)

The flexibility in content structure is what makes Lektor a more framework-like CMS. The possible complexity can't really be represented with newlines. For example, my "Abstract" field might be several paragraphs long.

Re: Introducing Lektor – A Static File Content Management System For Python

#70

Post by ar-jan »

currysausage wrote: post #57
ar-jan wrote: post #52

Earlier quoted context omitted.

GravCMS perhaps? http://getgrav.org

Grav advertises "smart caching", so it's not static export by design, is it?

You're right, it's not a static site generator, but a (very fast) dynamic flat file CMS. I guess I got this mixed up because I found it while looking into static site generators.
Post reply on HN