One problematic part about serialisation is structuredepth. In development you might not want to handle complex structures by shifting folders around, so it would be nice to have a format that allows to define a substructure, so in the Sling Initialcontent you might even define one big JSON that defines the complete structure. The consequence of that if you also need to be able to export changes to the filesystem it isn't clear when things should be handled within a file, and when to break up in folderstructures.
In vault this is implicitly solved for specific nodetypes. E.g. in cq a dialog always gets exportet to a specific xml file covering this explicit substrutcture in one aggregated file. But still even in vault you can have situations where you define substructures in the .content.xml which leads to an instant "asynchronity" with the repository since vault tries to synch that as folder/file structure. I currently have no idea for good solution, but in any case these problems should be solved. Dominik On Fri, May 31, 2013 at 3:19 PM, Robert Munteanu <romb...@apache.org> wrote: > On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler wrote: > > Some time ago I thought about this and had the following idea: > > - we define a packaging for resources - this can be used to represent the > > resources in the file system or in a zip file > > - if a resource is a file, it is represented as a file with the same name > > - if a resource is not a file, it is represented as a directory > > - properties if a non-file resource, and all additional metadata of a > file > > is stored in a [content].xml (or json) > > Good point, added > https://cwiki.apache.org/confluence/display/SLING/Sling+IDE > +tooling#SlingIDEtooling-Resourceserializationformat to capture the > proposal / points to discuss. > > Robert > > > This would allow browsing through the file system to the resource you > want > > to edit and just edit the properties of this resource in a file. It makes > > syncing very easy and fast. > > > > Maybe we can distinguish between a resource which might have child nodes > > and one that doesn't and make the mapping differently. > > > > In any case the whole mechanism needs some research, a disadvantage might > > be if you map a huge resource tree which has no files at all to the file > > system, this will result in a huge directory tree instead of one large > > content.xml - however as we're talking about developer tooling, we can > > neglect this. > > > > Just a rough idea > > > > Carsten > > > > > > 2013/5/31 Robert Munteanu <romb...@apache.org> > > > > > On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote: > > > > is the vlt sync now actually updating .content.xml files? I thought > it > > > > can only sync regular files. > > > > > > I'm frankly more of an IDE guy than a VLT guy from a development > > > experience point of view. > > > > > > However, I think that the IDE is the right place for the change > > > detection/sync capabilities, while VLT will be a mechanism from > > > transporting changes from/to the repository. > > > > > > Robert > > > > > > > > > > > > > >
