Package com.uwyn.rife.template

Provides classes and interfaces for the template engine.

See:
          Description

Interface Summary
BeanHandler Handles the process of setting values in a template based on a Java bean instance.
Template A template is used to construct, manipulate and produce text content.
TemplateEncoder Encodes Strings into a corresponding template output format, so they will be displayed correctly in the resulting file.
TemplateInitializer  
TemplateTransformer  
ValueRenderer An object which can render content for a value in a template.
 

Class Summary
AbstractBeanHandler  
AbstractTemplate  
BeanHandlerPlain  
BeanHandlerXhtml  
BeanHandlerXml  
EncoderDummy  
EncoderHtml  
EncoderSql  
EncoderXml  
ExternalValue  
FilteredTagProcessor  
FilteredTagProcessorGroovy  
FilteredTagProcessorJanino  
FilteredTagProcessorMvel  
FilteredTagProcessorOgnl  
FilteredTagProcessorOgnl.RifeResolver  
FilteredTags  
FilteredTagsMap  
InternalString  
InternalValue An anonymous value inside a template, which is not referenced anywhere in the template, but can be used to produce intermediate strings using the template engine.
ParsedBlockValue  
Parser  
Parser.ConfigPart  
Parser.MandatoryConfigPart  
Parser.OptionalConfigPart  
TemplateDeployer  
TemplateFactory  
TemplateFactoryEngineTypes  
TemplateTransformerXslt  
XsltExtension  
 

Enum Summary
Parser.PartType  
 

Package com.uwyn.rife.template Description

Provides classes and interfaces for the template engine.

Almost all template engines start out with a desire to seperate design from logic, they allow users to push or pull values into the template and then they get stuck. Design is far more complex than setting a couple of values, so they start providing simple logical constructs and loops, maybe even variables, blocks and scopes, functions to reuse code, etc etc ... and in the end run incorporate an entire language (JSP) or create a new one (PHP). All this is based on the assumption that the logic provides data to the design which is then decorated and rendered from within the template. Imho, a fundamental last step is missing which creates an overly complex model to try to simulate it.

When data has been integrated into a design, a template engine should allow the logic to retrieve the result and use the concrete version of the templated layout for real output and manipulation. This means that together with incorporating data, a template engine should also provide results and thus be able to work in a bidirectional fashion instead of the limited common unidirectional approach.

All of a sudden the template engine then becomes extremely simple, no need to integrate any kind of logical constructs or loops, the same logic that provided the data is able to select or repeat results easily. It can extract and combine them and if the template engine is powerful enough, use it as a scratchpad to assemble all the pieces of the layout in an efficient manner. All the required information is already available in the logic. You also don't have to worry anymore about just how much logic bleeds into a template. The entire template becomes totally language independent and designer-friendly.

Related Documentation

For overviews, tutorials, examples, guides, and documentation, please see:



Copyright © 2001-2007 Uwyn sprl/bvba. All Rights Reserved.