Rich Widget Factory API that fulfills needs of JSF component JavaScript API

Hey guys,

I have found a following issue:

we expose public JSF component API for Widget Factory based component by

allowing to reference widget reference (i.e. call methods directly on

widget instance):

#.close();

It will make sure that e.g. following methods can be invoked:

http://www.richwidgets.io/api/classes/autocomplete.html

But those methods doesn't have to be as rich as JSF component we had in RF4.

E.g. in Autocomplete, we had methods getValue() and setValue().

Those methods doesn't do anything else than setting an appropriate value to

the input field. In order to allow unified API, we could expose those

methods for RF5 Autocomplete as well, which will be just syntactic sugar in

terms of Widget Factory -based API.

WDYT?

~ Lukas

One of the solutions could be as follows:

RichFaces components API will be exposed on Bridges instead of components:

var bridge = ...;

var autocomplete = this.input.data('autocomplete')

$.each(autocomplete, function(key, value) {

  // for public methods

  if (key.indexOf('_') !== 0) {

    bridge[key] = function() {

      autocomplete[key].apply(autocomplete, arguments);

    }

   }

}

This could be even generalizes to bridge-base.js.

Then, once we reference public methods from widget and expose them to

bridge,

we could simplify RichFaces.component method.

Finally, we could expose JSF-facing JavaScript API methods on the bridge:

}

~ Lukas

On Wed, Nov 27, 2013 at 3:20 PM, Lukáš Fryč <[e-mail]> wrote:

Hey guys,

I have found a following issue:

we expose public JSF component API for Widget Factory based component by

allowing to reference widget reference (i.e. call methods directly on

widget instance):

#.close();

It will make sure that e.g. following methods can be invoked:

http://www.richwidgets.io/api/classes/autocomplete.html

But those methods doesn't have to be as rich as JSF component we had in

RF4.

E.g. in Autocomplete, we had methods getValue() and setValue().

Those methods doesn't do anything else than setting an appropriate value

to the input field. In order to allow unified API, we could expose those

methods for RF5 Autocomplete as well, which will be just syntactic sugar in

terms of Widget Factory -based API.

WDYT?

>

~ Lukas

[bleathem]

Lukas, this is an interesting observation, and I like your proposed

solution.

However, in thinking about it, I'm wondering if the JSF bridge widgets

should simply extend their RichWidget counterpart.  This would offer a

number of advantages:

1) Allow for extending the widget API as per your initial suggestion

2) Instantiate a single widget per component (instead of the 2 we are

now)

This would make the widgets easier to consume and interact with for a

JSF developer, as they wouldn't have to distinguish between

functionality in the bridge and in the widget.

This would of course have to be explored in 5.0.0.Alpha3.

Brian

On Fri 29 Nov 2013 09:53:12 AM PST, Lukáš Fryč wrote:

One of the solutions could be as follows:

RichFaces components API will be exposed on Bridges instead of components:

var bridge = ...;

var autocomplete = this.input.data('autocomplete')

$.each(autocomplete, function(key, value) {

  // for public methods

  if (key.indexOf('_') !== 0) {

    bridge[key] = function() {

      autocomplete[key].apply(autocomplete, arguments);

    }

   }

}

This could be even generalizes to bridge-base.js.

Then, once we reference public methods from widget and expose them to

bridge,

we could simplify RichFaces.component method.

Finally, we could expose JSF-facing JavaScript API methods on the bridge:

{

    setValue : function(value) {

       autocomplete.input.val(value);

    }

}

_______________________________________________

richfaces-dev mailing list

[e-mail]

https://lists.jboss.org/mailman/listinfo/richfaces-dev