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:[email protected]] >Sent: Wednesday, March 15, 2017 3:35 PM >To: [email protected] >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 >[email protected]
