feature: supports yml configuration format. fixes #653

[kezhenxu94]

This patch tries to fixes the issue #653 , though at this moment this patch only supports simple yml format and doesn't take complex situations into account such as array.

I open this PR in case that anyone is to do the same thing, and, if anyone has any advices after reviewing this commit, he/she can give constructive suggestions here and I'll update this patch.

[codecov-io]

Codecov Report

❗ No coverage uploaded for pull request base (master@5ca5a63). Click here to learn what that means.
The diff coverage is 76.19%.

@@            Coverage Diff            @@
##             master    #1863   +/-   ##
=========================================
  Coverage          ?   48.41%           
  Complexity        ?     1919           
=========================================
  Files             ?      395           
  Lines             ?    11720           
  Branches          ?     1232           
=========================================
  Hits              ?     5674           
  Misses            ?     5596           
  Partials          ?      450

Impacted Files	Coverage Δ	Complexity Δ
...p/framework/apollo/portal/service/ItemService.java	63.71% <50%> (ø)	16 <0> (?)
...llo/portal/component/txtresolver/YamlResolver.java	80.55% <80.55%> (ø)	6 <6> (?)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5ca5a63...e0839d2. Read the comment docs.

[nobodyiam]

Looks promising!

[nobodyiam]

To support yml, there are 2 possible solutions:

1. Use the same way as what we did for properties file and convert it to k-v when user submits it in portal ui
2. Store and publish the original yml texts and parse them in the client side

However, I'm not sure which one is better, i.e. easier to implement and easier to extend.

[kezhenxu94]

To support yml, there are 2 possible solutions:

1. Use the same way as what we did for properties file and convert it to k-v when user submits it in portal ui
2. Store and publish the original yml texts and parse them in the client side

However, I'm not sure which one is better, i.e. easier to implement and easier to extend.

As I know, using solution 1 makes the key unreadable when the configuration is complex, which is exactly the situation where people prefer yml compared to other formats. The keys look like akey[0].bkey, akey[1].bkey in arrays and akey.bkey.ckey, akey,bkey.dkey in objects. it would be worse when configuring object arrays.

Solution 2 would be flexible in client side and can be parsed into custom config bean.

So I prefer solution 1 ^_^

[kezhenxu94]

Closing as this approach is not preferable

[nobodyiam]

I'm not sure which one is better, but this is the next big feature to be done...

[kezhenxu94]

Then I'll keep this PR opened and try another preferable solution(in my opinion), when it's done, we'll compare and pick one of them(if any of them is acceptable)

[nobodyiam]

@kezhenxu94

I'm working on #1944 to add yml support, which uses the solution Store and publish the original yml texts and parse them in the client side. Please take a look, thanks!

[kezhenxu94]

@nobodyiam will take a look soon(perhaps later tonight or tomorrow)