[CONF] Apache Tapestry > Component Rendering
Component Rendering File attached by Bob Harner tapestry_render_phases.png (61 kB image/png) - Updated render phase chart (PNG) Stop watching space | Change email notification preferences View Attachments
[CONF] Apache Tapestry > Component Rendering
Component Rendering File attached by Bob Harner tapestry_render_phases.gliffy (39 kB application/octet-stream) - Updated render phase chart (Gliffy source) Stop watching space | Change email notification preferences View Attachments
[CONF] Apache Tapestry > Component Rendering
Component Rendering File attached by Bob Harner tapestry_render_phases.png (49 kB image/png) - Updated render phase chart (PNG) Stop watching space | Change email notification preferences View Attachments
[CONF] Apache Tapestry > Component Rendering
Component Rendering File attached by Bob Harner tapestry_render_phases.gliffy (38 kB application/octet-stream) - Updated render phase chart (Gliffy source) Stop watching space | Change email notification preferences View Attachments
[CONF] Apache Tapestry > Component Rendering
Component Rendering Page edited by Bob Harner Comment: Updated the Render Phases diagram Changes (2) ... !component-render-states.png|title=Component Render States! !tapestry_render_phases.png|title=Component Render Phases! Each of the orange phases (SetupRender, BeginRender, BeforeRenderBody, etc.) corresponds to an annotation you may place on one or more methods of your class. The annotation directs Tapestry to invoke your method as part of that phase. ... Full Content Component Rendering Related Articles Page: Request Processing Page: Content Type and Markup Page: Page Life Cycle Page: Page Navigation Page: Component Events Page: Component Events FAQ Page: Component Rendering Rendering of components in Tapestry 5 is based on a state machine and a queue (instead of the tail recursion used in Tapestry 4). This breaks the rendering process up into tiny pieces that can easily be implemented or overridden. Don't worry, in practice, writing components requires a breathtakingly small amount of code. Rendering Phases The rendering of each component is divided into a number of phases, illustrated below. Each of the orange phases (SetupRender, BeginRender, BeforeRenderBody, etc.) corresponds to an annotation you may place on one or more methods of your class. The annotation directs Tapestry to invoke your method as part of that phase. Methods marked with these annotations are called render phase methods. Your methods may be void, or return a boolean value. Returning a value can force phases to be skipped, or even be re-visited. In the diagram, solid lines show the normal processing path. Dashed lines are alternate flows that are triggered when your render phase methods return false instead of true (or void). Render phase methods may take no parameters, or may take a parameter of type MarkupWriter. The methods can have any visibility you like ... typically, package private is used, as this visibility makes it possible to unit test your code (from within the same Java package) without making the methods part of the component's public API. All Render phase methods are optional; a default behavior is associated with each phase. Annotation Method Name When Called @SetupRender setupRender() When initial setup actions, if any, are needed @BeginRender beginRender() When Tapestry is ready for the component's start tag, if any, to be rendered @BeforeRenderTemplate beforeRenderTemplate() Before Tapestry renders the component's template, if any @BeforeRenderBody beforeRenderBody() Before Tapestry renders the body of the component, if any @AfterRenderBody afterRenderBody() After Tapestry renders the body of the component, if any, but before the rest of the component's template is rendered @AfterRenderTemplate afterRenderTemplate() After Tapestry finishes rendering the component's template, if any @AfterRender afterRender() After Tapestry has finished rendering both the template and body of the component @CleanupRender cleanupRender() When final cleanup actions, if any, are needed The large number of phases reflects the need for precise control of components from component mixins. Several of the phases exist almost exclusively for mixins. Generally, your code will use the SetupRender, BeginRender, AfterRender and CleanupRender phases ... often just one or two of those. An Example Here's the source for a looping component that counts up or down between two values, renders its body a number of times, and stores the current index value in a parameter:
[CONF] Apache Tapestry > Component Rendering
Component Rendering File attached by Bob Harner component-render-states.png (86 kB image/png) - Older render phase chart Stop watching space | Change email notification preferences View Attachments
[CONF] Apache Tapestry > Component Rendering
Component Rendering File attached by Bob Harner tapestry_render_phases.png (50 kB image/png) - Updated render phase chart (PNG) Stop watching space | Change email notification preferences View Attachments
[CONF] Apache Tapestry > Component Rendering
Component Rendering File attached by Bob Harner tapestry_render_phases.gliffy (38 kB application/octet-stream) - Updated render phase chart (Gliffy source) Stop watching space | Change email notification preferences View Attachments
[CONF] Apache Tapestry > Component Rendering
Component Rendering
Page edited by Bob Harner
Comment:
A clarification on how often SetupRender methods are called
Changes (4)
...
Render phase methods may take no parameters, or may take a parameter of type [MarkupWriter|DOM]. The methods can have any visibility you like ... typically, package private is used, as this visibility makes it possible to unit test your code (from within the same Java package) without making the methods part of the component's _public_ API.
These methods are *optional*, a default behavior is associated with each phase.
All Render phase methods are _optional_; a default behavior is associated with each phase.
|| Annotation || Method Name || When Called ||
| *[@SetupRender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SetupRender.html]* | setupRender() | When initial setup actions, if any, are needed | | *[@BeginRender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeginRender]* | beginRender() | When Tapestry is ready for the component's start tag, if any, to be rendered |
...
Generally, your code will use the SetupRender, BeginRender, AfterRender and CleanupRender phases ... often just one or two of those.
h2. An Example
Here's the source for a looping component that counts up or down between two values, renders its body a number of times, and stores the current index value in a parameter:
...
What's really mind blowing is that the template and body of a component will often contain ... more components! That means that many different components will be in different phases of their own state machine.
h2. Render Phases in Detail {float:right|background="" {note} The SetupRender phase, like all render phases, occurs once for each rendering of the component. If the component is inside a looping component ([Loop|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/components/Loop.html], [Grid|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/corelib/components/Grid.html], etc.), then the SetupRender method will be called once for _each_ iteration of the loop. {note} {float}
h3. SetupRender
...
Full Content
Component Rendering
Related Articles
Page:
Request Processing
Page:
Content Type and Markup
Page:
Page Life Cycle
Page:
Page Navigation
Page:
Component Events
Page:
Component Events FAQ
Page:
Component Rendering
Rendering of components in Tapestry 5 is based on a state machine and a queue (instead of the tail recursion used in Tapestry 4). This breaks the rendering process up into tiny pieces that can easily be implemented or overridden. Don't worry, in practice, writing components requires a breathtakingly small amount of code.
Rendering Phases
The rendering of each component is divided into a number of phases, illustrated below.
Each of the orange phases (SetupRender, BeginRender, BeforeRenderBody, etc.) corresponds to an annotation you may place on one or more methods of your class. The annotation directs Tapestry to invoke your method as part of that phase.
Methods marked with these annotations are called render phase methods.
Your methods may be void, or return a boolean value. Returning a value can force phases to be skipped, or even be re-visited. In the diagram, solid lines show the normal processing path. Dashed lines are alternate flows that are triggered when your render phase methods return false instead of true (or void).
Render phase methods may ta
[CONF] Apache Tapestry > Component Rendering
Component Rendering Page edited by Bob Harner Comment: Added table of render phases Changes (3) ... These methods are *optional*, a default behavior is associated with each phase. The large number of phases reflects the use of [component mixins|Component Mixins] which also plug into the render phases. Several of the phases exist almost exclusively for mixins. || Annotation || Method Name || When Called | | | *[@SetupRender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SetupRender.html]* | setupRender() | When initial setup actions, if any, are needed | | *[@BeginRender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeginRender]* | beginRender() | When Tapestry is ready for the component's start tag, if any, to be rendered | | [@BeforeRenderTemplate|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderTemplate] | beforeRenderTemplate() | Before Tapestry renders the component's template, if any | | [@BeforeRenderBody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderBody] | beforeRenderBody() | Before Tapestry renders the body of the component, if any | | [@AfterRenderBody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRenderBody] | afterRenderBody() | After Tapestry renders the body of the component, if any, but before the rest of the component's template is rendered | | [@AfterRenderTemplate|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRenderTemplate] | afterRenderTemplate() | After Tapestry finishes rendering the component's template, if any | | *[@AfterRender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRender]* | afterRender() | After Tapestry has finished rendering both the template and body of the component | | *[@CleanupRender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/CleanupRender]* | cleanupRender() | When final cleanup actions, if any, are needed | The large number of phases reflects the need for precise control of components from [component mixins|Component Mixins]. Several of the phases exist almost exclusively for mixins. Generally, your code will use the SetupRender, BeginRender, AfterRender and CleanupRender phases ... often just one or two of those. ... Full Content Component Rendering Related Articles Page: Request Processing Page: Component Rendering Page: Content Type and Markup Page: Page Life Cycle Page: Page Navigation Page: Component Events Page: Component Events FAQ Rendering of components in Tapestry 5 is based on a state machine and a queue (instead of the tail recursion used in Tapestry 4). This breaks the rendering process up into tiny pieces that can easily be implemented or overridden. Don't worry, in practice, writing components requires a breathtakingly small amount of code. Rendering Phases The rendering of each component is divided into a number of phases, illustrated below. Each of the orange phases (SetupRender, BeginRender, BeforeRenderBody, etc.) corresponds to an annotation you may place on one or more methods of your class. The annotation directs Tapestry to invoke your method as part of that phase. Methods marked with these annotations are called render phase methods. Your methods may be void, or return a boolean value. Returning a value can force phases to be skipped, or even be re-visited. In the diagram, solid lines show the normal processing path. Dashed lines are alternate
[CONF] Apache Tapestry > Component Rendering
Component Rendering
Page edited by Bob Harner
Comment:
Fixed heading level
Changes (6)
...
{code}
h2. Short Circuiting
If a method returns a true or false value, this will short circuit processing. Other methods within the phase that would ordinarily be invoked will not be invoked. Most render phase methods should return void, to avoid unintentionally short circuiting other methods for the same phase.
h2. Method Conflicts and Ordering
...
* Mixin parent class methods
h23. Within a Single Class
Currently, rendering methods having the same annotation within a single class are executed in alphabetical order by method name. Methods with the same name are ordered by number of parameters. Even so, annotating multiple methods with the same rendering phase is not a great idea. Instead, just define one method, and have it call the other methods in the order you desire.
h3. Short Circuiting
h2. Rendering Comments
If a method returns a true or false value, this will short circuit processing. Other methods within the phase that would ordinarily be invoked will not be invoked. Most render phase methods should return void, to avoid unintentionally short circuiting other methods for the same phase. h3. Rendering Comments
Starting with version 5.3, Tapestry can optionally emit rendering comments for all requests; these are comments such as that can assist you in debugging markup output on the client-side. This will significantly increase the size of the rendered markup, but can be very helpful with complex layouts to determine which component was responsible for which portion of the rendered page.
...
Full Content
Component Rendering
Related Articles
Page:
Component Events FAQ
Page:
Request Processing
Page:
Component Events
Page:
Content Type and Markup
Page:
Page Navigation
Page:
Page Life Cycle
Page:
Component Rendering
Rendering of components in Tapestry 5 is based on a state machine and a queue (instead of the tail recursion used in Tapestry 4). This breaks the rendering process up into tiny pieces that can easily be implemented or overridden. Don't worry, in practice, writing components requires a breathtakingly small amount of code.
Rendering Phases
The rendering of each component is divided into a number of phases, illustrated below.
Each of the orange phases (SetupRender, BeginRender, BeforeRenderBody, etc.) corresponds to an annotation you may place on one or more methods of your class. The annotation directs Tapestry to invoke your method as part of that phase.
Methods marked with these annotations are called render phase methods.
Your methods may be void, or return a boolean value. Returning a value can force phases to be skipped, or even be re-visited. In the diagram, solid lines show the normal processing path. Dashed lines are alternate flows that are triggered when your render phase methods return false instead of true (or void).
Render phase methods may take no parameters, or may take a parameter of type MarkupWriter. The methods can have any visibility you like ... typically, package private is used, as this visibility makes it possible to unit test your code (from within the same Java package) without making the methods part of the component's public API.
These methods are optional, a default behavior is associated with each phase.
The large number of phases reflects the use of component mixins which also plug into the render phases. Several of the phases exist almost
[CONF] Apache Tapestry > Component Rendering
Component Rendering
Page edited by Bob Harner
Comment:
Added Rendering Comments section at Howard's suggestion
Changes (1)
...
Most render phase methods should return void, to avoid unintentionally short circuiting other methods for the same phase.
h3. Rendering Comments Starting with version 5.3, Tapestry can optionally emit rendering comments for all requests; these are comments such as that can assist you in debugging markup output on the client-side. This will significantly increase the size of the rendered markup, but can be very helpful with complex layouts to determine which component was responsible for which portion of the rendered page. Rendering comments are only available when not running in [production mode|Configuration#tapestry.production-mode]. To turn on rendering comments for all requests, set the [tapestry.component-render-tracing-enabled|Configuration#tapestry.component-render-tracing-enabled] configuration symbol to "true". To turn on rendering comments only for a particular request, add the query parameter {{t:component-trace=true}} to the URL: {code} http://www.example.com/myapp/mypage?t:component-trace=true {code}
Full Content
Component Rendering
Related Articles
Page:
Component Events FAQ
Page:
Request Processing
Page:
Component Events
Page:
Content Type and Markup
Page:
Component Rendering
Page:
Page Navigation
Page:
Page Life Cycle
Rendering of components in Tapestry 5 is based on a state machine and a queue (instead of the tail recursion used in Tapestry 4). This breaks the rendering process up into tiny pieces that can easily be implemented or overridden. Don't worry, in practice, writing components requires a breathtakingly small amount of code.
Rendering Phases
The rendering of each component is divided into a number of phases, illustrated below.
Each of the orange phases (SetupRender, BeginRender, BeforeRenderBody, etc.) corresponds to an annotation you may place on one or more methods of your class. The annotation directs Tapestry to invoke your method as part of that phase.
Methods marked with these annotations are called render phase methods.
Your methods may be void, or return a boolean value. Returning a value can force phases to be skipped, or even be re-visited. In the diagram, solid lines show the normal processing path. Dashed lines are alternate flows that are triggered when your render phase methods return false instead of true (or void).
Render phase methods may take no parameters, or may take a parameter of type MarkupWriter. The methods can have any visibility you like ... typically, package private is used, as this visibility makes it possible to unit test your code (from within the same Java package) without making the methods part of the component's public API.
These methods are optional, a default behavior is associated with each phase.
The large number of phases reflects the use of component mixins which also plug into the render phases. Several of the phases exist almost exclusively for mixins.
Generally, your code will use the SetupRender, BeginRender, AfterRender and CleanupRender phases ... often just one or two of those.
Here's the source for a looping component that counts up or down between two values, renders its body a number of times, and stores the current index value in a parameter:
package org.example.app.components;
import org.apache.tapestry5.annotations.Parameter;
import org.apache.tapestry5.annotations.AfterRender;
import org.apache.tapestry5.annotations.SetupRender;
public class Count
{
@Parameter
private int start = 1;
@Parameter(required = true)
[CONF] Apache Tapestry > Component Rendering
Component Rendering
Page edited by Bob Harner
Comment:
(Per TAP5-1217) Added "Further Return Types" section from the long-lost 5.2 trunk docs
Changes (3)
...
Returning a component instance does *not* short circuit method invocation, the way returning a boolean would. It is possible that multiple methods may return components (this is not advised -- insanity may ensue).
h2. Further Return Types Further return types for a render phase method are [Block|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/Block.html], [Renderable|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/Renderable.html] and [RenderCommand|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/RenderCommand.html]. The following component returns a Renderable in the early phase BeginRender and skips the phase BeforeRenderTemplate. {code:lang=java} public class OutputValueComponent { @Parameter private String value; Object beginRender() { return new Renderable() { public void render(MarkupWriter writer) { writer.write(value); } }; } } {code}
h2. Method Conflicts and Ordering
...
When a component has [mixins|Component Mixins], then the mixins' render phase methods execute _before_ the component's render phase methods. If a mixin extends from a base class, the mixin's parent class methods execute before the mixin subclass' render phase methods.
The order in which the mixins execute is not defined at this time.
Exception: Mixins whose class is annotated with @[MixinAfter|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/MixinAfter.html] are ordered _after_ the component, not before.
The order in which the mixins of a given class (@MixinAfter or mixins before) execute is determined by the ordering constraints specified for the mixins. If no constrains are provided, the order is undefined. See [Component Mixins] for more details.
h3. Parents before Child
...
Full Content
Component Rendering
Related Articles
Page:
Component Events
Page:
Request Processing
Page:
Component Events FAQ
Page:
Page Life Cycle
Page:
Page Navigation
Page:
Component Rendering
Rendering of components in Tapestry 5 is based on a state machine and a queue (instead of the tail recursion used in Tapestry 4). This breaks the rendering process up into tiny pieces that can easily be implemented or overridden. Don't worry, in practice, writing components requires a breathtakingly small amount of code.
Rendering Phases
The rendering of each component is divided into a number of phases, illustrated below.
Each of the orange phases (SetupRender, BeginRender, BeforeRenderBody, etc.) corresponds to an annotation you may place on one or more methods of your class. The annotation directs Tapestry to invoke your method as part of that phase.
Methods marked with these annotations are called render phase methods.
Your methods may be void, or return a boolean value. Returning a value can force phases to be skipped, or even be re-visited. In the diagram, solid lines show the normal processing path. Dashed lines are alternate flows that are triggered when your render phase methods return false instead of true (or void).
Render phase methods may take no parameters, or may take a parameter of type MarkupWriter. The methods can have any visibility you like ... typically, package private is used, as this visibility makes it possible to unit test your code (from within the same Java package) without making the methods part of the component's public API.
These methods are optional, a default behavior is associated with ea
[CONF] Apache Tapestry > Component Rendering
Component Rendering
Page edited by Kalle Korhonen
Changes (1)
...
h2. Rendering Components
Instead of returning true or false, a render phase method may return a component. The component may have been injected via the @[Component|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Component.html] annotation, or may have been passed to the owning component as a parameter.
In any case, returning a component will queue that component to be rendered *before* the active component continues rendering.
...
Full Content
Component Rendering
Related Articles
Page:
Component Events FAQ
Page:
Component Events
Page:
Component Rendering
Page:
Page Life Cycle
Page:
Page Navigation
Page:
Request Processing
Rendering of components in Tapestry 5 is based on a state machine and a queue (instead of the tail recursion used in Tapestry 4). This breaks the rendering process up into tiny pieces that can easily be implemented or overridden. Don't worry, in practice, writing components requires a breathtakingly small amount of code.
Rendering Phases
The rendering of each component is divided into a number of phases, illustrated below.
Each of the orange phases (SetupRender, BeginRender, BeforeRenderBody, etc.) corresponds to an annotation you may place on one or more methods of your class. The annotation directs Tapestry to invoke your method as part of that phase.
Methods marked with these annotations are called render phase methods.
Your methods may be void, or return a boolean value. Returning a value can force phases to be skipped, or even be re-visited. In the diagram, solid lines show the normal processing path. Dashed lines are alternate flows that are triggered when your render phase methods return false instead of true (or void).
Render phase methods may take no parameters, or may take a parameter of type MarkupWriter. The methods can have any visibility you like ... typically, package private is used, as this visibility makes it possible to unit test your code (from within the same Java package) without making the methods part of the component's public API.
These methods are optional, a default behavior is associated with each phase.
The large number of phases reflects the use of component mixins which also plug into the render phases. Several of the phases exist almost exclusively for mixins.
Generally, your code will use the SetupRender, BeginRender, AfterRender and CleanupRender phases ... often just one or two of those.
Here's the source for a looping component that counts up or down between two values, renders its body a number of times, and stores the current index value in a parameter:
package org.example.app.components;
import org.apache.tapestry5.annotations.Parameter;
import org.apache.tapestry5.annotations.AfterRender;
import org.apache.tapestry5.annotations.SetupRender;
public class Count
{
@Parameter
private int start = 1;
@Parameter(required = true)
private int end;
@Parameter
private int value;
private boolean increment;
@SetupRender
void initializeValue()
{
value = start;
increment = start < end;
}
@AfterRender
boolean next()
{
if (increment)
{
int newValue = value + 1;
if (newValue <= end)
{
value = newValue;
return false;
}
}
else
{
int newValue = value - 1;
if (newValue >= end)
{
value = newValue;
return false;
}
}
return true;
}
}
Returning false from next() causes Tapestry to re-run the BeginRender phase, and from there, re-render the component's body (this componen
[CONF] Apache Tapestry > Component Rendering
Component Rendering Page edited by Bob Harner Comment: Better wording on the render phase descriptions, and clarified the duplicate-annotation-within-a-single-class paragraph Changes (9) ... h3. SetupRender [...@setuprender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SetupRender.html] -- This The SetupRender phase (see [...@setuprender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SetupRender.html]) is where you can perform any one-time per-render setup for your component. This is a good place to read component parameters and use them to set temporary instance variables. h3. BeginRender [...@beginrender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeginRender.html] -- The BeginRender phase (see [...@beginrender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeginRender.html]) occurs at the start of the rendering of the component. For components that render a tag, the start tag should be rendered here (the close tag should be rendered inside the AfterRender phase). The component can also prevent the template and/or body from being rendered by returning false. Components may or may not have a template. If a component has a template, and the template includes a element, then the BeforeRenderBody phase will be triggered (giving the component the option of rendering its body or not). ... h3. BeforeRenderTemplate [...@beforerendertemplate|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderTemplate.html] -- This The BeforeRenderTemplate phase (see [...@beforerendertemplate|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderTemplate.html]) exists to allow a component to decorate its template (creating markup around the template generated markup), or to allow a component to skip its template. h3. BeforeRenderBody [...@beforerenderbody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderBody.html] -- This The BeforeRenderBody phase (see [...@beforerenderbody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderBody.html]) is associated with a component's body (the portion of its container's template that the component occupies). The BeforeRenderBody phase allows the component the ability to skip the body, while still rendering the rest of the component's template (if any). If no methods are annotated with BeforeRenderBody, then the body will be rendered by default. Again, this occurs when the element of the component's template is reached, or automatically if the component has no template (but the component does have a body). ... h3. AfterRenderBody [...@afterrenderbody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRenderBody.html] -- This The AfterRenderBody phase (see [...@afterrenderbody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRenderBody.html]) is executed after the body is rendered; this only occurs for components with a body. h3. AfterRender [...@afterrender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRender.html] -- This The AfterRender phase (see [...@afterrender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRender.html]) complements BeginRender, and is often used to render the close tag that matches the start tag rendered in the BeginRender phase. In any case, the AfterRender phase can continue on to CleanupRender, or revert back to BeginRender (as in our Count component example, above). If no methods are annotated with AfterRender, then no special output occurs, and the CleanupRender phase is triggered. ... h3. CleanupRender [...@cleanuprender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/CleanupRender.html] -- This The CleanupRender phase (see [...@cleanuprender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/CleanupRender.html]) is the counterpart to SetupRender, allowing final cleanup to occur. h2. Using Method Names instead of Annotations ... h2. Within a Single Class Currently, methods are sorted alphabetically. Methods with the same name are sorted by number of parameters. Even so, this is not a great idea ... just define one method, and have it call the other methods in the order you desire. Currently, rendering methods having the same annotation w
[CONF] Apache Tapestry > Component Rendering
Component Rendering Page edited by Bob Harner Comment: Removed initial focus on Tapestry 4. Reduced heading sizes for consistency with other pages. (h1 should only be used as the top-most heading, if at all) Changes (21) h1. Component Rendering h2. Tapestry 4 Approach Rendering of components in Tapestry 5 is based on a _state machine_ and a _queue_ (instead of the tail recursion used in Tapestry 4). This breaks the rendering process up into tiny pieces that can easily be implemented or overridden. Don't worry, in practice, it is a breathtakingly small amount of code to write. Rendering was a recursive process. Each component implemented a render() method (inherited from an IRender interface). Components would invoke render() on the objects in their template, including other components. h2. Rendering Phases [Bruce Tate|http://blog.rapidred.com/] has said "if you get vertigo, don't stand at the edge of a JavaServer Faces stack trace and look down". The same applies to Tapestry 4. Once you have heavily nested, looping components, the stack trace can get quite deep. h2. Tapestry 5 Approach Rendering of components is based on a _state machine_ and a _queue_ instead of tail recursion. This breaks the rendering process up into tiny pieces that can easily be implemented or overriden. Don't worry, in practice, it is a breathtakingly small amount of code to write. h1. Rendering Phases The rendering of each component is divided into a number of phases, illustrated below. ... What's really mind blowing is that the template and body of a component will often contain ... more components! That means that many different components will be in different phases of their own state machine. h23. SetupRender [...@setuprender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SetupRender.html] -- This is where you can perform any one-time per-render setup for your component. This is a good place to read component parameters and use them to set temporary instance variables. h23. BeginRender [...@beginrender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeginRender.html] -- For components that render a tag, the start tag should be rendered here (the close tag should be rendered inside the AfterRender phase). The component can also prevent the template and/or body from being rendered by returning false. ... If no methods are annotated with BeginRender, then no special output occurs during this phase, but the template (if present) or body (if no template is present, but the component has a body) will be rendered. h23. BeforeRenderTemplate [...@beforerendertemplate|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderTemplate.html] -- This phase exists to allow a component to decorate its template (creating markup around the template generated markup), or to allow a component to skip its template. h2.BeforeRenderBody h3. BeforeRenderBody [...@beforerenderbody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderBody.html] -- This phase is associated with a component's body (the portion of its container's template that the component occupies). The BeforeRenderBody phase allows the component the ability to skip the body, while still rendering the rest of the component's template (if any). ... If no methods are annotated with BeforeRenderBody, then the body will be rendered by default. Again, this occurs when the element of the component's template is reached, or automatically if the component has no template (but the component does have a body). h23. AfterRenderBody [...@afterrenderbody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRenderBody.html] -- This phase is executed after the body is rendered; this only occurs for components with a body. h23. AfterRender [...@afterrender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRender.html] -- This phase complements BeginRender, and is often used to render the close tag that matches the start tag rendered in the BeginRender phase. In any case, the AfterRender phase can continue on to CleanupRender, or revert back to BeginRender (as in our Count component example, above). ... If no methods are annotated with AfterRender, then no special output occurs, and the CleanupRender phase is triggered. h23. CleanupRender [...@cleanupre
[CONF] Apache Tapestry > Component Rendering
Component Rendering Page edited by Bob Harner Comment: Fixed ../apidocs/ links, and unlinked the H2 headers (not a good practice to link headers) Changes (18) ... What's really mind blowing is that the template and body of a component will often contain ... more components! That means that many different components will be in different phases of their own state machine. h2. [SetupRender|../apidocs/org/apache/tapestry5/annotations/SetupRender.html] SetupRender [...@setuprender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/SetupRender.html] -- This is where you can perform any one-time per-render setup for your component. This is a good place to read component parameters and use them to set temporary instance variables. h2. [BeginRender|../apidocs/org/apache/tapestry5/annotations/BeginRender.html] BeginRender [...@beginrender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeginRender.html] -- For components that render a tag, the start tag is should be rendered here (the close tag should be rendered inside the AfterRender phase). The component can also prevent the template and/or body from being rendered by returning false. Components may or may not have a template. If a component has a template, and the template includes a element, then the BeforeRenderBody phase will be triggered (giving the component the option of rendering its body or not). ... If no methods are annotated with BeginRender, then no special output occurs during this phase, but the template (if present) or body (if no template is present, but the component has a body) will be rendered. h2. [BeforeRenderTemplate|../apidocs/org/apache/tapestry5/annotations/BeforeRenderTemplate.html] BeforeRenderTemplate [...@beforerendertemplate|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderTemplate.html] -- This phase exists to allow a component to decorate its template (creating markup around the template generated markup), or to allow a component to skip its template. h2. [BeforeRenderBody|../apidocs/org/apache/tapestry5/annotations/BeforeRenderBody.html] h2.BeforeRenderBody Phase [...@beforerenderbody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/BeforeRenderBody.html] -- This phase is associated with a component's body (the portion of its container's template that the component occupies). The BeforeRenderBody phase allows the component the ability to skip the body, while still rendering the rest of the component's template (if any). If no methods are annotated with BeforeRenderBody, then the body will be rendered by default. Again, this occurs when the element of the component's template is reached, or automatically if the component has no template (but the component does have a body). h2. [AfterRenderBody|../apidocs/org/apache/tapestry5/annotations/AfterRenderBody.html] AfterRenderBody Phase that [...@afterrenderbody|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRenderBody.html] -- This phase is executed after the body is rendered; this only occurs for components with a body. h2. [AfterRender|../apidocs/org/apache/tapestry5/annotations/AfterRender.html] AfterRender [...@afterrender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/AfterRender.html] -- This phase complements BeginRender, and is often used to render the close tag that matches the start tag rendered in the BeginRender phase. In any case, the AfterRender phase can continue on to CleanupRender, or revert back to BeginRender (as in our Count component example, above). If no methods are annotated with AfterRender, then no special output occurs, and the CleanupRender phase is triggered. h2. [CleanupRender|../apidocs/org/apache/tapestry5/annotations/CleanupRender.html] CleanupRender The counterpart to SetupRender, this allows final cleanups to occur. [...@cleanuprender|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/CleanupRender.html] -- This is the counterpart to SetupRender, allowing final cleanup to occur. h1. Using Method Names instead of Annotations ... h1. Rendering Components Instead of returning true or false, a render phase method may return a component. The component may have been injected via the [Component|../apidocs/org/apache/tape
