logseq / logseq/db-test-cn

用namespace实现卡片式笔记系统的建议

Open
#9 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
No language data
Stars
4
Forks
0
PR merge metrics
No merged PRs in 30d

Description

Search first
  • I searched and no similar issues were found
What Happened?

在卢曼的一生中,他积累了9万多张像明信片大小的知识卡片,并把它们都分门别类地放进对应的盒子里面,通过逐层有序分级的方式持续整理,相当于建立了一个大的个人知识图书馆,支持了他传奇性的学术创作历程。

这是我们都熟悉的卡片式笔记方式。在DB上如何实现以上的卡片系统呢?有没有方便简洁的方法呢?

建立一个卡片 class
#卡片 它的property如下:
来源:: 某页面 某书某章节 等
性质:: 原文摘要,自己的观点,实证,提问等等
重要性::
关联:: 可能关联的其他卡片
分类:: 领域A/数学B/代数几何C/基础知识D/关于XXX的问题E 或者是领域A/数学B/代数几何C/未分类 或者是领域A/未分类 等等。
这里有一个方便的层级下拉菜单以供选择。
当进行过滤筛选的时候,过滤D,可以得到所有代数几何基础知识D相关的卡片。同样,过滤C,可以得到所有代数几何的相关卡片。这就是我理解的层级关系。
另外,可以筛选出所有未分类卡片来进行整理。
分类这里是多选项。

卡片有了,怎样拥有一个分类的盒子呢?

这个盒子,可能长得像页面,是一个大纲样式的东西。其中的节点:

1,可以由前面的分类自动建立,就像以前的namespace。
2,也可以直接建立,就像写一个大纲页面一样。这里的节点可以进行编辑和拖动(以前的namespace不能直接编辑和拖动)。
3,每一个分类下可以自动显示有多少卡片在其中。类似于一个块引用。但是它有层级的关系。上一层的卡片数目是下面层级所有卡片的总和。
4,每一个分类下的卡片也可以编辑,复制和拖动。当复制或拖动时,卡片的property自动发生相应的改变。
5,每一个分类也属于 某个class(希望能统一设置,不希望手动的每一个分类去建立),这样,除了大纲view也可以有和其他class同样的列表view。

对于用户来讲,这是最直观最简单容易理解且方便使用的卡片系统了。

Reproduce the Bug

Expected Behavior

No response

Screenshots

No response

Browser, Desktop or Mobile Platform Information

No response

Additional Context

No response

Are you willing to submit a PR? If you know how to fix the bug.
  • I'm willing to submit a PR (Thank you!)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names the existing namespace concept but provides no files, tests, or concrete entry point to inspect. First clarify the card properties, hierarchical filtering, editable outline, counts, and drag/copy behavior; completion would require agreed acceptance criteria for these requested features.

Written by the indexing model from the issue text.

Assessment

Domain
content
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.