Open CanePlayz opened 1 year ago
The issue is that, within the current framework, we only know about the given channel's parent. So for a channel – it's the category, and for a thread – it's the parent channel.
We could try to add a new token that evaluates to the full path (what to name it?), but we would have to pull that information early and embed it within the Channel
object.
Nevermind, we should be able to evaluate the full path as is. I still think we need a new token for this, but I'm not sure. Thoughts?
I can propose the following solution: %r
/%R
token that evaluates to the root parent's id/name. In case with a channel, it would be the category, and in case with a thread, it would be the parent channel. Would that work? @CanePlayz
I can propose the following solution:
%r
/%R
token that evaluates to the root parent's id/name. In case with a channel, it would be the category, and in case with a thread, it would be the parent channel. Would that work? @CanePlayz
Isn't that what – according to my example above – %T
already does currently? It returns the category as the parent of the channel and the parent channel as the parent of the thread...
What we'd essentially really want there is to be able to access the category when exporting a thread instead of only accessing its parent channel, so that a structure like this could be achieved:
Server name
|
|-- Category name 1
| |
| |-- Channel name 1
| |-- Channel name 2
| |-- Threads of Channel name 1
| | |-- Thread of channel 1
Isn't that what – according to my example above –
%T
already does currently? It returns the category as the parent of the channel and the parent channel as the parent of the thread...
Sorry, you're right. I mistyped. In case of a thread it would also be the category.
What we'd essentially really want there is to be able to access the category when exporting a thread instead of only accessing its parent channel, so that a structure like this could be achieved:
I'm a bit wary about making assumptions anymore, after Discord added threads. In this case, it's better to expect that channels might eventually have deeper hierarchy than 1 or 2 levels, or that there might be channels that are completely outside of categories.
One thing we can expose is the hierarchical name of the channel/thread as one token -- i.e. %H
⇒ Category - Channel - Thread
. But then the delimiter would have to be baked in.
The issue with the root parent token proposal is that for channels both %R
and %T
would be the same, so you'd have to use different templates regardless.
Sorry, you're right. I mistyped. In case of a thread it would also be the category.
Interesting. I like the general idea of that as it would behave differently for channels and threads and therefore only require one path argument. However, it would limit the folder and file names to just being the plain category/channel name without extra modifications.
One thing we can expose is the hierarchical name of the channel/thread as one token -- i.e. %H ⇒ Category - Channel - Thread. But then the delimiter would have to be baked in.
Yeah, same concern as the one above.
The issue with the root parent token proposal is that for channels both %R and %T would be the same, so you'd have to use different templates regardless.
Yeah, the solution with two added tokens would require separate arguments for channel and thread paths, so while it might look elegant at first, it might not be that easy to implement.
There is an another option - let user export only threads without channel. Then the user can run two commands - first one to export channels, second one to export threads - for each command the user can pass different path (achieving option 1)
There is an another option - let user export only threads without channel. Then the user can run two commands - first one to export channels, second one to export threads - for each command the user can pass different path (achieving option 1)
This is already the case. I'm assuming @CanePlayz's issue is when you export multiple types of channels at once.
- For threads, evaluate the same term for the parent channel and put the threads inside whatever folder their parent channel is in.
This could work, but it might be confusing that the supplied path is actually for the parent channel (which may or may not be exported at the same time), and that the actual path will be somewhat different.
- For threads, evaluate the same term for the parent channel and put the threads inside whatever folder their parent channel is in.
This could work, but it might be confusing that the supplied path is actually for the parent channel (which may or may not be exported at the same time), and that the actual path will be somewhat different.
Yup, that would be confusing and also limit the possible paths quite hard.
Version
v2.40.4
Flavor
GUI (Graphical User Interface), CLI (Command-Line Interface)
Platform
Any
Export format
No response
Steps to reproduce
Export threads and use template tokens in the path
Details
Path parameters need to be rethought with threads because DCE uses the same given path for both channels and threads. That messes with threads. Let's look at the following example:
\\%G\\%P – %T\\%p – %C.html
It essentially means:
Server\\Category\\Channel.html
This should result in the following structure:
If I export a channel, the term gets evaluated properly.
However, if I export a thread, the term doesn't get evaluated properly. Here's why:
%P – %T
will evaluate to the parent channel, because that is "the thread's category", instead of using the server-level category.Ultimately, this means that you will end up with something like this:
Possible solutions would be:
The first option would be more flexible, and clearer to the user. However, we'd need two more parameters: one for the name of a parent channel and one for a thread's name.
Checklist