+1
Herzliche Grüße - Best Regards,
Michael Müller
Brühl, Germany
blog.mueller-bruehl.de <
http://blog.mueller-bruehl.de/>
it-rezension.de <
http://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 <mailto: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
> <mailto: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 <http://virtua.tech>
> JSFCentral.com <http://JSFCentral.com> | @jsfcentral | knowesis.io
> <http://knowesis.io/web/webcomponents> - fresh Web Components info
> +1 203-998-0403 <tel:%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
> <mailto:balusc_at_gmail.com>> wrote:
>
> Hi,
>
> h:commandScript is result of
> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-613
> <https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-613>
> See also
> http://arjan-tijms.omnifaces.org/p/jsf-23.html
> <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 <mailto: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
> <mailto: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
> <mailto: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
>
>
>
>
>
>
>