android H5可视化编辑

转载

cnolnic 2024-07-07 09:46:31

文章标签 android H5可视化编辑 javascript ckeditor HTML sed 文章分类 Android 移动开发

最近因为项目有用到编辑器的需求，经过考量过后选择了ckeditor5。

ckeditor5功能强大，UI也比简介美观。

Rich text editor of tomorrow, available today.

ckeditor5名副其实，将代码块插入编辑器的功能备受好评！

android H5可视化编辑_ckeditor

其他的功能，风格都算的上市应有尽有，满足基本所有的主流编辑器使用需求！在线自定义构建ckeditor5，一键生成代码的功能也大大降低了开发门槛。

“美中不足”的是ckeditor5没有源代码编辑模式！

有些非ckeditor5编写的文章需要用到ckeditor5来编辑，偶尔就会遇到一些空标签在可视化的操作界面不方便处理的时候（如下图），就想用源代码模式去处理空标签。

android H5可视化编辑_HTML_02

这种功能在以前的编辑器里也算非常常见的，kindEditor、Ueditor实现源代码模式也就加一个配置项的操作。但是在ckeditor5怎么也找不到，猜测是不是ckeditor5面世不久，生态插件还不太完善。就怀着这种疑问四处找为什么ckeditor5至今还没有源代码模式的答案。最后在ckeditor5的issues里找到了答案：

CKEditor 5 implements a custom data model. In order to load data to this model you need to have view -> model converters for each piece of the content that you want your editor to support. Then, you need model -> view converters in order to make this content editable (it needs to be rendered in the editor for editing). Finally, you need to configure the schema and sometimes customize certain features like Enter so they know the meaning of this content that you loaded into the editor and how to modify it. In other words, because of the data model a feature needs to implement the full life-cycle of a specific piece of content (tag, attribute, etc.) which it handles – from data loading, through rendering for editing, editing itself and data retrieval.
In your case, if what you edit are links but with a different markup, I'd recommend forking the @ckeditor/ckeditor5-link package. You can find there the mentioned converters. You can modify them to fit your use case and if you'll keep the rest of the code you'll have the whole UI and the rest of the logic.
As for the 'where we want to bring the editor out of the "HTML Editor" thing' comment: Why? CKEditor is a WYSIWYG HTML editor. Nothing more, nothing less.
This is how many developers perceive it and we are aware of that. But that's not true.
Let's state this clearly – CKEditor is not an HTML editor. It is a content editor and HTML is just one of the possible outputs.
Most of the use cases that you mentioned were related to manually adjusting the output and adding custom markup. Yes, this is possible in CKEditor 4. But CKEditor 4 is not meant to be used this way. When hacking the output you risk that the next time this content will be loaded into CKEditor 4 something will break.
Why? One of the reasons is that CKEditor 4 needs to understand the content. When content is being edited in the WYSIWY* mode the editor needs to apply many complex transformations to it. Those algorithm needs to make decisions based on the content that you're editing. So if you put into the editor content which it wouldn't generate itself, you risk that this content will not be understood and will be somehow broken.
This is, IMO, one of the most frequent reasons why developers dislike WYSIWY* editors – it's because they are abusing them.
CKEditor 5
So far I've been talking about CKEditor 4. How's CKEditor 5 different?
CKEditor 4 uses the DOM as a model. When loading data, the HTML is processed (read – filtered, normalized and escaped) but it ends up in the DOM anyway.
CKEditor 5 has a custom data model. When you load HTML into the editor, it's parsed and then features (initialized previously in the editor) try to pick up from this HTML the pieces they understand. This is called "conversion". As a result of a conversion, the content is being loaded into the custom data structure. The reverse process is executed when content needs to be rendered back to the DOM (either for editing or for data retrieval).
This means that if you don't have a feature which handles a certain HTML tag/attribute/style/whatever then the editor will automatically drop it.
This is how all modern rich-text editors work. Nothing special here (well, except the fact that we support OT ;P)
Source mode
So, I think that the discussion above missed the point. Why doesn't source mode make sense for CKEditor 5? It's because you will lose all changes done in the source mode unless they are compatible with what the initialized features understand. But in this case, you'd be able to just apply these changes in the WYSIWYM mode.
Solutions?
Don't use CKEditor as a page builder (aka HTML editor). Use it exclusively for content editing. Write features for custom stuff that you want it to handle. Build a proper app for page building (if you need it) and use CKEditor as a part of it.
That's the direction which we were empowering in CKEditor 4 by the introduction of features such as Allowed Content Filter and widgets. And CKEditor 5 just made a couple of steps further.
PS
It should be possible to implement a "wildcard" feature in CKEditor 5 (I guess we'd call it "AllowedContentTrue" ;P), but just... don't. Don't do it cause loading data is one thing, but then all the features still need to understand that content for editing.