Convert Dragon processing from procedural to event-based

[bobbermac]

In order to best support a flexible, extensible text processing framework, Dragon should support a user's or other application's ability to respond to published Dragon events. Event processing should also be a first-class citizen, with Dragon using it natively for all of its own internal processing.

Tasks:

• Examine the existing general workflow for processing posts in Dragon
• Identify all the stages at which points event publication might be useful. E.g., read file, write file; before-read, after-read, before-write, after-write
• Convert Dragon parsing process to async
  • use a core.async pub-sub
  • devise a message structure that Dragon can use externally but which could be used by other apps (that use Dragon) too
  • keep in mind that plugins would likely use this as well
• Identify all areas of Dragon that can and should be converted to using this new infrastructure
• Create and add an event-system component
• Publish an event when the event-system is up
• Declare the full set of events and functions to run
• Set up a subscriber registry in the event system component
  • create a simple, first draft for mass-subscription

[bobbermac]

Current data flow for parsing goes like this:

1. Blog app: get configuration
2. dragon.blog: walk the file system starting at the posts directory and process all legal post content
3. dragon.blog.post: for each file, gather post stats, add dates, and convert post body based on content type
4. Blog app: generate routes for each post & generate other routes that need post data (e.g., sitemap files)
5. dragon.generator: using a map whose keys are routes and whose values are generator functions, write to the file system

[bobbermac]

Proposed events (note that some may have a pre- and post- events:

• read configuration - message should have configuration data
• process all blog posts - message should have source dir location (post message should have all posts data)
• read source file - pre message should have source file location and parsed file extension; post message should have same data as pre as well as read content and content type info
• parse post content - pre message should have same message data as read-source-post message; post message should have parsed data
• write output file - pre message should have all posts data; post message should have file write success/failure
• generate routes - pre message should have all posts data; post message should have all routes and success/failure messages for each route's file write

[bobbermac]

Looking awesome, @oubiwann! Thanks for doing this 😄

[oubiwann]

Moved registry tasks into their own ticket: #6

[oubiwann]

Moved switch to component-based approach to own ticket: #7

[oubiwann]

See PR #9

[oubiwann]

Merged.