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

[polyglot-yaml] Add ability to customise list element types #152

Open
Tzrlk opened this issue Jan 4, 2018 · 2 comments
Open

[polyglot-yaml] Add ability to customise list element types #152

Tzrlk opened this issue Jan 4, 2018 · 2 comments

Comments

@Tzrlk
Copy link

Tzrlk commented Jan 4, 2018

Following on from #151, there should be an annotation that allows for list items to be customised in special circumstances. Given the following configuration:

configuration:
  pluginOptions:
    - option1
    - option2

The xml that gets generated ends up like this:

<configuration>
  <pluginOptions>
    <pluginOption>option1</pluginOption>
    <pluginOption>option2</pluginOption>
  </pluginOptions>
</configuration>

Unfortunately, in my specific case, the xml generated needs to be like this:

<configuration>
  <pluginOptions>
    <option>option1</option>
    <option>option2</option>
  <pluginOptions>
</configuration>

A potential solution is to add a tag option (http://yaml.org/spec/1.1/#id858961) which gets read and interpreted as the element type (examples here), e.g.:

configuration:
  pluginOptions: !option
    - option1
    - option2

or add parameterisation to the tag and try to find the metadata during parsing:

configuration:
  pluginOptions: !xml:element:option
    - option1
    - option2

If tags aren't usable, the parser could always look at lists and split the name on :. e.g.:

configuration:
  pluginOptions:option:
    - option1
    - option2

Or tags could be used statically to specify an element with metadata:

configuration:
  pluginOptions: !xml:list
    elementType: option
    elements:
      - option1
      - option2
@Tzrlk
Copy link
Author

Tzrlk commented Jan 4, 2018

Option 2 is my favourite, but option 4 is a lot easier to implement. Make sure you have a class to hold the element name in, and implement things like in the snakeyaml examples.

@SanderSmee
Copy link

I read through the issue list and think #44 or #122 can help you out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants