Re: [contentparser] API for simple content representation

2017-03-16 Thread Carsten Ziegeler
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 >>

RE: [contentparser] API for simple content representation

2017-03-16 Thread Stefan Seifert
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

Re: [contentparser] API for simple content representation

2017-03-15 Thread Robert Munteanu
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

Re: [contentparser] API for simple content representation

2017-03-15 Thread Carsten Ziegeler
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

RE: [contentparser] API for simple content representation

2017-03-15 Thread Stefan Seifert
>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

Re: [contentparser] API for simple content representation

2017-03-15 Thread Carsten Ziegeler
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

RE: [contentparser] API for simple content representation

2017-03-15 Thread Stefan Seifert
>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

Re: [contentparser] API for simple content representation

2017-03-15 Thread Carsten Ziegeler
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,

RE: [contentparser] API for simple content representation

2017-03-15 Thread Stefan Seifert
>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

Re: [contentparser] API for simple content representation

2017-03-14 Thread Bertrand Delacretaz
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

Re: [contentparser] API for simple content representation

2017-03-14 Thread Konrad Windszus
> 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

RE: [contentparser] API for simple content representation

2017-03-14 Thread Stefan Seifert
>> 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

Re: [contentparser] API for simple content representation

2017-03-14 Thread Konrad Windszus
> 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. >