Lgtm, thanks Stefan! Carsten
Stefan Seifert wrote > i've prepare a new PR with *only* a streaming API [1]. > please have a new review on the API part. > > it has a very simple ContentHandler interface which reports every resource > found with its map of properties - ordered as found in the source. > > to keep the existing unit tests i added the handler that converts the stream > API to a map representation to the *unit test* code - this is the code which > will then be duplicated across the modules that need a map representation. [2] > > when this is the way we want to go i will commit it. > > stefan > > [1] https://github.com/apache/sling/pull/203 > [2] > https://github.com/stefanseifert/sling/tree/feature/SLING-6592-contentparser-stream-api/bundles/jcr/contentparser/src/test/java/org/apache/sling/jcr/contentparser/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 >> >> 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 contentparser really needs it, it >>>> can use whatever it wants. >>> >>> a Stream API would be a good solution for one half of the use cases. >>> the other half benefits from a Traversing API - we may leave it to the >> other bundles and live with some code duplication. >>> >>> before dropping traversing API completely - what about this: we rename >> the traversing API to something that makes it obvious that this is not yet- >> another-content-representation-api but only a tool to hand over data - e.g. >> "ParsingResult" instead of "Content"? >>> >>> the solution could be: >>> - offer a Streaming API >>> - offer an optional handler based on this streaming API that produces a >> "ParsingResult" that has the minimal traversing capabilities as outlined in >> the PR. >>> >>> we could even put this in two separate modules, but this feels a bit >> over-engineered. >>> >> >> I guess whatever we name it, it's another traversing API :) >> I would prefer to go with just the streaming api and only if really >> really really needed by many others start about thinking how to solve that. >> >> Carsten >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
