27 lines
1.6 KiB
Markdown
27 lines
1.6 KiB
Markdown
|
# Phase 7
|
||
|
|
|
||
|
|
Supporting single-file (as opposed to folder) drawers has introduced a bug, which will require some refactoring to fix.
|
||
|
|
The basic problem is a confusion over where to open a single-file drawer to, the filename specified in the target path
|
||
|
|
(including the default name rules on that) or the filename in the tarball.
|
||
|
|
|
||
|
|
The desired behavior is that if a target path is specified, it should be what's validated and used. If a target path is
|
||
|
|
not specified, the default should be:
|
||
|
|
|
||
|
|
- For a single-file drawer, the filename of the single file in the drawer
|
||
|
|
- For a folder drawer, a folder named after the drawer file (without extension)
|
||
|
|
|
||
|
|
In order to make this work, we'll need to refactor to move some of the validation into perform_open, since we can't
|
||
|
|
check whether the target path is valid (or even know what it is) until we first load and decrypt the drawer.
|
||
|
|
|
||
|
|
Let's do the following:
|
||
|
|
|
||
|
|
- `target_path` now needs to be an `Option<PathBuf>` and we can get rid of `target_inferred` because `target_path` being
|
||
|
|
None means the same thing.
|
||
|
|
- Let's make a `default_target` method which returns what the default target would be for a given DrawerOperation, to
|
||
|
|
encapsulate these default rules (and put a nice comment above it explaining the rules).
|
||
|
|
- `validate_open` should no longer attempt to validate the target path.
|
||
|
|
- `perform_open` now needs to figure out a target path using the new `default_target` method (or `target_path` if present)
|
||
|
|
and can do the validation there.
|
||
|
|
|
||
|
|
As an aside, is there any duplicated logic between `validate_open` and `validate_close` as far as checking the drawer file
|
||
|
|
path? Can any of that be extracted into a method?
|