Hi,
BS>> The onclose of a view scoped socket can be used to notify the client
of
BS>> an expired view.
Agreed.
BS>> The onclose of a session scoped socket can be used to notify the
client
BS>> of an expired session.
I tend to disagree. The reason that justify my position is the websocket
lifetime is shorter than the session scope lifetime. So, a if a view is
discarded the associated websocket connection is no longer valid, but if the
session is discarded, all views related to this session are discarded too.
BS>> I only don't agree that the view must be closed or discarded on the
BS>> client automatically. Let the developer take responsibility for this.
Well, I'm not saying to make it automatically, I agree it is a developer
resposibility. I just want to check how the developer can do this.
I have checked that in primefaces, p:ajax listener="#{...}" can return a
String that can be used as a redirect, in the same way action="#{...}"
does.
So in that library it is valid to do this (hope to not be wrong):
<p:socket ...>
<p:ajax event="close" listener="#{...}"/>
</p:socket>
It is a cleaner syntax, but f:ajax does not support that. Maybe use
f:websocket and h:commandScript is enough in this case.
regards,
Leonardo Uribe
2016-10-13 2:02 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
> Hi,
>
> The onclose of a view scoped socket can be used to notify the client of an
> expired view. The onclose of a session scoped socket can be used to notify
> the client of an expired session. I only don't agree that the view must be
> closed or discarded on the client automatically. Let the developer take
> responsibility for this.
>
> Cheers, B
>
> On Tue, Oct 11, 2016, 04:46 Leonardo Uribe <leonardo.uribe_at_irian.at>
> wrote:
>
>> 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/
>> JAVASERVERFACES_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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>