[jsr-314-open] ADMIN: Final list of issues for JSF 2.0 and actions for each

[Dan Allen]

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

-- 
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action

http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan

NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters.  Please don't hesitate to resend a message if
you feel that it did not reach my attention.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090418/a7b2959d/attachment.html