|Gregory Murray||Apr 10, 2007 10:44 pm|
|Norbert Truchsess||Apr 11, 2007 12:03 am|
|Norbert Truchsess||Apr 11, 2007 12:05 am|
|Gregory Murray||Apr 11, 2007 12:26 am|
|Gregory Murray||Apr 11, 2007 12:48 am|
|Craig McClanahan||Apr 11, 2007 12:58 am|
|Craig McClanahan||Apr 11, 2007 1:19 am|
|Ed Burns||Apr 11, 2007 6:32 pm|
|Ed Burns||Apr 11, 2007 7:52 pm|
|Craig McClanahan||Apr 11, 2007 7:53 pm|
|Ed Burns||Apr 11, 2007 8:28 pm|
|Craig McClanahan||Apr 11, 2007 9:41 pm|
|Craig McClanahan||Apr 11, 2007 9:44 pm|
|Craig McClanahan||Apr 11, 2007 9:51 pm|
|Norbert Truchsess||Apr 11, 2007 10:08 pm|
|Norbert Truchsess||Apr 11, 2007 10:15 pm|
|Craig McClanahan||Apr 12, 2007 12:19 am|
|Norbert Truchsess||Apr 12, 2007 1:19 pm|
|Norbert Truchsess||Apr 12, 2007 2:54 pm|
|Norbert Truchsess||Apr 12, 2007 3:43 pm|
|Gregory Murray||Apr 14, 2007 4:56 pm|
|Gregory Murray||Apr 14, 2007 5:03 pm|
|Craig McClanahan||Apr 14, 2007 5:06 pm|
|Ed Burns||Apr 16, 2007 8:18 am|
|Gregory Murray||Apr 16, 2007 8:32 am|
|Ed Burns||Apr 16, 2007 8:55 am|
|Gregory Murray||Apr 16, 2007 9:09 am|
|Norb...@t-online.de||Apr 16, 2007 9:21 am|
|Ed Burns||Apr 17, 2007 9:59 am|
|Craig McClanahan||Apr 17, 2007 10:23 am|
|Norbert Truchsess||Apr 17, 2007 1:05 pm|
|Craig McClanahan||Apr 17, 2007 3:30 pm|
|Gregory Murray||Apr 18, 2007 1:54 am|
|Norb...@t-online.de||Apr 18, 2007 4:44 am|
|Norbert Truchsess||Apr 19, 2007 1:40 pm|
|Subject:||Re: service-url derived from value-attribute?|
|From:||Norbert Truchsess (norb...@t-online.de)|
|Date:||Apr 17, 2007 1:05:25 pm|
Ed Burns schrieb:
NT> Greg, NT> Ed used this misleading subject, so the 'reall' question got unanswered.
NT> Even if this breaks some of our samples (which just means we have to NT> rename some value-attributes to 'service') my Vote goes to:
NT> 'A ValueExpression in Value-attribute shall allways be evaluated on NT> server-side and the result shall be sent to the widget as literal. NT> if there's no 'service'-attribute in widget's tag, there ain't no NT> service-attribute being rendered to the widget.'
But what about the service-url sent to the client? If there is no service attribute on the tag, but there is a value attribute that is a ValueExpression, what then?
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.
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).