THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- It could encourage writing complex Pages that are hard to understand and maintain
- Could lead to an explosion of control subclasses to add Ajax functionality. This can be alleviated using Helper objects to encapsulate Ajax behavior
- Can lead to difficult to find bugs if there is mismatch between the client side Ajax ID attribute and the server side control ID attribute. Dynamic stateless pages could also lead to difficulties if an Ajax control is added inside another control's listener and subsequent requests won't have the Ajax control present in the server-side component tree.
- Implementation is more complex than for Page Methods
- The stateless nature of Click makes Ajax applications inherently tricky, because if a non-Ajax request is made to the server, all Ajax related state will be undone. This can be alleviated by using Stateful pages, but since requests to stateful pages are serialized, this creates another, albeit small, problem in that parallel Ajax requests to a stateful page won't work. In other words if the browser makes two Ajax requests to a stateful Page where the first request is very resource intensive and takes 10 seconds to execute, the second Ajax request will have to wait until the first request finishes. Although this might not be a common use case, it is worth taking into consideration.
...
Code Block | ||||
---|---|---|---|---|
| ||||
public class MyPage extends Page { public void onInit() { Form form = new Form("form"); TextField field = new TextField("field"); AjaxBehavior behavior = new AjaxBehavior("click") { // Note: Behavior has an onAction event similar to an ActionListener public Partial onAction(Control resource, Event event) { Partial partial = new Partial(); partial.add(new Label("hello")); return partial; } }); field.addBehavior(behavior); form.add(field); // <- First we attach the field to its parent form to ensure the field.getId() // will return its fully qualified ID: "form-field", not just "field". } } |
Pros:
- Won't lead to an explosion of new controls since the Ajax behavior is encapsulated inside a reusable object. That said certain controls, such as Form, might still benefit from an Ajax specific subclass, however this should be avoided as much as possible so that existing Form subclasses can add Ajax behavior.
- If JavaScript is not enabled the Control ActionListener's onAction(Control sourceIf JavaScript is not enabled the Control ActionListener's onAction(Control source) method will be invoked, providing a simple fallback mechanism.
- Both POST and GET requests are supported. For example an Form could be created which performs an Ajax post. As the onInit event is executed, the Form and Fields will be created and ready to be bound to incoming request parameters. Thus a Submit button can register an Ajax listener and save the submitted Form data to the database, before responding with a Partial response, such as a success message, or error message.
- Can create prepackaged Ajax behaviors and Ajax aware controls
Cons:
- It could encourage writing complex Pages that are hard to understand and maintain
- The concept of a Behavior is a bit complex to understand at first.
...