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
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.
As the diagram suggests, ideally, we would develop one View (called ReusableView). Given that it makes sense from the requirements standpoint, we would like to use that View in both Module1 and Module2 modules. Since we cannot know in advance where in module View hierarchy this View will be used, we should make the View hierarchy ambivalent - meaning that View can work at any level of the View hierarchy.
Somewhat connected to the hierarchy ambivalence is the host ambivalence. At the moment of the View design we do not know which View will serve as a Host for our Reusable View, therefore we should design the View in such a way that it does not matter which View is the Host.
Finally, we are not creating carbon copy modules, but rather modules that are very similar, yet different in certain details. Most probably, the template used by our reusable View will differ from module to module. In that aspect we also have to ensure that our View can work with different templates and different implementations of View child controls.
It is important to note that we will not be able to change absolutely everything (nor would it make sense - if we need to change everything - we may just as well create a new View). So for example, the crucial child controls that View is using to perform its function will have to be present in all templates. We will see, however, how we can take advantage of interfaces to loosen up these requirements.
In the following three articles we will explain and give code samples on how to achieve the goals we have set for the reusable View design:
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.