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.
[This post is part of the developer's manual preview published on this blog. You can find temporary TOC here.]
Recognizing this problem, which became apparent with large and more complex modules, we have decided to provide a framework for building modules which would inherently provide for reusability. The key piece of this new architecture is a View. We have been talking quite a lot about Views in this manual, so we will not go back to the details; however, let us consider some of the promises that Views pledge to us as developers:
Let us consider built-in Generic Content module for a second. The module itself has about dozen or so Views. Each View does only one single thing: for example, ContentItemEdit View is responsible for displaying the form for editing content. Because the View has only this one purpose, we are able to create a new View from it (ContentItemNew View) which is in charge of creating new content. We know that the ContentItemEdit View does only one thing (save changes to existing content), which is extremely similar to what the View for creating new content does (save changes to the new content). With this tight focus on the functionality, we are able to reuse View without worrying about anything else (e.g. categories, displaying list of the content, tags, comments and so on).
This simplistic approach to the View design also allows us to port the View from one module to another. For example, editing content is almost identical to editing blog posts. Now, blogs module itself is rather different than the Generic Content module (e.g. concept of parent/child relations between blogs and posts), but since our Views are designed to do one isolated thing, we can port only those that we need (like the view for editing content) and leave other Views intact.
Finally, we could decide that every time content is saved we should run the content through the web service for translation. Whereas built-in ContentItemEdit View does not provide this functionality, we are at freedom to simply enhance this one View and replace the original View with the enhanced version through the configuration - meaning that we have a highly maintainable application at our hands.
So, as it was demonstrated on the example of ContentItemEdit View, benefits of designing Views with single responsibility are numerous. Our modules will be easier to maintain, we will be able to reuse the already existing functionality and finally, we will be able to build more and more complex modules through the composition of Views - each one responsible for one piece of functionality.
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.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Learn MoreSubscribe to get all the news, info and tutorials you need to build better business apps and sites
Progress collects the Personal Information set out in our Privacy Policy and the Supplemental Privacy notice for residents of California and other US States and uses it for the purposes stated in that policy.
You can also ask us not to share your Personal Information to third parties here: Do Not Sell or Share My Info
We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.
Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.