Hi
BS>> +1 as to f:ajax onevent being too generic. I'd also like to see an
BS>> f:ajax onstart/oncomplete/onsuccess/onerror. I only fear some
confusion
BS>> with PrimeFaces as their p:ajax oncomplete is essentially executed at
BS>> same time as f:ajax onsuccess.
I see. Primefaces javadoc says this about p:ajax :
onstart: Client side callback execute before ajax request is begins.
oncomplete: Client side callback execute when ajax request is completed
and dom is updated.
onsuccess: Client side callback execute before dom is updated.
onerror: Client side callback execute when ajax requests returns
with error response.
But JSF says this (see JSF 2.2 section 14.4.1):
- begin: Occurs immediately before the request is sent.
- complete: Occurs immediately after the request has completed. For
successful
requests, this is immediately before javax.faces.response is called. For
unsuccessful requests, this is immediately before the error handling
callback is invoked.
- success: Occurs immediately after jsf.ajax.response has completed.
I have to say it, JSF description looks better than Primefaces to me. In my
opinion we shouldn't worry about it.
BS>> -1 as to aversion of "getting hands dirty with JavaScript". JSF should
BS>> be flexible towards pragmatic developers.
I agree JSF should be flexible towards pragmatic developers. It is just
the magic about JSF is the ability to create reusable component units
and mashups. I would like to keep that property.
regards,
Leonardo Uribe
2016-10-28 3:32 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
> 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
>>>>> >
>>>>>
>>>>>
>>>>
>>>
>>
>