[jsr-314-open] ADMIN: Final list of issues for JSF 2.0 and actions for each
Pete Muir
pmuir at REDHAT.COM
Thu Apr 16 19:00:23 EDT 2009
Hi Ed,
Thanks for the update. Minor inline.
On 16 Apr 2009, at 23:44, Ed Burns wrote:
> 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.
I sent this to you yesterday around 17:45 EDT - official answer is to
follow my agreements to defer.
>
> 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 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.
> --
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
More information about the jsr-314-open-mirror
mailing list