Different ways to handle suspected errors

[Lokorin]

Status: Included in version 1.4.0

The following quote is taken from a thread about gui changes.

[Lokorin]

The "Ignore" options should probably be named "Hide" as they can be reshown by clicking the "Display all" button ("Show all" is probably a better name).

[Lokorin]

A thing that I didn't think about before trying to implement this: How are input such as the new member name going to reach the error when correcting it?

This is how I have currently implemented it:
First an interface ErrorCorrection which exposes two methods, one for getting a description of the correction and another which corrects an error supplied as parameter. The corrections are then hidden in each error type as an enumeration implementing the interface.

The GUI gains access to the corrections by SuspectedError (supertype of all errors) exposing a method that gives a list of the corrections that can be applied. This way the GUI never has to care about the type of error. The data used when correcting the errors are (like before) given upon construction of the error, hence no parameters are needed when fixing the error.

So the problem is how the new name should be delivered to the instance of ErrorCorrection when the error is to be fixed. The GUI has to know when it should ask for input and when it should not, so the correction will have to give that kind of information. The question then becomes how to do that in a clean way. A few ways from the top of my head:

* Add an additional method to the error correction that gives some kind of structured data describing what kind of input it wants (e.g. a request for a String with the description "Member name") which the GUI collects from the user (no member list selection) and then passes as an additional parameter to the error correction instance (as e.g. an list of objects).
* Add some special flags to the correction, e.g. one basically telling the GUI "I want a member name when I correct something". That would allow a fancy member list selection but would become ugly when other inputs are needed (i.e. future errors types or new ways to correct the old ones).
* Do not allow corrections that require input, hence skip all the "rename x" corrections.

Personally I'm currently leaning towards skipping the ones that require input, but that depends on how important they are (which I don't know). Hopefully there are better ideas out there.

[impishfae]

Hmmm... You could have one GUI handler for each error type, which knew how to perform ALL the corrections possible for that error. (whether add/remove/rename/etc) So there's just a couple of buttons on the main suspected error pane: "Fix" and "Hide" and "Show all".

The "Fix" button invokes the appropriate GUI for each error type, which pops up with specialised knowledge on the set of operations you could perform to correct an error, what kind and format of input is required, etc.

[Lokorin]

Thats a possibility, but I'm not too fond of having to write the actual logic into the GUI or having it depend on all different subclasses instead of just the superclass.

If the renaming options are important then I will probably go with a variation of the first option and have the ErrorCorrection interface provide a method named "requiredInput" that gives a map that maps description strings to classes. The correctError method would then require the same map to be given as input, but with instances of the classes rather than the classes themselves. This would allow the GUI to obtain the input in any way it likes (if it sees that "Member" is one of the classes then it could launch a member selection dialog if it wants) without adding any additional dependencies (but adding a bit of additional work).

So it would go something like this:
1. An error is selected, the GUI requests all error corrections available from the error and lists their descriptions.
2. A correction is selected and requested by the user, the GUI looks up the correction (instance of ErrorCorrection) and requests the required input. If it's a rename corrections then it might recieve something such as the following map {"New member name"=Class<com.lokorin.dkplp.Member>}.
3. The GUI searches through the map, matching the class names with classes that it knows how to request from the user (Member might be one, String could be another, an Object fallback is probably required). The GUI then requests the input from the user and enters it into a map as {"New member name"=[Member instance]}.
4. The GUI sends the error and input (may be empty if none was requested) to the error correction through correctError(error, map).
5. The error correction ensures that all the requested input was provided and extracts it from the map.
6. The error correction performs the correction.
7. The error is marked as corrected and all observers are notified,

[impishfae]

Fair call!

There's probably even frameworks floating around out there, that know how to map basic data types into a graphical representation, so that you 'just' need to hold a place open in the panel for them. (Certainly some web-app frameworks seem to do this automagically. Don't know if swt has any)

[impishfae]

For the 'notamember' error, can we also have an option to add an alias mapping (as well as adding to the member list). People are beginning to regularly bring their alts along to the raids, and our alias mapping file is growing!

(Which brings me to a related question: if you've added an alias mapping, do you then need to re-parse the file to activate the mapping on the data, or does it happen when you create the alias mapping? The suspected error doesn't go away until you force a re-parse of the file, but I wasn't sure if that was just a refresh glitch)

[Lokorin]

[impishfae]

When you correct an error, is there any way the system can check the rest of the suspected errors and remove duplicates?

If I have 6 intervals, with an unknown member in all of them, I get six errors saying Player X is not a member during interval nn:nn to mm:mm

Select the first one, add to member list, correct.
This should really clear up the rest of the not-a-member errors for player X.

Viewing the member list seems to make the error pane wake up and clear out the duplicates at least... ?

[Lokorin]