A short while ago I wanted to convert my ajax tagger in to a Windows Live Writer Plugin.
After some silly mistakes creating sample plugins I started to learn how the API works and some the short falls of the current API.
The main thing I noticed was that you cannot access the text of the post inside your plugin. You cannot access the selected text either.
I pinged off an email to the Window Live Writer Forum
I am in the process of playing with the SmartContentSource class for creating a plugin. But I am having some problems.
I am debugging my plugin, to see the state of certain objects such as the SmartContent Objects. My Plugin creates a side bar and manipulates the SmartContent Object, all fine and well.
The problem that I am having is that I can determine what text is in the blog post at the moment. The SmartContent object doesn't have anything, and the object represented by the ISmartContentEditorSite interface doesn't have the whole text or selected text.
Does anybody know how to get at this text, because as I see it, if plugins can't see the blog post then there is only a small finite amount of plugins that we as developers can create.
And this was the response that I got from Joe Cheng at Microsoft.
Right now, the plugin model is just about inserting objects. Can you share what your idea for a plugin is?
It's not as simple as saying "whole text" or "selected text", blog posts are composed of a pretty rich set of objects from MSHTML and from our own framework. If we can understand your specific scenario it would help us figure out the right way to design these interfaces.
Which is straight to the point. I have let them know of the ideas of the things that I wanted to do.
I would also suggest that if you have any other ideas for plugin for Windows Live Writer that you cannot create in the current implementation of the API, then let them know as quick as you can so that we can get a big bit of ground support so that are requests will be taken notice of.
I belive we need access to the text of the plugin because without it we will be very limited to the number and types of plugins that we can create.
For instance we would not be able to mark up posts with microformats as easily. We will not be able to respond to the content and meaning of the post, so for instance we would not be able to create an automated tagger that simply looks at the content of a post and works out the topics (much like my Ajax Tagger http://ajaxtag.kinlan.co.uk/).
About Me: Paul Kinlan
I lead the Chrome Developer Relations team at Google.
We want people to have the best experience possible on the web without having to install a native app or produce content in a walled garden.
Our team tries to make it easier for developers to build on the web by supporting every Chrome release, creating great content to support developers on web.dev, contributing to MDN, helping to improve browser compatibility, and some of the best developer tools like Lighthouse, Workbox, Squoosh to name just a few.