Closed joekrill closed 5 months ago
This looks very nice, but you'll have to wait a bit until I merge it since I'm not near a laptop for the next week or so. Very excited about the tree plug!
Edit: scratch that. I'll have a closer look now and get this in. I really like to unblock you. Your tree looks great.
Edit: scratch that. I'll have a closer look now and get this in. I really like to unblock you. Your tree looks great.
Awesome, thanks!!
I've actually already got drag-and-drop working, but realized I can't release that version yet because it's not going to work correctly with anyone running an older version of SilverBullet (it will actually do some very unexpected and unwanted things!). I thought I could just check the version, and enable drag/drop if > 0.7.1, and disable it otherwise. But I actually don't think there's currently a way for a plug to get the current system version, unless I'm missing something? So I just threw up another #721 that adds a system.getVersion
syscall. Does that seem like the best way to deal with this sort of thing? Or is there a better way or some other functionality I'm missing?
I think that's a sensible approach for the future yes
Adds the ability to send additional arguments to
renamePageCommand
andrenamePrefixCommand
of theindex
plug, as well as returningtrue
orfalse
from each command to indicate whether the action was successful.The arguments are completely optional, and the existing behavior remains the default when the additional arguments aren't provided, so everything remains fully backward-compatible.
Why
I've created a tree view component/plug and one of the desired features is to allow dragging and dropping nodes to rename pages. That renaming functionality already exists via these two methods, but we need to be able to pass in some values that are currently hard-coded in those functions. We also need to know whether the operation succeeded or failed to determine if the tree should be updated, and - in some cases - whether the user should be redirected to the renamed page.
renamePageCommand
This command already allowed a
page
argument to be provided that specified the name to rename to. If this wasn't provided the user is prompted for a new name. The following additional arguments can now be passed:oldPage
- This is the page to be renamed from. Previous behavior always used the current page (editor.getCurrentPage()
), and this is still the case ifoldPage
is not provided. But in the case of the tree view, the user may be dragging page other than the current one.navigateThere
- Specifies whether, after the rename, the user should be navigated to the new page. Previously this was alwaystrue
, because it was always the current page being renamed, so it made sense to navigate to the updated page. This still defaults totrue
, but can be override to prevent that behavior. If the user drags a node from the tree view that isn't the current page, we don't want to redirect them to that page.renamePrefixCommand
This command is written in a way that always prompts the user for the prefixes to rename from and to, as well as showing a confirmation dialog before performing the rename. It did not have the ability to be given any arguments at all. This update allows the following arguments to be provided programmatically:
oldPrefix
- The prefix to rename fromnewPrefix
- The prefix to rename to.disableConfirmation
- When true, disables showing the confirmation prompt before renaming.