Commented on a handful of issues.
PM> ISSUE: 3) Better handling of whitespace in facelets. Currently
PM> whitespace in view sources can get "eaten" and you have to resort to
PM> tricks like to add space. I would put this as a critical and
PM> the (spec) complexity as low (simply switch it on/off).
ACTION: Defer to a later release.
EB> Martin agrees to defer. Not a spec issue.
The whitespace problem is a spec issue if we choose to solve it by specifying in the component configuration whether whitespace should be skipped or treated as a component. For instance, when whitespace is between links inside of a paragraph tag, it should be preserved. However, when it is between links inside of an <h:panelGrid>, it should not be preserved. That needs to be controlled by the UIPanelGrid component (possibly).
I'm fine to defer, but mark my word, the community is going to perceive the lingering of this issue as sloopy.
PM> ISSUE: 2) First class support for page actions. This allows a more
PM> action orientated approach (Struts style) approach to page
PM> authoring, where some arbirtrary method can be run when the page is
PM> accessed. Use cases include security (redirect to another page if
PM> the user isn't logged in for example). JSF2 currently includes
PM> "second class" support - it's possible to do this stuff, but not in
PM> simple fashion. As the design for this has already been done, and
PM> reviewed/approved by the EG, the complexity is low. I would put this
PM> as a blocker. It also has the support of Oracle.
Pete, when we had the discussion regarding View Parameters, we decided
to defer Page Actions to a later release. We will not reverse that
decision.
ACTION: Defer to a later release.
EB> Pete says "I am happy for this to slip, given you can do a
EB> workaround with events. l know Dan is unhappy with the current
EB> state. On this one, Gavin was wavering, and would probably be happy
EB> to slip it".
EB> Andy can accept deferral for this
EB> Ken says, "Events should be able to accommodate this use case until
EB> we have a chance to improve the user-experience in a later release.
EB> I think we should defer this.
EB> Martin says ok to defer. But Ed and Martin agree that we should
EB> have a {Pre,Post}BuildViewEvent that is published appropriately.
EB> Kito agrees to defer.
EB> Alexandr, agrees to defer
I've come to terms with the fact that page actions are out. But I want to leave off with the right impression. The idea is to tie page actions to the navigation handler. Yes, it's possible to hack together this feature together with events. But that doesn't leverage the declarative navigation system. And that is what makes page actions the most useful. Please keep that picture in your mind going into 2.1.
PM> ISSUE: 5) make behaviour of new components more consistent -
PM> currently f:validateBean (JSR-303 support) / f:ajax use different
PM> strategies to mark areas of the areas of the page to enable. Align
PM> these. This is a blocker (once it is written in stone we can't go
PM> back and fix it) and complexity low (the EG has agreed on the
PM> correct design, so the language needs tweaking in the spec and
PM> javadoc). This has the support of Oracle.
ACTION: If the EG agrees that the default validator setup currently hard
coded into UIInput.encodeEnd() can be moved into
Application.createComponent(), this can be done.
EB> Pete agrees with the plan on this.
EB> Andy agrees with the plan on this.
EB> Ken agrees with the plan on this.
EB> Martin agrees with the plan on this.
EB> Kito agrees with the plan on this.
EB> Alexandr agrees with the plan, but thinks the tag handler is a
EB> better place to imbue the component with the default validator.
I agree with the plan.
PM> ISSUE: 7) Allow multiple error messages for a component to be
PM> displayed - especially useful for JSR-303 support. This is
PM> complexity low, and priority minor (easy for an addon to fix).
ACTION: Pete, please submit a diff patch modifying the following files:
We did. The patch also included fixes for the BeanValidator to bring it in line with the spec.
PM> ISSUE: 6) Better support for timezones. Currently only one of two
PM> timezones can be used - default or system. The user may well be in
PM> some other timezone entirely, so make the timezone used
PM> configurable. This is a critical issue, and the complexity is medium
PM> (but we have a full proposal for this waiting in the wings that
PM> didn't make it due to time constraints)
If this was a truly critical issue, it would have been brought up a long
time ago, not after the PFD has been published. Furthermore, this is a
platform level thing. I direct you to your JSR-316 EG rep for this feature.
ACTION: Defer to later release.
It is an important issue, but it is my fault for not bringing it up earlier. Thus, in respect of process, it must be deferred. But please avoid generalizations. Just because the EG doesn't raise the point doesn't mean it isn't causing people pain (and money). Time zones are contextual and need support from JSF... 2.1 ;)
Thanks,
Dan