Table of Contents
The Kuali Rapid Application Development (KRAD) framework and tools are provided to enable universities to more quickly build "rich-UI" web-based and client applications. KRAD expands the set of application features beyond what was formerly available through KNS alone.
As with KNS, KRAD is a developer framework to enable consistency.
It adheres to development standards and architectural principles.
It’s a stable core for efficient development.
It reduces the amount of code you need to write and supports code reuse.
KRAD supports the KNS document types - Lookups, Inquiries, and Maintenance pages - while it also provides more flexibility in user interface layouts, for example, beyond the "vertical" tab section and collection layouts that are supported by KNS.
(more in progress here)
KRAD introduces the concept of a "View" and a hierarchy of pieces which can be added to a view. A view can represent a whole page or even, in some cases, multiple document pages. Inside the view, a number of different groups can be arranged - some as tabs, perhaps, others as field sets within other groups or even collections of field sets. Some of these groups are made up of fields, controls, and widgets (controls providing an extra level of interactive functionality by incorporating rich user interface techniques).
All of these - views, groups, fields, controls, and widgets - all are components of a KRAD renderer, and therefore all implement the org.kuali.rice.kns.uif. component interface.
In KRAD, a container is simply a component with a main job of containing other components to render. A view is a container, and several containers have the ability to contain other containers - views can contain groups, for instance, and groups, in turn, can contain any other kinds of components - including other groups. By default, a container such as a view has three areas: 1) a header, encapsulated in a HeaderField; 2) a footer, and then 3) any other encapsulated items which make up the body. The renderHeader and renderFooter properties of the container can be set to false to turn off presentation of the heater and footer rendering. Body rendering cannot be turned off because the point of the container is to render some kind of contained body elements - the content. However, the body elements are are defined in the container (the semantics) but thay are laid out on a page by a LayoutManager - in this way, you can keep the page layout "rendering" separate from the container's content - the body rendering attributes which define the semantics - enabling you to architect applications so they can more easily be ready for different view windows and devices.
