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

This is the final list of issues for JSF 2.0. No other issues will be considered for 2.0. I do not think content of any of these issues, nor their quantity, warrant another Proposed Final Draft, but I will of course produce an Editor's Draft for the public on jsr-314-open to review. I will send another email with the dates for the remainder of JSR-314. Any further discussion on any topic sent to this list will be rolled into the next release of the spec. SECTION: List of EG Members from whom I have obtained explicit buy-in I have obtained explicit buy in for this list in its present state from the following EG members. Pete Muir Status: DONE, but need final official answer from JBoss. Promised by 1800 EDT 20090415.

Andy Schwartz 617 794 7974 Status: DONE Spoke with him 1319 20090415 Kito Mann 917 848 3359 Status: DONE Spoke with him 1600 20090415 Martin Marinschek +43 699 1805 3906 Status: DONE Spoke with him at 1400 EDT 20090415 Ken Paulsen x42083 Status DONE Spoke with him 1403 20090415 Alexandr Smirnov DONE IRC chat with him 16:00 20090415 SECTION: Issue sums Number of issues remaining: 30 I've broken down the issues into two groups, bigger and smaller. I assert that we do not need to do a PFD2 because none of the issues are so big as to warrant such an action. Bigger issues: Number of bigger issues: 16 deferred: 5 will fix: 10 pushed to EG member requesting the issue: 1 Smaller issues: Number of smaller issues: 14 deferred: 1 will fix: 13 SECTION: Bigger issues PM> ISSUE: 1) Fully stateless views. This is a performance optimization PM> which is ideal for the use case of pages which are output-only (no PM> form). This is moderately complex to get right, and a blocker in our PM> opinion. This also has the support of Apache. We see two aspects to consider. a. Marking specific views in an app as stateless. Putting a transient="true" attribute on <f:view> doesn't work here because the template page with <f:view> can be shared across pages. There are several options we could try but none of them are feasible at this point in time. b. If the Form Renderer never calls StateManager.writeState(), and the ViewHandler is aware of this fact, then you have a stateless view. Therefore, statelessness is an implementation detail. Adam Winer provided this idea, which we implement in Mojarra. ACTION: Defer to a later release. EB> Pete agrees to defer, but Gavin does not. EB> Andy agrees to defer. EB> Ken agrees to defer. EB> Martin agrees to defer. EB> Kito agrees to defer EB> Alexandr, agrees to defer, but is unhappy about it. 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 &nbsp; 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> Pete says, "70 - yes, defering that is fine" EB> Andy is ok for deferring this EB> Ken is ok to defer. EB> Martin agrees to defer. Not a spec issue. EB> Kito agrees to defer. EB> Alexandr, agrees to defer 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 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. 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: standard-html-renderkit-base.xml jsf-api/doc/standard-html- renderkit-base.xml message-message-props.xml jsf-api/doc/message-message-props.xml to specify the change, and the necessary implementation changes for this feature. For to the patch to be accepted at this VERY late date it must meet the following requirements. Because of the late timing of this feature request we will be unable to accept the feature if the patch doesn't meet all of the following requirements. * All existing automated tests still run successfully after applying the patch. * The spec wording in the patch requires no grammatical or formatting changes. * The patch is sent to the EG list no later than 23:59 EDT Wednesday 20090415. RL> ISSUE: 2. View ID Derivation Fix RL> (java.net Issue 1002) RL> Status: Ed had a fix - push back from Ken Paulsen on the fix; ACTION: Because this breaks the V3 Admin GUI, it must be fixed for 2.0 => edburns fix by Thursday 20090316 17:00 EDT. RL> ISSUE: 3. Client Behavior in Composite Components RL> (patch from Exadel) RL> Status: Patch 1 checked in; Patch 2 checked in; RL> Javadocs / prose updates need to be made. ACTION: Fix checked in to revision 6952, will review spec implications RL> ISSUE: 4. Bean Validation Bug Fixes RL> (java.net issue 1058) RL> Status: Checked in; Needs discussion; Javadocs, prose updates ACTION: Will review docs, RELEASE_PENDING. Make sure spec for CompositeComponent Attributes ELResolver mentions this, 5.6.2.2 JD> ISSUE: Impl 1071: UIData.visitTree() ACTION: Will Fix. fully specify JD> ISSUE: Impl 1072: Facelet Meta* Javadocs not cleanroom implementable ACTION: Will fix. EG> ISSUE: JavaScript disabled support [Was: Outcome of JSFDays EG> discussions] ACTION: This can easily be doable in a later release. Considering the late date of this request we need to defer it. EB> Pete is ok with deferring this. EB> Andy is ok with deferring this. EB> Ken is ok to defer. EB> Martin is ok with defer EB> Kito agrees to defer. EB> Alexandr agrees to defer. EG> ISSUE: minor feature enhancement for Facelets/VDL ACTION: Defer to a later release EB> Pete's ok with deferring this. EB> Andy's ok with deferring this. EB> Ken is ok to defer. EB> Martin ok to defer. EB> Kito ok to defer. EB> Alexandr is ok to defer. EG> ISSUE: required attributes in composite components ACTION: Defer to a later release EB> Pete's ok with deferring this. EB> Andy's ok with deferring this. EB> Ken is ok to defer this. EB> Martin is ok to defer this. EB> Kito ok to defer this. EB> Alexandr, agrees to defer EG> ISSUE: remove target attr from h:outputStylesheet (was: EG> h:outputStylesheetdocs need to be updated) ACTION: Will fix this EG> ISSUE: #{compositeComponent.attrs....} verbosity ACTION: Change "compositeComponent" to be "cc". Implementations may provide a context-param that allows renaming the implicit object name to an arbitrary value for the case where an app happens to have a managed-bean named cc. EB> Pete says he won't object to this solution. EB> Andy is ok with this action EB> Ken says, "I like 'cc' better to solve the verbosity issue. I EB> recommend deferring on the renaming via context-param for now -- but EB> would not object to it making the release if others feel strongly EB> that it needs to be done now." EB> Martin is ok with this solution. EB> Kito is ok with this solution. EB> Alexandr is ok to defer. EG> ISSUE: composite insert children ACTION: 2 days. Take the following steps EB> Pete is ok with this action. EB> Andy is ok with this action. Ken says, KP> I am very nervous about the reparenting (insert*) commands. If 2 KP> composite:insertFacet/Children tags are used in the same composite KP> component, it will likely fail. Is that acceptable? EB> We will specify that if multiple <composite:insertFacet> elements EB> exist with the same name in the <composite:implementation> section, EB> the "last one wins". EB> We will specify that if multiple <composite:insertChildren> elements EB> exist in the <composite:implementation> section the facelet layer EB> must throw a FaceletException. KP> If the component inserted has code which does: getParent(), they'll KP> be exposed to the internal workings of a composite component (which KP> they shouldn't know exists). Yes, you are correct, but I feel this is sufficiently corner case to ignore. KP> I would prefer render* in most cases. In cases where this isn't KP> possible (implementing a facet inside a composite component), KP> perhaps we can do a proxy component which can be added to the inner KP> facet and delegate rendering to the page-facet? I think there will KP> be problems with this implementation. If I am wrong, then I do not KP> object to this going in -- otherwise, I think it should be deferred. EB> Martin is ok with this action. EB> Alexandr is ok with this action. 1. rename composite:insertFacet to composite:renderFacet 2. create composite:insertFacet that reparents the named facet from the top level component to be a facet child of the parent tag in the composite:implementation section in which the composite:insertFacet resides. 3. delete composite:renderUsingPageChildren 4. create composite:insertChildren that reparents the children from the top level component to the parent of tag in the composite:implementation section in which the composite:insertChildren resides. 5. For composite:insert{Facet,Children} support nested composite components. => edburns take this to Bill and see what he thinks, if we need to do a PFD2. SECTION: Smaller issues 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. EB> Pete is ok with deferring this. EB> Andy is ok with deferring this. EB> Ken says defer. EB> Martin ok to defer. EB> Kito ok to defer. EB> Alexandr is ok to defer RL> ISSUE: 2. 11.4.7 - Absolute ordering. I think if a document name RL> is explicitly referenced but not present, an exception should be RL> thrown. ACTION: We'll log a message in this case. EB> Pete's ok with this action. EB> Andy's ok with this action. EB> Ken's ok with this action. EB> Martin is ok with this action. EB> Kito is ok with this action EB> Alexandr states, "if related document was not present, it is critical error, therefore Exception should be thrown." Given the prevailing opinion, we'll stick with logging. RL> ISSUE: 3. FacesRenderKit annotation hasn't existed from some time RL> now. ACTION: Remove this from the spec. RL> ISSUE: 4. Javadocs for EditableValueHolder.addValidator() and RL> ValueHolder.setConverter() mention ResourceDependency annotation RL> processing. This documentation should be moved to RL> Application.createConverter() and Application.createValidator(). ACTION: Will fix this in the spec. RL> ISSUE: 5. 3.1.11 mentions that the AttributesMap, if the current RL> component is composite, must eval any ValueExpressions stored in the RL> Map. This is incorrect. This logic is handled by the RL> CompositeComponentAttributesELResolver ACTION: Will fix in the spec. RL> ISSUE: 6. Preface references META-INF/managed-beans.xml. Support RL> for this file is no longer required. ACTION: Will fix. RL> ISSUE: 7. 5.6.2.2 Doesn't mention any support for the special RL> parent keyword in #{compositeComponent} expressions. ACTION: Will fix. RL> ISSUE: 8. 6.1.1.15 lists Flash as a property of FacesContext. It's RL> now a property of ExternalContext. ACTION: Will fix. RL> ISSUE: 9. 7.1.1 and 7.1.2 Typo in assertion marker RL> 'defualtActionListener' and 'defualtRenderKit' There may be others. ACTION: Will fix RL> ISSUE: 10. 7.4.2 will need to be discussed due to the RL> implementation of issue 1066. ACTION: Will fix RL> ISSUE: 11. 7.4.3 should include a navigation case example with RL> redirect parameters. ACTION: Will fix RL> ISSUE: 7.5.1 and others. This may already be done, but RL> PageDeclarationLanguage should be ViewDeclarationLanguage ACTION: Will fix. Make sure retargetAttachedObjects and retargetMethodExpressions are on VDL, not ViewHandler. RL> ISSUE: 1. Spec ResponseWriter methods: startCDATA endCDATA (java.net RL> issue 1055) Status: impl done; method javadocs / prose need to be RL> done; ACTION: Will fix EG> ISSUE: View and custom scoped eager managed beans? ACTION: Will Fix. Add eager for session scoped managed beans RL> Update 3rd bullet in 11.5.1 so that pattern for custom faces config file names is something that ends with .faces-config.xml. This brings it in alignment with 11.4. --