The next steps are using streaming API also for the nested Grantlee
invocations and replacing DefaultRendererPrivate* in the render plugin
API.
Details
Details
- Reviewers
knauss - Commits
- R94:00232c2d52df: Port internal render plugins to HtmlWriter
Diff Detail
Diff Detail
- Repository
- R94 PIM: Message Library
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
| messageviewer/src/messagepartthemes/default/defaultrenderer.cpp | ||
|---|---|---|
| 868 | we need a loop here to get all plugins. the registry.at(0) was just a shortcut to test my idea ( but its outofscope here). But here the streaming api has a big disadvantage, because you need to trust, that the plugin don't write anything to htmlWriter if it don't handle the MessagePart otherwise things get messed up in htmlWriter. Or can you somehow seek the output again, when a plugin don't handle the part aka return false? | |
| messageviewer/src/messagepartthemes/default/plugins/textmessagepartrenderer.cpp | ||
| 44–49 | can be deleted. | |
| 75 | we have drp that has already the method drp->alignText() | |
| messageviewer/src/messagepartthemes/default/defaultrenderer.cpp | ||
|---|---|---|
| 868 | The loop is coming in the patch adding proper plugin handling (still WIP). Rewinding the stream to a defined restore point is possible if we need that, similar to what QIODevice::start/commit/rollbackTransaction do for the read direction. | |
| messageviewer/src/messagepartthemes/default/plugins/textmessagepartrenderer.cpp | ||
| 44–49 | done in the DRP removal patch | |
| 75 | Addressed in the subsequent patch removing drp. | |
| messageviewer/src/messagepartthemes/default/defaultrenderer.cpp | ||
|---|---|---|
| 868 | I think rewinding the stream is really nessary, so that we have the control over what ends up in the stream. in future we may be not have control who is writing plugins and i think a bad plugin should not fuckup the whole rendering. | |
| messageviewer/src/messagepartthemes/default/plugins/textmessagepartrenderer.cpp | ||
| 44–49 | nope not for TextMessagePartRenderer. | |
| messageviewer/src/messagepartthemes/default/defaultrenderer.cpp | ||
|---|---|---|
| 868 | Sure, we can do that whenever the problem arises. The old plugin interface was affected by the same issue, didn't seem to be a problem so far. | |