Hi,
good point, I don't like the second option as I prefer having everything
in a single file. The third option would introduce a special format per
extension which then might need special rules/implementation for merging
two modules or handling inheritance/includes.
Which leaves us with the first option :)
I think parsing this is easy: if it's in array simply concat the values
and apply newlines in between. In the same way we could write out a text
value: we split the text by newlines and create an array out of it.
Regards
Carsten
Robert Munteanu wrote
> Hi,
>
> While working some more with the feature model I realized that text
> sections can not contain newlines - this is a limitation of JSON.
>
> This makes it very hard to work with repoinit sections. I end up with
> (literally) 10k characters on a single line. Diffs are going to be
> interesting with such formats :-)
>
> I think it would help adoption a lot if we have a more friendly format
> for text entries.
>
> One option would be to have lines stored as an array, e.g.
>
> "repoinit:TEXT|false": [
> "create path (sling:Folder) /libs",
> "create path (sling:Folder) /apps",
> "create path (sling:Folder) /tmp"
> ]
>
> Not that nice, but it keeps the file self-contained.
>
> Another option would be to keep a secondary text file around and
> introduce a new field type, file:
>
> "repoinit:FILE": "./repoinit.txt"
>
> This has the disadvantage of no longer having the configuration be
> self-contained, but on the other hand it's a text file, which the
> repoinit format was built for.
>
> The third option - for the sake of being complete - is to have a
> structured JSON format for repoint, but IMO that's overkill. Something
> like:
>
> "repoinit": {
> "paths": [
> "/libs (sling:Folder)",
> "/apps (sling:Folder)",
> "/tmp (sling:Folder)"
> ]
> }
>
> Thoughts? I think the feature model approach is great, but we need to
> improve on the usability of text sections.
>
> Thanks,
>
> Robert
>
--
Carsten Ziegeler
Adobe Research Switzerland
[email protected]
