The Sun ONE Application Framework has the notion of a display field. This isn like the J2EE Blueprints or other J2EE architectures Ive seen–why not just pull values directly from a helper bean?
The display field paradigm offers unique advantages over more primitive techniques. Before explaining these advantages, note that there is no reason to use display fields in an application as they have been envisioned. The container and child view mechanisms are based entirely on the notion of embeddable arbitrary view objects. A child view object could be as coarse grained as an entire shopping cart display or application menu, or as fine-grained as individual display fields. This flexibility allows application composition from modular pieces, as well as a more traditional display field oriented approach. In short, you can just pull values directly from a helper bean in the Sun ONE Application Framework, but hopefully you can be convinced that there is a better way. Each top-level ViewBean instance (or root view) is an instance of ContainerView, and can contain any arbitrary set of sub-views, some of which can be display field views. TiledViews are also sub-views, and can be arbitrari
Related Questions
- The Sun ONE Application Framework has the notion of a display field. This isn like the J2EE Blueprints or other J2EE architectures Ive seen--why not just pull values directly from a helper bean?
- What J2EE application deployment architectures can be targeted using Oracle ADF?
- How is the Sun ONE Application Framework different from other J2EE frameworks?
