preaction / statocles Goto Github PK

Index pages should be paginated after about 5 posts.

Build the date from the path. Moving the post changes the date.

This should be part of my bare minimum script template

Imagine a blog post that has more images, so it needs a specific template. Or a static page that shouldn't have the header/footer, so it needs a specific layout.

• List the available apps. Since apps are referred to by their name in the Site, we'll need a way to list what those names are.
• The blog should be able to create new posts, opening $EDITOR. Defaults to the current date, but allows overriding the date.

Statocles::Template is not documented

Go through and ensure that all attributes and methods are documented as well, because why not?

A command to create a site. Should take the site class, create the site.yml, directories, and other things like git repositories.

Site objects should have some kind of navigation data structure that the layout.tmpl can use.

::default -> dist_dir( 'Statocles', 'theme', 'default' );

Maybe in the future we can do something like:

Statocles-Theme-Mine::name -> dist_dir( 'Statocles::Theme::Mine', 'theme', 'name' )

But I don't think that's as big of a deal.

When we switch branches, Git::Repository writes to STDOUT.

Also, if we're already on the deploy branch, we don't need to switch branches.

Get rid of them. Warnings are bad.

Page should be a role to refactor the common bits of ::Page and ::Page::List. The role should probably be named Statocles::Role::Page. Or maybe Statocles::Page is the role, and Statocles::Page::Document is the single-document Page.

Naming things is hard.

The blog index page should be allowed to restrict to a certain set of tags, so that a "private" tag results in a private part of the blog, accessible only through the direct URL.

Call it a "Deck" app?

It should be able to translate the YAML into a format appropriate for one of the JS presentation systems.

The one I've been using is React.js, so maybe it should simply be called Statocles::App::Presentation::React

I really really want to be able to simply move between JS presentation systems though... Or at least build Deck.js slide shows using markdown...

This entire app should be bundled in the git repo and work out of the box with a core Perl (for example, Strawberry Perl).

It is also editable without using Perl to generate the site, but it should be easy to get set up for generating the site.

http://jekyllrb.com/docs/frontmatter/

---
yaml document

---
markdown document

Make it into the current Statocles::Document

We need an app that simply does static content, js, css, images, etc...

The "preview server" function will need some kind of way to regenerate the static pages when the underlying source file changes. Since we're doing pure-perl, this can't use libnotify.

Beam::Emitter is a good option here, but presently the relations between the models and views do not allow for a good flow from File to Document to Page. Files may contain multiple Documents, which means that new Documents could be created, and old Documents could be deleted, necessarily changing the number of Pages that exist.

Apps may have to take charge of this, by attaching themselves to Files, keeping track of the documents and pages that are a result of the file. But the site would then also have to keep track of all the pages and apply any new pages / remove any deleted pages.

Encapsulation is key here.

Not having to regenerate the entire site if one thing changes is another key here.

A better doc would look like:

---
title: The Title
author: 
content: |
    # Be sure to maintain the indentation
    Markdown content goes here

We need an app that does simply Markdown pages.

It should probably handle the same YAML format that the Blog does (i.e. the default Statocles::Document).

I think it removes the need for all the File:: modules I'm currently using.

We need a command that can:

• build the site. Should only update that which has changed.
• deploy the site.

All site commands should be one word. The future app commands can be multiple words, the first word being the name of the app.

There should be links in the footer to edit this page, if there's an easy way to do it.

For Github, this URL is like: https://github.com/<user>/<repo>/edit/<branch>/<document_path>

If the user specifies everything up to <document_path>, this should work.

Right now the documents are not ordered in any way

We probably want to render Statocles' documentation as HTML.

The site should have a title that is available from the layout template.

The default theme templates should be flexible enough to handle a lot of different needs.

Pre-dated blog posts will not appear on the site until the date. Deploy will not add these pre-dated blog posts until the wallclock date is greater than or equal to the post date.

If the internals are built on-top of Mojo::, we get:

1. Mojo::EventEmitter (needed for #1)
2. Mojo::Template (fixing #17)
3. Mojo::Log
4. Mojo::Base (though our own base is more feature-rich... maybe we keep ours?)

Humph. We get the template language and we'll use the event emitter and probably the logger (though for that we need to inherit from Mojo::Base).

How about we just start with the template and see where that takes us...

The Theme should use Store to find/load its files. Store is the abstraction for dealing with the filesystem (or the database, or whatever persistence).

Mojolicious and Dancer both have their own template language. I'd really like to avoid that, but I'd also really like a pure-Perl template language that doesn't suck.

The link points to the document, not the page

Do them right. http://perldoc.perl.org/perlpod.html shows you how...

Google hates duplicate URLs for a single page, so the site index should probably simply rename whatever app page it is built from.

YA DUN GOOFED WINDERS: http://www.cpantesters.org/cpan/report/1a15388e-6bf7-1014-81e5-9e9e4fa1e24a

Looks like we're checking for a lot of / when Windows gives .

Pages should be able to have tags, and there should be paginated lists of tags.

Each list page (all posts, tag posts) should have a corresponding RSS feed.

A basic, generic, git-based deployment.

For Github Pages specific features, we will make a Statocles::Site::Github.

The Git site should do better commit messages that include what has changed since the last build.

Two scenarios:

1. Deploy to the same branch as build
2. Deploy to a different branch as build

If it's the same branch, look for the last deploy by finding a "Statocles-Deploy" tag in a commit and include the commit spec from then to now.

If it's a different branch, look for the last build commit from the last Statocles-Deploy tag, then concatenate the commit messages, including the commit spec from then to now.

We really only need to know the last build-side commit. If there's a "Statocles-Build-Commit" tag, we know it's a Statocles deploy commit.

Nobody uses the horizontal rule (or at least, they shouldn't), so break the content up into two parts based on "---". Make a "read more..." link that goes directly to the --- break point.

The main Statocles.pm should be a command runner, but also the entry point for documentation to describe the core concepts.

There may be more details guides/tutorials later, but a quick overview should be included in the main document.

Apparently setting the environment variables does not count.

#   Failed test at t/store.t line 74.
# Compared $data->[0]{"path"}
#    got : '/2014/05/22/(regex)[name].file.yml'
# expect : '/2014/04/23/slug.yml'
# Looks like you failed 1 test of 1.

Should probably use a bag()

Until we get a proper "create" command (which may, itself, be insufficient to describe the Beam::Wire configuration file being used), create a Setup guide.

The command-line app should be able to bundle the app into the current directory. Should include all prereqs, which is where our pure-Perl requirement comes in. Put the command-line script itself into the current directory, and the libs into the lib/ directory. The script will need to add a "use lib" line, of course.

http://www.perlrdf.org

We need to be able to handle UTF-8. Look up how to do it. Every file read and write needs to be UTF-8.

At the moment, the Statocles::Document is the only possible document class, but in the future I imagine that other Document classes will come in.

Obviously, we'll wait until we actually need one, but we'll leave this ticket open until we do.