[CONF] Apache Tapestry Component Events
Bob Harner edited the page:
Component Events
Comment: fixed language param of code macro
...
Let's review a simple example. Here's a portion of the template for a page (let's call it Chooser) that lets the user choose a number between 1 and 10:
Code Block
language
xml
p Choose a number from 1 to 10:
t:count end=10 value=index
a t:id=select t:type=actionlink context=index${index}/t:comp
/t:count
/p
...
When a component event occurs, Tapestry invokes any event handler methods that you have identified for that event. You can identify your event handler methods via a naming convention (see Method Naming Convention below), or via the @OnEvent annotation.
Code Block
language
java
[CONF] Apache Tapestry Component Events
Component Events
Page edited by Bob Harner
Comment:
"then then" fixed per M. MGelbana
Changes (1)
...
In the above example, the navigational response is the page itself.
If there is no exception event handler, or the exception event handler returns null (or is void), then then the exception will be passed to the [RequestExceptionHandler|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/RequestExceptionHandler.html] service, which (in default configuration) will be render the exception page.
Full Content
Component Events
Related Articles
Page:
Request Processing
Page:
Component Events
Page:
Component Rendering
Page:
Page Life Cycle
Page:
Page Navigation
Page:
Component Events FAQ
Component events are Tapestry's way of conveying a user's interactions with the web page, such as clicking links and submitting forms, to designated methods in your page and component classes. When a component event occurs, Tapestry calls the event handler method you've provided, if any, in the containing component's class.
Let's review a simple example. Here's a portion of the template for a page (let's call it "Chooser") that lets the user choose a number between 1 and 10:
p Choose a number from 1 to 10:
t:count end="10" value="index"
a t:id="select" t:type="actionlink" context="index"${index}/t:comp
/t:count
/p
Notice that Chooser.tml contains an ActionLink component. When rendered on the page, the ActionLink component creates a component event request URL, with the event type set to "action". In this case the URL might look like http://localhost:8080/chooser.select/3
This URL identifies the page that contains the component ("chooser"), the type of event (unless it is "action", the default and most common event type), the id of the component within the page ("select"), plus the additional context value ("3"). Additional context values, if any, are appended to the path.
There's no direct mapping from URL to a piece of code. Instead, when the user clicks on the link, the ActionLink component emits events. And then Tapestry ensures that the correct bit of code (your event handler method, see below) gets invoked for those events.
This demonstrates a critical difference between Tapestry and a more traditional, action oriented framework. The URL doesn't say what happens when the link is clicked, it identifies which component is responsible when the link is clicked.
Often, a navigation request (originating with the user) will spawn a number of flow-of-control requests. For example, an action event will trigger a form component, which will then emit notification events to announce when the form submission is about to be processed, and whether it was successful or not, and those event could be further handled by the page component.
Event Handler Methods
When a component event occurs, Tapestry invokes any event handler methods that you have identified for that event. You can identify your event handler methods via a naming convention (see Method Naming Convention below), or via the @OnEvent annotation.
@OnEvent(component = "select")
void valueChosen(int value)
{
this.value = value;
}
Tapestry does two things here:
Because of the annotation, it identifies method valueChosen() as the method to invoke.
When the link is clicked, it converts the context value from a string to an integer and passes it into the method.
Added in 5.3
Starting in release 5.3, Tapestry will validate that the component, if any, identified for the event handler method actually exists in the containing component's template. This helps with typos in annotations (or in the naming conventions identified below).
In the above example, the valueChosen() method will be invoked when the default
[CONF] Apache Tapestry Component Events
Component Events
Page edited by Bob Harner
Comment:
Another typo
Changes (1)
...
In the above example, the navigational response is the page itself.
If there is no exception event handler, or the exception event handler returns null (or is void), then the exception will be passed to the [RequestExceptionHandler|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/RequestExceptionHandler.html] service, which (in default configuration) will be render the exception page.
Full Content
Component Events
Related Articles
Page:
Request Processing
Page:
Component Rendering
Page:
Page Life Cycle
Page:
Page Navigation
Page:
Component Events FAQ
Page:
Component Events
Component events are Tapestry's way of conveying a user's interactions with the web page, such as clicking links and submitting forms, to designated methods in your page and component classes. When a component event occurs, Tapestry calls the event handler method you've provided, if any, in the containing component's class.
Let's review a simple example. Here's a portion of the template for a page (let's call it "Chooser") that lets the user choose a number between 1 and 10:
p Choose a number from 1 to 10:
t:count end="10" value="index"
a t:id="select" t:type="actionlink" context="index"${index}/t:comp
/t:count
/p
Notice that Chooser.tml contains an ActionLink component. When rendered on the page, the ActionLink component creates a component event request URL, with the event type set to "action". In this case the URL might look like http://localhost:8080/chooser.select/3
This URL identifies the page that contains the component ("chooser"), the type of event (unless it is "action", the default and most common event type), the id of the component within the page ("select"), plus the additional context value ("3"). Additional context values, if any, are appended to the path.
There's no direct mapping from URL to a piece of code. Instead, when the user clicks on the link, the ActionLink component emits events. And then Tapestry ensures that the correct bit of code (your event handler method, see below) gets invoked for those events.
This demonstrates a critical difference between Tapestry and a more traditional, action oriented framework. The URL doesn't say what happens when the link is clicked, it identifies which component is responsible when the link is clicked.
Often, a navigation request (originating with the user) will spawn a number of flow-of-control requests. For example, an action event will trigger a form component, which will then emit notification events to announce when the form submission is about to be processed, and whether it was successful or not, and those event could be further handled by the page component.
Event Handler Methods
When a component event occurs, Tapestry invokes any event handler methods that you have identified for that event. You can identify your event handler methods via a naming convention (see Method Naming Convention below), or via the @OnEvent annotation.
@OnEvent(component = "select")
void valueChosen(int value)
{
this.value = value;
}
Tapestry does two things here:
Because of the annotation, it identifies method valueChosen() as the method to invoke.
When the link is clicked, it converts the context value from a string to an integer and passes it into the method.
Added in 5.3
Starting in release 5.3, Tapestry will validate that the component, if any, identified for the event handler method actually exists in the containing component's template. This helps with typos in annotations (or in the naming conventions identified below).
In the above example, the valueChosen() method will be invoked when the default event, "action", occurs
[CONF] Apache Tapestry Component Events FAQ
Component Events FAQ Page edited by Bob Harner Comment: "redirect-after-post" renamed to Post/Redirect/Get Changes (1) ... h3. Why does Tapestry send a redirect after a form is submitted? This is an extension of the [redirect after post|http://en.wikipedia.org/wiki/Post/Redirect/Get] [Post/Redirect/Get|http://en.wikipedia.org/wiki/Post/Redirect/Get] approach. It ensures that after an operation that updates server-side state, such as a form submission, if the user resubmits the resulting page, the operation is *not* performed a second time; instead just the results of the operation, reflecting the changed server-side state, is re-rendered. This has the unwanted requirement that any data needed to render the response must persist between the event request (the form submission) and the render request; this often means that fields must be annotated with @[Persist|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Persist.html]. ... Full Content Link Components FAQFrequently Asked Questions_javascript_ FAQ Component Events Why does Tapestry send a redirect after a form is submitted? This is an extension of the Post/Redirect/Get approach. It ensures that after an operation that updates server-side state, such as a form submission, if the user resubmits the resulting page, the operation is not performed a second time; instead just the results of the operation, reflecting the changed server-side state, is re-rendered. This has the unwanted requirement that any data needed to render the response must persist between the event request (the form submission) and the render request; this often means that fields must be annotated with @Persist. Added in 5.2 If you want to short-circuit this behavior and render a response directly, your component event handle method may return an instance of StreamPageContent. Tapestry will render the page as part of the event request and stream its content back to the client web browser, rather than sending the normal redirect. Added in 5.4 Starting in release 5.4, Forms (by default) will NOT redirect after post if there are validation errors. This makes it possible to re-render the page, with error decorations, without requiring that the validation errors be stored in the session between requests ... and that means that the application can remain stateless much longer. I specified a zone in my ActionLink/EventLink, so why doesn't my event fire via ajax (request.isXHR() is false)? Check your browser's _javascript_ console for errors. It's likely that a _javascript_ error has prevented Tapestry from transforming your ActionLink/EventLink from a page render action to an ajax action. Link Components FAQFrequently Asked Questions_javascript_ FAQ Stop watching space | Change email notification preferences View Online | View Changes
[CONF] Apache Tapestry Component Events FAQ
Component Events FAQ
Page edited by Bob Harner
Comment:
Added Lance
Changes (1)
...
{since}
h3. I specified a zone in my ActionLink/EventLink, so why doesnt my event fire via ajax (request.isXHR() is false)? Check your browsers _javascript_ console for errors. Its likely that a _javascript_ error has prevented Tapestry from transforming your ActionLink/EventLink from a page render action to an ajax action.
{scrollbar}
Full Content
Link Components FAQFrequently Asked Questions_javascript_ FAQ
Component Events
Why does Tapestry send a redirect after a form is submitted?
This is an extension of the redirect after post approach. It ensures that after an operation that updates server-side state, such as a form submission, if the user resubmits the resulting page, the operation is not performed a second time; instead just the results of the operation, reflecting the changed server-side state, is re-rendered.
This has the unwanted requirement that any data needed to render the response must persist between the event request (the form submission) and the render request; this often means that fields must be annotated with @Persist.
Added in 5.2
If you want to short-circuit this behavior and render a response directly, your component event handle method may return an instance of StreamPageContent. Tapestry will render the page as part of the event request and stream its content back to the client web browser, rather than sending the normal redirect.
Added in 5.4
Starting in release 5.4, Forms (by default) will NOT redirect after post if there are validation errors. This makes it possible to re-render the page, with error decorations, without requiring that the validation errors be stored in the session between requests ... and that means that the application can remain stateless much longer.
I specified a zone in my ActionLink/EventLink, so why doesn't my event fire via ajax (request.isXHR() is false)?
Check your browser's _javascript_ console for errors. It's likely that a _javascript_ error has prevented Tapestry from transforming your ActionLink/EventLink from a page render action to an ajax action.
Link Components FAQFrequently Asked Questions_javascript_ FAQ
Stop watching space
|
Change email notification preferences
View Online
|
View Changes
[CONF] Apache Tapestry Component Events
Component Events
Page edited by Bob Harner
Comment:
Mentioned new URL return value for Ajax requests, which Kalle just committed
Changes (1)
...
In the case of an Ajax request to update a zone, the component event handler will return the new zone body, typically via an injected component or block.
Starting in Tapestry 5.4, an Ajax event handler may alternatively return a java.net.URL, in which case a redirect for that URL will be sent to the client.
See [Page Navigation] for other return values.
...
Full Content
Component Events
Related Articles
Page:
Component Events FAQ
Page:
Page Life Cycle
Page:
Request Processing
Page:
Component Rendering
Page:
Component Events
Page:
Page Navigation
Component events are Tapestry's way of conveying a user's interactions with the web page, such as clicking links and submitting forms, to designated methods in your page and component classes. When a component event occurs, Tapestry calls the event handler method you've provided, if any, in the containing component's class.
Let's review a simple example. Here's a portion of the template for a page (let's call it "Chooser") that lets the user choose a number between 1 and 10:
p Choose a number from 1 to 10:
t:count end="10" value="index"
a t:id="select" t:type="actionlink" context="index"${index}/t:comp
/t:count
/p
Notice that Chooser.tml contains an ActionLink component. When rendered on the page, the ActionLink component creates a component event request URL, with the event type set to "action". In this case the URL might look like http://localhost:8080/chooser.select/3
This URL identifies the page that contains the component ("chooser"), the type of event (unless it is "action", the default and most common event type), the id of the component within the page ("select"), plus the additional context value ("3"). Additional context values, if any, are appended to the path.
There's no direct mapping from URL to a piece of code. Instead, when the user clicks on the link, the ActionLink component emits events. And then Tapestry ensures that the correct bit of code (your event handler method, see below) gets invoked for those events.
This demonstrates a critical difference between Tapestry and a more traditional, action oriented framework. The URL doesn't say what happens when the link is clicked, it identifies which component is responsible when the link is clicked.
Often, a navigation request (originating with the user) will spawn a number of flow-of-control requests. For example, an action event will trigger a form component, which will then emit notification events to announce when the form submission is about to be processed, and whether it was successful or not, and those event could be further handled by the page component.
Event Handler Methods
When a component event occurs, Tapestry invokes any event handler methods that you have identified for that event. You can identify your event handler methods via a naming convention (see Method Naming Convention below), or via the @OnEvent annotation.
@OnEvent(component = "select")
void valueChosen(int value)
{
this.value = value;
}
Tapestry does two things here:
Because of the annotation, it identifies method valueChosen() as the method to invoke.
When the link is clicked, it converts the context value from a string to an integer and passes it into the method.
Added in 5.3
Starting in release 5.3, Tapestry will validate that the component, if any, identified for the event handler method actually exists in the containing component's template. This helps with typos in annotations (or in the naming conventions identified below).
In the above example, the valueChosen() method will be invoked
[CONF] Apache Tapestry Component Events
Component Events
Page edited by Bob Harner
Comment:
Added mention of more event handler return values
Changes (5)
...
For page navigation events (originating in components such as EventLink, ActionLink and Form), the value returned from an event handler method determines how Tapestry will render a response.
If the event handler method returns no value, or returns null, then the current page (the page containing the component) will render the response.
* *Null*: For no value, or null, the current page (the page containing the component) will render the response. * *Page*: For the name of a page, or a page class or page instance, a render request URL will be constructed and sent to the client as a redirect to that page. * *URL*: For a java.net.URL, a redirect will be sent to the client. (In Tapestry 5.3.x and earlier, this only works for non-Ajax requests.) * *Zone body*: In the case of an Ajax request to update a zone, the component event handler will return the new zone body, typically via an injected component or block. * *HttpError*: For an [HttpError|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/HttpError.html], an error response is sent to the client. * *Link*: For a [Link|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/Link.html], a redirect is sent to the client. * *Stream*: For a [StreamResponse|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/StreamResponse.html], a stream of data is sent to the client
If the name of a page, or a page class or page instance, is returned, then a render request URL will be constructed and sent to the client as a redirect to that page.
See [Page Navigation] for more details.
If a java.net.URL is returned then a redirect will be sent to the client. (In Tapestry 5.3.x and earlier, this only works for non-Ajax requests.) In the case of an Ajax request to update a zone, the component event handler will return the new zone body, typically via an injected component or block. See [Page Navigation] for other return values.
h2. Multiple Method Matches
...
Full Content
Component Events
Related Articles
Page:
Component Events FAQ
Page:
Page Life Cycle
Page:
Request Processing
Page:
Component Rendering
Page:
Page Navigation
Page:
Component Events
Component events are Tapestry's way of conveying a user's interactions with the web page, such as clicking links and submitting forms, to designated methods in your page and component classes. When a component event occurs, Tapestry calls the event handler method you've provided, if any, in the containing component's class.
Let's review a simple example. Here's a portion of the template for a page (let's call it "Chooser") that lets the user choose a number between 1 and 10:
p Choose a number from 1 to 10:
t:count end="10" value="index"
a t:id="select" t:type="actionlink" context="index"${index}/t:comp
/t:count
/p
Notice that Chooser.tml contains an ActionLink component. When rendered on the page, the ActionLink component creates a component event request URL, with the event type set to "action". In this case the URL might look like http://localhost:8080/chooser.select/3
This URL identifies the page that contains the component ("chooser"), the type of event (unless it is "action", the default and most common event type), the id of the component within the page ("select"), plus the additional context value ("3"). Additional context values, if any, are appended to the path.
There's no direct mapping from URL to a piece of code. Instead, when the user clicks on the link, the ActionLink component emits events. And then Tapestry ensures that the
[CONF] Apache Tapestry Component Events
Component Events
Page edited by Bob Harner
Comment:
(Per TAP5-1217) Added a couple sections from the long-lost 5.2 trunk docs
Changes (5)
...
{code}
Notice that Chooser.tml contains an ActionLink component. When rendered on the page, the ActionLink component creates a link with an action URL, which in this case might look like {{http://localhost:8080/chooser.select/3}}
Notice that Chooser.tml contains an ActionLink component. When rendered on the page, the ActionLink component creates component event request URL, with the event type set to action. In this case might look like {{http://localhost:8080/chooser.select/3}}
This URL identifies the page that contains the component (chooser), the type of event (unless it is action, the default and most common event type), the id of the component within the page (select), plus the additional context value (3). _Additional context values, if any, are appended to the path._
...
Returning a boolean value from an event handler method is special. Returning true will abort the event with no result; use this when the event is fully handled without a return value and no further event handlers (in the same component, or in containing components) should be invoked.
Returning false is the same as returning null.
Returning false is the same as returning null; event processing will continue to look for more event handlers, in the same component or its parent.
When an event bubbles up from a component to its container, the origin of the event is changed to be the component. For example, a Form component inside a BeanEditForm component may fire a success event. The page containing the BeanEditForm may listen for that event, but it will be from the BeanEditForm component (which makes sense, because the id of the Form inside the BeanEditForm is part of the BeanEditForms implementation, not its public interface).
h1. Event Method Exceptions
...
Full Content
Component Events
Related Articles
Page:
Component Events
Page:
Request Processing
Page:
Component Events FAQ
Page:
Page Life Cycle
Page:
Page Navigation
Page:
Component Rendering
Component events are Tapestry's way of conveying a user's interactions with the web page, such as clicking links and submitting forms, to designated methods in your page and component classes. When a component event occurs, Tapestry calls the event handler method you've provided, if any, in the containing component's class.
Let's review a simple example. Here's a portion of the template for a page (let's call it "Chooser") that lets the user choose a number between 1 and 10:
p Choose a number from 1 to 10:
t:count end="10" value="index"
a t:id="select" t:type="actionlink" context="index"${index}/t:comp
/t:count
/p
Notice that Chooser.tml contains an ActionLink component. When rendered on the page, the ActionLink component creates component event request URL, with the event type set to "action". In this case might look like http://localhost:8080/chooser.select/3
This URL identifies the page that contains the component ("chooser"), the type of event (unless it is "action", the default and most common event type), the id of the component within the page ("select"), plus the additional context value ("3"). Additional context values, if any, are appended to the path.
There's no direct mapping from URL to a piece of code. Instead, when the user clicks on the link, the ActionLink component emits events. And then Tapestry ensures that the correct bit of code (your event handler method, see below) gets invoked for those events.
This demonstrates a critical difference between Tapestry and a more
[CONF] Apache Tapestry Component Events
Component Events
Page edited by Howard M. Lewis Ship
Comment:
discuss validation
Changes (10)
...
void valueChosen(int value) {
this.value = value;F
} {code}
...
* When the link is clicked, it converts the context value from a string to an integer and passes it into the method.
{since:since=5.3} Starting in release 5.3, Tapestry will validate that the component, if any, identified for the event handler method actually exists in the containing components template. This helps with typos in annotations (or in the naming conventions identified below). {since}
In the above example, the valueChosen() method will be invoked when the default event, action, occurs in the {{select}} component (and has at least one context value).
...
{code}
{info}
Note from Howard: Ive found that I prefer the naming convention approach, and reserve the annotation just for situations that dont otherwise fit.
{info}
h2. Method Return Values
...
When an event handler method is invoked, the strings are converted back into values, or even objects. A [ValueEncoder|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ValueEncoder.html] is used to convert between client-side strings and server-side objects. The [ValueEncoderSource|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ValueEncoderSource.html] service provides the necessary value encoders.
As shown in the example above, most of the parameters passed to the event handler method are derived from the values provided in the event context. Each successive method parameter matches against a value provided in the event context (the context parameter of the ActionLink component; though many components have a similar context parameter). In some cases, it is desirable to have direct access to the context (for example, to adapt to cases where there are a variable number of context values). The context values may be passed to an event handler method as parameter of the following types: * [EventContext|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/EventContext.html] * Object[] * ListObject The latter two should be avoided, they may be removed in a future release. In all of these cases, the context parameter acts as a freebie; it doesnt match against a context value as it represents _all_ context values. h2. Accessing Request Query Parameters A parameter may be annotated with the @RequestParameter annotation; this allows a query parameter to be extracted from the request, converted to the correct type, and passed to the method. Again, this doesnt count against the event context values.
h2. Method Matching An event handler method will only be invoked _if the context contains at least as many values as the method has parameters_. Methods with too many parameters will be silently skipped.
h2. Collections
Tapestry will silently skip over a method if there are insufficient values in the context to satisfy the number of parameters requested.
To designate that an event handler method should be invoked regardless of how many context parameters are available, change the method to accept a _single_ parameter of type Object[], type List, or type [EventContext|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/EventContext.html].
EventContext parameters, and parameters annotated with @RequestParameter, do not count against this limit.
h2. Method Ordering When multiple methods match within the same class, Tapestry will invoke them in ascending alphabetical order. When there are multiple overrides of the same method name, Tapestry invokes them in descending order by number of parameters. In general, these situations dont happen ... in most cases, only a single method is required to handle a specific event form a specific component. An event handler method may return the value {{true}} to indicate that the event has been handled; this immediately stops the search for additional methods in the same class (or in base classes) or in containing components.
h1. Event Bubbling
...
Full Content
Component Events
Related Articles
Page:
Component Rendering
Page:
Component Events
[CONF] Apache Tapestry Component Events FAQ
Component Events FAQ Page added by Howard M. Lewis Ship Change Notification Preferences View Online
[CONF] Apache Tapestry Component Events FAQ
Component Events FAQ
Page edited by Howard M. Lewis Ship
Changes (2)
{scrollbar}
h2. Component Events h3. Why does Tapestry send a redirect after a form is submitted? This is an extension of the [redirect after post|http://en.wikipedia.org/wiki/Post/Redirect/Get] approach. It ensures that after an operation that updates server-side state, such as a form submission, if the user resubmits the resulting page, the operation is *not* performed a second time; instead just the results of the operation, reflecting the changed server-side state, is re-rendered. This has the unwanted requirement that any data needed to render the response must persist between the event request (the form submission) and the render request; this often means that fields must be annotated with @[Persist|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/Persist.html]. {since:since=5.2} If you want to short-circuit this behavior and render a response directly, your component event handle method may return an instance of [StreamPageContent|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/StreamPageContent.html]. Tapestry will render the page as part of the event request and stream its content back to the client web browser, rather than sending the normal redirect. {since} {scrollbar}
Full Content
Link Components FAQFrequently Asked Questions_javascript_ FAQ
Component Events
Why does Tapestry send a redirect after a form is submitted?
This is an extension of the redirect after post approach. It ensures that after an operation that updates server-side state, such as a form submission, if the user resubmits the resulting page, the operation is not performed a second time; instead just the results of the operation, reflecting the changed server-side state, is re-rendered.
This has the unwanted requirement that any data needed to render the response must persist between the event request (the form submission) and the render request; this often means that fields must be annotated with @Persist.
Added in 5.2
If you want to short-circuit this behavior and render a response directly, your component event handle method may return an instance of StreamPageContent. Tapestry will render the page as part of the event request and stream its content back to the client web browser, rather than sending the normal redirect.
Link Components FAQFrequently Asked Questions_javascript_ FAQ
Change Notification Preferences
View Online
|
View Changes
[CONF] Apache Tapestry Component Events
Component Events
Page edited by Bob Harner
Comment:
Added a few mentions of EventLink
Changes (7)
...
{code}
Notice that Chooser.tml contains an ActionLink component. When rendered on the page, the ActionLink component creates a link with an action URL, which in this case might look like {{http://localhost:8080/chooser.select/3}}
This URL identifies the page that contains the component (chooser), the type of event (unless it is action, the default and most common event type), the id of the component within the page (select), plus the additional context value (3). _Additional context values, if any, are appended to the path._
...
void valueChosen(int value) {
this.value = value;F
} {code}
...
{code}
The {{value}} attribute of the OnEvent annotation is the name of the event to match. The default event type is action; the ActionLink and Form components each use this event type. Alternatively, we could have used an EventLink component, in which case the name of the event is determined by the elements ID, rather than being action.
If you omit the {{component}} part of the OnEvent annotation, then youll receive notifications from _all_ contained components, possibly including nested components (due to event bubbling).
...
Main Article: [Page Navigation]
For page navigation events (originating in components such as EventLink, ActionLink and Form), the value returned from an event handler method determines how Tapestry will render a response.
If the event handler method returns no value, or returns null, then the current page (the page containing the component) will render the response.
...
If the name of a page, or a page class or page instance, is returned, then a render request URL will be constructed and sent to the client as a redirect to that page.
In the case of an Ajax request to update a zone, the component event handler will return the new zone body, typically via an injected component or block.
See [Page Navigation] for other return values.
...
h1. Event Context
The context values (the context parameter to the EventLink or ActionLink component) can be any object. However, only a simple conversion to string occurs. (This is in contrast to Tapestry 4, which had an elaborate type mechanism with the odd name DataSqueezer.)
Again, whatever your value is (string, number, date), it is converted into a plain string. This results in a more readable URL.
If you have multiple context values (by binding a list or array of objects to the ActionLinks context parameter), _context_ parameter of the EventLink or ActionLink), then each one, in order, will be added to the URL.
When an event handler method is invoked, the strings are converted back into values, or even objects. A [ValueEncoder|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/ValueEncoder.html] is used to convert between client-side strings and server-side objects. The [ValueEncoderSource|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/services/ValueEncoderSource.html] service provides the necessary value encoders.
...
Full Content
Component Events
Related Articles
Page:
Request Processing
Page:
Page Life Cycle
Page:
Component Rendering
Page:
Page Navigation
Page:
Component Events
Component events are Tapestry's way of conveying a user's interactions with the web page, such as clicking links and submitting forms, to designated methods in your page and component classes. When a component event occurs, Tapestry calls the event handler method you've provided, if any, in the containing component's class.
Let's review a simple example. Here's a portion of the
[CONF] Apache Tapestry Component Events
Component Events
Page edited by Bob Harner
Comment:
Lots of rewording, trying to simplify and organize this material for new users. Not done yet, though.
Changes (62)
h1. Component Events
Component events are the means by which components are made aware of behaviors by the user, such as clicking links and submitting forms.
*Component events* are Tapestrys way of conveying a users interactions with the web page, such as clicking links and submitting forms, to designated methods in your page and component classes. When a component event occurs, Tapestry calls the event handler method youve provided, if any, in the containing components class.
Component events are used for two purposes:
Lets review a simple example. Heres a portion of the template for a page (lets call it Chooser) that lets the user choose a number between 1 and 10:
* They represent requests initiated by the user, triggered by links and forms in the client web browser. These are described more fully in [page navigation|#pagenav.html] and in [request processing|#request.html]. * They represent flow-of-control within a request, allowing one component to notify its container about some kind of circumstance (a form was submitted), or to collect some piece for data from the container. Often, a navigation request (originating with the user) will spawn a number of flow-of-control requests. For example, a Form component will be triggered by an action request, and will then send notification events to announce when the form submission is about to be processed, and whether it was succesful or not. In Tapestry 4, you would configure a parameter of a component with the name of a method to invoke when a certain event occured, usually a request from the client. This has some limitations, including the fact that only a single method could be invoked, and that it tied together a component and a method based on a method name, which required careful coordination between the template and the Java code. Tapestry 5 introduces the concept of _event handler methods_, identified via a naming convention, or via the [OnEvent annotation|http://tapestry.apache.org/current/apidocs/org/apache/tapestry5/annotations/OnEvent.html]. Event handler methods may have any visibility, even private. Normally they are given package private visibility, to support testing. Rather than configure a component to invoke a particular method, you identify one or more methods to listen for events from that component. A single event handler method may receive notifications from many different components. For example, heres a portion of a page (lets call it Chooser) that lets the user choose a number between 1 and 10:
{code:xml}
p Choose a number from 1 to 10: /p
p
t:count end=10 value=index a t:id=select t:type=actionlink context=index${index}/t:comp
...
{code}
The ActionLink component creates an action URL.
Notice that Chooser.tml contains an ActionLink component. When rendered on the page, the ActionLink component creates an action URL, which in this case might look like {{http://localhost:8080/chooser.select/3}}
The URL identifies the page that contains the component (chooser), the type of event (unless it is action, the default and most common event type), the id of the component within the page (select), plus the additional context value(s).
This URL identifies the page that contains the component (chooser), the type of event (unless it is action, the default and most common event type), the id of the component within the page (select), plus the additional context value (3). _Additional context values, if any, are appended to the path._
A sample URL: {{http://localhost:8080/chooser.select/3}}.
Theres no direct mapping from URL to a piece of code. Instead, when the user clicks on the link, the ActionLink component emits events. And then Tapestry ensures that the correct bit of code (your event handler method, see below) gets invoked for those events.
When there are additional context values, they are appended to the path.
This demonstrates a critical difference between Tapestry and a more traditional, action oriented framework. The URL doesnt say what happens when the link is clicked, it identifies _which component is responsible_ when the link is clicked.
This demonstrates a critical difference between Tapestry and a more traditional, action oriented framework. This URL doesnt say what happens when the link is clicked, it identifies _which component is
