Ed Burns schrieb:

So how shoud this work? (Please excuse me for the quite lengthy response, but it's not sufficient to just talk about attribute-syntax without understanding the underlying mechanisms).

generally speaking there are two ways of communication in between a widget and it's serverside:

1. a widget polls a service. The request is initiated by the widget itself and response is directly send back to the widget.

2. the widget hold holds a value and provides a mechanism to retrieve and set this value by javascript from outside the widget. Communication is initiated from a 'page-wide' framework by collecting widget value(s) (not limited to a single widget), sending the collected set of values to a serverside service. The response contains a 'self-describing' structure that contains return-values that the page-wide framework brakes up into the individual values which it then passes to each individual widget.

Each 1) and 2) may be extended in a way that the serverside might push a value at any given time (using comet-protocol), but given todays browser limitations (in terms of supported number of concurrently open connections) only case 2) can be expected to work efficiently.

For both 1) and 2) the value is not limited to be a simple type - it may be any complex data-structure that might be encodet in a string (e.g. xml or json).

For 1) a service-url is mandatory for the widget to connect to it's service.

For 2) no service-url is required when the widget is instantiated. The widget needs to be register with the page-wide framework that knows about the service-url.

Both Ways of initiating data-exchange in between a widget and it's server-side make sense for certain use-cases.

Case 1) is good for applications where the server-side counterparts of the widgets are orthogonal to each other, or there is at least no need to enforce transactional behavior in between widgets. The application is a composition of weakly (client-side) coupled components where it doesn't cause trouble when some part of the screen might display outdated values while others are allreay updated. An example is a suggestion-control whiches suggested options to choose from have no dependencies to other entry-fields on the page.

Case 2) is good for applications that require enforcement of transactional behavior in between widgets. (E.g. a shoppingcart where it's mandatory that the cart's content and the prices are allways in sync).

Widgets can easyly be designed to support both types of use. It's as easy as to provide getValue/setValue and retrieveState/saveState-methods. (Plus some kind of cross-widget page-wide ValueChangeListener-mechanism that weaves this all together)

Which type of communication is chosen to be used depends on the business-requirenments and the server-side capabilities to efficiently support more complex dependencies and transactional behavior. Since JSF can easily support type 2) communication model this should be the default here. Setting a value-attribute alone should result in the (server-side) computed value to be send with the response (-page) that instantiates the widget, registers the widget with jMaki (and Dynafaces) and sets up client-side valuechangelistener-dependencies (Glue). On a registered valuechange-event jMaki could use Dynafaces to collect all widgets values, send them to the server, retrieve and parse the response and distribute new widget-values to all affected widgets. At the same time the developer should allways be free to choose type 1) communication by setting the 'service'-attribute, which allows to integrate widgets that depend on services that do not integrate with the jsf-lifecycle. (E.g. a google-map-widget).

- Norbert