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 <[email protected]> > > > 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 > > > > > >
