I am open to the idea of using VLT as a base, but we will have to do some pretty extensive work to clean up the error handling and messaging. I haven't taken a look at the newest version, but 2.4.18 is still a black box when it doesn't work, which seems to happen unpredictably. I am assuming we would be skipping the CLI stuff and invoking whatever APIs VLT uses internally to handle imports/exports, correct?
Another idea I've been thinking about would be some sort of .content.xml file editor. Nothing too fancy, more of a helper than a full featured node editor. I haven't come up with a UI yet, but is this something that might be worth looking into as well? -Dan -----Original Message----- From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian Boston Sent: Friday, May 31, 2013 12:07 AM To: dev@sling.apache.org Subject: Re: [tooling] Moving forward with IDE tooling @Justin, will do. @Ruben, it doesnt :(, but IMHO it should. (knowing very little about its internals). On 31 May 2013 13:48, Ruben Reusser <r...@headwire.com> 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 <i...@tfd.co.uk> 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 <jus...@justinedelson.com> 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 >>>> <romb...@apache.org >>>> >>>>> 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.ap >>>>> ache.org/SLING/slingclipse.html> >>>>> [2]: >>>>> >>>> https://cwiki.apache.org/**confluence/display/SLING/**Sling+IDE+too >>>> ling<https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+to >>>> oling> >>> >>>> >>>>> > ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3343 / Virus Database: 3184/6366 - Release Date: 05/29/13
