[jsr-314-open] ADMIN: Final list of issues for JSF 2.0 and actions for each
by Ed Burns
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 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.
--
13 years, 10 months
Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
by Ed Burns
>>>>> On Tue, 18 Aug 2009 08:08:31 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi Ed,
>> Which I still don't understand. Can you please explain explicitly?
MM> I sent a mail to Kin-Man that we can't pass parameters from the
MM> framework to the method-expression. So, we can now do:
MM> #{bb.action(myparam)}
MM> to call a method with signature:
MM> public String action(String myparam) {}
MM> but we can not do:
MM> #{bb.valueChangeListener(myparam)}
MM> to call a method with signature:
MM> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
MM> only with signature:
MM> public void valueChangeListener(String myparam) {}
MM> so what we loose is the ValueChangeEvent, which was provided by the
MM> JSF framework as a parameter to the invoke-call in the
MM> Method-Expression instance (we will only receive the parsed
MM> parameters).
Thanks. Now I understand your request.
MM> I already got mail by Kin-Man - he said this won't be included, we
MM> are too late.
MM> This effectively means we cannot use the new EL functionality to solve
MM> the problem that was discussed in this thread (using
MM> valueChangeListeners in a dataTable), and therefore, even though we
MM> can get rid of the f:setPropertyActionListener, we would still need an
MM> f:setPropertyValueChangeListener - a pity.
I agree that the feature you request is indeed valid. Can you please
file it in the uel.dev.java.net issue tracker?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 6 months
Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
by Ed Burns
>>>>> On Fri, 07 Aug 2009 08:31:51 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi Lincoln,
>> Unless I'm mistaken, ui:repeat is not a component and therefore cannot
>> be bound to a backing bean,
MM> I thought it was - and just checked, it derives from UIComponentBase.
MM> Does the binding attribute not work for you?
Yes, but it's implementation specific and not in the
javax.faces.component package.
LB> **Question 1: Almost every AJAX framework I know of allows you to simply
LB> execute a method on the server side, with or without params, and return
LB> a result... is this possible with JSF's Ajax framework?
Such DWR style functionality was in DynamicFaces, but didn't make it
into the JSF standard Ajax.
>>>>> On Thu, 13 Aug 2009 00:10:59 +0100, Pete Muir <pmuir(a)redhat.com> said:
PM> IMO this is not an uncommon use case, and we should support via (1)
Can you please be more specific, Pete? Which part of LB's mail is not
an uncommon case? What is (1)?
>>>>> On Thu, 13 Aug 2009 00:26:14 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi Dan,
MM> I did a little research, and it won't work. Therefore I just sent a
MM> mail out to the JSR-245 spec lead asking for the following signature
MM> in the EL-resolver - that might help at least a little in providing
MM> such functionality. And I thought we had discussed that this should
MM> work at some point of time.
MM> public Object invoke(ELContext context,
MM> Object base,
MM> Object method,
MM> Class[] formalParamTypes,
MM> Object[] formalParams,
MM> Class[] parsedParamTypes,
MM> Object[] parsedParams
MM> ) {
MM> ...
MM> }
>>>>> On Thu, 13 Aug 2009 01:45:45 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> 1) add a method-attribute to the f:valueChangeListener-tag
You mean, have an attribute that means, "The value of this attribute
must be a MethodExpression that points to a method that conforms to the
signature of ValueChangeListener.processValueChange()"? If so, then yes
I agree, and we should add it for all the attached objects where it
makes sense.
MM> 2) get Unified-EL to also support passing the formal parameters (see
MM> my mail to the spec lead)
Which I still don't understand. Can you please explain explicitly?
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 7 months
[jsr-314-open] Need guidance: invalid assumptions in design of resource versioning feature
by Ed Burns
Thanks to Ryan Lubke for bringing this up and authoring the first draft
of this email.
Recall the resource versioning scheme we have that enables runtime
upgrades of component resources without redeployment. A valid resource
identifier has the following parts. Optional parts are in square
brackets.
[libraryName/][libraryVersion/]resourceName[/resourceVersion]
Recall also that the default ResourceHandler supports loading resources
in an "exploded" fashion, from the <web app root>/resources directory,
and also from the classpath via entries in the META-INF/resources
directory.
Summary of Issue
-----------------------------------
Derivation of library and or resource versions is currently dependent on
the URL type exposed when searching for classpath resources. Within
Mojarra, we can properly find versions if the URL protocol is 'file' or
'jar'.
URLs with a file protocol can be used to construct a File instance with
which we can use standard Java File IO to find the versions.
URLs with a jar protocol allow access to the JAR file itself with which
we can use the standard JAR apis to navigation through the JAR and find
versions.
If the URL protocol is of any other type, we really have no way to
derive the version information in a portable manner.
It just so happens that there are several cases when it's not possible
to meet the version scanning requirements in all containers and in all
deployment scenarios. For example, in glassfish, if you deploy your
resource in an OSGi bundle, we don't see jar: or file: URLs. In another
example, JBoss AS has its own loading scheme thit also is not jar: or
file:. Therefore, we cannot guarantee the version scanning feature will
work in all cases.
Options to resolve the issue
--------------------------------------
1. Update the specification to state that versioned resources are only
supported when they are included as resources under /resources
2. Update the specification to state that only classpath resources
included in the web application will be searched. This means that
resources installed to the server classpath will not be considered.
Implementations could then explode the resources found within the
JAR files included in the application to a temporary directory. The
classpath searching algorithm would then search this temporary
directory instead. Doing this for server classpath resources may be
impossible depending on the container.
ACTION: Please choose one of the two options above or suggest another.
Silence implies consent with option 2. Please reply in a timely
fashion.
Sincerely,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 7 months
Re: [jsr-314-open] FYI: onchange for radio and checkbox
by Ed Burns
>>>>> On Wed, 12 Aug 2009 14:27:37 -0700, Jim Driscoll <Jim.Driscoll(a)Sun.COM> said:
JD> So, in the interests of making all browsers behave similarly, I've
JD> changed the default behavior to onclick for those components.
I agree with this modification. I didn't see anything in the
ChangeLog[1]. Can you add it, please, Jim.
Jim, I'd still like to see your answer to Dan Allen's question about,
"can we manually emulate the real, onchange behavior by doing some kind
of old/new comparison". However, I must say that I don't personally
think the extra logic is worth it.
Ed
[1] http://wiki.java.net/bin/view/Projects/Jsf2MR1ChangeLog
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 7 months
[jsr-314-open] Fwd: Minor corrections and request for clarification
by Dan Allen
>From the jsr-314-comments inbox...
---------- Forwarded message ----------
From: Leonardo Uribe <lu4242(a)gmail.com>
Date: Wed, Aug 26, 2009 at 1:29 AM
Subject: [jsr-314-open] Error on web-facelettaglibrary_2_0.xsd
To: jsr-314-comments(a)jcp.org
Hi
Checking the appendix A of the spec, the description of the file
web-facelettaglibrary_2_0.xsd has a small bug.
The attribute composite-library-name used in this context:
//<facelet-taglib>
// <namespace>http://some.domain.com/path</namespace>
// <composite-library-name>compositeLibName</composite-library-name>
//</facelet-taglib>
says this
<xsd:element minOccurs="0" maxOccurs="1"
name="composite-library-name"
type="javaee:fully-qualified-classType"/>
but it should be this:
<xsd:element minOccurs="0" maxOccurs="1"
name="composite-library-name"
type="javaee:string"/>
I also would like to know if composite:clientBehavior exists or not (the
plddocs does not mention it, but if is not what is the purpose of
BehaviorAttachedObjectHandler?)
Also, the documentation of ui:remove has a attribute with no name, and
ui:param has a attribute duplicated, but I think it is a different one.
Also, the documentation of javax.faces.CompositeFacet has an error in its
description. First it says encodeBegin() should not be implemented, but then
describe how it should be. I think it describes encodeChildren() instead.
I'll appreciate a lot all responses to my comments.
regards
Leonardo Uribe
14 years, 7 months
Re: [jsr-314-open] [AjaxBehaviorEventAttribute] why must it be a literal?
by Ed Burns
>>>>> On Mon, 24 Aug 2009 17:29:11 -0400, Andy Schwartz <andy.schwartz(a)oracle.com> said:
AS> Right. Behaviors are created and wired into the component tree during
AS> tag/handler execution. The event name is used during this process - ie.
AS> is specified when registering the Behavior with the hosting
AS> UIComponent. In theory we could allow the event name to be specified
AS> via an EL expression, but the spec would need to be clear that this EL
AS> expression would be evaluated immediately during tag/handler execution
AS> (as the component tree is built) rather than deferred/re-evaluated
AS> during later phases.
Which begs the question: do we need to re-introduce immediate evaluation
for EL expressions? In other words, do we bring back $?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 7 months
[jsr-314-open] [AjaxBehaviorEventAttribute] why must it be a literal?
by Ed Burns
Hello team,
Mojarra impl issue 1143 asserts there is a use case for which allowing
the value of the "event" attribute of <f:ajax> (and thus for all
behaviors) to be a ValueExpression, at least in the case of composite
components.
I suspect there's a good reason why we chose to force the value of the
event attribute to be literal, likely security. However, I want to know
why so I can close this bug in an informed manner, or challenge our
decision and possibly broaden the allowable value type for the
attribute.
Can someone please enlighten me?
Sincerely,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 8 months
