- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Jaydoh's Template Mechanism - A Proven J2EE Pattern Page 2
Principals of Jaydoh's Template Mechanism:
1. Developer's develop and Graphic Designers design.
- No scripting is required in the templates (although, we do support JSP markup if you choose to code in the template). One and only one tag is introduced -- this tag has one attribute: name.
2. Don't change or interpret the content of a template.
- No assumptions are made regarding the content of your template, hence, once you understand Jaydoh's Template Mechanism, you can use it for any kind of text-based content. For example, you can use Jaydoh's Template Mechanism for WML(WAP).
How does it work?
Jaydoh's Template Mechanism, introduces a single tag that has one attribute, name. This tag has one purpose, to declare a name for an atomic region of content. You can declare as many regions as you desire, or none. Regions may also be nested.
Using these regions, you can create a final "rendered page" or View by combining a Template, with zero or more Page Providers (static fragments), and zero or more Object Providers (dynamic fragments) as shown in the diagram above.
Page Providers, can contain any number of nested regions and act like a template. For example, a typical Page Provider might be a company logo. Object Providers are actual Java objects that supply portions of content via method invocations -- that is, Object Providers generally provide information that is more dynamic (e.g. from business objects).
The interesting technical point is that, whether the content is static or dynamic, the Graphic Designers never need to know -- the only thing that Graphic Designers know about is regions, which is a very familiar concept.
The Template once again defines the regions it wants rendered by other components. If one of the configured Object Providers supplies an implementation, it is used. Otherwise, each configured Page Provider is asked if it can handle the region. If neither of these components can supply the defined region, then the Template's default implementation is used. If it helps, think of the relationship between these components as an inheritance hierarchy. Regions within Page Providers override regions defined in the Template, and regions defined within Object Providers override regions defined in Page Providers.
Why use it?
- To totally separate presentation from business logic.
- To easily combine a number of atomic components in a variety of ways.
- The template mechanism enables Rapid Prototyping. It allows the application interface to be completely built and have things become "dynamic" when they are ready.
- Its inheritance/region based implementation allows you to do things such as swap the look-and-feel depending on the device or user setting. For example, if the user is in a certain age range you can have a look-and-feel that targets that age-group.
- The template mechanism enables reuse of components: you can have the same Object Providers render content to different Templates -- that is, the same business object can be used when a browser connects to the service, in which case you stream back HTML, or when a WAP phone connects to the service, in which case you stream back WML.
- To enable a fast, iterative approach to application development. That is, Graphics Designers and Developers can work in parallel and integrate seamlessly and continuously.