Trying to learn the UML by studying the language specification is a difficult task. Not just because the size of the specification is so huge but because there are two complimentary specifications; the Superstructure and the Infrastructure. The UML Infrastructure specification acts as a kernel. There isn't any lower level of UML specification. The UML Superstructure defines all modeling elements found in the language by reusing and expanding on the elements found in the Infrastructure specification.
This sounds like a good application of reuse. The common elements are separated from the more specific elements. However, this has led to some level of redundancy in the UML specification, making UML concepts more difficult to grasp. This UML Simplification RFP aims to fix several specification problems, including the disconnect between the Infrastructure and Superstructure specifications. These problems also serve as a good example that reuse can sometimes lead to other unanticipated issues.
Showing posts with label reuse. Show all posts
Showing posts with label reuse. Show all posts
Wednesday, May 26, 2010
Thursday, March 25, 2010
HTML Reuse
One of the great features of any web application framework is the HTML template. These templates allow developers to inject variables into the page. In fact, most templates allow logic to be placed directly into the HTML page (which isn't a good idea, but not really the point here).
The server, by using HTML templates, can iterate over data sets and churn out HTML that is sent to the browser. This, in effect, saves us from storing the static page structure that is then sent to the client.
This is all well and good on the server side, but what about the client? It is given a static structure to display. The browser, behind the scenes is rendering the HTML into pixel values but the HTML itself is static.
This means that HTML that can often be computed is in a static form instead. Would it not make more sense to have the Javascript of a web application build these display elements based on application data returned from the server? Maybe not the entire display but I'm sure there are many repetitive elements that can be computed rather than delivered statically.
The server, by using HTML templates, can iterate over data sets and churn out HTML that is sent to the browser. This, in effect, saves us from storing the static page structure that is then sent to the client.
This is all well and good on the server side, but what about the client? It is given a static structure to display. The browser, behind the scenes is rendering the HTML into pixel values but the HTML itself is static.
This means that HTML that can often be computed is in a static form instead. Would it not make more sense to have the Javascript of a web application build these display elements based on application data returned from the server? Maybe not the entire display but I'm sure there are many repetitive elements that can be computed rather than delivered statically.
Subscribe to:
Posts
(
Atom
)