Hi,
MM> Thinking of HTML friendly coding, it would be great, to implement it as
HTML attribute also (same thoughts might be applied to other tags):
MM>
MM> <h:inputText ...>
MM> <f:socket.../>
MM> </h:inputText>
What exactly would this do?
To me, it would make more sense if it was the other way round as it's push,
not pull. E.g.
<f:socket>
<h:outputText value="#{bean.message}" />
</f:socket>
or perhaps even
<f:socket ... render="foo" />
...
<h:panelGroup id="foo">
<h:outputText value="#{bean.message}" />
</h:panelGroup>
This only requires reusing partial rendering as done by <f:ajax> in some
way and that's so far not covered by <p:socket> and the vdldoc. But it
would definitely reduce JS boilerplate to update the HTML DOM.
Cheers, B
On Thu, Aug 20, 2015 at 9:24 PM, Cagatay Civici <cagatay.civici_at_gmail.com>
wrote:
> Hi,
>
> I also like f:channel name instead of f:socket.
>
> A component is not strictly necessary but we definitely need an easy to
> use client side api to connect and send messages. Bauke summarized this
> really well.
>
> Regards,
>
> Cagatay Civici
>
> PrimeFaces Lead
>
> PrimeTek Informatics
>
> <http://www.primefaces.org> <http://www.primefaces.org>www.primefaces.org
>
> On Aug 15, 2015, at 19:57, "Michael Müller" <
> michael.mueller_at_mueller-bruehl.de> wrote:
>>
>> Hi All,
>>
>> EB> 2. I opted not to have a corresponding UIComponent, whereas in
>> EB> PrimeFaces there is a corresponding UIComponent and Renderer [3].
>> EB> I am taking f:ajax as a model in this regard. I'd like to hear
>> EB> from Cagatay why he found it necessary to have a backing
>> EB> UIComponent.
>>
>> JJ> - Given that there will be no UIComponent to accompany the new
>> JJ> feature, the chosen transport could then drive the type of
>> JJ> UICompnent that will be used by the developer. For instance, a
>> JJ> WebSocket transport could utilize a UIInput, whereas an SSE could
>> JJ> utilize a UIOutput component only.
>>
>> It seems to be natural to connect a socket (I personally would prefer
>> "f:channel" over "f:socket" because this is neutral whereas "socket"
>> implies websocket ousting SSE as fallback) to a UIComponent. The
>> approach as discussed so far, allows the user to connect it (like
>> f:ajax) to any
>> UIComponent. And it should be possible to connect SSE to
>> a input element too, although this channel provides a one way connection
>> only.
>>
>> But what about non-UIComponents? Shall we consider that a JSF user might
>> "connect" it to some client side (JavaScript) object?
>>
>> And, should it be implemented as a tag only? Thinking of HTML friendly
>> coding, it would be great, to implement it as HTML attribute also (same
>> thoughts might be applied to other tags):
>>
>> <h:inputText ...>
>> <f:socket.../>
>> </h:inputText>
>>
>> Now, using HTML friendly style, a tag seems to pollute the HTML:
>>
>> <input type="text" jsf:value=...>
>> <f:socket.../>
>> </input>
>>
>> In my opinion, this integrates much better into HTML:
>>
>> <input type="text" jsf:value=... jsf:socket.../>
>>
>> Can we implement this feature (as well as elder ones) as attribute
>> beside the tag implementation?
>>
>> Just my two
>> pence...
>>
>> Herzliche Grüße - Best Regards,
>>
>> Michael Müller
>>
>> Read my book "Web Development with Java and JSF": https://leanpub.com/jsf
>>
>>