WebLearn/CopyUI/Design

New Design & Implementation

This page is intended to capture ideas regarding improvements to the current design and implementation.

(CT: We need to keep in mind that we have very limited time to spend on this -- probably finishing within the first week of November. The initial idea was to incorporate the SPWS work that was useful, and to look at extending it with the templating concept introduced in ../RelatedIdeas. Refactoring will be worthwhile if it means future work or maintenance will be made a lot easier, with the trade-off that it introduces more work when it comes to merging with the Bod code, especially for UHI. We need to ensure that the work is broken up into tasks that add some usefulness, to ensure that we have something other than code cleaning-up to show after a few weeks work.)

Refactorings

Changes

• the factoring of copy (and bring) methods needs to be improved. These are very long methods (without comments) which are incredibly hard to follow (and thus modify). They need to be broken down into smaller, more easily understood methods. (CT: Incredibly hard to follow?? I agree that there is duplicated code in the copy and bring methods, and that that should be consolidated into common methods.)

• copying is primarily handled by Facility (and it's subclasses). Facility is supposed to represent the web-interface. Therefore it could be BuildingSession and it's subclasses instead? (CT: I don't think it's worth the upheaval. I also think work like this should be undertaken as a separate excercise with the community as a whole, when Weblearn code is closer to Bod.)

  • There are effectively 2 types of session; SingleResourceSession and ReusableResourceSession. The distinction being that the latter can be bound to different resources over time. A CopySession could be a ReusableResourceSession, as it would be associated with source and destination resources.

• many methods concerned with copying in the Facility class hierarchy are private. As they are effectively doing the same thing they could be protected instead, so as to emphasize their commonality and ease understanding. In other words, if this appropriate, this would emphasize that a method in a sub-class is in fact overriding the behaviour of the superclass and common behaviour can just reside in the superclass. (CT: Agreed, that's an easy fix.)

• certain behaviour could be delegated to the resource classes themselves. For instance, they could have public clone() methods and / or copy constructors. (CT: That would be good, but not required in the short-term.)

Removals

• discard the notion of a best practice area.

• discard the distinction of peer-to-peer and adopter copying (effectively just have the latter).

Additions

• store all the variables concerned with copying in a single object maintained within the HttpSession instance.

• enable bring to follow the same UI-driven approach as copy.

• relating to the point above, factor out the commonality between bring and copy.