I think usercontroll is here the essential point. Serialization FS -> Sling does not have this problem since it completely unfolds the structure. Looking at CQ as sample does come up with some usecases where you want to handle complete structures in one file for a proper overview like the dialog definitions. Like stated earlier vault seems to have this capabilities but it is just implictly bound to specific nodetypes which might be confusing for devs. An IDE tool covering this whould need to mark constellations that do not cover the current behavior (so FS currently has another structure then a fresh checkout would create) and have all the tooling required to transform the structure and/or the serializationdefinition.
Dominik On Mon, Jun 3, 2013 at 2:34 PM, Robert Munteanu <romb...@apache.org> wrote: > On Mon, 2013-06-03 at 14:25 +0200, Dominik Süß wrote: > > Hi Robert, > > > > regarding your sample - this kind of annotation does work for sure, what > I > > was talking about is the finegrained control over serialisation and > > breakpoints (when to build a complete serialized file and where to split > up > > in subfolder and subsequent metafiles) - I'm sure someone can come up > with > > an intelligent more or less selfexplaing solution, but I'm not aware of > > something existing that could be taken as bluepint. > > I see. That's something that Carsten also pointed out and I've noted at > [1] . I'm not sure how we would achieve a fine control over > serialisation. Is think something you would see as user-controllable? > > Also, what sort of breakpoints do you have in mind? ( I only know of > debugger breakpoints :-) ). > > Robert > > > [1]: > > https://cwiki.apache.org/SLING/sling-ide-tooling.html#SlingIDEtooling-Resourceserializationformat > > > > > Cheers > > Dominik > > > > > > On Mon, Jun 3, 2013 at 2:18 PM, Robert Munteanu <romb...@apache.org> > wrote: > > > > > > > > > I have found Sling -> FS auto syncing useful for several reasons. > > > > 1. The IDE lets me know if files in the repo are being changed, with > the > > > > message, '....do you want to reload this file.' > > > > 2. When I do a svn status, or git status I know I am looking at an > exact > > > > copy of what I just tested. > > > > 3. Because of 1 and 2 I can be certain that what I am editing is > what I > > > am > > > > testing and the repo: > > > > a) Hasn't mysteriously branched. > > > > b) Hasn't overwritten the change I just made with one of its own. > (try > > > one > > > > way sync to experience this, its very frustrating until you work out > > > whats > > > > happening) > > > > 4. I can load things into the repo and have them appear in the IDE. > > > > > > > > But I dont want to steer this thread if the intention was for tooling > > > that > > > > would only work if everything is done in the IDE. > > > > > > I agree that we must allow developers to sync repository -> IDE > > > workspace. I believe that this must be under the developer's control > all > > > the time nevertheless. > > > > > > A visual paradigm that Eclipse uses is the Synchronize view [1] , which > > > is something we can build upon. For IntelliJ we should use what makes > > > most sense in its visual paradigm. > > > > > > IMO this action should be manually triggered. > > > > > > Robert > > > > > > [1]: http://imgur.com/Zht175G > > > > > > > > > >
