1 Reply Latest reply on Sep 17, 2009 6:10 PM by pkaiser

    RT WebParts RoadMap and the evntual migration to ASP.NET web part base class?


      Hi guys


      In other posts I ask questions pertaining to SharePoint web part base class and its connection mechanisms, we all know the connections IRowProvider, and IParametersOutProvider that work with RT webparts are now obsolete. So my question is does OSI’s have a plan and time frame for migrating to the ASP.NET web part base class?


      If not what would be the alternate technology they would be pursuing?



        • Re: RT WebParts RoadMap and the evntual migration to ASP.NET web part base class?

          Though older connection interfaces such as IRowProvider have been marked obsolete, the SharePoint web part base class has not. In addition, using the older SharePoint web part base class does not preclude us from taking advantage of newer connection interfaces, such as the support for ITransformableFilterValues that we introduced in RtWebParts version 2.1. So the base classes and connection interfaces are related, but not inescapably tied to one another.


          When RtWebParts was first introduced, there was a SharePoint web part base class from which we derived to create SharePoint web parts. Later, Microsoft introduced a second base class in ASP.NET, that allowed you to create web parts for SharePoint that could also reside outside of SharePoint. We would like to transition to the new ASP.NET web part base class, but there are still good reasons for not doing so. One of the main reasons why we haven't already done so is that the ASP.NET web part base class does not support client-side connections. Changing base classes also poses versioning challenges. For an explanation from Microsoft on the differences between these two base classes, see this MSDN article: http://msdn.microsoft.com/en-us/library/ms415560.aspx. In particular, note the last section that includes rules that help you choose between these two base classes.


          Assuming that we can overcome the versioning challenges, the lack of support for client-side connections in the ASP.NET web part base class is still quite troubling; client-side connections is a very popular feature with our customers. If we were to implement it ourselves, we might not be able to continue to have client-side connections with existing web parts that support them, and any web parts that could take advantage of them would have to be written to work with our custom client-side connections implementation. Ideally, this functionality would be added to the ASP.NET web part base class. We do not yet have a roadmap from Microsoft on the future of this functionality, so at this time we have a desire to move to the ASP.NET web part base class, but it poses significant technical challenges, and we do not yet have a timeline for doing so. We are not considering any other technology.


          With regard to connection interfaces, we continue to support the IRowProvider and IParametersOutProvider interfaces that we implemented originally. Yes, these interfaces are marked obsolete, but they are our only means of providing client-side connections, and SharePoint in most cases can transform them to connect to newer interfaces such as IRow. We have had some problems with this built-in interface transformation in SharePoint, and are fixing some of the known issues there in PI WebParts version 3.0, as well as adding consumption of .NET row provider, and consumption from the SharePoint ListView web part. We've also supported the new ITransformableFilterValues interface for some time. We have no concrete plans at this time for moving to all new connection interfaces, but it would make sense for such a transition to occur in concert with a transition to the ASP.NET web part base class.