Convert Dragon processing from procedural to event-based
Closed this issue · 7 comments
bobbermac commented
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.asyncpub-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
- use a
- 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 commented
Current data flow for parsing goes like this:
- Blog app: get configuration
dragon.blog: walk the file system starting at the posts directory and process all legal post contentdragon.blog.post: for each file, gather post stats, add dates, and convert post body based on content type- Blog app: generate routes for each post & generate other routes that need post data (e.g., sitemap files)
dragon.generator: using a map whose keys are routes and whose values are generator functions, write to the file system
bobbermac commented
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-postmessage; 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
oubiwann commented
Merged.