Weblog posting interface, cont’d

Some good feedback. Simon suggests deriving from the existing IBlogThis – sounds fine to me, especially since there seem to be a fair amount of IBlogThis implementations out there already.

Matt confirms the need for this extra functionality…glad to know I’m not the only one who thinks we need this. :-)

Douglas asks why we don’t just use attributes for the extra information. A good thought; however, I think there is then an additional, implicit contract. I might get the name of a type that implements the configuration GUI, but what do I do with it then? There are implicit assumptions if we go this way; I’d much rather have an interface method, and let the implementor decide how it should work.

I also forgot a couple of things. First, we need to pass a parent to the Configure function, so the implementation can use it to parent any dialogs if necessary. And we need a way to get the display name of the plug-in, to be shown to the user in a list of plug-ins (which could be an attribute, but I’ve left it as a property for the moment). So my new proposed version:

public interface IBlogThisEx : IBlogThis
{
 // Name of plug-in, suitable for display to a user
 string DisplayName;
 
 // Display configuration dialog to user, if applicable
 void Configure(IWin32Window parent);
 // Return true if an editing GUI will be shown to the
 // user when BlogItem is called. In this case, the
 // aggregator will not display its own editing UI.
 bool HasEditingGUI();
}

Keep the comments coming!

15 Comments

15 thoughts on “Weblog posting interface, cont’d”

  2. Kevin Dente

    Douglas’ suggestion of separate UI configuration component does have an additional benefit – it would allow the configuration UI to be hosted inside of your configuration dialog; on a separate tab, for example. There’s nothing that says that these approaches are mutually exclusive – you could offer the attribute option for plug-ins that want a deeper integration, and use the Configure approach for those plug-ins that prefer the simpler approach of just popping up their own dialog.

    Reply ↓
  6. Plato

    A quick check shows:

    In mono, there’s ShowDialog() but ShowDialog(System.Windows.Forms.IWin32Window) isn’t yet implemented (probably because IWin32Window isn’t yet defined).

    dotGNU doesn’t appear to have a UI library, but most UI development appears to be using Qt# and from the API docs it looks like they’d use a Qt.QWidget.

    Perhaps the answer is to have both Configure() and Configure(IWin32Window parent).

    Would Configure(object parent) work?

    Reply ↓
  8. Plato

    True, but … you could cast an object to be whatever window type you needed (in Qt# the equiv to control is a widget). Control does look like it should be OK in mono though.

    Reply ↓
  10. BlogThis extension

    Greg and Simon are talking about an extension to BlogThis. I agree that BlogThis as-is is fairly limited and could definitely use some improvements. For instance, I had been considering writing a w.bloggar plugin but quickly realized that it needed a configuration setting (the install directory of w.bloggar). Unfortunately, IBlogThis does not provide any hooks for configuration of the…[more]

    Reply ↓

Leave a Reply