Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructure configuration keys #82

Closed
mojavelinux opened this issue Jun 2, 2016 · 2 comments
Closed

Restructure configuration keys #82

mojavelinux opened this issue Jun 2, 2016 · 2 comments
Assignees
Milestone

Comments

@mojavelinux
Copy link
Member

Right now, all the general settings for the plugin are defined as top-level configuration keys.

  • asciidoc
  • asciidoc_ext
  • asciidoc_page_attribute_prefix
  • asciidoc_require_front_matter_header

I think these keys should be moved underneath the asciidoc key as follows:

asciidoc:
  processor: asciidoctor
  ext: asciidoc, adoc, ad
  page_attribute_prefix: page
  require_front_matter_header: true

We can still support the old keys for backwards compatibility. We simply check if the asciidoc key has a String or Hash value. If the key has a String value, assume the old keys (issuing a warning and coercing them into the new structure). If it has a Hash value, use the new structure.

We'll leave the asciidoctor key alone as that's an orthogonal set of configuration.

@mojavelinux mojavelinux added this to the v1.2.0 milestone Jun 2, 2016
@mojavelinux mojavelinux self-assigned this Jun 2, 2016
mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 4, 2016
- move asciidoc keys to Hash under asciidoc key
- use old keys if new keys aren't specified
- add warning if old structure is detected
mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 4, 2016
- move asciidoc keys to Hash under asciidoc key
- use old keys if new keys aren't specified
- add warning if old structure is detected
mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 4, 2016
- move AsciiDoc configuration to Hash under asciidoc key
- use old keys if new keys aren't specified
- add deprecation warning if old structure is detected
- chomp trailing hyphen on page_attribute_prefix in initialize
- treat nil value for page_attribute_prefix as empty string
- use a module to mark initialized configuration
mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 4, 2016
- move AsciiDoc configuration to Hash under asciidoc key
- use old keys if new keys aren't specified
- add deprecation warning if old structure is detected
- chomp trailing hyphen on page_attribute_prefix in initialize
- treat nil value for page_attribute_prefix as empty string
- use a module to mark initialized configuration
- update README to document new keys
@mojavelinux
Copy link
Member Author

PR ready. See #84.

@mojavelinux
Copy link
Member Author

Backwards compatibility has been fully maintained in this case.

I also made it so that a value of nil for the page_attribute_prefix is treated as empty string. In other words, we avoid crashing because of bad configuration values.

mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 5, 2016
- move AsciiDoc configuration to Hash under asciidoc key
- use old keys if new keys aren't specified
- add deprecation warning if old structure is detected
- chomp trailing hyphen on page_attribute_prefix in initialize
- treat nil value for page_attribute_prefix as empty string
- use a module to mark initialized configuration
- update README to document new keys
mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 5, 2016
- move AsciiDoc configuration to Hash under asciidoc key
- use old keys if new keys aren't specified
- add deprecation warning if old structure is detected
- chomp trailing hyphen on page_attribute_prefix in initialize
- treat nil value for page_attribute_prefix as empty string
- use a module to mark initialized configuration
- update README to document new keys
mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 5, 2016
- move AsciiDoc configuration to Hash under asciidoc key
- use old keys if new keys aren't specified
- add deprecation warning if old structure is detected
- chomp trailing hyphen on page_attribute_prefix in initialize
- treat nil value for page_attribute_prefix as empty string
- use a module to mark initialized configuration
- update README to document new keys
mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 5, 2016
- move AsciiDoc configuration to Hash under asciidoc key
- use old keys if new keys aren't specified
- add deprecation warning if old structure is detected
- chomp trailing hyphen on page_attribute_prefix in initialize
- treat nil value for page_attribute_prefix as empty string
- use a module to mark initialized configuration
- update README to document new keys
- explain that the asciidoctor block accepts any option supported by the Asciidoctor API
mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 5, 2016
- move AsciiDoc configuration to Hash under asciidoc key
- use old keys if new keys aren't specified
- add deprecation warning if old structure is detected
- chomp trailing hyphen on page_attribute_prefix in initialize
- treat nil value for page_attribute_prefix as empty string
- use a module to mark initialized configuration
- update README to document new keys
- explain that the asciidoctor block accepts any option supported by the Asciidoctor API
mojavelinux added a commit to mojavelinux/jekyll-asciidoc that referenced this issue Jun 5, 2016
- move AsciiDoc configuration to Hash under asciidoc key
- use old keys if new keys aren't specified
- add deprecation warning if old structure is detected
- chomp trailing hyphen on page_attribute_prefix in initialize
- treat nil value for page_attribute_prefix as empty string
- use a module to mark initialized configuration
- update README to document new keys
- explain that the asciidoctor block accepts any option supported by the Asciidoctor API
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant