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 repositories in > sling-mock (resourceresolver-mock, jcr-mock, oak) -> import to repository via > Resource API (not JCR API) > 2. load content from JSON or JCR XML files for mounting them in the > fsresource provider -> hold data in a cheap in-memory-cache for developer > machines mounting a couple of projects with fsresource > 3. probably migrate the JSON content parsing part of jcr contenloader to this > lib, it has the same parsing logic implemented currently > 4. outside sling i've other projects which need this logic as well e.g. [2] > > as 1. and 2. are maintained in two branches we've currently 4-5 active > projects in sling that need this component and more projects outside, and we > do not want to duplicate the logic again and again. > > my first intention for the API was to have nearly no API, so i used nested > maps for content representation. this created problems with the JCR specialty > allowing node and property with same name, so this thread with the new > proposal with a very thin layer above the nested maps. i do not want to make > the API more complex. but we need some sort of interface to get the parsed > content in a hierarchical form to process it further. > > one perhaps open question is if a stream-based API is better than an > "in-memory" map-based API. for use cases like contentloader and mock-import > stream-based is better, for fsresource map-based is easier. of course it's > possible to create a map with a stream-based API, but then helper methods > like "getChild(path)" is duplicated again. > Thanks for the explanations.
Certainly the JCR api is way to complicated for this use case and I understand that the resource API is close, but returning a resource would create some restrictions on it's usage. So using that would be problematic. I was wondering if it would work to have a parse method which gets a resource resolver and maybe a root path. And the parser would then simply parse the file and directly create the resources in the resource tree. So this would rather be an importer than a parser, but it would avoid having a intermediate tree representation. But that doesn't seem to fit all use cases. 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. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]
