Here are the notes I just typed up after listening to the audio.
* The first 10 minutes were consumed with technical issues and role
call.
* 10:00 Ed started by reviewing an automated test that shows the status
of
what's currently implemented.
<p>
<input jsf:id="inputText" type="text" jsf:value="#{bean.name}"
disabled="disabled" />
</p>
<p>
<input jsf:id="inputText2" type="text" jsf:value="#{bean.name}"
/>
</p>
<p>
<input name="textField" type="text" jsf:value="#{bean.name}" />
</p>
* 12:00 Ed suggests the decode-only renderer approach.
* 13:20 Ed reviews the passthrough attribute feature.
* 18:46 Returns to explaining the decode-only renderer approach
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1111?page=com.a
tlassian.jira.plugin.system.issuetabpanels%3Aworklog-tabpanel#action_13
753
* 20:00 Frank suggests the direct mapping from the HTML element name to
specific JSF components is difficult, because it's not a 1:1 mapping.
Frank suggests the idea of using a tag decorator to do this.
The idea is to transform a tag and create a new one.
* 22:00 What is a JSF component? decoding and encoding. A PassThrough
element is where the encoding is specified by the page author and the
decoding comes in Java classes.
* 23:00 Ed questinos if the "direct mapping" approach will give us the
necessary flexibility.
* 24:00 Ted suggests a way to associate a decode-only renderer with a
bit of markup.
* 27:00 Ed gives the history of the name Renderer: was "Client adapter"
before we decided on Renderer.
* 27:17 Neil suggested extracting a "Decoder" interface from Renderer.
Ed
labels it as degenerate case of Renderer.
* 38:00 Neil suggests that you could have renderers and decoders in the
XML.
* 30:49 How do you decide how to choose a decoder given some arbitrary
markup. Ed suggests allowing the XML decoder declaration to contain
the information to make that decision.
The system is currently hard-coded: the element name "input" causes a
the javax.faces.Input javax.faces.passthrough.Input renderer to be
associated with the markup.
* 35:35 Ted suggests that the element name and some attributes that
would have to match would be a good way to make the decision.
* 36:00 What about Ajax?
* 38:00 The standard components in javax.faces.component do not
implement ClientBehaviorHolder. So we need to make the corresponding
component be one from javax.faces.component.html.
* 39:00 Werner suggested mapping the f:ajax attributes to special
attributes that can be put on any HTML markup.
* 40:00 Imre endorsed Frank's "direct mapping" approach. He also
cautioned that the practice of adding lots of special attributes
would
move us away from normal HTML. This is a good point.
* 43:00 Imre suggested a way to explicitly declare the decoder.
* 43:40 Ed re-stated Imre's suggestion and cautionary note for Werner.
* 44:45 Ted suggested it's good to map to a concrete component whenever
you know that would be a valid mapping, and leave the generic case
still possible for future HTML elements that don't map.
* 45:09 Ed recounts the experience he had in delegating the task of
estimating task duration to EG members. But he still asks the EG
members if it's possible to have something that works by JavaOne.
* 45:45 Imre says the "direct mapping" solution should be possible to
do.
* 46:32 Andy Schwartz joins, asking about scope and use-cases. Andy
wants to know the scope and the target use-cases.
Ed agrees that we should explicitly talk about scope.
1. input components
2. command components
Use an HTML button, but associate that with an action listener.
- Would you still use EL bindings to invoke your server-side logic?
Take these two cases and discover what is the minimal amount of
intrusion on the HTML way of doing things.
* 50:14 Ed explains that activating the form is so intrinsic to how JSF
works, that you have to do that the JSF way.
* 51:31 Ed's instincts say we should not try to adapt an HTML idiom for
the form submission, but instead we should just accept the JSF idiom
for the form submission.
* 54:40 We should admit the fact that f:ajax is easy enough to begin
with, so we should try to re-use that.
* 56:24 Andy's suggestion for using the binding attribute.
I'm really not trying to do the "push more into Java code" thing that
Andy is talking about.
* 1:06:00 Imre describes the "direct mapping" approach as akin to using
XSLT to transform the HTML into Facelets.
* 1:08:35 Andy continues to advocate for instance-specific (aka
callsite
specific) capabilities. "For this particular button, I want to set
an
execute list and a render list".
Ed