Hi,
+1 as to f:ajax onevent being too generic. I'd also like to see an f:ajax
onstart/oncomplete/onsuccess/onerror. I only fear some confusion with
PrimeFaces as their p:ajax oncomplete is essentially executed at same time
as f:ajax onsuccess.
-1 as to aversion of "getting hands dirty with JavaScript". JSF should be
flexible towards pragmatic developers.
Cheers, B
On Fri, Oct 28, 2016 at 8:19 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> Hi
>
> BS>> Usage of <h:commandScript name> is essentially exactly the same as
> BS>> <f:ajax onevent>. Its vdldoc however merely states "The name of the
> BS>> JavaScript function that will handle UI events". Should this also be
> BS>> improved?
>
> Well, to be honest f:ajax onevent is one of those things I really hate with
> passion in JSF spec. I never understood that part. Let me show the defects
> of the old solution and possible solutions to this defects.
>
> The first defect is described in this spec issue:
>
> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-873
> Add pre and post ajax transaction function callbacks
>
> The description says this:
>
> "... Use case: say the user wants to use some effect to fade in/out the
> content to be updated via Ajax. It would be nice to have a way to install
> pre-request and post request callback functions. On the post request, we
> need to have actually two functions. One when we have the response but
> have not yet done the replacement, and another after we have done the
> replacement. ..."
>
> The reason why this issue exists is there is no easy way to hook scripts to
> f:ajax without define a function callback. In other words the callback
> is not a good match for f:ajax.
>
> The reason is developers are usually interested in perform actions before
> and after the ajax operation, so why define a global function for
> something
> that should be an attribute of f:ajax? Why do developers have to embed
> all these lines of code?:
>
> function onEventFunction(data) {
> var status = data.status; // Can be "begin", "complete" or "success".
>
> switch (status) {
> case "begin": // Before the ajax request is sent.
> // ...
> break;
>
> case "complete": // After the ajax response is arrived.
> // ...
> break;
>
> case "success": // After update of HTML DOM based on ajax
> response..
> // ...
> break;
> }
> }
>
> Instead this:
>
> <f:ajax event="click" render="renderMe" onsuccess="do_something_useful"/>
>
> No callback, no useless code, just what the developer really needs.
>
> Think a bit radical further:
>
> <f:ajax event="click" render="renderMe">
> <s:effectFade event="success" forId="panel"/>
> </f:ajax>
>
> A client behavior could have nested client behavior instances? Of course.
> THAT SHOULD BE POSSIBLE IN THE SPEC.
>
> Why do you want to write an ugly callback when you can declare what you
> want
> and encapsulate the client behavior in a graceful way?
>
> h:commandScript fills the gap when you really need to call the script from
> somewhere. Ok, I get it. But it is better if we can kill the callback and
> instead prefer client behavior + strenght the event model.
>
> If the callback is still required by whatever reason, let the user define
> the "name" but if the user doesn't want to remember the function name use
> a generated one derived from the clientId using an EL Function. This will
> cover all possible combinations without any degradation over flexibility.
>
> In summary:
>
> - Client Behavior API has a mayor fault, and it is that you can't mix them.
> - All ClientBehavior instances should implement ClientBehaviorHolder.
> - f:ajax has 3 client behavior events : begin, complete and success.
> - h:commandScript is a component that is useful but on situations where
> the client behavior event model does not help, and you need to get your
> hands dirty with javascript (a hack cannot be a substitute of an
> abstraction).
> - The changes proposed does not suppose any degradation over flexibility.
> Instead, they are improvements that can be done on the way and that helps
> to build more stable and reusable component units in JSF applications.
>
> regards,
>
> Leonardo Uribe
>
> 2016-10-27 3:15 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
>
>> Hi,
>>
>> Usage of <h:commandScript name> is essentially exactly the same as
>> <f:ajax onevent>. Its vdldoc however merely states "The name of the
>> JavaScript function that will handle UI events". Should this also be
>> improved?
>>
>> Cheers, B
>>
>> On Wed, Oct 26, 2016 at 3:47 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
>> wrote:
>>
>>> Hi
>>>
>>> NG>> Therefore I propose that the responsibility of namespacing the
>>> NG>> h:commandScript "name" attribute be placed on the JSF portlet
>>> developer,
>>> NG>> and not on the FacesBridge or Faces Runtime.
>>>
>>> Sounds good to me. Maybe a warning in the tlddoc or javadoc of
>>> h:commandScript
>>> "name" would be helpful, to avoid later reports on the issue tracker.
>>> Something like "... it is resposibility of the developer to choose a
>>> naming
>>> convention if the component could be rendered many times on the same
>>> view ..."
>>>
>>> The important thing is one way or another, the way how to use "name" must
>>> be clear to developers.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> 2016-10-25 18:28 GMT-05:00 Neil Griffin <neil.griffin_at_portletfaces.org>:
>>>
>>>> Sorry, typo: I should have written "responsibility of namespacing the
>>>> h:commandScript ..." and not h:commandButton.
>>>>
>>>> > On Oct 25, 2016, at 7:19 PM, Neil Griffin <
>>>> neil.griffin_at_portletfaces.org> wrote:
>>>> >
>>>> > @Bauke, @Leonardo: Thank you very much for considering the portlet
>>>> case.
>>>> >
>>>> > Portlet developers are aware that they need to namespace JavaScript
>>>> function names.
>>>> >
>>>> > I recently tried the following example with Pluto 3.0 + Mojarra 2.3
>>>> and it worked fine:
>>>> >
>>>> > <?xml version="1.0" encoding="UTF-8"?>
>>>> > <ui:composition xmlns="http://www.w3.org/1999/xhtml"
>>>> > xmlns:h="http://xmlns.jcp.org/jsf/html"
>>>> > xmlns:portlet="http://xmlns.jcp.org/portlet_3_0"
>>>> > xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
>>>> >
>>>> > <portlet:namespace var="portletNamespace" />
>>>> > <h:form>
>>>> > <h:commandScript name="#{portletNamespace}myJsClientFunction"
>>>> action="#{myBean.myJavaServerMethod('bar')}" render=":output" />
>>>> > </h:form>
>>>> > <button onclick="#{portletNamespace}myJsClientFunction()" />
>>>> > <h:outputText id="output" value="#{myBean.output}" />
>>>> >
>>>> > </ui:composition>
>>>> >
>>>> > Therefore I propose that the responsibility of namespacing the
>>>> h:commandButton "name" attribute be placed on the JSF portlet developer,
>>>> and not on the FacesBridge or Faces Runtime.
>>>> >
>>>> >
>>>> > Best Regards,
>>>> >
>>>> > Neil
>>>> >
>>>> >> On Oct 8, 2016, at 4:02 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> I just added <f:ajax> support to OmniFaces <o:socket>:
>>>> https://github.com/omnifaces/omnifaces/commit/6f0407c2d5d877
>>>> d20025a7f249597cfce06c924d
>>>> >>
>>>> >> The basics work fine and it's indeed much more natural, but I still
>>>> need to investigate and if necessary improve the behavior of "connected"
>>>> and "rendered" attributes. Once I'm satisfied, I will rework f:websocket
>>>> based on this.
>>>> >>
>>>> >> I will get back on h:commandScript+portlets later. This is a
>>>> separate issue not related to f:websocket.
>>>> >>
>>>> >> Cheers, B
>>>> >
>>>>
>>>>
>>>
>>
>