parser/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
>>
17 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
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 reusing
> > > the Resource
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 content
>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
>can
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 repos
>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
(resourceresol
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, b
>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 leave a lot of methods t
> 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 of worms because we would
>> 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 l
> 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.
>
> the following feedbac
13 matches
Mail list logo
