r/impl/mapsupport
>
>
>
>> -Original Message-
>> From: Carsten Ziegeler [mailto:cziege...@apache.org]
>> Sent: Wednesday, March 15, 2017 3:35 PM
>> To: dev@sling.apache.org
>> Subject: Re: [contentparser] API for simple content representation
>>
7 3:35 PM
>To: dev@sling.apache.org
>Subject: Re: [contentparser] API for simple content representation
>
>Stefan Seifert wrote
>>
>>> A streaming API which defines a handler with a method that gets the name
>>> (or path?) and the map of properties would avoid hav
On Tue, 2017-03-14 at 14:19 +0100, Konrad Windszus wrote:
> > On 14 Mar 2017, at 14:11, Stefan Seifert
> > wrote:
> >
> > > > please give [2] as short review from the API perspective.
> > >
> > > I just did it. Basically it looks good, but I would be in favour
> > > of
Stefan Seifert wrote
>
>> A streaming API which defines a handler with a method that gets the name
>> (or path?) and the map of properties would avoid having this additional
>> tree api. I don't see a huge need to be able to have an api to traverse
>> the parsed content. If any user of the
>A streaming API which defines a handler with a method that gets the name
>(or path?) and the map of properties would avoid having this additional
>tree api. I don't see a huge need to be able to have an api to traverse
>the parsed content. If any user of the contentparser really needs it, it
Stefan Seifert wrote
>
>> What is the exact purpose of this module? Or asked differently, what do
>> we expect clients do with the parsed content?
>
> some background about contentparser in this initial thread [1]
>
> my use cases are:
> 1. load content from JSON or JCR XML files into mock
>What is the exact purpose of this module? Or asked differently, what do
>we expect clients do with the parsed content?
some background about contentparser in this initial thread [1]
my use cases are:
1. load content from JSON or JCR XML files into mock repositories in sling-mock
Stefan Seifert wrote
>
>> I like Stefan's Content proposal but it's really a ContentTree, right?
>
> to be precise the current "Content" interface represents one node in the tree
> - so alternative names could be "ContentNode" or "ContentResource"?
>
Sorry for joining the discussion so late,
>I like Stefan's Content proposal but it's really a ContentTree, right?
to be precise the current "Content" interface represents one node in the tree -
so alternative names could be "ContentNode" or "ContentResource"?
stefan
On Tue, Mar 14, 2017 at 2:11 PM, Stefan Seifert wrote:
>> Konrad wrote:
>>...I would be in favour of reusing the Resource interface from Sling API...
>
> ...this would open a can of worms because we would have to support all of it
> including ResourceResolver etc.
> or we
> On 14 Mar 2017, at 14:11, Stefan Seifert wrote:
>
>>> please give [2] as short review from the API perspective.
>>
>> I just did it. Basically it looks good, but I would be in favour of reusing
>> the Resource interface from Sling API.
>
> uh, this would open a can
>> please give [2] as short review from the API perspective.
>
>I just did it. Basically it looks good, but I would be in favour of reusing
>the Resource interface from Sling API.
uh, this would open a can of worms because we would have to support all of it
including ResourceResolver etc. or we
> On 14 Mar 2017, at 14:03, Stefan Seifert wrote:
>
> after the name is settled starting a new thread about the api oft he new "JCR
> Content Parser" component [1].
> the previous implementation used a simple nested map approach for
> representing the parsed content.
>
after the name is settled starting a new thread about the api oft he new "JCR
Content Parser" component [1].
the previous implementation used a simple nested map approach for representing
the parsed content.
the following feedback was open:
1. konrad: JCR allows to have a child node and
14 matches
Mail list logo