<table><tr><td style="">vkrause added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D8071" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>But that would tie processing and rendering always together to the same plugin, wouldn't it? In which case the entire exercise of splitting this up becomes kinda pointless, we could just render with the same plugin that managed to succeed in processing.</p>

<p>Also, look at it from the plugin developer POV: In this scenario I need to implement process() to decide if I want to deal with it (fair enough), implement my own sub-class of TextMessagePart or AttachmentMessagePart (without any extra data, everything I need is already there, so that's just busy work), fill it with the same logic that TextPlainBodyPartFormatter has presumably (that's highly error prone, that code deals with sign/encrypt state for example), and then I eventually get that passed to my render() method that actually does what my plugin wants to do.<br />
As most plugins are purely dealing with rendering, I think this deserves a more convenient API. Ie. leave processing to things like crypto that actually manipulates the hierarchy, and to do things like determining what's the main body text etc, and allow rendering to work on top of that result.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R94 PIM: Message Library</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D8071" rel="noreferrer">https://phabricator.kde.org/D8071</a></div></div><br /><div><strong>To: </strong>vkrause, knauss<br /><strong>Cc: </strong>KDE PIM, dvasin, winterz, vkrause, mlaurent, knauss, dvratil<br /></div>