Home

How can a page/post/layout have awareness of other similar data types?

• Create a data instance class that contains a rendered representation and a data representation of the content.

  • That creates a situation where you have a cyclical dependency - you can't render any pages until all are loaded into memory because the sidebar needs to know what the three most recent pages are.

    • What is the memory footprint of a single page?

      • It doesn't really matter. The memory usage of the application should remain constant.

        • The only way to do that would be to make the implementation deterministic. How can you tell which of 100 blog posts are newest before they're all in memory?

          • Pie gets around this by forcing the post age into the filesystem.

            • That makes managing the post age difficult.

What does the render pipeline look like?

• Filtering posts by most recent and rendering archives requires the ability to filter and paginate content. The content object has properties, of which the content is just one.

  • So should we use a database for this?

    • Well, a NoSQL solution would make the most sense, but that would inhibit installation uptake.

      • Yes and a management issue. But apart from the filesystem, how do you store that data?

        • Well, the memory footprint of a single page is likely to top out at 500kb. The average much closer to 50kb. So it's likely that 1000 posts would be at most 100mb

          • Well that's fucking awful, isn't it.

            • Scratch that, the average might actually be closer to 250k.

              • Well, then storing all of that page content in memory is not possible.

If that is the case, there needs to be a preprocessor step that only loads the page/post header and finalizes all filters before render.

• So then do page/posts have a special filesystem format?

  • Of course not. They're the same think to the framework. They're just a convention based on the publisher.

    • So the framework is three-step then - choose files, then create a data representation, then execute the filter.

      • The application should use caching on the pattern so that the data collection is not needlessly recreated.

        • Should also cache individual file data to be shared across collections. Collection -> File List; Master -> File: File Data

Markdown files do not need a header. Should the header not be in markdown format, then, but mustache format?

• Mustache doesn't really have a data definition format. Will have to be a custom file format that integrates JSON configuration with the mustache file:

  { "name": "World" }
  ~~~
  

  • Hello, {{namme}}!

How do you define a filter for a partial?

• The only way to define a filter would be in a publisher. Perhaps there should be a name for a filter that doesn't produce output (a map?)

How do you define an archive?

• Create an array of posts/pages delineated by year/month or count:

  [ '1' => [ ... ], '2' => [ ... ] ]
  

• Doesn't even necessarily need to be a hash.

  • How do you know when you're on the first/last page?

    • Well the other difficulty here is that you need to create an internal representation for that page - there's no way to multiplex a page into more than one output file at the moment.

    • You would need to be able to apply a 1->many relationship for things like archive pages an the like.

      • That would require something in the header telling the publisher to use that filter

        • Actually, the publisher itself is/would be responsible for output, so the publisher could choose to output a file for every item in an array of the map and could also pass the status of the prev/next items into the context.

Finally, how does a partial that relies on a map get published?

• A FILTER is a mapping between the filesystem and a collection of objects. A MAP is the mapping between a collection of objects and another collection of objects.

  • How would a partial that references a map look?

    • Well, all maps and filters are stored and cached during publishing. They should be exposed to the application for iteration.

      • So then the publishing flow looks like:

        • Choose files based on FILTERS defined in PUBLISHERS to create initial (named) COLLECTIONS

        • Create filtered COLLECTIONS based on MAPS.

        • Execute PUBLISHERS which are PHP. Publishers have access to MAPS.

      • By that logic, filters and maps can be defined outside of the scope of a publisher.

        • What does that mean for the execution phase?

          • Well, we can either rely on conventions (boo) or create an execution class that can define filters, maps, and publishers within itself and use executors for each to create new maps and file output.

            • The declarative solution would be to only compile maps if they are demanded by publishers and only compile filters if they are demanded by maps.

              • That's too fucking elegant for my tastes and would make partials a headache.

                • Well the GENERATION cycle is filter -> map -> publish (wingnut generate MainExecutor)

                  • So there is a MainExecutor class that publishers, filters, and maps/collections are registered to.

Can publishers only be defined in PHP?

• Yes.

How do publishers output?

• Publishers will need to have some sort of write pattern. That write pattern will have to be compiled into a map. That map will then be iterated over and published individually.

Can maps only be defined in PHP?

• Filters will create their collections by default. Dumb collections can be defined in JSON. Maps can be defined in PHP or JSON.

  • You'll need to define a format for the JSON maps e.g.

    { "greaterThan": [ "published.year", "2014" ] }
    

  • That looks unenjoyable. Maybe we should stick to PHP generation initially.