On Tue, Mar 14, 2017 at 12:44 PM, Stefan Seifert wrote:
> ...nested maps are dead simple, but perhaps not enough here...
MultiMap from commons [1] might help maybe?
And maybe a utility class for walking the content tree that the
MultiMap represents.
-Bertrand
[1]
https://commons.apache.org/pr
I would like to see this somewhat separated from the JCR and to have a more
similar data structure to Resources and ValueMaps (Resource-lite?). This
may actually be a really interesting concept for import jobs where you
could create the data structure you are importing and just "apply" it over
a re
>> 4. think about making a variant of the TestUtil.getDeep() method
>available in the API as well - it was already duplicated in fsresource
>
>Please see my feedback on http://www.mail-
>archive.com/dev@sling.apache.org/msg65486.html. I don't think using
>Map is the proper return type here.
you're
> On 14 Mar 2017, at 09:51, Stefan Seifert wrote:
>
> thanks for all the feedback - from the discussion i got the following next
> steps and will take care of them:
>
> 1. rename it to "contentparser"
> 2. move it to bundles/jcr (next to contentloader) *)
> 3. remove the parse(File) methods fr
Hi,
On Tue, Mar 14, 2017 at 9:51 AM, Stefan Seifert wrote:
> ...4. think about making a variant of the TestUtil.getDeep() method available
> in the API as well...
FWIW I was thinking along similar lines for a different goal -
representing content in a Sling-independent way (probably using Maps
thanks for all the feedback - from the discussion i got the following next
steps and will take care of them:
1. rename it to "contentparser"
2. move it to bundles/jcr (next to contentloader) *)
3. remove the parse(File) methods from the API
4. think about making a variant of the TestUtil.getDeep(
Another remark on the API:
Currently ContentFileParser methods always returns Map.
If I understood correctly, the keys are both direct property names of the root
resource as well as child resources.
That is not good because in JCR it is perfectly valid to have a node called
"parent" having a su
On Monday 13 March 2017 12:34:45 Stefan Seifert wrote:
> >and moving it to bundles/jcr (next to contentloader)
> >
> >>bundles/commons is for modules not related to Sling/JCR at all.
>
> the fscontentparser component has currently no dependency to Sling API or
> any other sling bundles, so it's no
> On 13 Mar 2017, at 14:24, Bertrand Delacretaz wrote:
>
> Hi Stefan,
>
> On Mon, Mar 13, 2017 at 9:48 AM, Stefan Seifert
> wrote:
>> i've recently created a new commons sling component which i named "File
>> System Content Parser"...
>
> Great, thanks for this!
>
> Are you planning to reu
Hi Stefan,
On Mon, Mar 13, 2017 at 9:48 AM, Stefan Seifert wrote:
> i've recently created a new commons sling component which i named "File
> System Content Parser"...
Great, thanks for this!
Are you planning to reuse this in the Sling Content Loader? IIUC it
implements the same formats?
> ..
>and moving it to bundles/jcr (next to contentloader)
>>bundles/commons is for modules not related to Sling/JCR at all.
the fscontentparser component has currently no dependency to Sling API or any
other sling bundles, so it's not really misplaced. it has an outside dependency
to jackrabbit file
I could live with both 2. and 4.
> +1 for *contentparser* and moving it to bundles/jcr (next to contentloader)
> as
> bundles/commons is for modules not related to Sling/JCR at all.
No sure whether bundles/jcr is a good fit either, as only some parser's are
specific to the JCR (document XML, Fi
On Monday 13 March 2017 08:48:05 Stefan Seifert wrote:
> i've recently created a new commons sling component which i named "File
> System Content Parser", source currently at [1] related ticket is
> SLING-6592 [2].
>
> it's main goal is to support various serializiation formats of resource
> conte
13 matches
Mail list logo
