jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-569) WorkspaceImporter Refactoring
Date Wed, 13 Sep 2006 18:21:23 GMT
    [ http://issues.apache.org/jira/browse/JCR-569?page=comments#action_12434503 ] 
Jukka Zitting commented on JCR-569:

> 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
> 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


View raw message