I personally think creating a new thing from scratch is easier, sure there might a little bit of work - but on the other hand it comes with a lot of benefits.
However, whoever does the work can decide - and why not having more than one prototype and then see whats the better way? Or in other words, I think it makes sense at least to think about this issue green field without already having existing solutions prediction the final solution. Carsten 2013/5/31 Justin Edelson <jus...@justinedelson.com> > 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 > > > > > > -- Carsten Ziegeler cziege...@apache.org
