On Fri, 2013-05-31 at 05:10 +0000, Dan Klco wrote: > 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?
Yes, I plan to use the VLT APIs, not the CLI. > > 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? Yes, definitely. We should have a friendly content editor. Eclipse, for instance, has a 'Design' tab for XML files which has a basic view [1] which can be customised later. Robert [1]: http://docs.oracle.com/cd/E15919_01/wlp.1032/e14244/img/servlet.gif > > -Dan > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Ian Boston > Sent: Friday, May 31, 2013 12:07 AM > To: [email protected] > 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 <[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.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 >
