CWKB numbers not being deleted #273
Comments
|
This sounds like a problem with the editor to me. Is that your impression @rla2118 @jcowey @Edelweiss? I've added the "editor" label based on that assumption. |
|
In DCLP EpiDoc there is no specific xpath reserved for CWKB numbers (such as a TEI:idno). The representation of CWKB numbers within EpiDoc is a URL inside a @ref attribute: If you want to get rid of a CWKB number, you also have to remove the corresponding link. If you don’t remove the URL, the editor will (for your convenience) restore the CWKB number from the given URL the next time you call up that file for display in the editor mask. (The same goes for TLG, Stoa and PHI numbers)
We could change that behaviour so that the editor will delete any URL if there is an empty string in the corresponding number field. But beware: If we use this logic, the users will have to provide a CWKB number whenever they want to save a link to CWKB. If they only provide a link and leave the corresponding number field blank, the link will be deleted. Let’s call that alternative (I). Further alternatives could be: (II) Make the editor delete links automatically once the number in the corresponding text field is erased (and of course the other way around, i.e. when a link is deleted, the corrsponding number will disappear). Perhaps a message box could inform the users about the repercussions of their actions. This would be the client side version of alternative (I). (III) Hide the links (as suggested during one of our hands-on workshops here in Heidelberg). It’s actually very much like alternative (I), but the users won’t see that there are any links unless they view the xml. This might, however, make them think that they need to provide the links themselves. SoSOL can, of course, remove dupliactes, but the users might wonder why the data they enter is not being displayed in the editor mask. The entry field would look like this:
(IV) Get rid of the numbers at the top altogether to have the editor reflect the underlying xml as accurately as possible. It would look like this:
I would opt for alternatives (II) or (IV) or leave it as it is, as these are the alternatives with either the least suprise or the least chances of accidental data loss. |
|
I will ask the users here at the workshop in NYC today which approach they would prefer. |
|
Cool! |
|
Users here would prefer not to see the URLs at all. Further, they recommend an interface that would look like this:
|
|
@Edelweiss where should we look to test this? cc @jcowey |
|
per discussion with @jcowey @Edelweiss @m-k-r this morning, Heidelberg to provide links to committed code discussed above |
|
This can be tested on litpap.info. Testing was meant to ensure that the new interface didn’t break the underlying logic that is responsible for loading from and saving to EpiDoc. As this was lower priority the desiderata were not fully implemented. Yet to be done:
|
I listed only the relevant commits. There are also a few other commits that are related to the same editor component but are not part of the resolution of this issue. Regarding the commits mentioned above in an isolated container may cause some quirks, though, such as wrong captions for digital identifiers. |
|
The part of this ticket that concerns the new user interface lives on in #331 |
Residual CWKB numbers are not being deleted from the XML whenever an attempt is made to save a new number.
The text was updated successfully, but these errors were encountered: