1

I am using the basic instructions (here) for creating a property driven by a custom ToolPart.

All is good, except for the part where, in order to access the webpart property within the ApplyChanges method I must cast the "this.ParentToolPane.SelectedWebPart" back to a concrete "SimpleWebPart" class. 

public override void ApplyChanges()
{
    SimpleWebPart wp1 = (SimpleWebPart)this.ParentToolPane.SelectedWebPart;

// Send the custom text to the Web Part.
    wp1.Text = Page.Request.Form[inputname];
}

Doing this means that I must pair each toolpart with a specific webpart. Is there a better way? I cannot create an interface as there is no way of specifying a property in one.

I ineptly tried an passing an event/eventhandler during toolpart creation, but that did not update the webpart property when called.

I could create a base class for all the webparts that have a public "Text" property, but that is fugly.

I could also get desperate and crack open the this.ParentToolPane.SelectedWebPart reference with Reflection and call any properties named "Text" that way.

Either way, I am staring down the barrel of a fair bit of faffing around only to find out each option is a dead end.

Has anyone done this and can recommend the correct method for creating a reusable toolpart?

Nat
  • 14,175
  • 5
  • 41
  • 64
  • Whats the problem with a base webpart/toolpart and inheriting/overriding as necessary? – Ryan Nov 29 '11 at 08:25
  • nothing until I need to run several different combinations of properties against several different toolparts. – Nat Nov 29 '11 at 20:06
  • Thats true - but perhaps you can get 80% of the usual, related properties like this? Depends on your exact use case. Have to say, no offence, but I fear you may be getting a case of Architect Astraunatis ;) (over abstraction) - http://www.joelonsoftware.com/items/2008/05/01.html – Ryan Nov 30 '11 at 08:13
  • I doubt trying to applying the Dependency inversion prinicpal is taking things to far. – Nat Dec 01 '11 at 20:03
  • Well my Q would be - how much time have you spent researching this & how much time would it have taken just to do do it the 'easy' way? I have no idea how complex your toolparts are and how many different versions there will be so no point in getting into a debate - it was just my uninformed 'gut' feeling. Such a lofty rebuttal does strengthen it though ;) – Ryan Dec 02 '11 at 08:49
  • 1
    Fair enough. My gut feeling was that this is a problem I am going to have enough of that putting some effort into a solid solution was going to pay off in the long term. – Nat Dec 04 '11 at 20:46

1 Answers1

0

I have used an interface instead of a specific instance of a webpart.

private class IMyProperty
{
    void SetMyProperty(string value);
}

public override void ApplyChanges()
{
    IMyProperty wp1 = (IMyProperty)this.ParentToolPane.SelectedWebPart;

    // Send the custom text to the Web Part.
    wp1.SetMyProperty(Page.Request.Form[inputname]);
}

But this does not give a compile time warning that the toolpart requires the parent webpart to implement the IMyProperty interface.

The simple solution to that is to add a property of the IMyProperty interface in the toolpart constructor and call this reference instead of the this.ParentToolPane.SelectedWebPart property.

public ToolPart1(IContentUrl webPart)
{
    // Set default properties              
    this.Init += new EventHandler(ToolPart1_Init);
    parentWebPart = webPart;
}

public override void ApplyChanges()
{
    // Send the custom text to the Web Part.
    parentWebPart.SetMyProperty(Page.Request.Form[inputname]);
}

public override ToolPart[] GetToolParts()
{
    // This is the custom ToolPart.
    toolparts[2] = new ToolPart1(this);
    return toolparts;
}

This works fine, but I cannot get over the feeling that there is something nasty in the underlying SharePoint code that may trip me up later.

Nat
  • 14,175
  • 5
  • 41
  • 64