= 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''.