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