<div class="gmail_quote"><div>Commented on a handful of issues.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
PM> ISSUE: 3) Better handling of whitespace in facelets. Currently<br>
PM> whitespace in view sources can get "eaten" and you have to resort to<br>
PM> tricks like &nbsp; to add space. I would put this as a critical and<br>
PM> the (spec) complexity as low (simply switch it on/off).<br>
<br>
ACTION: Defer to a later release.<br>
<br>
EB> Martin agrees to defer. Not a spec issue.<br>
<br></blockquote><div><br>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).<br>
<br>I'm fine to defer, but mark my word, the community is going to perceive the lingering of this issue as sloopy.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
PM> ISSUE: 2) First class support for page actions. This allows a more<br>
PM> action orientated approach (Struts style) approach to page<br>
PM> authoring, where some arbirtrary method can be run when the page is<br>
PM> accessed. Use cases include security (redirect to another page if<br>
PM> the user isn't logged in for example). JSF2 currently includes<br>
PM> "second class" support - it's possible to do this stuff, but not in<br>
PM> simple fashion. As the design for this has already been done, and<br>
PM> reviewed/approved by the EG, the complexity is low. I would put this<br>
PM> as a blocker. It also has the support of Oracle.<br>
<br>
Pete, when we had the discussion regarding View Parameters, we decided<br>
to defer Page Actions to a later release. We will not reverse that<br>
decision.<br>
<br>
ACTION: Defer to a later release.<br>
<br>
EB> Pete says "I am happy for this to slip, given you can do a<br>
EB> workaround with events. l know Dan is unhappy with the current<br>
EB> state. On this one, Gavin was wavering, and would probably be happy<br>
EB> to slip it".<br>
<br>
EB> Andy can accept deferral for this<br>
<br>
EB> Ken says, "Events should be able to accommodate this use case until<br>
EB> we have a chance to improve the user-experience in a later release.<br>
EB> I think we should defer this.<br>
<br>
EB> Martin says ok to defer. But Ed and Martin agree that we should<br>
EB> have a {Pre,Post}BuildViewEvent that is published appropriately.<br>
<br>
EB> Kito agrees to defer.<br>
<br>
EB> Alexandr, agrees to defer</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
PM> ISSUE: 5) make behaviour of new components more consistent -<br>
PM> currently f:validateBean (JSR-303 support) / f:ajax use different<br>
PM> strategies to mark areas of the areas of the page to enable. Align<br>
PM> these. This is a blocker (once it is written in stone we can't go<br>
PM> back and fix it) and complexity low (the EG has agreed on the<br>
PM> correct design, so the language needs tweaking in the spec and<br>
PM> javadoc). This has the support of Oracle.<br>
<br>
ACTION: If the EG agrees that the default validator setup currently hard<br>
coded into UIInput.encodeEnd() can be moved into<br>
Application.createComponent(), this can be done.<br>
<br>
EB> Pete agrees with the plan on this.<br>
<br>
EB> Andy agrees with the plan on this.<br>
<br>
EB> Ken agrees with the plan on this.<br>
<br>
EB> Martin agrees with the plan on this.<br>
<br>
EB> Kito agrees with the plan on this.<br>
<br>
EB> Alexandr agrees with the plan, but thinks the tag handler is a<br>
EB> better place to imbue the component with the default validator.</blockquote><div><br>I agree with the plan.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
PM> ISSUE: 7) Allow multiple error messages for a component to be<br>
PM> displayed - especially useful for JSR-303 support. This is<br>
PM> complexity low, and priority minor (easy for an addon to fix).<br>
<br>
ACTION: Pete, please submit a diff patch modifying the following files:</blockquote><div><br>We did. The patch also included fixes for the BeanValidator to bring it in line with the spec.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
PM> ISSUE: 6) Better support for timezones. Currently only one of two<br>
PM> timezones can be used - default or system. The user may well be in<br>
PM> some other timezone entirely, so make the timezone used<br>
PM> configurable. This is a critical issue, and the complexity is medium<br>
PM> (but we have a full proposal for this waiting in the wings that<br>
PM> didn't make it due to time constraints)<br>
<br>
If this was a truly critical issue, it would have been brought up a long<br>
time ago, not after the PFD has been published. Furthermore, this is a<br>
platform level thing. I direct you to your JSR-316 EG rep for this feature.<br></blockquote><div> <br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">
ACTION: Defer to later release.<br></blockquote>
<br>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 ;)<br>
<br></div>Thanks,<br><br>Dan<br></div><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br>
<a href="http://in.relation.to/Bloggers/Dan">http://in.relation.to/Bloggers/Dan</a><br><br>NOTE: While I make a strong effort to keep up with my email on a daily<br>basis, personal or other work matters can sometimes keep me away<br>
from my email. If you contact me, but don't hear back for more than a week,<br>it is very likely that I am excessively backlogged or the message was<br>caught in the spam filters. Please don't hesitate to resend a message if<br>
you feel that it did not reach my attention.<br>