8:20 a.m.
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):
#{rich:component('autocomplete')}.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
11:53 a.m.
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);
}
}
~ Lukas
On Wed, Nov 27, 2013 at 3:20 PM, Lukáš Fryč <lukas.fryc(a)gmail.com> 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):
#{rich:component('autocomplete')}.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
1 p.m.
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);
}
}
4041
days inactive
4043
days old
2 comments
2 participants
participants (2)
-
Brian Leathem -
Lukáš Fryč