[ http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12434503 ] Jukka Zitting commented on JCR-569: -----------------------------------
Nicolas: > I would like to create two classes: one generic Importer (name to be defined) > and one dedicated to import a workspace. This would still be a part of the flexibility goal (E in my message to the mailing list). To keep things simple I'd suggest that you limit this issue to a patch that refactors the methods within WorkspaceImporter without introducing another class. Note also that the responsibility of WorkspaceImporter is not to "import a workspace" but to import content *into* a workspace. > [The methods of the generic Importer] are private since no other class need > them (this class is used with the ContentHandler). How would a subclass modify the behaviour of the class if those methods are private? > If you are OK with this approach, I will work on this and propose you soon a > patch implementing this refactoring. It looks OK, but I think the main issue is seeing how the existing code gets mapped to the proposed structure. A patch would be the perfect way to show this. :-) > WorkspaceImporter Refactoring > ----------------------------- > > Key: JCR-569 > URL: http://issues.apache.org/jira/browse/JCR-569 > Project: Jackrabbit > Issue Type: Improvement > Reporter: Nicolas Toper > Attachments: SysViewImporter.patch > > > Hi, > As you know, I have run into an issue with the backup tool using the > WorkspaceImporter. I ended up copy/pasting large body of code since the > current WorkspaceImporter was not flexible enough for my use (in my class > called SysViewImporter). This solution was perfectly valid for Google SoC (a > lot of time constraints) but unacceptable in the long run for any project (we > hate large body of duplicate code :p). > Also, some issues have been raised with this class (i.e. jcr:root > importation, allowsSameNameSiblings issue). > Overall I feel this class is circumvoluted and really hard to understand. > For instance, the current code contains at most 5 imbricated if and uses a > lot of different ways to pass information (stacks, objects set on null). > I tried to refactor my SysViewImporter and the WorkspaceImporter but it > implies a new code for the WorkspaceImporter and the SysViewImporter. Here is > its skeleton! I first wanted to gather the community feedback before stepping > in. I tried moving all "work code" away from the startNode method and > reorganise it for readilibility. > Please give me your feedback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
