>>>>> On Fri, 08 Jun 2012 19:23:10 -0400, Andy Schwartz <andy.schwartz_at_oracle.com> said:
AS> I wanted to go back to something that Ed mentioned earlier:
EB> The jsfc feature crept in when we adopted Facelets, but it was never
EB> given the true attention it deserved because not all EG members liked
EB> it.
AS> Pretty sure I must have been one of the EG members who expressed doubts
AS> about this feature. My dislike for jsfc is not because I am opposed to
AS> the idea of facilitating HTML-centric page authoring, but because I
AS> don't actually think that jsfc helps nearly as much as it should. jsfc
AS> gives the impression that JSF/Facelets supports an HTML-centric
AS> authoring model. However, this model falls on its face way too quickly.
AS> Let's look at a simple example...
[...]
AS> As we look to enhance (or replace?) jsfc, I hope that we can keep this
AS> simple, yet fundamental, limitation in mind.
Thanks for so clearly illustrating the limitation.
[...]
AS> If we are hoping to tackle this area, we probably need to start by
AS> trying to identify the range of use cases that we hope to cover. Simple
AS> div/input/button cases are one thing. What about more complex
AS> components - eg. tables, or components that have no equivalent in HTML
AS> land? How far do we hope to take this?
Here's how far I'd like to take this: far enough so that the use cases
in the existing spec issues 991-Input, 1075-MetadataContent,
1076-SectioningAndHeading, 1077-FormAssociatedElements can be addressed
and those issues closed for JSF 2.2.
For components that have no equivalent in HTML, use a proper JSF
component (including the ability to use a composite component).
I just had a phone call with Blake about this issue. He and I are going
to synthesize a response on this thread and hopefully we can quickly
reach consensus about how to move forward.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 17 Business days til JSF 2.2 Public Review to EG