Hi
Good to know that. Thanks Bauke for your efforts. Since omnifaces is Apache
license v2.0, which is compatible with MyFaces codebase, I can take a look.
There is a possible use case that maybe it is worth to study a bit.
The problem is use f:websocket to trigger a redirect over a view that
has expired. The idea is if a view has been discarded, all its associate
websockets must be closed automatically and that means the view on the
client it is no longer valid, so it must be closed or discarded on the
client too.
In that case a combination of f:websocket and f:ajax doesn't help, but you
could use f:websocket and h:commandScript, but a cleaner syntax using a
custom attribute in f:websocket without h:commandScript could help.
BS>> I will get back on h:commandScript+portlets later. This is a separate
issue not related to f:websocket.
Ok.
regards,
Leonardo Uribe
2016-10-08 18:07 GMT-05:00 Josh Juneau <juneau001_at_gmail.com>:
> Thanks Bauke, I appreciate your time and effort. Will try to take a look
> at the updated <o:socket>.
>
>
> Josh Juneau
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
>
> On Oct 8, 2016, at 3: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/6f0407c2d5d877d20025a7f249597cfce06c924d
>
> 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
>
> On Mon, Oct 3, 2016 at 2:57 PM, Michael Müller <michael.mueller_at_mueller-
> bruehl.de> wrote:
>
>> +1
>>
>> Herzliche Grüße - Best Regards,
>>
>> Michael Müller
>> Brühl, Germany
>> blog.mueller-bruehl.de
>> it-rezension.de
>> @muellermi
>>
>>
>> Read my books
>> "Web Development with Java and JSF": https://leanpub.com/jsf
>> "Java Lambdas und (parallel) Streams" Deutsche Ausgabe:
>> https://leanpub.com/lambdas-de
>> "Java Lambdas and (parallel) Streams" English edition:
>> https://leanpub.com/lambdas
>>
>> On 09/26/2016 01:41 PM, Josh Juneau wrote:
>>
>> +1...I agree. Individuals already understand the way that <f:ajax>
>> functions, so it makes sense to use it if possible.
>>
>> Josh Juneau
>> juneau001_at_gmail.com
>> http://jj-blogger.blogspot.com
>> https://www.apress.com/index.php/author/author/view/id/1866
>>
>>
>> On Mon, Sep 26, 2016 at 5:38 AM, Kito Mann <kito.mann_at_virtua.com> wrote:
>>
>>> +1 for adding <f:ajax> support to <f:websocket>. I believe PrimeFaces
>>> does this with <p:socket>, and it's certainly more intuitive than hooking
>>> it up to <f:commandScript>.
>>>
>>> ___
>>>
>>> Kito D. Mann | @kito99 | Author, JSF in Action
>>> Web Components, Polymer, JSF, PrimeFaces, Java EE, and Liferay training
>>> and consulting
>>> Virtua, Inc. | virtua.tech
>>> JSFCentral.com | @jsfcentral | knowesis.io
>>> <http://knowesis.io/web/webcomponents> - fresh Web Components info
>>> +1 203-998-0403 <%2B1%20203-998-0403>
>>>
>>> * Listen to the Enterprise Java Newscast: *http://
>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>> <http://ww.enterprisejavanews.com>*
>>>
>>>
>>> On Sun, Sep 25, 2016 at 11:55 AM, Bauke Scholtz <balusc_at_gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> h:commandScript is result of https://java.net/jira/browse/J
>>>> AVASERVERFACES_SPEC_PUBLIC-613 See also
>>>> http://arjan-tijms.omnifaces.org/p/jsf-23.html for others.
>>>>
>>>> I do understand the h:commandScript limitation in portlet case, but in
>>>> a portlet app there's also only one JavaScript context.
>>>>
>>>> I have to admit that the f:websocket+f:ajax looks more natural. I will
>>>> try creating a POC on this. I only don't like the idea of turning the
>>>> f:websocket from TagHandler into UIComponent. It's really kind of view
>>>> metadata.
>>>>
>>>> Cheers, B
>>>>
>>>>
>>>>
>>>> On Sat, Sep 24, 2016 at 3:53 AM, Leonardo Uribe <
>>>> leonardo.uribe_at_irian.at> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I see, so this is hidden in the spec. Thanks for mention it.
>>>>>
>>>>> I have to say I can see a problem with this structure, and it is
>>>>> related to the "name" used on the script.
>>>>>
>>>>> In JSF each component has it own clientId that is calculated somehow.
>>>>> So according to the location of the component inside the tree, the clientId
>>>>> is generated.
>>>>>
>>>>> The way how clientId works ensures the component can be relocated to
>>>>> different parts of the tree and it will still work.
>>>>>
>>>>> The problem with a hardcode name is that you lose this property in the
>>>>> code. If you are in a portlet case, I can see that if the same component is
>>>>> used twice on different portlets, the page will crash by a duplicate
>>>>> definition.
>>>>>
>>>>> There is a component in tomahawk sandbox that try this and it is
>>>>> called s:jsCallbackFunction . Remember the component is in sandbox, so in
>>>>> that sense it is experimental.
>>>>>
>>>>> * This component creates a function inside an inline <script>
>>>>> tag,
>>>>> * with a function that can be referenced later using
>>>>> getFunctionName() method
>>>>> * inside this component instance or the EL function
>>>>> #{s:jsCallbackFunctionName(UIComponent)}.
>>>>> * <p>
>>>>> * Inside the function, the following code is added:
>>>>> * </p>
>>>>> * <code>
>>>>> * generatedFunctionNameUsingClientIdAndEventName = function (...
>>>>> arguments ...){
>>>>> * ... jsStartContent ...
>>>>> * ... clientBehavior scripts ...
>>>>> * ... jsEndContent ...
>>>>> * }
>>>>> * </code>
>>>>> * <p> This is useful in situations where the context where this
>>>>> script is
>>>>> * rendered is important, and it is not possible to put the scripts on
>>>>> static
>>>>> * javascript files.</p>
>>>>>
>>>>> What I mean is with an EL function it is possible to generate the
>>>>> function name based on the clientId of the component and avoid the problem
>>>>> h:commandScript has.
>>>>>
>>>>> Let me be clear about this: the way how h:commandScript works right
>>>>> now creates a conflict for portlet case, and I do not want to create
>>>>> another one after spend a lot of time trying to solve
>>>>> JAVASERVERFACES_SPEC_PUBLIC-790.
>>>>>
>>>>> The way how h:commandScript and f:websocket interact should be more
>>>>> subtle. If f:websocket is a component with an id, it should be possible to
>>>>> reference it so you could "declare" a h:commandScript to be called for
>>>>> f:websocket. So, with one f:websocket it should be possible to call many
>>>>> h:commandScript functions.
>>>>>
>>>>> I think we should focus our efforts in create a syntax easy to
>>>>> understand, that solve the problem of update parts of the view after an
>>>>> event triggered on the server.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>>
>>>>> 2016-09-23 16:01 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> It has already been thought about, it can be combined with
>>>>>> h:commandScript, also new in JSF 2.3.
>>>>>>
>>>>>> <f:websocket ... onmessage="someCommandScript" />
>>>>>> <h:commandScript name="someCommandScript" action="#{bean.pushed}"
>>>>>> render="foo" />
>>>>>>
>>>>>> The message will transparently be available as request parameters in
>>>>>> associated bean.
>>>>>>
>>>>>> Cheers, B
>>>>>>
>>>>>> On Fri, Sep 23, 2016 at 9:22 PM, Leonardo Uribe <
>>>>>> leonardo.uribe_at_irian.at> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> I have been thinking about the way how f:websocket / PushContext
>>>>>>> works, just trying to see what's missing or another way to see this
>>>>>>> feature, to see if we can make it better.
>>>>>>>
>>>>>>> Even if f:websocket behavior is well understood and very flexible
>>>>>>> the way it is, what bothers me about it is this feature is too javascript
>>>>>>> specific. What I mean is you always need to write a javascript block to
>>>>>>> handle the incoming processing.
>>>>>>>
>>>>>>> But sometimes what you really want is update a part or just an
>>>>>>> specific component in the view. In other words, sometimes the web socket is
>>>>>>> only used as way to notify the view that something has changed on the
>>>>>>> server and the view needs to be updated somehow.
>>>>>>>
>>>>>>> In other words, sometimes the user doesn't want to override
>>>>>>> onmessage and instead just say update component xxx or yyy.
>>>>>>>
>>>>>>> For example, imagine the following syntax:
>>>>>>>
>>>>>>> <f:websocket channel="ping">
>>>>>>> <f:ajax event="update" render="myInfoBox"/>
>>>>>>> </f:websocket>
>>>>>>>
>>>>>>> On the server the update is triggered using this:
>>>>>>>
>>>>>>> @Inject
>>>>>>> @Push(channel="ping")
>>>>>>> private PushContext push;
>>>>>>>
>>>>>>> ....
>>>>>>>
>>>>>>> push.send("update");
>>>>>>>
>>>>>>> Now, f:websocket looks more like a component that implements
>>>>>>> ClientBehaviorHolder than a tag, and the "default" onmessage is a method
>>>>>>> that takes the message and if the event match the message it triggers the
>>>>>>> related f:ajax script.
>>>>>>>
>>>>>>> In html markup, f:websocket should create a html tag with the
>>>>>>> associated custom events.
>>>>>>>
>>>>>>> What do you think guys about it? does it work? is it useful? is it
>>>>>>> worth?
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Leonardo Uribe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>