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
>
>
>
>
>
>
>
>
>
>
>