@Justin, will do. @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its internals).
On 31 May 2013 13:48, Ruben Reusser <[email protected]> wrote: > is the vlt sync now actually updating .content.xml files? I thought it can > only sync regular files. > > Ruben > > > On 5/30/2013 7:24 PM, Justin Edelson wrote: > >> Ian - please do add the autosync use case to the wiki page I created. >> >> >> On Thu, May 30, 2013 at 9:47 PM, Ian Boston <[email protected]> wrote: >> >> Hi, >>> +1 to that. After working on sling for many years doing a mixture of >>> bundle >>> and UI work, mainly using the FileSystemResolver bundle, I realise now if >>> VLT had been available with sync mode (ie auto syncing the repo and the >>> file system), we (the team I was working with at the time) would have >>> made >>> much more rapid progress. UI dev work needs file-save-refresh. The in >>> browser editing UIs deliver this, as does VLT in sync mode, but >>> unfortunately native eclipse based tooling is just too slow (on my >>> machine, >>> might be my machine). Using VLT since I joined Adobe, has been a joy, >>> and I >>> am very glad to know its being donated to the ASF. >>> >>> Had we had VLT then, we would have developed in a very different way, and >>> might not have had half the problems we had with tooling and team >>> structure. >>> Ian >>> >>> >>> On 31 May 2013 10:16, Justin Edelson <[email protected]> wrote: >>> >>> Hi, >>>> I would strongly suggest that this effort be based on VLT. As mentioned >>>> >>> on >>> >>>> the wiki page, we're in the process of moving that to ASF and I think >>>> >>> once >>> >>>> the code is available, it will be clear that it provides a good >>>> low-level >>>> interface for this type of UI. >>>> >>>> While it is true that VLT currently only works with DavEX servers, I >>>> suspect it would not be hard to isolate the "Ex" bits and have a >>>> "WebDAV" >>>> only driver which could be used on non-JCR applications for basic file >>>> operations. >>>> >>>> My concern is that we end up building one more abstraction which is >>>> going >>>> to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK, >>>> >>> etc.). >>> >>>> I know VLT has some baggage, but I'd just ask that people keep an open >>>> mind. >>>> >>>> Separately, I'm going to start a child page of this wiki page to gather >>>> >>> use >>> >>>> cases. There are some functional areas listed on the main page, but I >>>> >>> think >>> >>>> we should try to capture individual use cases. >>>> >>>> Regards, >>>> Justin >>>> >>>> >>>> On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu <[email protected] >>>> >>>>> wrote: >>>>> Hi, >>>>> >>>>> Following Antonio's kick-start of the Sling developer tooling [1] I've >>>>> gathered some thoughts about the initial goals and implementation of >>>>> >>>> our >>> >>>> Sling IDE tooling. >>>>> >>>>> The document is at [2] so please have a look and let me know what your >>>>> thoughts are. I intend to take a pass at the code next week and align >>>>> >>>> it >>> >>>> to the proposed structure, as a foundation for feature work. >>>>> >>>>> Robert >>>>> >>>>> [1]: >>>>> https://cwiki.apache.org/**SLING/slingclipse.html<https://cwiki.apache.org/SLING/slingclipse.html> >>>>> [2]: >>>>> >>>> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+tooling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling> >>> >>>> >>>>> >
