Page History

Table of content

• Background
• Client Side Support
• Proposals
  1. Page methods
  2. Ajax Controls
  3. Ajax Behaviors
• Which one?

Anchor
background background

Background

I'd like to see improved Ajax support in Click 2.2.0, especially around the area of reusable Ajax controls. It is not currently possible to create such controls.

...

I'll use jQuery where client-side JavaScript is required to convey a concept.

Anchor
client-side-support client-side-support

Client Side Support

There are two sides to Ajax support, the client side HTML markup and JavaScript code to initiate the Ajax request, and the server side support, to handle the request and return a partial response.

...

Next I'll cover the proposals to handle the Ajax request and response on the server-side.

Proposals

Anchor
page-methods page-methods

1. Ajax aware Page methods

The simplest way to improve Ajax support is to allow Page methods to be called directly from the browser. The Page method could return a Partial response that contains the data to return to the browser.

...

• caters only for GET requests, not POSTS, since page events are not executed
• does not cater for ajax aware controls
• interaction with other components on the Page will be fairly limited, since no initialization or binding occurs

Anchor
ajax-controls ajax-controls

2. Ajax aware Controls

A more sophisticated approach would be to allow control listeners to be invoked for Ajax requests. A special AjaxListener can be set as a Control listener, that will be invoked if the incoming request targets that control:

...

• A control can only have a single listener defined. How will a control handle multiple incoming events? For example a field might handle two Ajax events, "onblur" for validation purposes, and "onkeypress" for auto-completion. The Event object passed into the listener could be inspected, but this leads to if-else logic. This brings up the idea of having multiple listeners per control.
  • Pro: Each listener could be registered for a specific event, and will only be triggered for Ajax requests of that event type.
  • Con: Having multiple listeners per control could increase the conceptual complexity and could lead to an increase in maintenance. For example, if the client-side code neglects to pass the event parameter, no listener will be invoked. The user will now have to deal with whether the control ID or event request parameter or both are missing.

Anchor
ajax-behaviors ajax-behaviors

3. Behaviors

Behaviors is a concept borrowed from Wicket and JSF. A behavior is attached to a Control and will be notified by the Control for specific events such as onInit, onProcess, onRender, getHeadElements. A behavior can also act as a listener and receive events, just like a Control does.

...

• The initial thinking is that a behavior can only have a single listener defined. How will a behavior handle multiple incoming events? For example two behaviors could be registered on a field, "onblur" for validation purposes, and "onkeypress" for auto-completion. The Event object passed into the listener could be inspected, but this leads to if-else logic. This brings up the idea of having multiple listeners per behavior.
  • Pro: Each listener could be registered for a specific event, and will only be triggered for Ajax requests of that event type.
  • Con: Having multiple listeners per behavior could increase the conceptual complexity and could lead to an increase in maintenance. For example, if the client-side code neglects to pass the event parameter, no listener will be invoked. The user will now have to deal with whether the control ID or event request parameter or both are missing.

Anchor
which which

Which one?

I'm leaning towards