Deliver superior customer experiences with an AI-driven platform for creating and deploying cognitive chatbots
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
A complete cloud platform for an app or your entire digital business
Detect and predict anomalies by automating machine learning to achieve higher asset uptime and maximized yield
Automate decision processes with a no-code business rules engine
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Personalize and optimize the customer experience across digital touchpoints
Build, protect and deploy apps across any platform and mobile device
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
The content you're reading is getting on in years
This post is on the older side and its content may be out of date.
Be sure to visit our blogs homepage for our latest news, updates and information.
When implementing a widget, generally only one class is enough – the control that represents the widget. In Sitefinity, it is a very good idea to inherit from a base class called SimpleView, when implementing widgets.
If the widget is to be configured by the users, we may also decide to implement a widget designer, in order to provide a user friendly way of configuring the widget. Note that even if you don’t implement the widget designer, users will still be able to configure the widget through the automatically generated property grid. Now, take a look at the following screenshots to get a better feeling of the terminology.
So, now that we are clear on the terminology, let’s start explaining the files included in the project and their purpose.
First, let me explain why is it necessary that the designers are implemented on the client side. Namely, Sitefinity 4.0 is not using postbacks at all – and this would introduce quite an inconsistency if we’d use postbacks here. In order to make both, designers and property grid, be synchronized and be so without the postbacks we have decided to go this way. There is no doubt that your users like this approach better.
The sample provided in this blog post can be used as a starting point for any widget / designer implementation and by minimally changing it (only the things that are really different) you can have your designers up and running in no time. For example, it took me less than 2 hours to write this sample.
View all posts from The Progress Team on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.