35 messages in net.java.dev.ajax.devRe: service-url derived from value-at...| From | Sent On | Attachments |
|---|---|---|
| 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 19, 2007 1:40:22 pm | |
| List: | net.java.dev.ajax.dev | |
If all agree I'd implement the following behaviour (as lined out by Greg below):
value: either literal or ValueBinding, (no service-url derived from value) options: either literal of ValueBinding. service: either literal or MethodBinding, if MethodBinding is set, an URL pointing to the PhaseListener is rendered (as it is now).
- Norbert
Norb...@t-online.de schrieb:
On Wed, 18 Apr 2007 10:54:41 +0200 Gregory Murray wrote: Greg> I hope you all don't mind but I've commented a bit inline to save on Greg> email traffic.
On Apr 17, 2007, at 3:30 PM, Craig McClanahan wrote:
Norbert Truchsess wrote:
Ed Burns schrieb:
On Mon, 16 Apr 2007 18:21:38 +0200, "Norbert.Truchsess@t- online.de" said:
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?
Ed
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.
Greg> A service or a topic.
- Service (as something to connect to over the network)
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.
Greg> This could be done in glue application wide or on a page by page Greg> basis. Dynamic faces uses this approach today and this is the Greg> approach I would like to encourage. This brings me to wonder if we
Greg> should migrate away from widget specific services and start thinking Greg> in terms of topic and have glue code and client side JavaScript value Greg> binding expressions to get widgets the data they need. We are taking Greg> this approach with the Java BluePrints program and it seems to be
Greg> working.
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.
Greg> I prefer this.
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.
Greg> I think we should not dictate this at a widget level but enable users Greg> to decide on a case by case basis. A framework that does too much
Greg> might be seen as restrictive. Not to say we should not provide a Greg> recommended approach.
- agree, we should not dictate, but support both and let the users choose the appropriate approach. And obviously we should hand out reasonable guidelines that allow for a valid decision.
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).
Greg> We also want to investigate both DWR which provides a client-server Greg> binding which we can bind to widgets using JavaScript clientside Greg> value binding expressions. Dojo data is another topic we should Greg> investigate more as it is trying to solve this.
from my understanding DWR implements the Type 1) communication pattern?
Craig> I can see use cases for both behaviors. What I don't see is how I Craig> can: Craig> Craig> * Have both at the same time (an autocomplete text widget that uses Craig> "service" Craig> for the completion list, and "value" for , err, the value :-).
Craig> Every time I read Craig> a description of the proposed algorithm, it seems that I can only Craig> have one or Craig> the other.
The widget should support both and if both is used 'at the same time', one will just overwrite the other. E.g. an autocomplete text widget might get it's autocomplete-list from its service, while the page-wide framework might overwrite the value (and if appropriate even the autocomplete-list) if some condition outside the widgets scope is met.
Craig> * Turn off the (2) behavior until I explicitly ask for it. I don't Craig> want any of the Craig> values sent as client side updates occur; I want to send the Craig> entire related set, Craig> once, when the user initiates an appropriate action. (This is Craig> essentially what Craig> Dynamic Faces does, so sending the values separately is redundant and Craig> wasteful.)
- agree, without having specified which set should be sent and when, there should just nothing happen.
Craig> * Have the (2) behavior of sending values asynchronously, even if
Craig> my server Craig> side component does not have a value binding on the value Craig> property. That Craig> should be a detail invisible to the client side.
- agree
Greg> I agree with Craig here: Greg> Greg> We really need to keep the model consistent and I think we need to
Greg> work the way JSF handles things. Greg> Greg> Here is what I would like (I'm pretty much re-iterating what is above): Greg> Greg> service = Always loaded after the widget is loaded and is handled on Greg> a widget per widget basis. A service might just load the data or it Greg> more be more interactive. We should not define the API. Craig, Carla Greg> and I have discussed some URL patterns which we can discuss in a Greg> separate email that are based on the GET / POST / PUT / DELETE HTTP Greg> Greg> methods which we can use to map changes. These URLs would be Greg> generated under the covers and would be the wargs.service that a Greg> developer receives.
'service' being optional?
Greg> value = A value get rendered when the page is rendered and does not Greg> change. This is what the widget sees. Value bound expressions would Greg> be supported but the values would not be updated. If a user wants a Greg> value that will be updatable on the server we will requires the Greg> users to use a service from here on in.
agree to the point that the value is rendered and sent with the page. If the value should be updatable on the server, but no service is providet the widget just cannot update the value itself - in this case it can only be sent to the server by the page-wide framework whenever it's apropriate or a regular 'submit' takes place.
Greg> options = a new property that allows for another set of objects to be Greg> sent to the client. Like the value these can be mapped to value bound Greg> expressions and they do not change
both 'value' and 'options' should be updatable on the client-side by the page-wide framework. This way the serverside could 'push' updates to widgets value and options without an active poll (from the widget itself) having happened before.
The main difference in between value and options is that a value will trigger Validation and ValueChangeEvents on the serverside as it's submitted, while 'Options' is not submitted to the server at any time.
Greg> While we have done the mappings from value to service in JSF for Greg> method bound expressions I think it is generally a bad idea. We can Greg> migrate existing users and the same API we have today to be using the Greg> service attribute. This would not be too much work and I think now Greg> is the time for this.
- agree
Greg> Can we all agree to this ? Greg> Greg> -Greg