The DataAlterationRequest (DAR) encodes a primitive operation on an abstract bean model, consisting of either the attachment or detachment of an object appearing at a particular EL bean path. The object value referred to in the DAR may require conversion at the point of delivery by the DARApplier. Note that if the value object is of type String, it may represent either i) a genuine String value, ii) an EL reference designating an r-value to be read at the point of delivery, or iii) an XML-encoded object tree. These cases cannot be disambiguated (reliably) until the type designated by the path field can be determined.

The data members of DAR appear here:

public class DataAlterationRequest {
  public static final String ADD = "add";
  public static final String DELETE = "delete";
  public String path;
  public Object data;
  public String type = ADD;

The RSVC log approach of RSF towards state essentially decomposes all user operations within a particular scope as a list of DAR objects. This enables "side-effected" or otherwise unreasonable bean models to be used directly.

It's possible that all of this functionality should be replaced by OGNL. I'm a little concerned at the performance implications, given the reliance of RSF on very high throughput of EL binding (although it looks like a FastClass-based OGNL MethodAccessor could be quite easy to produce), and also the resultant complexity.

Historical note: DAR was actually invented for a completely different purpose, although prompted by a similar cause: The timing of JSF bean manipulation operations was seen to be so haywire that it was considered too hazardous to try to interleave a user transaction in amongst them. The DAR was invented so that beans in the bean model could act as a "proxy", accumulating alteration events which were delivered at some arbitrary time in arbitrary order, which were simply queued - once application code was finally invoked, the transaction could be opened, the queue replayed and the alterations effected at the desired time in a visible, reliable transaction scope.

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-) was last changed on 19-Jul-2006 09:36 by UnknownAuthor