[获取目录的API] 请求获取目录的API返回的数据中catalogueType的值的问题

ddwolf715 commented 1 year ago

Search before asking

[x] I had searched in the issues and found no similar question.
[X] I had searched my question on the internet but i didn't get any help.
[X] I had read the documentation: Taier doc but it didn't help me.

Description

版本：1.4.0 接口： /batchCatalogue/getCatalogue 描述：获取目录（获取当前目录和下一级目录）调试工具：Apifox

请求这个接口时，发现如下的问题，不知道是本身接口就是这样，还是这个接口存在如下的问题。 请求1： 参数设置为 "nodePid": 0 时，返回的结果没有问题，返回数据的 catalogueType 都显示正确，如下图

请求2： 参数设置为其他中的某一级，例如 "nodePid": 47 时，catalogueType 都变null，导致分不清目录是什么类型的，如下图

Code of Conduct

[X] I agree to follow this project's Code of Conduct

ddwolf715 commented 1 year ago

自己顶一顶贴。。。。路过的大神留步解惑。

mortalYoung commented 1 year ago

我从前端的角度解答一下吧

首先 nodePid 为 0 的时候表示获取根目录，前端获取到根目录后，根据 catalogueType 对目录进行区分。
而后的其他所有请求，前端都暂时用不到 catalogueType 了。因为目前前端的逻辑是根据请求的 id 去获取到目录树，然后再把获取到的目录树根据 id 插入到现在有目录树中去。

前端相关的逻辑详见：taier-ui/catalogueService

ddwolf715 commented 1 year ago

我从前端的角度解答一下吧

首先 nodePid 为 0 的时候表示获取根目录，前端获取到根目录后，根据 catalogueType 对目录进行区分。

而后的其他所有请求，前端都暂时用不到 catalogueType 了。因为目前前端的逻辑是根据请求的 id 去获取到目录树，然后再把获取到的目录树根据 id 插入到现在有目录树中去。

前端相关的逻辑详见：taier-ui/catalogueService保存和观看

您的解答明白。也就是原接口中的catalogueType的值可能不适用我需要实现的功能。

我简单说一下我要实现的：我是在另外一个web 应用里，想通过调用taier开放出来的接口简单集成taier，其中有个功能的需求是要得到某个开发目录的完整路径，但这个路径我只需要到“任务开发”这里就可以了。所以，我就写了一个递归程序，一层一层向上取得目录名称，然后通过判断 catalogueType 的值是TaskManager，并且获取得下级就可以了，就构造出我需要的完整路径了。

结果发现了贴中的问题，不能使用 catalogueType 的值判断有没有达到我需要层次。

发现这个问题后，我改了一下思想： 1.用 nodePid = 0 请求此接口，通过判断 catalogueType的值是TaskManager，然后取这个层级的下一级的目录ID，即“任务开发”，比如取到的ID值是48，将这个值保存到数据库或其他地方。 2.再用我的递归程序找目录的所有上一级拼接路径，递归到id为48时，结束递归，返回完整路径。

不知道我这么实现是不是比较合理呢？会不会有其他我没有考虑到的情况。

mortalYoung commented 1 year ago

你可能需要考虑 Folder 和任务 ID 相同的情况，例如 ID 同样是 48，你需要区分是任务还是文件夹。另外，如果按照你的做法来看的，我理解可能代码的健壮性比较一般，需要做很多的边缘情况的校验来防止代码崩溃，或者查找不到，或者无限递归等情况的出现。我更加推荐的做法是把这个功能做到服务端去，让前端通过接口来获取相印的功能。

BTW：不排除后续迭代里会实现你这个功能，因为有打算去实现一个「 command pallette 来支持快速查找任务并打开」，这个需求的实现大概率会用到类似于你的这个接口所实现的功能

ddwolf715 commented 1 year ago

你可能需要考虑 Folder 和任务 ID 相同的情况，例如 ID 同样是 48，你需要区分是任务还是文件夹。另外，如果按照你的做法来看的，我理解可能代码的健壮性比较一般，需要做很多的边缘情况的校验来防止代码崩溃，或者查找不到，或者无限递归等情况的出现。我更加推荐的做法是把这个功能做到服务端去，让前端通过接口来获取相印的功能。

BTW：不排除后续迭代里会实现你这个功能，因为有打算去实现一个「 command pallette 来支持快速查找任务并打开」，这个需求的实现大概率会用到类似于你的这个接口所实现的功能

是在服务端做的开发，并且也只限制为是Folder的ID。以目前的版本，我可能先暂时这么实现了。如果之后接口升级了，再改用升级的接口。

感谢！！

mortalYoung commented 1 year ago

如果可以的话，你也可以贡献一个这个方法出来，我这边可以在开发一个上面提到的功能

ddwolf715 commented 1 year ago

ok.

DTStack / Taier