Introduction

Some notes about the ViewTaxonomy (this assumes you've read ViewTaxonomy):

Sometimes it is difficult to draw hard and fast boundaries between presentation and other concerns. For example, one can express how pages will be rendered in a componentised way, using templates, while also specifying a mirror image of the same components with programming language counterparts. The template is used to generate pages, but each component in the template is somehow bound to its programming language counterpart. This way, events emanating from a rendered component on the template can automatically be mapped to event handlers on its programming language counterpart.

It is tempting to add another top-level category to the taxonomy called hybrid models for such solutions. But the strategy of duplicating the logical component composition structure of a display (specified with a template) by means of a programming language in order to be able to handle events in a structured way, is really a controller issue---hence not applicable to this taxonomy.

That said, some frameworks use such a programming language mirror for reasons other than merely handling events---data received from components can be type checked and converted to native data types, and validation can also be specified---the result is components that are not only rendered, but that also have server side state and server side behaviour. (JavaServerFaces is an example of such a framework.)

All of the strategies in the taxonomy are really some combination of two main choices:

The ViewTaxonomy lends the second choice more importance for historical reasons, but in reality both dimensions are equally important.


I do think this matrix-like structure will disappear when more interesting approaches are added. (See AddingBentoDiscussion.)

-- IwanVosloo 2006-01-25 09:31:15

ViewTaxonomyDiscussion (last edited 2006-01-25 09:31:17 by IwanVosloo)