Hi, These are all excellent points. I am a bit confused about mentions of the Sling Resource API. This is a server-side API while we are discussing client code. AFAIK we don't have a client implementation of the Resource API nor do we have a standard transport mechanism. We do have the default GET and POST servlets, but as Robert pointed out in the wiki, those can't be depended upon consistently.
The points Carsten and Dominik point to something broader - not using vlt (and the content packing process in general) necessitates defining packaging and deployment mechanisms. After all, it wouldn't be acceptable to have a way to develop and application without being able to deploy it. With vlt, these mechanisms are defined already (whether these mechanisms are ideal or not is a separate problem). One option is to use Sling-InitialContent and POST to the webconsole (as Dominik suggested); another is to build something new (as Carsten suggested). At the end of the day, what I'm asking is that we wait until vlt has been moved to ASF before judging it. My belief, based on some experience embedding vlt, is that the issues raised in this thread are relatively easy to resolve. Certainly easier than creating a new thing. Justin On Fri, May 31, 2013 at 8:21 AM, Dominik Süß <dominik.su...@gmail.com>wrote: > One comment about content.xml - in our CQ solutions we do use the > Sling-Initialcontent (with the much nicer json files placed parallel to > the folders with the same name instead of .content.xml underneath) instead > of packing it directly in the vault based packages. This leads to a clean > and much better searchable filestructure. The code at least for the jcr > installation is yet there so this json based syntax would be an option that > allready works. The syntax is exactly what you get from the default GET > Servlet dumping the structure as json. > > The only drawback to vault is that synchronisation is just in direction of > the repository, no export (but dumping via the default get servlet). > > Cheers > Dominik > > > On Fri, May 31, 2013 at 2:14 PM, Carsten Ziegeler <cziege...@apache.org > >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) > > > > 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 > > > > > > > > > > > > -- > > Carsten Ziegeler > > cziege...@apache.org > > >
