Again, I don't want to do it, if we don't have to, but it is definitely
possible, no?
A map embedded in a list like...
"list": [
"e1",
{
"k1": "v1",
"k2": "v2"
},
"e3"
]
would translate to..
list.0: e1
list.1.k1: v1
list.1.k2: v2
list.2: e3
On Fri, Feb 24, 2017 at 10:26 AM, Otto Fowler <ottobackwa...@gmail.com>
wrote:
> I agree with this, flattening the map doesn’t change it’s meaning - it is
> not arbitrary.
> Finding an item still makes sense, what I mean is the flattened name is
> meaningful.
>
> What you would have to do for an array would make it not meaningful, since
> it would just be an
> arbitrary positional number in the name.
>
> Now, how should we handle lists that contain maps? Don’t flatten the list,
> but flatten the maps inside?
>
>
> On February 24, 2017 at 10:15:02, Casey Stella (ceste...@gmail.com) wrote:
>
> I don't know, I think I'm ok with lists, but I might be biased. I think
> it's the nested maps that were the issue. Flattening lists seems...wrong
> to me. Maybe that's wrong-headed, but there it is. ;)
>
> On Fri, Feb 24, 2017 at 10:12 AM, Nick Allen <n...@nickallen.org> wrote:
>
> > Per Otto's advice, I am looking to reuse the normalizer/flattener
> mechanism
> > that currently exists in JSONMapParser. It looks like the mechanism is
> > built into the class, so I will have to extract it. It looks like landing
> > it in JSONUtils is a logical place.
> >
> > It appears that the mechanism only handles maps, not lists. Is that true?
> > I will need to add similar functionality for lists to reuse this for
> > METRON-686.
> >
>
