[JAVASERVERFACES_SPEC_PUBLIC-1348] Better define usage of Flash, specifically with respect to response buffer size Created: 12/Jan/15  Updated: 12/Jan/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Manfred Riem Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1320 Expose Flash for use from MVC Open




[JAVASERVERFACES_SPEC_PUBLIC-1342] Support @Inject of current flow like "@Inject Flow currentFlow" Created: 12/Dec/14  Updated: 12/Dec/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CDI Conversation scope is injectable into @ConversationScoped beans like this:

@Inject
Conversation currentConversation

The same should be true for the current Flow for @FlowScoped beans.






[JAVASERVERFACES_SPEC_PUBLIC-1321] Leverage HTTP2 Server Push from JSF Created: 13/Oct/14  Updated: 13/Oct/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Because JSF 2.3 is allowed to depend on Java EE 8, we can take advantage of Servlet 4.0 features such as server push.






[JAVASERVERFACES_SPEC_PUBLIC-1320] Expose Flash for use from MVC Created: 13/Oct/14  Updated: 12/Jan/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-1348 Better define usage of Flash, specifi... Open

 Description   

This issue covers whatever changes to the spec are necessary to expose Flash scope to MVC.






[JAVASERVERFACES_SPEC_PUBLIC-1316] Support @Inject on JSF artifacts Created: 09/Oct/14  Updated: 11/Feb/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JAVASERVERFACES_SPEC_PUBLIC-527 Support @Inject for FacesContext Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1309 Support @Inject for ExternalContext Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1323 Support @Inject for the applicationMap Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1327 Verify @Inject HttpSession support Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1333 Support @Inject for UIViewRoot Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1335 Support @Inject for the viewMap Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1345 Support @Inject for the sessionMap Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1349 Support @Inject for FacesConverter Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1350 Support @Inject for FacesValidator Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1351 Support @Inject for FacesBehavior Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1353 Support @Inject for RequestCookieMap Resolved
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1283 Allow for injection on UIComponent, C... Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-763 Web Container injection support shoul... Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1315 Simplify EL resolver chain by using CDI Open
is related to JAVASERVERFACES_SPEC_PUBLIC-1287 Make @javax.faces.bean.ManagedBean me... Resolved

 Comments   
Comment by Manfred Riem [ 15/Oct/14 ]

Make sure the following artifacts are mentioned in the spec PDF when describing @Inject support

  • applicationMap
  • externalContext
  • facesContext
  • session (delegating that responsibility back to default CDI runtime)
  • sessionMap
  • view
  • viewMap
  • converters annotated with @FacesConverter (and managed = true)
  • validators annotated with @FacesValidator (and managed = true)
  • behaviors annotated with @FacesBehavior (and managed = true)
  • requestCookieMap
Comment by Ed Burns [ 14/Jan/15 ]

Do you have any plans to support Component, Behavior and Validator?

Comment by Manfred Riem [ 14/Jan/15 ]

In Progress

Comment by Manfred Riem [ 15/Jan/15 ]

Note @Inject on UIComponent instances will not be done as the view state is managed outside of CDI.





[JAVASERVERFACES_SPEC_PUBLIC-1315] Simplify EL resolver chain by using CDI Created: 08/Oct/14  Updated: 11/Feb/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: EL
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Manfred Riem Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by JAVASERVERFACES-3478 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1311 Let CDI handle #{facesContext} EL res... Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1322 Simplify #{externalContext} to use Ex... Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1325 Let CDI handle #{applicationScope} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1328 Let CDI handle #{session} EL resolving Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1331 Let CDI handle #{application} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1332 Let CDI handle #{view} Resolved
is blocked by JAVASERVERFACES_SPEC_PUBLIC-1334 Let CDI handle #{viewScope} Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1316 Support @Inject on JSF artifacts Open

 Comments   
Comment by Manfred Riem [ 15/Oct/14 ]

Make sure the appropriate spec text is added for:

application - describe that this only does EL resolving
applicationScope
externalContext
facesContext
session - describe that this only does EL resolving (core CDI does the @Inject for session)
view
viewScope





[JAVASERVERFACES_SPEC_PUBLIC-1301] XML validation gives error on vdl-document in faces-config Created: 25/Aug/14  Updated: 25/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: pholthuizen Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See also https://java.net/jira/browse/JAVASERVERFACES-3381

The following XML document gives the following error when validating the contents within Eclipse or Netbeans.

Errors:

cvc-pattern-valid: Value '/sec/flows/flow1/step1.xhtml' is not facet-valid with respect to pattern '($|_|\p

{L})(\p{L}
\p {Nd}
_ $)*' for type
'null'.
cvc-complex-type.2.2: Element 'vdl-document' must have no element [children], and the value must be valid.

faces-config:
<?xml version="1.0" encoding="UTF-8"?>
<faces-config
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd"
version="2.2">
<flow-definition id="createInvoice">
<start-node>index</start-node>
<view id="index">
<vdl-document>/sec/flows/flow1/step1.xhtml</vdl-document>
</view>
</flow-definition>
</faces-config>






[JAVASERVERFACES_SPEC_PUBLIC-1298] Resolve backward incompatible change regarding PartialResponseWriter.writePreamble() Created: 11/Aug/14  Updated: 05/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3366 Fix ResponseWriter backwards compatib... Closed

 Description   

Issue JAVASERVERFACES_SPEC_PUBLIC-1069 was introduced to cover a problem with jsf.js and Portets. Unfortunately, the resolution was backward incompatible for parties that implement ResponseWriter.



 Comments   
Comment by Ed Burns [ 11/Aug/14 ]

These were done at the request of the portlet community:

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069

And in fact Blake did weigh in on this way back then:

https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/49

B> I guess I would question whether any fixes for 1) or 2) are
B> necessary. The proposal before is to make non-backwards compatible
B> behavior changes. For such a change, I would want to see some clear
B> benefits. In this case, the Bridge has a work-around. It doesn't
B> sound like the work-around is hurting performance--nor does it sound
B> like the Bridge is being asked to do something outside of its
B> purview--which in this case is turning a document-oriented page into
B> a fragment.

And Neil Griffin replied with a justification:

https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/57

But there the discussion appears to have ended. It looks like we ended
up going with Neil's suggestions.

Comment by Ed Burns [ 11/Aug/14 ]

Let me clarify why Blake asserts this is a backward incompatible change.

In JSF 2.1, the writing of the XML preamble was the responsibility of the PartialResponseWriter.startDocument().

In JSF 2.2, we moved that out into PartialResponseWriter.writePreamble(), removing it from PartialResponseWriter.startDocument(). This means that any code that was counting on the XML preamble having been written based on a JSF 2.1 runtime will fail when running against a JSF 2.2 runtime.

Comment by btsulliv [ 14/Aug/14 ]

To clarify further, this change was guaranteed to be incompatible because all pre-2.2 code had to rely on startDocument() writing any necessary XML declaration or docType as the new methods:

writePreamble

public void writePreamble(String preamble)
throws IOException
Write a string containing the markup specific preamble. No escaping is performed. The default implementation simply calls through to Writer.write(java.lang.String) .

The implementation makes no checks if this is the correct place in the response to have a preamble, nor does it prevent the preamble from being written more than once.

Parameters:
preamble - Text content of the preamble
Throws:
IOException - if an input/output error occurs
Since:
2.2
writeDoctype

public void writeDoctype(String doctype)
throws IOException
Write a string containing the markup specific doctype. No escaping is performed. The default implementation simply calls through to Writer.write(java.lang.String) .

The implementation makes no checks if this is the correct place in the response to have a doctype, nor does it prevent the doctype from being written more than once.

Parameters:
doctype - Text content of the doctype
Throws:
IOException - if an input/output error occurs
Since:
2.2

Did not exist before 2.2 and therefore could never have been called. This reason should have been sufficient on its own to have precluded the current design as minor releases are not allowed to break compatibility and even major releases should have a could have a good reason for doing so. In this cases, even the justification was sorely lacking:

"For JSF 2.2 portlet alignment, I think it's important (from a design perspective) to fix servlet environment assumptions in the JSF API or Spec. If such assumptions are present in a JSF implementation, then the portlet bridge can simply perform overrides at the proper extension points. The solutions below seem reasonable to me, since they appear to be implementation details that do not affect existing JSF applications."

It should be pointed out that:
1) The rationale is incorrect--the problem in this case wasn't that the JSF ResponseWriter was servlet-oriented, but rather, that the ResponseWriter assumed that startDocument() would actually begin writing a new document. In the Portlet case, the bridge wanted to write its own envelope content and then embed the payload from the wrapped writer inside this content. When the envelope was XML, the XML declaration and doctype caused problems.

2) The bridge had already worked around this problem by parsing the beginning of the wrapped content and discarding the XML declaration and docType. Since this content was at the beginning of the output of the wrapped content, this was actually pretty fast. The advantage of the change was that it made this aspect of the Portlet bridge easier to re-implement and faster (though this part isn't performance critical).

To make this worse, the rest of the design was messed up:

1) the two new methods should never have been public as an application calling these methods can only cause harm. This is because
a) In order to pass the correct parameters, the application would have to know the implementation of the ResponseWriter
b) If the application passes different parameters than the ResponseWriter expects, bad things can happen

The point of adding these methods as hooks for a ResponseWriter implementation could have been met with protected methods, thus avoiding potential new sources of error.

These problems are compounded by the lack of documentation surrounding the new contract in the javadoc for the class.

While it is clear that we should have never added these methods in the first place, let alone in the current fashion, we are stuck with trying to make these work the best we can. To that end we have two approaches:

Simple:

Admit that this was a bad idea. Make the new methods no-ops, go back to the old behavior and put the portlet bridge code back as well. This is by far the smallest change.

Change the incompatibility from the callers of the ResponseWriters (application developers) to the ResponseWriter implementations. This is actually less compatible than making the apis no-ops.

1) Document that while writeDocType and writePreamble are public, they should only be called by ResponseWriter implementations. Application developers should continue to only call startDocument
2) Document that neither writeDocType not writePreamble should be called after startDocument, that writePreamble should preceed any call to writeDocType and implementations are allowed, but not required to throw an IllegalStateException if this occurs.
3) Require that ResponseWriter implementations call writePreamble if writeDocType is called without a preceeding call to writePreamble and both
a) This ResponseWriter supports docTypes
b) This ResponseWriter supports a preamble
4) Require that ResponseWriter implementations call writeDocType if startDocument is called without a preceeding call to writeDocType (which will then cause the correct preamble to be written, if necessary)
5) Allow the ResponseWriter to throw IllegalArgumentExceptions if the parameters passed to writePreamble or writeDocument

This is still an incompatible change for ResponseWriter implementors, who now need to maintain state. Note that if we had made the new methods protected and simply requried that the ResponseWriter implementations call these methods from startDocument, the change would have still been incompatible (as we are placing a new requriement on ResponseWriter implemetors), but much simpler overall, as the expectations for subclassers calling things correctly are less sever than for application developers.

Comment by Ed Burns [ 05/Sep/14 ]

This is still an incompatible change for ResponseWriter implementors, who now need to maintain state. Note that if we had made the new methods protected and simply requried that the ResponseWriter implementations call these methods from startDocument, the change would have still been incompatible (as we are placing a new requriement on ResponseWriter implemetors), but much simpler overall, as the expectations for subclassers calling things correctly are less sever than for application developers.

Looking at the Java EE compatibility guidelines < https://java.net/projects/javaee-spec/pages/CompatibilityRequirements >, I don't see anything that forbids making formerly public methods protected. Blake, if we were to do this and required your steps 1) and 2) above, would that be sufficient?





[JAVASERVERFACES_SPEC_PUBLIC-1284] Pop up inappropriate alert by JSF for canceling(status 0) XML request Created: 16/Jun/14  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: xiaojun.wu Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: jsf2_2

 Description   

Status 0 appears when an ajax call was cancelled before getting the response. So when you click a link of full request, unfinished ajax requests are cancelled. I traced JS code of JSF and found that alerted the error message. In 'http://...../javax.faces.resource/jsf.js.xhtml?ln=javax.faces&stage=Development' (it might be jsf-uncompressed.js), req.xmlReq.onreadystatechange(line 1722) was invoked back If request was cancelled. And onComplete(line 1740) found the status code was not be >=200 and < 300. So sendError(line 1892) set data.description = "The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons." Finally, pop up this error message.

I think cancelling ajax requests is a common phenomenon and not of a error. Browser should not pop up this message.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1279] UIInput.isEmpty() lacks specification Created: 15/May/14  Updated: 10/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3241 java.lang.IndexOutOfBoundsException: ... Closed

 Description   

This method should have a specification.

It was added in svn revision 6714 as part of issue JAVASERVERFACES_SPEC_PUBLIC-426.

  • make hitherto private static method isEmpty() public. Used from
    RequiredValidator.


 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1274] In ViewMetadata.createMetadataView() clarify state for temporary UIViewRoot Created: 10/Apr/14  Updated: 08/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3205 Postback executes <f:event type="preR... Closed

 Description   

In ViewMetadata.createMetadataView(), specify

  • the new UIViewRoot must be set as the FacesContext's viewRoot before applying the tag handlers, restoring
    the old FacesContext in a finally block.
  • The content's of the current UIViewRoot's ViewMap must be copied to the ViewMap of the new UIViewRoot
    before applying the tag handlers.


 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1273] Clarify what happens to the current FacesContext during the execution of ViewMetadata.createMetadataView() Created: 03/Apr/14  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3205 Postback executes <f:event type="preR... Closed

 Description   

See JAVASERVERFACES-3205.

first.xhtml
<f:view>
  <f:metadata>
    <f:viewParam name="id" value="#{outcomeTestFirstBean.firstId}"></f:viewParam>
  </f:metadata>

	<h:head>
	</h:head>
	<h:form>
		
		<h2>Problem description:</h2>
		When visiting this page using the following link: <a href="?id=11111">/first.jsf?id=11111</a> we can show that include-view-params causes a problem.<br/>
		Clicking the TestOutcomeLink poses no problem and will load the second page normally.<br/>
		Any postback will however try to execute the preRenderView event of the OutcomeTestSecondBean (because the metaData is parsed at ViewMetadataImpl.createMetadataView(FacesContext) line: 115)
		<br/><br/><br/>
		<h:link outcome="second" value="TestOutcomeLink" includeViewParams="true">
			<f:param name="extraParam" value="99999" />
		</h:link>
		<br/><br/><br/>
		<h:commandLink value="Postback goes BOOM" action="#{outcomeTestFirstBean.justAnAction}" />&nbsp;
		<h:commandButton value="Postback goes BOOM" action="#{outcomeTestFirstBean.justAnAction}" />
	</h:form>
</f:view>

and

second.xhtml
<f:view>
  <f:metadata>
    <f:viewParam name="id" value="#{outcomeTestSecondBean.secondId}"></f:viewParam>
    <f:event listener="#{outcomeTestSecondBean.load}" type="preRenderView" />
  </f:metadata>
	<h:head>
	</h:head>
	<h:form>
		<h:outputLabel value="#{outcomeTestSecondBean.secondId}" />
	</h:form>
</f:view>

When first.xhtml renders, the <h:link> will cause the <f:metadata>
section of second.xhtml to be executed. This will cause a dummy
UIViewRoot to be created and thrown away, per the spec. Unfortunately,
the <f:listener> in second.xhtml's <f:metadata> section ends up on
first.xhtml's UIViewRoot. The spec for
ViewMetadata.createMetadataView() must require the existing UIViewRoot,
if any, to be restored before returning from the method.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1270] JavaDoc for TagDecorator regarding pass-through attributes not in line with implementation Created: 19/Mar/14  Updated: 08/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: michael_kurz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The documentation for class TagDecorator states the following for processing attributes:

For each of argument tag's attributes obtain a reference to a TagAttribute with the following characteristics. For discussion let such an attribute be convertedTagAttribute.

  • convertedTagAttribute's location: from the argument tag's location.
  • If the current attribute's namespace is http://xmlns.jcp.org/jsf, convertedTagAttribute's qualified name must be the current attribute's local name and convertedTagAttribute's namespace must be the empty string. This will have the effect of setting the current attribute as a proper property on the UIComponent instance represented by this markup.
  • If the current attribute's namespace is empty or different from the argument tag's namespace, let the current attribute be convertedTagAttribute. This will have the effect of setting the current attribute as an attribute on the attributes map of the UIComponent instance represented by this markup.

The third item states, that attributes without a namespace or with a namespace different from the tag's namespace should be attributes of the component (and NOT pass-through attributes).

This is not in line with the implementation in Mojarra (which is correct in my opinion!). Mojarra treats all attributes of a pass-through element without a namespace as pass-through attributes. This perfectly makes sense as I would consider attributes without a prefix in a pass-through element as something belonging to the HTML tag.

With the behavior defined in the spec, this would not work:

<input type="text" jsf:id="name" jsf:value="#{bean.name}"
    placeholder="Enter name"/>

But this feels natural to me! The behavior implemented in Mojarra seems to be consistent too: pass-through attributes must be prefixed on jsf tags and jsf attributes must be prefixed on pass-through elements.

This issue popped up in MyFaces recently as MYFACES-3868 (see [1]).

[1]: https://issues.apache.org/jira/browse/MYFACES-3868



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1265] Clarify that a piece of text in the navigation handler section of the spec only pertains when inside of a flow. Created: 07/Feb/14  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Flow
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES-3130 NavigationHandlerImpl differs from sp... Closed

 Description   

Consider this spec text, from section 7.4.2:

If the <to-view-id> element is a non-view flow node, resolve it to a vdl view identifier by following the algorithm in Section 7.4.2.1 "Requirements for Explicit Navigation in Faces Flow Call Nodes other than ViewNodes".

That text only pertains to navigation within a flow. This restriction must be explicitly called out.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1262] web_partialresponse_2_2.xsd uses incorrect cardinality on partial-response element. Created: 03/Feb/14  Updated: 08/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES-3171 Exception during render on Ajax reque... Closed

 Description   

The XSD file for the partial-response element states that a <partial-response> may have exactly one of <changes>, <redirect>, or <error> as a child element. This is incorrect. We should allow any number and combination of those child elements for maximum flexibility.

This problem manifests itself when the server needs to send an <error> response when some <changes> response data has already been written to the response. This can happen if there is an error during rendering.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1258] Declare that text output by <h:outputText> (or equivalent inline EL expressions) within script or style blocks is not escaped by default. Created: 30/Jan/14  Updated: 16/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See JAVASERVERFACES-3150.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1255] f:view contracts="#{bean.contracts}" should allow to return null from the bean to let contracts be calculated from configurarion Created: 10/Jan/14  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

com/sun/faces/facelets/tag/jsf/core/ViewHandler uses TagAttribute.getValue() to retrieve the contracts EL expression value - EL (before 3.0) will coerce null from the bean.contracts to "" and make no contract active.

If ViewHandler would use TagAttribute.getObject() null would be evaluated to null and the contracts calculation from the configuration would be used.

This might as well affect the spec - if this is accepted, a SPEC issue has to be created as well.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1245] Section "Determining the active Locale" includes too narrow language Created: 26/Dec/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is text in section "Determining the active Locale" (section number 2.5.2.1 as of version 2.2 of the JSF spec) that speaks too narrowly of how the system must process the <supported-locale> entries in the <locale-config> of the faces-config.xml file. In particular, this text runs afoul of the changes for script tags specified in IETF BCP47.

This text must be generalized so that existing behavior continues to be spec compliant, while BCP47 style entries can also be supported.

The spec for the <f:view locale> attribute must also be inspected so that it is compatible with BCP47.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1244] Reword requirements for EL expressions inlined in Facelets pages, but outside of components. Created: 19/Dec/13  Updated: 16/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days


 Description   

Text copied from JAVASERVERFACES-3094

The JSF spec (2.1) requires in section 10.3.1 that "The runtime must ensure that EL expressions that appear in the page without being the right-hand-side of a tag attribute
are treated as if they appeared on the right-hand-side of the value attribute of an <h:outputText /> element in the http://java.sun.com/jsf/html namespace." This should also work in this case.

This text is problematic with respect to c:set and friends.

I suggest we soften the above language to make it clear that we don't need to have UIOutput instances in the tree. Rather, we just need it to render as if we did.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1242] Remove OpenAjax hub from Specification Created: 17/Dec/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Task Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

My question here in this group is: should we remove our mention and
usage of OpenAjax in the JSF spec?

EB> 13.2 JavaScript Namespacing

EB> JavaScript objects that are not enclosed within a namespace are global,
EB> which means they run the risk of interfering, overriding and/or
EB> clobbering previously defined JavaScript objects. This section defines
EB> the requirements for implementations intending to use the JavaServer
EB> Faces 2.0 JavaScript API.

EB> The Open Ajax Alliance is an organization of leading vendors, open
EB> source projects, and companies using Ajax. Their prime objective is to
EB> accelerate customer success with Ajax, through the use of open
EB> standards. The Open Ajax Registry is an industry-wide Ajax registration
EB> authority managed by the OpenAjax Alliance. The Registry maintains
EB> industry- wide lists of Ajax runtime libraries to help prevent object
EB> collisions.

EB> There is a top level namespace jsf that is registered with the Open Ajax
EB> Alliance:

EB> Java Ajax:

Unknown macro: {EB> namespaceURI}

EB> [P1-start openajax registration]If the OpenAjax library is available,
EB> libraries must register themselves using OpenAjax.registerLibrary() at
EB> the time when the JavaScript files are fetched and parsed by the
EB> browser\u2019s JavaScript engine. [P1-end]

EB> if (typeof OpenAjax != "undefined" &&
EB> typeof OpenAjax.hub.registerLibrary != "undefined")

Unknown macro: {EB> OpenAjax.hub.registerLibrary("jsf", "www.sun.com", "1.0",EB> null); }

EB> –
EB> 8<---------------

EB> Unfortunately, I now see this text on the website:

EB> "The following organizations were Members of OpenAjax Alliance at the
EB> time OpenAjax Alliance terminated formal operations:" A little research
EB> revealed this email about the termination:

EB> http://openajax.org/pipermail/steeringcommittee/2012q4/001015.html

EB> And this article, now nearly four years old.

EB> https://devcentral.f5.com/articles/5-years-later-openajax-who#.UqdusoG7liw

EB> Basically, it seems OpenAjax is dead. Anyone care to comment on whether
EB> we should bother with it in JSR-362?



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Ed Burns [ 13/Aug/14 ]

FWIW, I just updated the wikipedia page for Open Ajax Alliance to state that it has terminated operations.





[JAVASERVERFACES_SPEC_PUBLIC-1230] VDLDoc for <ui:repeat> does not have concept of rowStatePreserved which <h:dataTable> does have. Created: 14/Oct/13  Updated: 05/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1263 Add rowStatePreserved property to com... Open
is related to JAVASERVERFACES-2243 h:form inside nested ui:repeat fails ... Closed

 Description   

JSF 2.1 added to UIData the ability to declare that row state should be preserved on iterations. This capability should also be added to <ui:repeat>



 Comments   
Comment by Ed Burns [ 06/Mar/14 ]

>>>>> On Fri, 14 Feb 2014 16:17:46 -0500, Leonardo Uribe said:

LU> There is still a problem related to the component row state and its
LU> relation with the model. In few words, if you remove a row, since the
LU> state is associated to the rowIndex, the state of the removed row is
LU> passed to the next row and so on, breaking the state. Long time
LU> ago, I did a solution to the problem in tomahawk adding some
LU> attributes (rowKey and derivedRowKeyPrefix).

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1225] What to say about BCP47 Support? Created: 02/Oct/13  Updated: 20/Oct/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-1210 Account for BCP47 Closed

 Description   

BCP47 defines new rules for the parsing of Locale objects. These rules are implemented in the java.util.Locale class in JDK7. There are several places in the JSF spec that place requirements on how a Locale is encoded as a String.

  • XSD for supported-locale
  • XSD for default-locale
  • Spec section "2.5.2.1 Determining the Active Locale" in the portion of that section that deals with the locale attribute on the <f:view> tag.

In all of these places statements are made regarding the use of "-" or "_" as a separator. This issue asks if we should go further and require the use of JDK7 Locale.forLanguageTag() to obtain the Locale instance before trying the existing methods of obtaining a Locale.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1217] EnumConverter.getAsString() javadoc contains incorrect text, conflicts with its own @returns clause Created: 15/Aug/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes

Issue Links:
Related
is related to JAVASERVERFACES-2919 selectOneMenu + EnumConverter and nul... Closed

 Description   

The Javadoc for EnumConverter.getAsString() contains the text,

If the value argument is null, return null.

This is conflict with the @returns clause, and also with the super-interface declaration of the method.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1215] Add warning to javadoc of DelegatingMetaTagHandler.getTagHandlerDelegate Created: 12/Aug/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0, 2.1, 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 30 minutes
Time Spent: Not Specified
Original Estimate: 30 minutes


 Description   

The current spec has no javadoc for DelegatingMetaTagHandler.getTagHandlerDelegate(). [1] This issue proposes adding the following warning to the javadoc for this method.

Code that extends from DelagatingMetaTagHandler (directly or indirectly, as through extending ComponentHandler) must take care to decorate, not replace, the TagHandlerDelegate instance returned by this method. Failure to do so may produce unexpected results.

[1] http://docs.oracle.com/javaee/6/api/javax/faces/view/facelets/DelegatingMetaTagHandler.html#getTagHandlerDelegate%28%29



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1203] Empty String as Null is not effective in 2.2.0 Created: 04/Jul/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 1.1, 1.2, 2.0, 2.1, 2.2
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0, EL 3.0


Issue Links:
Related
is related to JAVASERVERFACES-3071 javax.faces.INTERPRET_EMPTY_STRING_SU... Closed
Tags: null, string

 Description   

GlassFish 4.0 uses EL 3.0.
Section 1.23.2 in EL 3.0 states that null String will be converted to empty String.
So we need a ELResolver to handle the conversion somethig like this

public class NullStringHanlder  extends ELResolver
{

	@Override
	public Class<?> getCommonPropertyType(ELContext context, Object base)
	{
		
		return String.class;
	}

	@Override
	public Iterator<FeatureDescriptor> getFeatureDescriptors(ELContext context,
			Object base)
	{
		return null;
	}

	@Override
	public Class<?> getType(ELContext context, Object base, Object property)
	{
		
		return null;
	}

	@Override
	public Object getValue(ELContext context, Object base, Object property)
	{
		
		return null;
	}

	@Override
	public boolean isReadOnly(ELContext context, Object base, Object property)
	{
		
		return true;
	}

	@Override
	public void setValue(ELContext context, Object base, Object property,
			Object value)
	{
		
		
	}

	@Override
	public Object convertToType(ELContext context, Object obj,
			Class<?> targetType)
	{
		if (obj==null && String.class.equals(targetType))
		{
			context.setPropertyResolved(true);;
			return null;
		}
		return null;
			
		
	}
	

}




 Comments   
Comment by Ed Burns [ 05/Jul/13 ]

Thanks for taking the time to report this. How do you suggest we reconcile this issue with the meaning of the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context-param? This param is described in section 11.1.3 Application Configuration Parameters of the spec.

javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL – If this param is set, and calling toLowerCase().equals("true") on a String representation of its value returns true, any implementation of UIInput.validate() must take the following additional action.
If the javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL context parameter value is true (ignoring case), and UIInput.getSubmittedValue() returns a zero-length String call UIInput.setSubmittedValue(null) and continue processing using null as the current submitted value

Comment by jasonzhang2002gmailcom [ 05/Jul/13 ]

This is integration issue. Mojarra definitely follows the specification. However, the problem is deeply down into EL implementation/Spec. I am currently using a custom ELResolver(see above) only for this string conversion. By this way, no mojarra or EL is effected. Mojarra can come with such a resolver to explicitly to control the string conversion by default.

Comment by Ed Burns [ 08/Jul/13 ]

We need to move this to the spec issue tracker because what you are asking is a spec change. We understand that EL 3.0 allows this, but we would need to bring this issue up to the expert group.

Comment by rekiem87 [ 10/Apr/14 ]

Glassfish 4.0.1 with the latest mojarra still have the issue

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1202] cc:attributes type attribute: fallback case: use what the ELResolver returns. Created: 03/Jul/13  Updated: 16/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 Description   

JAVASERVERFACES_SPEC_PUBLIC-745 amended the language for the Composite Component Attributes ELResolver's getType() method.

An additional change is needed for correctness to the cc:attribute tag's type attribute. The existing language states:

Declares that this attribute must be a ValueExpression whose expected type is given by the value of this attribute. If not specified, and no "method-signature" attribute is present, java.lang.Object is assumed. This attribute is mutually exclusive with the "method-signature" attribute. If both attributes are present, the "method-signature" attribute is ignored.

This needs to be changed. Instead of assuming java.lang.Object, the system must use the return from the CC attribute ELResolver's getType() method.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1199] Missing throws clauses in javadoc for implementing classes. Created: 11/Jun/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: dougd Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

N/A


Attachments: Text File file_list.txt    

 Description   

It appears that when we leave the javadoc of an Implementing classes method(s), that we are not getting all the throws clauses that we should be.

Example:
javax.faces.validator.MethodExpressionValidator implements the javax.faces.components.Stateholder interface, and implements saveState & restoreState methods. The API documents for these methods are copied automatically fro the StateHolder interface javadocs, but the "throws" clause is not being copied. We might need to implicitly tell the javadoc too do do this by adding something like the below.

/**

  • {@inheritDoc}
    * @throws{@inheritDoc}

    */

I have attached a file that contains a list of classes that have the "Description copied from" string in there Javadoc at some point. This file should help whom ever needs to go through and clean up the classes.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1193] Declaring component attributes via annotations Created: 11/May/13  Updated: 07/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: annotation, annotations, ease-of-use, ease_of_development, no-xml

 Description   

As of JAVASERVERFACES_SPEC_PUBLIC-594, custom components can be declared to be useable in Facelets via the @FacesComponent annotation. Via this it's no longer required to have an entry in a taglib.xml file.

However, if the component author wishes to declare the component's attributes (for documentation, tooling, etc), XML still has to be used.

I therefor would like to propose declaring these attributes via annotations as well.

E.g.

@FacesComponent(value="components.CustomComponent", createTag=true)
public class Foo extends UIComponentBase {

    @Attribute
    String color; // will be injected with getAttributes("color") 

    @Attribute(description="This will determine the ...", required=true)
    String style;

    @Attribute(description="The cost of ... ", default="100")
    Integer cost;

}


 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by c.beikov [ 07/Aug/14 ]

In my opinion the @Attribute annotation should go on an abstract getter and the component class should be declared as abstract. This way you could define reusable behavior in interfaces and inherit these attributes by implementing an interface.
The runtime can just generate an appropriate subclass of a component class that implements those methods. This also gives the implementation flexibility regarding the representation of the data.
If the values of EL expressions are bound to the component instance on creation of the component, how would the component get a changed value if the original EL expression would evaluate to a different value later in the lifecycle?

I implemented an annotation processor that generates these Java classes and XML files based on annotations for me at build time. I think Richfaces did something similar. JSF could just move that process to the runtime.





[JAVASERVERFACES_SPEC_PUBLIC-1185] Pass Through attribute should have priority when rendering Created: 25/Apr/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Bruno Borges Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tried the following code:

index.xhtml
<a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a>

The href attribute rendered contains the value anotherPage_fake.xhtml. In this case (and similar others), the pass through attribute should have priority in the rendering process, if it will compete with a static attribute.



 Comments   
Comment by Bruno Borges [ 13/Aug/13 ]

Digging more into Pass Through Attributes, I find this feature one of the best things I've ever seen in JSF in years, because it could bring development/designer preview without the need to run an app server. A feature that several frameworks permit, such as Apache Wicket and Tapestry. But if Pass Through Attributes doesn't override regular attributes, then it becomes not interesting.

The spec is not clear about this, and I think it should be provided an Errata, with a change in the current implementation.

Sample A

 
<script type="text/javascript"
             src="../../js/jQuery.js"
             p:src="${facesContext.externalContext.requestContextPath}/js/jQuery.js"></script>

Sample B

<script type="text/javascript" src="../../js/jQuery.js">
    <f:passThroughAttribute
       name="src"
       value="${facesContext.externalContext.requestContextPath}/js/jQuery.js" />
</script>

Either samples should end up with this:

<script type="text/javascript" src="/myapp-1.0-SNAPSHOT/js/jQuery.js"></script>
Comment by Frank Caputo [ 13/Aug/13 ]

Pass through attributes have priority as specified in the “Rendering Pass Through Attributes” section of the overview of the standard HTML_BASIC render kit: https://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_behavior_encoding

In <a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a> the href attribute becomes a pass through attribute and thus has priority.

Comment by Bruno Borges [ 13/Aug/13 ]

Hi Frank, thanks for pointing that out, but I disagree that "static" attributes should have priority when faced against calculated/dynamic attributes such as jsf:outcome.

If an element has both attributes (a static like 'href', and a dynamic as 'jsf:outcome'), the general idea is that the static attribute is for static preview/prototyping only, and should be replaced by the calculated value.

This is how other web frameworks have been doing for years.

Comment by jyeary [ 13/Aug/13 ]

The link you specified has some very specific text about priority.

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence. Pass through attributes are rendered as if they were passed to ResponseWriter.writeURIAttribute().

Unless I am reading this incorrectly, the jsf:outcome should take precedence over the static href attribute. I am on the fence on this though. I think that the pass through attributes are a great addition to the framework. However, if the renderer has the attribute defined, it can be set dynamically using EL. In this case, pass through attributes are simply duplicating the renderer specific attributes. This is for the case of the JSF components.

What advantages do we gain from the pass through taking precedence over the renderer specific attributes if they duplicate each other? I would say that the renderer specific attributes should take precedence.

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

Comment by Bruno Borges [ 13/Aug/13 ]

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

This is what I'm looking for. I don't want to loose the "previability" of the page.

Comment by Ed Burns [ 28/Aug/13 ]

From the spec section cited by John and Frank:

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence.

Consider Bruno's original markup:

<a href="anotherPage_fake.xhtml" 
   jsf:outcome="/anotherPage.xhtml">Another Page</a>

Because this is an <a> element with a jsf:outcome attribute, it is treated as an h:link, specified in the following.

http://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html

Perhaps the root problem here is that there is another set of attributes that must be considered, separate from the set of renderer specific attributes. This is the set of attributes that the renderer itself must use when rendering the component. Let's call these renderer required attributes. I suggest that the spec be modified to define the term renderer required attributes, and to say that renderer required attributes take precedence over pass through attributes on the markup.

Unfortunately, there is no runtime representation of the set of renderer required attributes, so it's not possible for the spec to say that, though. We would need to have a way for each renderer to declare its set of renderer required attributes, then we could require the ResponseWriter to act accordingly based on the priority.

There is no conflict because "href" is not a renderer specific attribute.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1179] Clarify UIComponent.encodeAll requirements Created: 04/Apr/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As requested by Manfred here:

http://java.net/jira/browse/JAVASERVERFACES-2743

I am logging this issue to request that the spec be more explicitly in stating that JSF implementations must call UIComponent.encodeAll() instead of directly calling each of encodeBegin/encodeChildren/encodeEnd() when rendering any component.

The reason for this is that UIComponent.encodeAll() is a non-final public method that components are free to override. JSF implementations should never bypass these overrides since this can result in bugs/loss of functionality.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1170] In facelet vdldoc for HTML_BASIC tag panelpassthrough.Element must be removed. Created: 27/Feb/13  Updated: 08/Sep/14

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours


 Description   

In facelet vdldoc for HTML_BASIC tag panelpassthrough.Element must be removed.



 Comments   
Comment by Ed Burns [ 27/Feb/13 ]

Roger, this doesn't need to be done by PFD. It can be done by final.

Comment by Ed Burns [ 27/Feb/13 ]

Roger, for the record, I did make this change but the problem persisted.

8<-----------------
Index: jsf-tools/conf/FaceletsHtmlBasicTaglib21.pre-maven-rename.properties
===================================================================
— jsf-tools/conf/FaceletsHtmlBasicTaglib21.pre-maven-rename.properties (revision 11661)
+++ jsf-tools/conf/FaceletsHtmlBasicTaglib21.pre-maven-rename.properties (working copy)
@@ -98,6 +98,7 @@
base.output.dir=build.pre-maven-rename/generate

#OPTIONAL PROPERTIES
+taglib.excludedRendererTypes=javax.faces.passthrough.Element
taglib.include=build/TAG-DEF-21.txt
taglib.description=This tag library contains JavaServer Faces component tags for all\n\
UIComponent + HTML RenderKit Renderer combinations defined in the\n\
Index: jsf-tools/conf/FaceletsHtmlBasicTaglib21.properties
===================================================================
— jsf-tools/conf/FaceletsHtmlBasicTaglib21.properties (revision 11661)
+++ jsf-tools/conf/FaceletsHtmlBasicTaglib21.properties (working copy)
@@ -97,6 +97,7 @@
base.output.dir=build/generate

#OPTIONAL PROPERTIES
+taglib.excludedRendererTypes=javax.faces.passthrough.Element
taglib.include=build/TAG-DEF-21.txt
taglib.description=This tag library contains JavaServer Faces component tags for all\n\
UIComponent + HTML RenderKit Renderer combinations defined in the\n\
8<----------------

I do suspect the taglib.excludedRendererTypes is part of the solution.

Comment by Ed Burns [ 27/Feb/13 ]

Also, note that h:doctype has value and converter and it should not.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1131] h:outputScript and h:outputStylesheet "name" attribute is not required Created: 15/Aug/12  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The facelets documentation javadoc for h:outputScript and h:outputStylesheet indicates that "name" attribute is required, but it is valid to use h:outputScript just to render a <script> tag that surrounds the inner content. For example:

<composite:implementation>
<h:outputScript rendered="#

{!empty cc.attrs.script}

"><!--
.myCustomScript = #

{cc.attrs.script}

;
//--></h:outputScript>
</composite:implementation>

or

<composite:implementation>
<h:outputStylesheet rendered="#

{!empty cc.attrs.style}

"><![CDATA[
.myCustomStyle { #

{cc.attrs.style}

}
]]></h:outputStylesheet>
</composite:implementation>

is a valid syntax.



 Comments   
Comment by marfous [ 12/Dec/12 ]

Please would be possible to increase the priority to the Major and fix the issue in the taglib specification.

See related NetBeans IDE issue:
Bug 216926 - h:outputScript and h:outputStylesheet "name" attribute is not required
http://netbeans.org/bugzilla/show_bug.cgi?id=216926

Comment by Lynx6 [ 06/Mar/13 ]

wow... this problem need to be fixed, netbeans is showing each file with error parsing.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1126] XSD for composite components incomplete Created: 27/Jul/12  Updated: 08/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1113] onselect attribute is only supported on INPUT and TEXTAREA elements, not on SELECT elements Created: 06/Jun/12  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: balusc Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As per http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents the "select" event is only supported on INPUT and TEXTAREA elements. The "onselect" attribute in h:selectOneMenu/h:selectManyMenu/h:selectOneListbox/h:selectManyListbox is therefore invalid and misleading and should be removed.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1102] Add support for condition check like regular for-loop in ui:repeat Created: 22/May/12  Updated: 22/Jan/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Jigar Joshi Assignee: Unassigned
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAVASERVERFACES-2240 Add support for c:forEach-like begin ... Closed
Related
is related to JAVASERVERFACES-2423 Add support for condition check like ... Closed

 Description   

It would be nice if <ui:repeat> supports the following construct.

<ui:repeat begin="#{bean.begin}" end="#{bean.end}">
  <div>foo</div>
</ui:repeat>

Which acts like JSTL's <c:forEach begin="1" end="10">, but then with EL support in the attributes.



 Comments   
Comment by Jigar Joshi [ 22/May/12 ]

It would be nice if supports the following construct.

<ui:repeat till="#

{someCondition}

">
<div>foo</div>
</ui:repeat>

which would be sort of similar to regular for loop

Comment by Aditya [ 10/Sep/12 ]

@Jigar Joshi- Nice idea. Would be very helpful!

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1095] Add "rendered" attribute description to "repeat" and "fragment" tag definition in "ui.taglib.xml". Created: 03/May/12  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates JAVASERVERFACES-2406 Add "rendered" attribute description ... Closed

 Description   

Add "rendered" attribute description to "repeat" and "fragment" tag definition in "ui.taglib.xml".

Sample file attached...



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1080] New Component APIs to manage EL context as it applies to components. Created: 05/Mar/12  Updated: 13/Aug/14

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 1.1, 1.2, 2.0, 2.1
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 6 days, 17 hours, 47 minutes
Time Spent: 6 hours, 13 minutes
Original Estimate: 1 week

Attachments: Text File 20120316-1025-i_spec_1080.patch     Text File 20120319-1714-i_spec_1080.patch    
Issue Links:
Dependency
depends on UEL-29 Make it possible to be notified when ... Open
Tags: adf_high

 Description   

B> The issue with clientIds is that portions of the clientId are an
B> implementation detail of the components and renderkit. The result is
B> that developers are not supposed to be hardcoding clientIds into their
B> code. Developers need a different kind of id that specifies context
B> like a clientId, but is standardized like a findComponent search
B> expression. Let's call this a contextId.

B> Given a contextId, we would like to be able to do the following:
B> 1) Efficiently convert the contextId into an object capable of
B> establishing and tearing down the context for the component relatively
B> efficiently. This would require new component apis.
B> 2) Add a function like findComponentInContext that may return a proxy
B> for the UIComponent executing in the context object from 1)
B> 3) Since setting up and tearing down context on every attribute
B> retrieval is inefficient--framework managed context so that the current
B> context may be torn down lazily.



 Comments   
Comment by Ed Burns [ 20/Mar/12 ]

I tried implementing the testing logic, but it became too complex and I decided it's not worth the trouble.

Sending jsf-api/src/main/java/javax/faces/component/UIComponent.java
Sending nbproject/project.xml
Transmitting file data ..
Committed revision 9769.

A better use of my time is to try to implement the API that Blake mentioned from Trinidad ComponentContextManager.

Ed

Comment by Manfred Riem [ 20/Mar/12 ]

Ed,

The latest commit for this issue broke the trunk build. When can we expect a resolution on this?

Manfred

Comment by Ed Burns [ 21/Mar/12 ]

http://adc2120535.us.oracle.com:7070/hudson/view/Jobs%20for%20Ed/job/mojarra-trunk-glassfish-3_1_2-no-cluster-systest/80/

Seems to be blue, and it's from r9772.

http://adc2120535.us.oracle.com:7070/hudson/view/Jobs%20for%20Ed/job/mojarra-trunk-glassfish-3_1_2-no-cluster-systest/78/

Is also blue, and that's from r9769.

Can you please point me to the failing job?

I'll fix it right away, of course.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1066] JavaDoc for Application#getNavigationHandler() method does not mention the navigation-handler within the application element of faces-config Created: 26/Jan/12  Updated: 16/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0, 2.1, 2.0 Rev a, 2.1 Rev a, 2.2 Sprint 1, 2.2 Sprint 2, 2.2 Sprint 3, 2.2 Sprint 4, 2.2 Sprint 5, 2.2 Sprint 6, 2.2 Sprint 7, 2.2 Sprint 8, 2.2 Sprint 9
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Neil Griffin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1072 Add javax.faces.application.Navigatio... Closed

 Description   

There is a documentation bug/omission in the JSF 2.0/2.1 JavaDoc. Specifically, the omission is that the Application#getNavigationHandler() method [1] is supposed to let you specify a wrappable implementation from the <navigation-handler> within the <application> element of faces-config. The feature is formally specified in the faces-config XML Schema [2]. I just checked and both Mojarra [3] and MyFaces [4] implement this feature.

Please refer to the Application#getResourceHandler() method [5] for an example of how to describe this feature in JavaDoc.

[1] http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Application.html#getNavigationHandler()
[2] http://java.sun.com/xml/ns/javaee/web-facesconfig_2_0.xsd
[3] com.sun.faces.config.processor.ApplicationConfigProcessor
[4] org.apache.myfaces.config.element.Application
[5] http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/application/Application.html#getNavigationHandler()



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1059] f:selectItem escapeItem attribute should be itemEscaped Created: 05/Dec/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The vdl docs are in error w/r/t f:selectItem escapeItem - it should be itemEscaped.
The implementation is correct here.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1056] More flexible state saving Created: 30/Nov/11  Updated: 22/Jan/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: state, state_saving_method

 Description   

In JSF the user can choose to save state on the server or the client via the javax.faces.STATE_SAVING_METHOD context parameter. Because this is a global setting that applies to all views in the application, it's not really flexible.

I would like to propose making this more flexible. Ideally the user would have three options for state: none (see JAVASERVERFACES_SPEC_PUBLIC-1055), client and server and would be able to set this globally, per URL pattern, or per view.

Setting the state saving method on a view would override any setting done per URL pattern, and setting state saving for a URL pattern overrides the global setting.

One step further would be to even allow setting the state saving method per individual component.



 Comments   
Comment by Ed Burns [ 01/Feb/12 ]

Although this would be very useful, we have to leave this as Fix Version unknown because I haven't figured out yet how to fit it into JSF 2.2.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1029] viewParam value lost after validation errors Created: 02/Aug/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 15
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: state, validation

 Description   

As every UIInput component, UIViewParameter normally retains its value after a postback. If there's any kind of validation error on the page (unrelated to the UIViewParameter) the model to which the UIViewParameter is bound will correctly not be updated. However, when the component is subsequently encoded this model will be queried for its value.

In effect, the retained value is typically lost when the model is in request scope.

The following reproduces this:

viewparam.xhtml
<html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
>

    <f:metadata>
        <f:viewParam id="id" name="id" value="#{viewParamBean.id}"/>
    </f:metadata>

    <h:body>

        <h:messages />

        #{viewParamBean.id} <br/>

        <h:form>
            <h:inputText value="#{viewParamBean.text}" >
                <f:validateLength minimum="2"/>
            </h:inputText>

            <h:commandButton value="test" action="#{viewParamBean.actionMethod}"/>
        </h:form>

    </h:body>
</html>
ViewParamBean.java
@ManagedBean
@RequestScoped
public class ViewParamBean {

    private long id;    
    private String text;

    public void actionMethod() {

    }

    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }

    public String getText() {
        return text;
    }

    public void setText(String text) {
        this.text = text;
    }    
}

If you call the Facelet with viewparam.xhtml?id=12 it will display the 12 onscreen. If you then input something valid, e.g. aaaaa, the id will disappear from the URL, but keeps being displayed on screen (owning to the stateful nature of ui components). As soon as any validator error occurs (e.g. entering a), the id will be permanently lost. Entering valid input afterwards will not bring it back.

The implementation of encodeAll of UIViewParameter in Mojarra highlights what's happening:

UIViewParameter.java
public void encodeAll(FacesContext context) throws IOException {
    if (context == null) {
        throw new NullPointerException();
    }

    // if there is a value expression, update view parameter w/ latest value after render
    // QUESTION is it okay that a null string value may be suppressing the view parameter value?
    // ANSWER: I'm not sure.
    setSubmittedValue(getStringValue(context));
}

public String getStringValue(FacesContext context) {
    String result = null;
    if (hasValueExpression()) {
        result = getStringValueFromModel(context);
    } else {
        result = (null != rawValue) ? rawValue : (String) getValue();
    }
    return result;
}

Because hasValueExpression() in getStringValue() is true, this will try to get the value from the model. But in case the model is request scoped it will not have any value for this request, since validation has just failed and thus no value has ever been set. In effect, the stateful value of UIViewParameter is overwritten by whatever the model returns as a default (typically null, but this depends on the model of course).

Expected behavior: After validation errors occur, the model should not be consulted (e.g. as implemented by Mojarra's HtmlBasicRenderer#getCurrentValue)



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1028] Clarify partial state save/restore traversal requirements Created: 02/Aug/11  Updated: 12/Aug/14

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.1
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Status Whiteboard:

size_small importance_medium


 Description   

Mojarra and MyFaces differ in how they implement the partial state save/restore traversals. Mojarra uses tree visiting. MyFaces does not. The spec should define requirements for this area to ensure consistency across implementations.



 Comments   
Comment by aschwart [ 02/Aug/11 ]

Expert group discussion can be found here:

http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2011-08/message/0

At this point it looks like we should specify that tree visiting should be used for these traversals, as this allows components (eg. Trinidad's UIXCollection) to intercept the traversal in order to perform component-specific processing.

Comment by Ed Burns [ 10/Aug/11 ]

Added to JSF_2_2_WORKING_SET <http://java.net/jira/secure/IssueNavigator.jspa?mode=hide&requestId=10531>. Added estimates.

Comment by Ed Burns [ 22/Dec/11 ]

Deprecate StateManager, point to StateManagementStrategy. In StateManagementStrategy, require the use of the visit API to perform the saving. http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1028

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/application/Application.java

  • mark {get,set}

    StateManager() as deprecated, pointing to the new
    equivalents.

M jsf-api/src/main/java/javax/faces/application/StateManager.java
M jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java

  • Deprecate these classes, pointing to the new equivalents.

M jsf-api/src/main/java/javax/faces/view/StateManagementStrategy.java

  • require the use of the visit API to perform the saving.

M jsf-api/src/main/java/javax/faces/context/FacesContext.java

  • fix javadoc error

Committed to trunk:

Sending jsf-api/src/main/java/javax/faces/application/Application.java
Sending jsf-api/src/main/java/javax/faces/application/StateManager.java
Sending jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java
Sending jsf-api/src/main/java/javax/faces/context/FacesContext.java
Sending jsf-api/src/main/java/javax/faces/view/StateManagementStrategy.java
Transmitting file data .....
Committed revision 9542.

Comment by Ed Burns [ 22/Dec/11 ]

Need to re-open to consider Ted Goddard's additional requests on this issue.

Comment by Ed Burns [ 22/Dec/11 ]

Roll back deprecation of entire StateManager in favor of just deprecating two methods:

{save,restore}

View(). http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1028

SECTION: Modified Files
----------------------------
M jsf-api/src/main/java/javax/faces/application/Application.java

  • Roll back deprecation of the stateManager property.

M jsf-api/src/main/java/javax/faces/application/StateManager.java

  • Roll back deprecation of the entire class.
  • Deprecated {restore,save}

    View().

M jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java

  • Roll back deprecation of the entire class.

M jsf-api/src/main/java/javax/faces/context/PartialResponseWriter.java

  • In the value for VIEW_STATE_MARKER, rather than duplicating the
    literal string, refer to the symbolic constant
    ResponseStateManager.VIEW_STATE_PARAM, the value of which is
    equivalent to the literal string being replaced.

Committed to trunk:

Sending jsf-api/src/main/java/javax/faces/application/Application.java
Sending jsf-api/src/main/java/javax/faces/application/StateManager.java
Sending jsf-api/src/main/java/javax/faces/application/StateManagerWrapper.java
Sending jsf-api/src/main/java/javax/faces/context/PartialResponseWriter.java
Transmitting file data ....
Committed revision 9543.

Comment by Ed Burns [ 03/Feb/12 ]

Move to sprint 11

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-1007] Explicit support for dynamic component tree manipulation Created: 22/May/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: components

 Description   

In JSF it's possible to manipulate a component tree using Java code after it has been build by the ViewHandler. From the very first JSF version on, there have been explicit APIs to do this manipulation.

E.g.

UIViewRoot root = FacesContext.getCurrentInstance().getViewRoot();
UIOutput output = new UIOutput();
output.setValue("Dynamically added component");
root.getChildren().add(output);

However, the exact moment when this kind of manipulation is legal to do has not been specified. In the past, people have been using various moments in the life-cycle, where success ranged from an exception, the component appearing in the rendered response but not surviving a postback, to everything working as expected. Furthermore, behavior varied between MyFaces and Mojarra.

In JSF 2.0, the PreRenderViewEvent seems like an excellent opportunity for this manipulation, but it has not been specified that this is the right moment and in practice implementations might still not support full manipulation here. See http://java.net/jira/browse/JAVASERVERFACES-1826

Proposal: Explicitly provide support for dynamic component tree manipulation, possibly by proving a special system event for this and mandating conforming implementations to fully allow such manipulations. In case this is not technically feasible, specify what kind of manipulations are guaranteed to work.



 Comments   
Comment by kennardconsulting [ 22/May/11 ]

Hi guys,

Thanks for opening this spec issue!

I'd like to point out that MyFaces, as of 2.0.3, has successfully supported dynamic component tree manipulation in all my SystemEvent Acid Tests (see https://issues.apache.org/jira/browse/MYFACES-2935) and in Metawidget (http://metawidget.org) which exercises dynamic component tree manipulation more than most.

So this spec change may be as simple as 'blessing' the MyFaces behaviour. Certainly this would seem preferrable to introducing a new SystemEvent. My only concerns:

1. The name of PreRenderViewEvent is fine, but the way you have to use it seems odd:

root.subscribeToViewEvent( PreRenderViewEvent.class, this );

I believe Ryan Lubke came up with this approach (see http://kennardconsulting.blogspot.com/2010/10/safely-manipulating-component-tree-with.html). It works, but it seems strange a component has to register against the 'UIViewRoot.subscribeToEvent' as opposed to just calling 'this.subscribeToViewEvent'? Perhaps this could be explained and documented in the spec.

2. Rinner23 has expressed concerns whether PreRenderViewEvent works inside a UIRepeat (see http://java.net/jira/browse/JAVASERVERFACES-1826?focusedCommentId=308718&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_308718). I have never tested this use case myself.

Regards,

Richard.

Comment by Ed Burns [ 06/Jun/11 ]

Bulk assign all of Sheetal's spec issues to me.

Comment by arjan tijms [ 16/Jul/11 ]

rogerk hinted at a possible necessity for this behavior to be spec'd:

I know there was some initial discussion on the EG related to this area - perhaps some of this should be spec'd so implementations have a blueprint to follow and MyFaces/Mojarra will be doing it the same way.

See: http://java.net/jira/browse/JAVASERVERFACES-1826?focusedCommentId=316876&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_316876

Comment by kennardconsulting [ 07/Nov/11 ]

I have done some further experiments using PreRenderViewEvent within 'repeater' components (such as ui:repeat and h:column).

There appears to be a fundamental problem whereby components that use PreRenderViewEvent cannot also access 'bound attribute values' (such as <h:dataTable var="internal">). Ed believes this is defined at the spec level, so needs to be fixed there too.

See http://java.net/jira/browse/JAVASERVERFACES-2089

Note there is a workaround if the parent component is defined by the developer. But this workaround is not available when using the built-in components (such as h:column).

See https://issues.apache.org/jira/browse/MYFACES-3168

Comment by Manfred Riem [ 16/May/12 ]

All the changes included in 1826, 2371, 2372 and 2373 should account for the ability to manipulate the component tree. Note that dynamic component tree manipulation can happen at any time after restoring the view and before state saving.

Comment by kennardconsulting [ 16/May/12 ]

I must point out that "the changes included in 1826, 2371, 2372 and 2373" do not fully "account for the ability to manipulate the component tree". Several show stopper bugs remain, as reported here http://java.net/jira/browse/JAVASERVERFACES-2283

Please address this! I have been waiting 2.5 years

Comment by arjan tijms [ 17/May/12 ]

Please also note the difference between the practical ability of Mojarra to allow dynamic manipulation and the spec actually demanding that compliant implementations should support this.

Comment by Manfred Riem [ 17/May/12 ]

OK I guess I need to clarify what I meant with my previous comment about 1826, 2371, 2372 and 2373. As this is a spec issue what I meant with it was the fact we have now identified at what point in the lifecycle it is save to do dynamic component tree manipulation. The following clarification / explanation can be added somewhere in the JavaDoc and/or specification. So any JSF implementation is aware of what is expected with regards to dynamic component tree manipulation.

"Dynamic component tree manipulation can happen at any time during and after restoring the view and before state saving and needs to function properly with respect to rendering and state saving"

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-984] Component context management Created: 21/Apr/11  Updated: 12/Aug/14

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.2 Sprint 8
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 15 minutes
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Dependency
depends on JAVASERVERFACES-2272 Implement ComponentModificationManager Closed
Status Whiteboard:

size_large importance_large


 Description   

CA fairly common pattern in JSF is for container components to temporarily set up context that is available while processing children - eg. UIData sets up the "var" value before executing child lifecycle methods. In Trinidad and ADF Faces we have a variety of components that establish similar context.

An issue with this is that there is no way to unwind/suspend this context in cases where it is necessary to interrupt processing in order to start over in a new context - eg. when invokeOnComponent() or visitTree() is called.

Trinidad has solved this problem via its ComponentContextManager API. See:

http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-api/src/main/java/org/apache/myfaces/trinidad/context/ComponentContextManager.java?view=markup

This provides a common mechanism that components can use for pushing/popping/suspending their context and allows for new invokeOnComponent()/visitTree() calls to be initiated in a clean environment.

In addition, Trinidad's UIXComponent provides a number of hooks to assist components with their context setup/teardown.

One problem with Trinidad's solution is that it only applies to Trinidad-based components. Ideally this problem should be solved by the JSF specification in a generic manner so that all components can participate.



 Comments   
Comment by Ed Burns [ 02/Nov/11 ]

Carry forward to 2.2 Sprint 9.

Comment by Ed Burns [ 16/Dec/11 ]

Andy, can you please verify my understanding? Have I got this right:

You are not suggesting that we implement this API and, at the same time, modify
invokeOnComponent() and visitTree() to automatically perform the spend/resume using
the API?

In other words:

This proposal seeks to provide an API that components can use themselves when they need
to be able to temporarily suspend their processing in order to correctly perform
a invokeOnComponent() or visitTree() operation. There will be no occurrences of using
this API in the standard components.

Is that correct?

Comment by Ed Burns [ 16/Dec/11 ]

First draft of API committed to trunk.

Adding jsf-api/src/main/java/javax/faces/component/visit/ComponentModification.java
Adding jsf-api/src/main/java/javax/faces/component/visit/ComponentModificationManager.java
Sending jsf-api/src/main/java/javax/faces/context/FacesContext.java
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Sending jsf-ri/src/main/java/com/sun/faces/context/FacesContextImpl.java
Transmitting file data .....
Committed revision 9521.

Comment by Ed Burns [ 14/Mar/13 ]

Re-opening per Andy's request.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-981] Explain partial state saving concept in spec document Created: 21/Apr/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.2
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Mathias Werlitz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 Description   

The spec 2.1 mentions the partial state saving concept but does not document the idea and which parts have (and how) to work together in order to achieve a correct partial state. In my opinion referencing the JavaDoc of PartialStateHolder is not sufficiant.



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-947] Relative Resources Created: 09/Mar/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 24
Labels: None
Σ Remaining Estimate: 5 days Remaining Estimate: 5 days
Σ Time Spent: 2 hours Time Spent: Not Specified
Σ Original Estimate: 5 days Original Estimate: 5 days

Attachments: Zip Archive sample.zip     Zip Archive sample_broken.zip    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-884 Support library prefix in resource URLs Reopened
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900 Images resources in css with relative... Closed
is duplicated by JAVASERVERFACES-1189 #{resource['...']} not usable in <ui:... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1079 Add method ResourceHandler.isResource... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-548 Resource localization is too rigid an... Sub-task Closed Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-884 Support library prefix in resource URLs Sub-task Reopened  
JAVASERVERFACES_SPEC_PUBLIC-996 The resources folder should be either... Sub-task Closed Ed Burns  
Status Whiteboard:

size_small importance_medium


 Description   

https://issues.apache.org/jira/browse/MFCOMMONS-29

The features of this ResourceHandler include the following:

  • relative paths between resources (css files referencing images
    without using #resource['..'])
  • caching resources in the client (disabled if ProjectStage == Development)
  • GZIP compression and local cache in tmp dir (disabled if
    ProjectStage == Development)
  • i18n (supporting country code and language).

In addition, it does NOT support ValueExpressions in resource files
for performance reasons.

The most important feature, in my opinion, is how the resource URL is
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css

... because it permits resources referencing other resources without
#

{resource['...']}

(e.g. css files referencing images or other css
files). With the standard ResourceHandler this is 1) annoying if you
have to change the files you get from your designer and 2) a
performance bottleneck, because resources with ValueExpressions are
not cached and also regenerated for each request.

Furthermore, the resource URL contains the locale and thus you have no
problems with cached resources if a users changes the locale, because
he/she will get a new URL and thus a new resource (the right one).



 Comments   
Comment by Jakob Korherr [ 15/Apr/11 ]

add duplicate links.

Comment by Jakob Korherr [ 13/Jun/11 ]

Just found out that ICEFaces actually provides a tool for processing url() references in css files which are served by JSF 2.0. For example, this tool creates url(#

{resource['org.site.lib/images/background.png']}

) out of url(../images/background.png).

This shows the big impact of this issue, I think.

See http://wiki.icefaces.org/display/ICE/ACE+CSS+URL+Mapping for more details!

We seriously need to fix this with JSF 2.2! Such (annoying) preprocessing should not be necessary.

Comment by Hanspeter Duennenberger [ 26/Aug/11 ]

Hi Jakob,

it would be usefull if there was a way to specify resources depending on the active ProjectStage - e.g. for css and Javascript files, to allow using packaged resources normally but uncompressed css/javascript when ProjectStage is set to Development.

I was discussing this once with someone and we ended up in a possible solution for that to put additional includeProjectStage/excludeProjectStage condition attributes on @ResourceDependency annotation and probably also same attributes on outputStylesheet/outputScript tags.

Might be this ends up in an additional independent issue, but as you are going to work on ResourceHandling anyway I feel adding it here is ok.

regards
Hanspeter

Comment by lu4242 [ 29/Aug/11 ]

In MyFaces and Tomahawk a custom hack is used to check if the project stage is Development and if a resource under META-INF/internal-resources (or in tomahawk META-INF/uncompressed-js-resources), just take this instead the compressed version used in Production stage.

I believe that it could be more simple to assume a "mirror uncompressed" location, and in practice use some plugin to compress the resources, and add the logic on the default (or custom) ResourceHandler algorithm.

EB> This approach breaks down when there is not a 1:1 mapping between
EB> compressed and non-comporessed resources. For example, when you
EB> want all your JS in one compressed file at Production time, and want
EB> several smaller, non-compressed files, at Development time.

Comment by Jakob Korherr [ 04/Sep/11 ]

Hi Hanspeter,

This is a very, very nice idea! I will prototype that in my relative-resource-handler at apache-extras (see http://code.google.com/a/apache-extras.org/p/relative-resource-handler/).

Also: Since I will have more time in the next two weeks, I really do hope to get some work done for the spec!

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 03/Oct/11 ]

Hi Jakob,

any progress here?

I wanted to add something about the ProjectStage dependent resources. There might be two options for it:

1. use a project stage dependent resource path in the jar (similar to Locale handling with fallback). This is useful if the resource is the same name but only compressed for production, e.g.

myJs/some.js
myJs/production/some.js             (compressed some.js)

2. because the JS files may get pretty big, we would like to use multiple JS files for development but combine/compress a number of such JS files to one for production. This means the number of resource dependencies change depending on project stage.

myJs/funct-a.js
myJs/funct-b.js
myJs/funct-c.js
myJs/{production/}funct-all.js      (compressed combination of funct-*.js files)

So for example, it should be possible to state one component needs funct-a.js and funct-b.js when in project stage Development and only funct-all.js when in project stage Production.

I think possibility 1 is a little closer to what Leonardo mentioned about the MyFaces specific hack.
I really would like to have a specified way to handle project-stage specific resources, this might need some discussion in expert group though.

Cheers
Hanspeter

Comment by Jakob Korherr [ 06/Oct/11 ]

Hi Hanspeter,

Currently I am trying to convince a professor at Vienna university of technology to let me write about the relative resource handler for my bachelor thesis. If this will be accepted, I will have a lot more time for the resource handler.

The idea is really very, very great and I'd like to do some prototyping here. However, I don't know if we should really follow a convention-over-configuration approach. I am actually not sure if we can find a convention for the resource name that will fit in most scenarios. Maybe we need some configuration mechanism here...

Regards,
Jakob

Comment by Hanspeter Duennenberger [ 09/Feb/12 ]

Hi all.

For multiple skins or theme support it will be necessary that the resource path may contain an optional skin or theme-path part.

 Skin-one
 /resources/skin-one/css/main.css

 Skin-two
 /resources/skin-two/css/main.css

The reference to this resource could be:

 <h:outputStylesheet name="main.css" library="css" />

I have kind of such an implementation, but it is probably to much integrated with our Skin interface. It should be a more general solution.

Regards
Hanspeter

Comment by Jakob Korherr [ 14/Feb/12 ]

Hi hanspeter,

You are totally right! In my resource handler I called it "support for multi-tenancy", however, this is not implemented yet.

Actually you need to add every information you need to determine the correct resource into the resource path, thus it somehow is a REST url. I also added a resource-version to the path in order to deal with resource-update-browser-cache problems.

Regards,
Jakob

Comment by Ed Burns [ 27/Feb/12 ]

Jakob, can you please hack upon this sample war to make it show the problem? The current war does use relative resources, but the browser is able to resolve them. Can you make it so the browser cannot resolve them?

Comment by Jakob Korherr [ 29/Feb/12 ]

Hi Ed,

Your sample is somehow funny. You use a css file in webapp/resources/library/style.css using relative paths like this: url(../../included.css) and url(../../expert-draft-bg.png). The two referenced resources, of course, are located two folders up in the directory tree (directly in webapp).

Now as it would seem to be logical that this works, it really is a coincidence. You see, style.css is loaded via the following url:

http://localhost:8080/faces/javax.faces.resource/style.css?ln=library

Thus, included.css and expert-draft-bg.png are loaded by the browser using the following urls:

http://localhost:8080/included.css
http://localhost:8080/expert-draft-bg.png

The 1st ".." removed "javax.faces.resource" and the 2nd ".." removed "faces" (however, you would actually think that the 1st ".." removes library and the 2nd ".." removes "resources"). This, of course, only works because tomcat (or any other servlet container) serves the two files directly, and it has nothing to do with the JSF resource handler (e.g. ValueExpressions won't work!).

Now, there are a number of possibilities to break the example:
1) use .jsf instead of /faces/ FacesServlet mapping
2) locate the two resources in the same folder as style.css (while removing the ".." sequences in style.css)
3) locate the two resources in the classpath (META-INF/resources)
...

I used the 2nd of the above options in my sample_broken.zip.

Here, style.css still gets loaded via:

http://localhost:8080/faces/javax.faces.resource/style.css?ln=library

But now the browser tries to locate included.css and expert-draft-bg.png using these urls:

http://localhost:8080/faces/javax.faces.resource/included.css
http://localhost:8080/faces/javax.faces.resource/expert-draft-bg.png

Which does NOT work, because the library request parameter is missing. My approach (http://code.google.com/a/apache-extras.org/p/relative-resource-handler/) creates an url in which the library is included in the url path, thus this will work.

If you have any further questions, please ask!

Regards,
Jakob

Comment by Jakob Korherr [ 29/Feb/12 ]

Added sample_broken.zip

Comment by Ed Burns [ 29/Feb/12 ]

Thanks for demonstrating to me exactly how this is broken.

Now I can proceed to better see how to fix it!

Comment by Ed Burns [ 29/Feb/12 ]

Looking at your relative-resource handler, it is immediately apparent that the ability for the relative resources to even work is based on how you are encoding the library name differently from what is specified. As stated in the javadocs for RelativeResourceHandler, you have to use

META-INF/relative-resources.xml

to declare libraries and we can't accept that requirement in the spec. Also, the stated limitation of only being able to work with prefix mapped JSF runtimes is unacceptable.

I can see why you made these decisions and how they enable the nice features of your Relative ResourceHandler, but we need to figure out how to do what you request without making unacceptable compromises.

Comment by Ed Burns [ 29/Feb/12 ]

Jakob, what is the main reason for being dissatisfied with this syntax for relative resources?

css_master.css:

@import url(#

{resource['this:layout.css']}

);

Is it performance?

Comment by Jakob Korherr [ 29/Feb/12 ]

The need to have the libraryName configured in relative-resources.xml does only exist, because I needed a way to enable the RelativeResourceHandler only for certain libraries. This would not be necessary if the standard ResourceHandler already uses the "relative-mechanism" (for all libraries).

There are many reasons:

1) Acceptance: There is no other framework (at least which I know of), in which you cannot use relative paths between resources as they would work in the file system. Nearly every IDE supports "resource-exists-checks" in css files with relative paths in the file system, and these IDEs will mark #

{resource[]}

url references as errors. Every server (http or servlet container), CDN,... supports relative paths in the URLs like a normal file system, why should JSF do this differently?

2) Effort: You need quite a lot of time to change a big CSS framework (which you will get from your designers) into a working JSF version. And remember, next day the designer may change something, then you will get a new version of the whole CSS framework, and the work starts again...

3) Performance: Actually, having ValueExpressions in resource files is not only a performance killer, it also gives the developer the impression as if she could change resource file contents in every request, whereas she really cannot, because the resource will get cached by the browser/proxy.

I actually would not use the current JSF ResourceHandler because of these points and instead let tomcat (or even weblets) handle my resources, because they both support relative paths like a calm.

Comment by Ed Burns [ 20/Mar/12 ]

A resource path from Jakob's impl looks like
"/javax.faces.resource/1.0.0/en_US/css/style.css". Does that 1.0.0
refer to library version or resource version?

Here's a clue, from RelativeResourceHandler#132.

// skip version in url (first part, only there to avoid cache problems on updates)
final int versionSlash = resourceName.indexOf('/');

But that still doesn't answer my question. What does the 1.0.0 mean?

Jakob's ResourceHandler.createResource() allows the entire resourceId to
be in the "resourceName", which it re-interprets according to its own
rules if it determines that the library is not a JSF 2.0 style resource
library.

JK> The need to have the libraryName configured in
JK> relative-resources.xml does only exist, because I needed a way to
JK> enable the RelativeResourceHandler only for certain libraries. This
JK> would not be necessary if the standard ResourceHandler already uses
JK> the "relative-mechanism" (for all libraries).

Ok, let's say we make relative libraries the default for prefix mapped
applications. If we have a jar in the classpath that contains a library
that is arranged according to the JSF 2.0 spec for resource libraries,
we now we need some way to detect that case and use the JSF 2.0 style
arrangement, right?

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-907] Improve Ajax Http.Get support to (re)render parts of the page Created: 04/Nov/10  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.1
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: mwessendorf Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 907
Status Whiteboard:

size_medium importance_large


 Description   

The current JavaScript Ajax API should be improved to have a simplified version
that allows to "just" render (several) components, via GET.

A use case would be:
-You have a client side callback that get's invoked (e.g. when a
Bayeux/WebSocket notification arrives). Inside the callback you are simply only
interested in (re)rendering some components.

Today it would look like:

webSocket.onmessage = function(evt)
{
// work with evt.data.....
jsf.ajax.request('jsfForm:dummyBtn',null,

{render:'listComp'}

);
};



 Comments   
Comment by mwessendorf [ 04/Nov/10 ]

Perhaps we could have something like:

/**

  • Issues an Http.GET request to render a set of components.
  • @param varargs that specify a list of components to re-render
    */
    jsf.ajax.renderRequest(varargs);
Comment by werpu [ 04/Nov/10 ]

I think this falls into a similar category like the ajaxed fileuploads, you have
to have a mechanism which allows a switchable transport layer.

We have the basics in myfaces already implemented, due to prototyping the ajax
fileupload for jsf 2.2, but a GET is missing on our side as well, but can be
easily added without too much effort.

Comment by mwessendorf [ 04/Nov/10 ]

For cases like this, another limitation is not only the POST. Also the fact that
'source' is needed..

jsf.ajax.request(source,null,

{render.... }

);

the event can be NULL, but source (currently) not.

Therefore we may need a new function, e.g. renderRequest() - as said before

Comment by rogerk [ 04/Nov/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-904] Composite component file extensions Created: 29/Oct/10  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 904
Status Whiteboard:

size_small importance_medium


 Description   

From jsr-314-open:

> Both MyFaces and Mojarra currently assume/require the file extension ".xhtml" for composite
> component resources. This seems overly restrictive. Composite component authors should be able
> to use other file extensions - eg. ".view.xml", or, as we would like to do here: ".jsf".

Thread starts here:

http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-October/000644.html



 Comments   
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





Relative Resources (JAVASERVERFACES_SPEC_PUBLIC-947)

[JAVASERVERFACES_SPEC_PUBLIC-884] Support library prefix in resource URLs Created: 17/Sep/10  Updated: 12/Aug/14

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0
Fix Version/s: None

Type: Sub-task Priority: Critical
Reporter: cayhorstmann Assignee: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
duplicates JAVASERVERFACES_SPEC_PUBLIC-947 Relative Resources Open
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900 Images resources in css with relative... Closed
Issuezilla Id: 884
Status Whiteboard:

size_small importance_medium


 Description   

Consider a stylesheet

<h:outputStylesheet library="styles" name="skin.css"/>

Resources are loaded with URLs such as

/context path/faces/javax.faces.resource/skin.css?ln=styles

(when prefix mapping is used).

CSS files commonly contain url(...) expressions such as

.ui-icon

{ width: 16px; height: 16px; background-image: url(myicon.png); }

These url(...) expressions fail to locate the dependent resources.

This discussion further explains the problem:
http://forums.sun.com/thread.jspa?threadID=5447194.

It is not reasonable to ask the users to rewrite the URLs in the style sheet
since style sheets are often auto-generated.

While it might be possible for JSF to automatically rewrite the URLs in a style
sheet as it is loaded, that would not work for other files (e.g. JavaScript).

If instead the library name is added as a prefix, then the problem goes away:

/context path/faces/javax.faces.resource/styles/skin.css

(NB. I believe the ?ln=xxx is a vestige of an earlier time
when the version and resource prefix were also specified as request
parameters, see
http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature.)

In the interest of backward compatibility, we can to provide an application
configuration parameter

javax.faces.RESOURCE_URL_MAPPING with options prefix and param

Then
http://download-llnw.oracle.com/javaee/6/api/javax/faces/application/Resource.html#getRequestPath%28%29
needs to be changed as follows:

  1. If getLibraryName() returns non-null, discover if the resources are prefix or
    param mapped, by consulting the application configuration parameter
    javax.faces.RESOURCE_URL_MAPPING. If prefix mapped, insert "/" +
    getLibraryName() after ResourceHandler#RESOURCE_IDENTIFIER. If param mapped, ...


 Comments   
Comment by Ed Burns [ 26/Oct/10 ]

2.2

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by ramiromagalhaes [ 14/Apr/11 ]

This is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900.

Comment by lamine_ba [ 14/Apr/11 ]

It seems that someone has reported this issue since a long time . It was one of the first issue I have to deal with JSF 2.0. How to load with css an image stored in my images folder?
If my faces servlet is mapped to .faces, I can overcome this problem by doing this

background-image: url(myicon.png.faces?ln=images)

If my faces servlet is mapped to /faces/*, I can overcome this problem by doing this

background-image: url(myicon.png?ln=images)

If would be nice if we could come back to this

background-image: url(images/myicon.png)

Comment by Jakob Korherr [ 15/Apr/11 ]

The problem described by lamine_ba is exactly why I created the MyFaces commons resourcehandler module (see [1]). Fortunately I already talked with Ed about it, and we will try to address this issue by re-using some of the code/concepts from MyFaces commons resourcehandler!

[1] https://svn.apache.org/repos/asf/myfaces/commons/branches/jsf_20/myfaces-commons-resourcehandler/

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-874] Clarify Executing Element Id In Ajax Request Created: 05/Aug/10  Updated: 08/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 874
Status Whiteboard:

size_small importance_medium


 Description   

On 8/3/10 10:45 AM, Werner Punz wrote:
> Hello while doing another round of testing and optimisations I noticed a
slight difference in the implementations of the request of mojarra and myfaces
which opened an area where the spec probably is unclear:
>
> Following case:
>
> <h:panelGroup id="bla">
>
> <h:inputText id="inputbla" value="#

{myBean2.searchTerm}

" />
>
> <h:commandLink value="Press me for more action"
action="#

{myBean2.doSearch}

">
> <f:ajax execute="bla" render="content"/>
> </h:commandLink>
> </h:panelGroup>
>
> now results in following post data:
>
> Mojarra:
>
> form2 form2
> form2:inputbla
> javax.faces.ViewState 6697453697014869722:-1090088301633916042
> javax.faces.behavior.even... action
> javax.faces.partial.ajax true
> javax.faces.partial.event click
> javax.faces.partial.execu... form2:j_idt8 form2:bla
> javax.faces.partial.rende... form2:content
> javax.faces.source form2:j_idt8
>
>
> in myfaces
> form2:inputbla
> form2_SUBMIT 1
> javax.faces.ViewState
EmWJgKYkJoTEWDCzpUwZQR3Ek94rGnxK1V6NEZgO6yDgPANeOc1wplJjDYezu2cx9aQ7ZSKNPyGY
L8P9y5DwH2codFvGPjklD04wuxG4XXTPutNww3pdzIsMkw0=
> javax.faces.behavior.even... action
> javax.faces.partial.ajax true
> javax.faces.partial.event click
> javax.faces.partial.execu... form2:bla
> javax.faces.partial.rende... form2:content
> javax.faces.source form2:j_id1980473354_760ba132
>
>
>
> While most of the differeing data is mostly implementation specific and
therefor it is not that interesting following is:
> javax.faces.partial.execu... form2:j_idt8 form2:bla
>
> compared to
>
> javax.faces.partial.execu... form2:bla
>
> Now the difference is that Mojarra adds the executing element as it seems
> while MyFaces does not.
> The second interesting fact is following definition from the spec:
>
> * Determine additional arguments (if any) from the options argument. If
options.execute exists:
> o If the keyword @none is present, do not create and send the post
data argument javax.faces.partial.execute.
> o If the keyword @all is present, create the post data argument with
the name javax.faces.partial.execute and the value @all.
> o Otherwise, there are specific identifiers that need to be sent.
Create the post data argument with the name javax.faces.partial.execute and the
value as a space delimited string of client identifiers.
> * If options.execute does not exist, create the post data argument with
the name javax.faces.partial.execute and the value as the identifier of the
element that caused this request.
>
>
> Which means exactly, that I am not sure which behavior is correct and which
not. My personal guess is that both implementations are
> correct because the spec clearly leaves it open if the issuing element also
can be added to the exec list unless no exec list is given at all.
> But that is merely an assumption on my side here.
> Any ideas on this.
>
> Werner

On 8/4/10 3:31 AM, Martin Marinschek wrote:
> Hi Werner,
>
> I think some clarification would certainly be good there (especially
> as the language doesn't really say what client identifiers should be
> present, plus once talks about client identifiers, and once about
> identifiers only). My POV: for now, Mojarra and MyFaces should behave
> the same. The sentence following the one that you highlighted in bold:
>
> "...with the name javax.faces.partial.execute and the value as the
> identifier of the element that caused this request..."
>
> indicates to me that the triggering client id should be there.
>
> best regards,
>
> Martin

On 8/4/10 5:08 AM, Werner Punz wrote:
> Hi,
> I just did some further digging around in the code specially since I am
currently doing some optimisation stuff in that area in myfaces. And I came to
the conclusion that Mojarras behavior breaks the spec.
>
> The reason. The spec itself leaves it open, but we have an implicit @this
parameter which can be set both in execute and in render
> and if this @this parameter is set then the issuing client id has to be set in
the list where it is set.
> So the spec clearly states here that @this is a placeholder for the executing
element. If is allowed in exec, appending automatically the issuing client id is
pointless.
>
> Werner



 Comments   
Comment by rogerk [ 05/Aug/10 ]

Evaluate

Comment by rogerk [ 27/Aug/10 ]

For now re-target for 2.2.
If time permits may revisit for 2.1.

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by werpu12 [ 06/Mar/12 ]

Ok MyFaces has in the meanwhile cloned mojarras behavior in this regard. So we probably can nail down the mojarra status quo into the spec.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-850] spec modifications to composite VDL docs Created: 22/Jun/10  Updated: 25/Mar/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: rogerk Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-853 composite.tld Missing composite:clien... Closed
Issuezilla Id: 850
Status Whiteboard:

changelog size_small importance_medium

Tags: changelog_2_1

 Description   

In composite.tld, need to specify "deferred-method" element nested within
cc:attribute.



 Comments   
Comment by rogerk [ 22/Jun/10 ]

changelog

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by Ed Burns [ 13/Sep/10 ]

add changelog_2_1 keyword

Comment by Ed Burns [ 20/Sep/10 ]

Ensure changelog_2_1 is in keywords list

Comment by Ed Burns [ 22/Oct/10 ]

composite.tld: Specify deferred-method Element Within cc:attribute

Also depends on issue 853: cc:clientBehavior not specified.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 25/Mar/15 ]

Reassigned to Ed as I am uncertain how exactly to do this





[JAVASERVERFACES_SPEC_PUBLIC-807] Need to pass FacesContext instance to system event listeners Created: 24/May/10  Updated: 03/Sep/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-473 FacesEvent should have a convenience ... Resolved
Issuezilla Id: 807
Status Whiteboard:

size_small importance_medium


 Description   

Reviewing some stuff, it was notice that the FacesContext instance is not passed
when event processing occur, so every time a system event should be processed, a
call to FacesContext.getCurrentInstance() should be done in almost all cases.

Below there are one example based on myfaces code (removed non relevant code):

public class HtmlStylesheetRenderer extends Renderer implements
ComponentSystemEventListener
{

public void processEvent(ComponentSystemEvent event)

{ UIComponent component = event.getComponent(); FacesContext facesContext = FacesContext.getCurrentInstance(); facesContext.getViewRoot().addComponentResource(facesContext, component, "head"); }

......
}

It could be good to pass the current facesContext (note the code in
Application.publishEvent receive it as param), to prevent those unnecessary
calls and enhance code performance. In theory it is possible to cache
facesContext object on listeners suscribed using
UIViewRoot.subscribeToViewEvent() because those listeners are not saved (but
maybe not because if the same view is used on portlet....), but that's not
possible on ComponentSystemEventListener instances.



 Comments   
Comment by Ed Burns [ 25/May/10 ]

Move to 2.1

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Hanspeter Duennenberger [ 19/Nov/10 ]

If FacesContext would be passed on all FacesEvent/SystemEvent objects, every
listener would have access to the current FacesContext from FacesEvent.

Thus the below code would look like:

public void processEvent(ComponentSystemEvent event)

{ UIComponent component = event.getComponent(); FacesContext facesContext = event.getFacesContext(); facesContext.getViewRoot().addComponentResource(facesContext, component, "head"); }
Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-803] Documentation of VisitHint.EXECUTE_LIFECYCLE is not clear Created: 18/May/10  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 803
Status Whiteboard:

size_small importance_small


 Description   

Looking the documentation there is a hint called VisitHint.EXECUTE_LIFECYCLE
that says the following:

"Hint that indicates that the visit is being performed as part of lifecycle
phase execution and as such phase-specific actions (initialization) may be taken."

I understand why VisitHint.SKIP_TRANSIENT and VisitHint.SKIP_UNRENDERED, but
looking the javadoc I couldn't find when, how or why that hint should be set. At
this time, myfaces just ignore it, but if it is used, there should be some
documentation on UIComponent.visitTree or UIData.visitTree. Maybe I'm wrong
about that, and if myfaces don't use it really there is not problem, but the
point is: Is mojarra really implementing the algorithm that says the javadoc?.
It could be good if someone could check this algorithm against javadoc, because
really it is very suspicious.

ANDY>Martin suggested "EXECUTE_LIFECYCLE" for this concept, and we rolled with that.

ANDY>In the version of Mojarra that I happen to have sitting here (about a month
old), UIData is looking for this hint. However... the PartialViewContext
implementation is not actually setting the hint, so this is not actually being
used at the moment.

After discuss this stuff, it was clear the utility behind
VisitHint.EXECUTE_LIFECYCLE, but if it is used, the documentation of
UIData.visitTree should be more explicit about how and when it is used (Right
now it is not clear from where this hint should be checked and the effect)



 Comments   
Comment by Ed Burns [ 19/May/10 ]

move to p2

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 24/May/10 ]

Mojarra UIData has this method

private void preVisitChildren(VisitContext visitContext) {

// If EXECUTE_LIFECYCLE hint is set, we need to do
// lifecycle-related initialization before visiting children
if (visitContext.getHints().contains(VisitHint.EXECUTE_LIFECYCLE))

{ FacesContext facesContext = visitContext.getFacesContext(); PhaseId phaseId = facesContext.getCurrentPhaseId(); if (phaseId == PhaseId.APPLY_REQUEST_VALUES) preDecode(facesContext); else if (phaseId == PhaseId.PROCESS_VALIDATIONS) preValidate(facesContext); else if (phaseId == PhaseId.UPDATE_MODEL_VALUES) preUpdate(facesContext); else if (phaseId == PhaseId.RENDER_RESPONSE) preEncode(facesContext); }

}

I will update the docs for UIData to require this behavior, but because this behavior is not currently
specified, I cannot include it in 2.0 Rev a. Therefore, I will move it to 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-790] javax.faces.ViewState + PPR does not work out for cross form ppr cases Created: 06/May/10  Updated: 25/Feb/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: werpu12 Assignee: balusc
Resolution: Unresolved Votes: 54
Labels: None
Remaining Estimate: 5 days
Time Spent: Not Specified
Original Estimate: 5 days
Environment:

Operating System: All
Platform: Macintosh


Attachments: Text File 790-js-workaround.txt     Text File changebundle.txt     Text File changebundle.txt     Java Source File ExtendedViewHandler.java    
Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-3436 ViewScoped bean reconstructs when usi... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1093 The id attribute of javax.faces.ViewS... Open
is related to JAVASERVERFACES-1715 Missing ViewState during partial view... Closed
Issuezilla Id: 790
Status Whiteboard:

size_small importance_small


 Description   

Following problem
<h:form id="a">
<h:commandButton action="#

{TestBean.action}" value="submit"/>
</h:form>

<h:form id="b">
<h:commandLink value="ajax ReRender"
onclick="jsf.ajax.request(this,event,{execute:'b a',render:'a'}); return false;"/>
</h:form>

Cannot work out because, the viewstate is returned as separate viewstate block
(in both implementations the <update id="a"> does not pass the viewState in the
update block.

Now the specification says:
If an update element is found in the response with the identifier
javax.faces.ViewState:

<update id="javax.faces.ViewState">
<![CDATA[...]]>
</update>

locate and update the submitting form's javax.faces.ViewState value with the
CDATA contents from the response.


Which means in this special case that the viewState for form a is lost.
Mojarra has fixed this to some degree by setting the viewstate if a direct form
render on a happens.
However if you do following:
<h:panelGroup id="myGroup">
<h:form id="a">
<h:commandButton action="#{TestBean.action}

" value="submit"/>
</h:form>
</h:panelGroup>

<h:form id="b">
<h:commandLink value="ajax ReRender"
onclick="jsf.ajax.request(this,event,

{execute:'b a',render:'myGroup'}

); return
false;"/>
</h:form>

Mojarra also fails.

The problem here lies clearly with the spec, I am not sure why the viewstate is
only updated to the issuing form.

Either all forms must be updated or at least the forms which are processed both
within the execute and render parts.

I also opened a discussion on the open mailinglist regarding this, since this is
a usecase which can happen quite often in a typical rich client szenario where a
lot of detachments can happen to satisfy ie6 and multiple forms are the norm if
you have floating frames.



 Comments   
Comment by Ed Burns [ 24/May/10 ]

Agree for inclusion in 2.0 Rev a

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 27/May/10 ]

I agree we should update all forms. Move to 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by werpu12 [ 12/Jul/10 ]

Actually I personally think the only possible solution here is to offload this
to the server, instead of issuing <update id="javax.faces.ViewState"> we have to
extend the protocol here so that the client is notified which form and viewstate
element needs to be updated.
I am not sure if updating all forms automatically really resolves the issue,
because in a portlet scenario this does not work out, how about client side
state saving or even worse if someone introduces multiple viewroots
programmatically just as portlets do?

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by frederickkaempfer [ 21/Sep/11 ]

The same problem occurs (in Mojarra 2.1.3) when the entire ViewRoot is replaced via ajax. In that case none of the forms get their view state updated. You need to submit a form at least twice in order to trigger the execution of the full JSF lifecycle. The first time only a new ViewState field is created in the submitted form.

At least all forms contained in the rendered section need to have their view state field updated. In the current implementation a ViewState field is only created if the render target is it self a form (not a parent of forms).

Updating all forms on the page is also a possibility though strictly speaking forms not contained in the <update/> section of the Ajax request are not part of the newly generated view state.

Possible duplicates of this bug I found so far:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1024
http://java.net/jira/browse/JAVASERVERFACES-2199

Comment by frederickkaempfer [ 22/Sep/11 ]

I have created a fix for the issue, which updates the ViewState field for forms which are children of the specified render targets.

Furthermore it handles the case where render="@all" is used. In this case all forms in the document will have their ViewState field updated. Previously this caused forms to loose their ViewState.

Note that this fix does not update all forms in the document, but only those which have been re-rendered (thus are part of the newly generated view on the server).

Comment by werpu12 [ 22/Sep/11 ]

Actually I have similar fixes for myfaces, I basically update all forms which have render targets in or forms which are part of a render target.
Additionally to that I added a update all config option which is outside of the spec.
But nevertheless.

But that is just a hack in my opinion. The root problem is in the protocol.
The protocol simply needs to deliver a list of form ids which need a viewstate update.
So I personally think the only viable long term solution to this problem simply is to update the protocol of jsf 2.2 in this regar ala <update id="javax.faces.ViewState" updateIds="id1 id2 id3">dkghsfkjgh</update> or for backwards compatibility reasons introduce an entirely new tag like <updateViewState id="...">....

Comment by rogerk [ 22/Sep/11 ]

Your workarounds are fine for now, but clearly this needs to be a spec change for the better.

Comment by frederickkaempfer [ 22/Sep/11 ]

If it was safe to assume that the ViewState does not change during a partial request the logic can be simplified by updating ALL forms in the document (not just render targets).

In Mojarra's ServerSideStateHelper (line 200) this assumption holds true, but I did not find anything in the spec enforcing this.

Additionally this would also take care of any Form dynamically added to the view or any render ids added via facesContext.getPartialViewContext().getRenderIds().add(...);

Right now only the "javax.faces.partial.render" argument is consulted which is indeed suboptimal.

I can change the workaround to simply update all forms in the page, which would also make it less of a "Hack". What do you think?

Comment by rogerk [ 22/Sep/11 ]

I was thinking along those same lines..
In which case we would not need to introduce a new response element as Werner mentioned.
It's been sometime since we looked at this - it has been discussed before.
Are there any portlet implications (namespace related) by doing this (that was brought up - but could be for a different issue)..

Comment by werpu12 [ 22/Sep/11 ]

Actually there are portlet implications, hence i stayed away from updating all forms automatically, but made it a config option you can turn on in myfaces.

The implication is that different portlets can host different forms under different viewroots and hence have different viewstates.
Now the main problem is, we dont have any viewroot information. So it comes down to following:
a) either send the viewstate info with an altered protocol i mentioned

  • safe since every form must have a unique id in the dom no double ids are allowed

b) add viewroot information and then update all forms under the corresponding viewroot - should be safe as well but is in my opinion not as clean as option a) and probably causes an alteration of the protocol as well (ala introduction of a viewroot element) or on the api side. I am not sure if we have a scenario where we have different viewstates under one viewroot though. I never really bothered to look deeper into this aspect of the jsf spec.

c) Try to move forward with the usual hacks - worst option of all

In my personal experience this multi form issue has been a huge issue for the users, I had about 5-10 requests on the myfaces mailinglist where users had problems and thought it was an issue of the implementation.

Comment by frederickkaempfer [ 23/Sep/11 ]

It's true that updating all forms won't work in any case where there are multiple viewroots involved. Anyhow I was hoping to find a solution that is usable even with the 2.1 and 2.0 spec versions, because this bug is not an enhancement, but currently breaks a couple of basic Ajax features in JSF. To summarize them quickly:

1. Specifying parents of forms as render targets.
2. Using the @all render target on any page with multiple forms.
3. Replacing the entire viewroot, for example via <h:commandLink action="myNavigationOutcome"><f:ajax/></h:commandLink>
4. Dynamically adding RenderIds that include forms in JSF Lifecycle with facesContext.getPartialViewContext().getRenderIds().add(...)

The workaround I provided should at least make 1-3 work again. Updating all forms in the document would make 1-4 work, but as you said will break Portlet compatibility.

There is another option to consider that does not require a protocol change:

Before the doUpdate function is called for any of the changes read the view state information at the end of the partial response document and save it in a variable in the jsf.ajax.response function. the viewstate can then be passed to any call of doUpdate function, which can then take care of creating view state fields where it is appropriate. This way we would not have to redundantly send the render ids, as they already provided as the <update> ids.

Comment by frederickkaempfer [ 23/Sep/11 ]

Here is a changebundle that updates the ViewState for each form element that is replaced during the ajax update.

I wonder if a Spec change is even necessary because: If a form is processed during an update it means that its ViewState field has to be updated (or created) as well. With this patch it is now done in the doUpdate function. On the other hand, if a form is not re-rendered there is no compelling reason to update its ViewState field, because if it had been changed on the server-side this would not be visible in the browser.

So following this logic, specifying the "updateIds" in a new protocol element will always replicate the render ids which are already contained in the <update> tags (or any of the forms contained in them, which can also be found using JavaScript, like it is done in the provided patch).

Do you think this is still too "hack"-ish?

Comment by werpu12 [ 23/Sep/11 ]

Unfortunately things are not that simple. I cannot speak for mojarra, but I assume it is similar, but myfaces has a meta information in the viewstate which also pinpoints to the viewid (and the state history as well) so if you do not update a second form even if you dont have a rerender there, you basically at a submit from that form can get a cannot find viewid once it drops out of the view history.

So we have two problems
a) update all forms automatically is prevented due to the fact that it breaks in a portlet environment

b) not updating not rendered forms might break the state history information of the viewstate not updated

So a pure javascript fixup will work and might work under normal non portlet circumstances (the simplest one probably is simply to update all forms for a normal webapp) but it will break in corner cases like portlet environments. Thats one of the reasons why I implemted about three fallback modes for this problem in myfaces. So that if even one fallback fails the user can switch to another one which might suite to his environment.

Comment by frederickkaempfer [ 23/Sep/11 ]

I think Mojarra does not even change the ViewState during partial requests.

Nevertheless I suppose there are two separate issues surfacing here that are remotely related. This patch should work in a Portlet scenario as well as the unpatched version and it fixes the 4 issues I mentioned earlier including the initial bug report. Contrary to updating all forms in the document, it doesn't make it any worse for the portlet scenario. But yes, it is a preliminary hack, if you consider the following change as the right way to handle the situation:

In your last comment you basically said that on each Ajax request all forms contained in a one ViewRoot have to be updated with new state information - at least in the case of MyFaces (it would work for Mojarra as well because the ViewState doesn't change):

  • If we are in a "normal" (non-portlet) environment with just one ViewRoot, this means updating all forms contained in the entire document.
  • If we are in a portlet environment it would mean updating all forms that are contained in the current ViewRoot.

So wouldn't the best course of action be your option b): make it possible to specify the view root element's id additionally in the partial response. If it is not specified or is set to a default value, update the entire document, if not only update forms contained in the viewroot element. This would also add the possibility to rerender a complete portlet with the special render target @all, which represents entire ViewRoot element. Sadly I don't know enough about the portlet spec to tell if this is a good idea and if this change is enough to support it properly.

Providing a list of update ids would then again be redundant, because the forms that need updating depend only on the ViewRoot that is currently - partly or in whole - redisplayed.

If this sounds like the right way to do it, then applying the changebundle will be counterproductive, because it is unnecessarily complex compared to updating all forms in the current ViewRoot. On the other hand it could even be backported to 2.0 or 2.1, it does not make things worse for portlets and it fixes the 4 critical bugs/problems i mentioned.

Comment by Ed Burns [ 23/Sep/11 ]

Thank you for excellent and clear analysis. Given my desire to include sketches for JAVASERVERFACES_SPEC_PUBLIC-730, JAVASERVERFACES_SPEC_PUBLIC-517, and JAVASERVERFACES_SPEC_PUBLIC-802, in next week's EDR of the spec, I'm going to defer this til after JavaOne.

Comment by codylerum [ 02/Nov/11 ]

This also is an issue with popup panels which often have their own form that when submitted rerenders content on the main page.

Since any forms on the main page did not participate in the submit they don't rerender with a viewstate and are unusable.

Comment by mdirkse [ 06/Dec/11 ]

Added a javascript workaround that fixes this issue and can be executed via the browser onLoad event handler. There are 2 versions: a plain JS one, and a jQuerified one. Tested and confirmed for Mojarra 2.1.2 (and jQuery 1.7.x).
Mad propz to frederickkaempfer for the original JS code.

Comment by werpu12 [ 06/Dec/11 ]

Sorry to crush some hopes here, but the posted solution is exactly the one I have in myfaces for the non portlet case (you can turn it on via a config param). And there it works, but it can only work in a non portlet environment, because there you have only one viewroot. So you can update all forms under document.

In a portlet environment you can have several viewroots under document with independend viewstates and independend forms. There the patch ultimately will break your portlet environment by applying wrong viewroots to other portlets. Thats because the which dom node is the viewroot info is simply missing on the client side and/or the protocol.

As I said before unless you have the viewroot info or you know which forms you update there is no way to resolve that issue for the portlet and non portlet case at the same time. The problem really is a problem of the protocol not the implementation.

Comment by rogerk [ 06/Dec/11 ]

I agree with Wevner's earlier assessment - that to handle the portlet case - multiple independent view root (eaxh with one or more forms) - we do need a new "server to client" message protocol that draws the association of which forms the view state should apply.

Comment by mdirkse [ 06/Dec/11 ]

werpu12 is right, the workaround I posted only works for the non-portlet case (and is only verified for mojarra 2.1.2)

Comment by sharath.naik [ 29/Dec/11 ]

Updating the MultiViewHandler's [ public void writeState(FacesContext context) throws IOException ] seems to fix the issue. The change made is to add the view state hidden field for forms, even when is a ajax request.

What is the purpose of not writing the view state if it is a partial request in this method?

Attaching the custom ViewHandler to override this method. would this be a fix that can be considered to be moved to MultiViewHandler?

Comment by frederickkaempfer [ 02/Jan/12 ]

@ sharath.naik: It's probably left out because the jsf ajax response already includes the view state information in an <update> tag, so the field can be created using JavaScript.

As I said earlier, the minimum a JSF implementation should do is update the view state information for all forms included in the render target list. I don't see how this creates any new problem in the portlet environment and that is what the latest changebundle I submitted does. Currently the algorithm detailed in the spec is not general enough and should be corrected.

A broader approach is to update all forms under the current view root. For that a protocol extension is necessary which tells the client which DOM element represents the view root. It would also enable scenarios where the whole view root is replaced (like @all and navigation) for the portlet environment. In my opinion for this a new spec enhancement should be issued.

Comment by codylerum [ 15/Feb/12 ]

Is the attached workaround meant to be called from the oncomplete of an ajax component or am I missing another way to trigger it?

Comment by frederickkaempfer [ 22/Feb/12 ]

@codylerum: it should be enough to execute the script once on a page load, after jsf.js is loaded of course.

Comment by Ed Burns [ 03/May/12 ]

TG> (First of all, javax.faces.ViewState should not be modified for Ajax
TG> updates using server-side state-saving, but this simple approach
TG> does not appear to be the current direction.)

Can you please elaborate more on what you mean by this? The issue
doesn't mention anything about Ajax specifically. Is this a separate
concern you are raising, Ted?

TG> We are a bit unclear on how the current implementation is intended
TG> to work, but expect that something like the following is necessary:

TG> When the request is submitted, call
TG> getElementsByName('javax.faces.ViewState') and store the list of IDs
TG> for all with equal value to that of the javax.faces.ViewState in the
TG> submitting form. In the case of future JSP inclusion or current
TG> Portlets, there will be javax.faces.ViewState fields not associated
TG> with the current view. They will have different values and are not
TG> included in the list.

TG> When the partial response is generated, it may contain rendered
TG> hidden inputs with name javax.faces.ViewState and unique IDs, but
TG> also contains the special case <update
TG> id="javax.faces.ViewState"><![CDATA[...]]></update>. The previously
TG> stored list of IDs are now all updated to use the new value. Any
TG> javax.faces.ViewState hidden fields that have been modified by the
TG> page update itself (potentially now having different IDs) have the
TG> correct value anyway because they were just updated.

These two comments are better suited to JAVASERVERFACES_SPEC_PUBLIC-790,
so I'll copy them there. Ted, can you please take a look at 790 and see
if you agree that your comments pertain more to that issue than this
one?

Comment by tedgoddard [ 07/May/12 ]

At least in the case of MyFaces, this complicates things considerably:

"Unfortunately things are not that simple. I cannot speak for mojarra, but I assume it is similar, but myfaces has a meta information in the viewstate which also pinpoints to the viewid (and the state history as well) so if you do not update a second form even if you dont have a rerender there, you basically at a submit from that form can get a cannot find viewid once it drops out of the view history."

It makes it necessary to update the ViewState key for every request. I was under the impression that a similar strategy was being considered for Mojarra.

In my above comments, I assume that the form Renderer would be modified to always write out the ViewState (even for partial rendering). Alternatively, the javax.faces.ViewState fields could be updated via two cases:

  • javax.faces.ViewState found in the current HTML document that match the submitting javax.faces.ViewState will be updated after the current response
  • javax.faces.ViewState found in the updated regions will be updated after the current response

This should handle portlet, servlet inclusion, and multiple form cases.

Comment by boogi [ 31/May/12 ]

Hi,
It says on fix version "2.2 Sprint 12" but it appears as unresolved on that sprint.
Do you a new estimation for the solution of this issue?

Comment by javaone9 [ 02/Nov/12 ]

I tried 2.1.14. it did not work.
I think this issue is urgent for any applications.

Comment by frederickkaempfer [ 18/Apr/13 ]

Please don't forget this issue for 2.2. It's one of the most annoying and frustrating aspects of the JSF Ajax experience. It would be a shame if the JSF community would have to wait another spec release -possibly another year- before this gets fixed.

tedgoddard made it very clear how to proceed with this issue in the previous comment.

Thanks a lot.

Comment by kfyten [ 25/Apr/13 ]

Roger/Ed - Just wanted to make it clear that this issue is currently blocking ICEfaces support for JSF 2.2. From a roadmap perspective it would be very helpful to us if this JIRA could be updated to reflect the current reality in terms of whether/when this issue may be resolved prior to 2.2 final release.

Thx.

Comment by rogerk [ 26/Apr/13 ]

Unfortunately I don't believe this made it into 2.2.

Comment by balusc [ 08/May/13 ]

This is really unfortunate.

In the meanwhile, developers can use this script to workaround the issue: http://balusc.blogspot.com/2011/09/communication-in-jsf-20.html#AutomaticallyFixMissingJSFViewStateAfterAjaxRendering

Comment by frederickkaempfer [ 08/May/13 ]

@balusc: I think that the workaround scripts have to be changed for 2.2, because the id of the ViewState field has been changed slightly. I didn't yet have time to look into it.

Comment by arjan tijms [ 08/May/13 ]

I think that the workaround scripts have to be changed for 2.2, because the id of the ViewState field has been changed slightly. I didn't yet have time to look into it.

They have changed indeed, see http://jdevelopment.nl/jsf-22/#220 and JAVASERVERFACES_SPEC_PUBLIC-220 for more details about this.

Comment by codylerum [ 08/May/13 ]

This is one of the larger pain points for developers utilizing ajax so it is very unfortunate that we are likely looking at years for resolution. Can anything be done at this point to speed that up?

Currently this issue has almost 2x the votes of the next closest issue.

Comment by swathireddy12 [ 22/Aug/13 ]

I am making use of JSF 1.2 version of jars (myfaces-api-1.2.9.jar ,myfaces-impl-1.2.9.jar,trinidad-api-1.2.13.jar,trinidad-impl-1.2.13.jar).
I am trying to retrieve the javax.faces.ViewState using the id attribute in a Javascript which works.

But i still don't see the id attribute in the loaded page
<input type="hidden" name="javax.faces.ViewState" value="!-14uywjgjai">

Could you please tell me if this is an issue with JSF 1.2 version as well?
Or once the page is rendered the id attribute associated with "javax.faces.ViewState" is not seen anymore.

Comment by werpu [ 22/Aug/13 ]

No this is a JSF 2.x issue only. This has nothing to do with JSF 1.2.

Comment by balusc [ 13/Jan/14 ]

This is one of the larger pain points for developers utilizing ajax so it is very unfortunate that we are likely looking at years for resolution. Can anything be done at this point to speed that up?

For exactly this reason, it has been added to OmniFaces 1.7: http://showcase.omnifaces.org/scripts/FixViewState

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-783] Unclear specification description for jsf.util.chain Created: 08/Apr/10  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: werpu12 Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 783
Status Whiteboard:

size_medium importance_large


 Description   

The current specification is very unclear regarding the parameters in the
jsf.util.chain functionality:

Here is the original quote:
jsf.util.chain(source, event)

A varargs function that invokes an arbitrary number of scripts.

<static> jsf.util.chain(source, event)

A varargs function that invokes an arbitrary number of scripts. If any script in
the chain returns false, the chain is short-circuited and subsequent scripts are
not invoked. Any number of scripts may specified after the event argument.

Parameters:
source
The DOM element that triggered this Ajax request, or an id string of the
element to use as the triggering element.
event
The DOM event that triggered this Ajax request. The event argument is optional.

There are several issues (some of them have been raised in the open list)

First of all it defines no return value so attaching functionality cannot
determine whether the chain has been processed fully or terminated only.
After asking in the eg it was more or less a consensous that the return value is
either true for having it processed fully or false otherwise, so that behaviors
can react properly.

Secondly, the entire parameter list aspect is rather unclear, first we have a
varargs function her, but it defines the event object as fixed object being
passed down, on the other hand it says it is optional.
So the description is clearly contradictory!

What was probably meant was that the event object must be passed down but its
values either can be an Event object or null or undefined!

therefore a call like chain(this, event, "alert..."
is valid
while a call like chain(this, "alert..." clearly is invalid
however a call like chain(this, null, "alert ..." ...

Have in mind that undefined, not always is an optional parameter in javascript,
but a full blown object of type 'undefined'!

The third issue is the term arbitrary number of scripts, a script can be two
things in javascript, either a string which later is evaluated (which is what
happens if you attach f:ajax, or it can be a function object which is passed
down which then later is executed.
I coded both cases into our myfaces chain, just to make sure the term arbitrary
is met, but this needs further clarification on the doc side as well!



 Comments   
Comment by Ed Burns [ 13/Apr/10 ]

2.1

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

triage- get in for 2.1_gf31_m6

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 27/Aug/10 ]

For now re-target for 2.2.
If time permits may revisit for 2.1.

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-776] <h:form> should support method=GET Created: 24/Mar/10  Updated: 22/Jan/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

Operating System: All
Platform: All


Issuezilla Id: 776
Status Whiteboard:

size_medium importance_medium


 Description   

Use Case: Imagine a simple search form with dropdown filters. Publicly
accessible, but server-side state saving is enabled for security reasons.

  • visit yoursite.com/search (which is a JSF search form)
  • do a search
  • see results screen which itself has a populated search box
  • wait for session timeout
  • click search
  • blammo

or even simpler:

  • visit yoursite.com/search (which is a JSF search form)
  • wait for session timeout
  • click search
  • blammo

Due to the fact that the JSF form is rendered and always does a POST back, there
is no way to prevent this aside from the typical "refresh the page every few
minutes before session times out," which I do not consider a great solution
because it means you're keeping sessions open as long as people sit on that page.

If <h:form> supported the method="GET" attribute and behavior, people could
avoid this situation entirely. Basically turning the form into a way to bind and
validate input (no value change listeners, most likely) but still get
functionality of inputs and action methods. It would nicely address this kind of
simple use case.



 Comments   
Comment by Ed Burns [ 18/May/10 ]

Requires impl change. Move to 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by kito75 [ 20/Apr/11 ]

This is pretty important – people have complained about the ViewExpiredException in this scenario to me before at talks; this would fix that problem.

It's also something that newbies expect to be supported.

Comment by lincolnbaxter [ 20/Apr/11 ]

I would vote for this if I could... it's a big issue.

Comment by arjan tijms [ 08/May/12 ]

This was targeted for JSF 2.2, but is it still considered for that release?

GET support is obviously still very important for a variety of use cases. JSF 2.0 has added great support for GET in general, but unfortunately h:form is still missing.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-677] Document more clearly the automatic UIPanel behavior for f:facet (was: f:facet can have more than one child) Created: 01/Dec/09  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: None

Type: Task Priority: Critical
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 677
Status Whiteboard:

cat2 vdldoc size_small importance_small


 Description   

Testing mojarra we found out that <f:facet> now can have more than one children,
which will automatically be put in a UIPanel.

However, the spec never mentions that fact.



 Comments   
Comment by mojavelinux [ 18/Dec/09 ]

Update milestone to 2.0 Rev a

This actually became a requirement to support <f:metadata>, so the rule is
loosely implied in that section.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 04/Mar/10 ]
      • Issue 522 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 22/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by Ed Burns [ 30/Jun/10 ]

I did some more research on this, digging into the JSF 1.0 (JSR-127) archive. Here's what I found:

On Wed, 13 Nov 2002, Craig McClanahan wrote:

CM> However, I believe the APIs would be simpler if we actually required
CM> the value pointed at by a "named child" name to be, in fact, a
CM> single component. In the cases where you really would like to use a
CM> collection, it's straightforward to use something like a UIPanel
CM> with arbitrarily nested contents – my "Grid" and "List" renderers
CM> in jsf-pseudo follow this sort of design pattern.

CM> Therefore, I'm proposing that, in the map of "named child" nodes,
CM> the key must be specified (and unique within parent), and the value
CM> must be a single UIComponent. If we decide that the "named list"
CM> notion is also useful, we can relax the latter constraint.

On Fri, 15 Nov 2002 Adam Winer wrote:

AW> The most common use case is that each name/role has either
AW> zero or one corresponding component.

AW> There's an open question of whether it's worth the added complexity
AW> to support a List of components per name/role, but I've not found this
AW> to be especially helpful.

I'm reluctant to change this beyond more clearly documenting the behavior of Mojarra to automatically
fabricate a UIPanel in the case of multiple children within a UIPanel.

Jacob, is this OK? If so, I'd like to change the Summary to:

Document more clearly the automatic UIPanel behavior for f:facet.

Comment by Jakob Korherr [ 02/Jul/10 ]

Yes, of course this is OK for me!

It would just be great to have some documentation about this new feature. For
example one question that would really be necessary to answer is: is this
behavior only supported on facelets or also on JSP?

Thanks!

Comment by Ed Burns [ 02/Aug/10 ]

fix summary as described

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by paul_dijou [ 13/Jun/12 ]

I was going to post a similar issue but I just found this one. I agree that the spec and Mojarra are not synchronized on that point.

Any news about the status of this issue? Will the spec be reviewed to allow several child inside a facet and wrap them automatically inside a javax.faces.component.UIPanel ?

Regards

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-672] Allow Ajax Listener for jsf.ajax.request Created: 17/Nov/09  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: driscoll Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 672
Status Whiteboard:

cat2 jsdoc size_medium importance_large


 Description   

There is no defined way to specify an arbitrary method to be called server-side
on the execution of a jsf.ajax.request function call.

This is an oversight in the spec, and it should be addressed for 2.1. In the
meantime, you can get almost equivalent functionality by using a valueChange
listener or an action listener in most cases.



 Comments   
Comment by driscoll [ 17/Nov/09 ]

javax.faces.behavior.event is also the way we currently transmit this data from
client to server. This is currently unspecified, and needs to be added to the spec.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

jsdoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 26/Aug/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.





[JAVASERVERFACES_SPEC_PUBLIC-613] Support standard AJAX server-side method invocation Created: 15/Aug/09  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Unresolved Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC
URL: http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/a4j/jsFunction.html


Issuezilla Id: 613
Status Whiteboard:

cat2 frame size_medium importance_large draft


 Description   

> Almost every AJAX framework I know of allows you to
> simply execute a method on the server side, with or without params,
> and return a result.

JSF should support this behavior. Use cases include:

  • Calling a server-side method to return values used to control page behavior.
  • Calling a server side method to submit data to the application, returning
    success, failure, or nothing to the UI.

This functionality is already part of the JBoss Ajax4JSF framework, every PHP
ajax framework, and every non-server tech-specific framework (such as Dojo,
Prototype, etc..)

See A4J:jsFunction component –
http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/a4j/jsFunction.html



 Comments   
Comment by Ed Burns [ 21/Aug/09 ]

Sure, I'll entertain this.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 25/Sep/09 ]

Retarget to 2.next

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by lincolnbaxter [ 26/Jan/10 ]

Categorized as part of Rev 2.0 A prep

Comment by rogerk [ 05/Mar/10 ]

cat2 - yes - this would be nice!

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 01/Jul/10 ]

re-target

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-559] Support for the "Synchronizer Token" pattern (avoiding double submits) Created: 05/May/09  Updated: 23/Mar/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 13
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: File jsf2csrf.war     File jsf2token.war    
Issuezilla Id: 559
Status Whiteboard:

cat2 frame size_medium importance_large cat3 draft


 Description   

This is a very common web application problem
(http://www.javajunkies.org/index.pl?lastnode_id=3361&node_id=3355) – avoiding
double submits. Struts had built-in support for this. JSF-related implementations:

Spring Web Flow, Struts 2, and Grails 1.1
(http://www.grails.org/1.1+Release+Notes) also support this natively.

I'd really like to see this in JSF 2.1 at the very latest.



 Comments   
Comment by Ed Burns [ 11/Aug/09 ]

Move to 2.1. Also make this handle Dan's concern here:

DA> It's crucial that the enablement of this feature be accompanied by a
DA> secure token being exchanged in the case of server-side state
DA> saving.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

lifecycle

Comment by Ed Burns [ 07/May/10 ]

Transaction token has been requested many times over the years.

Comment by kito75 [ 08/May/10 ]

I've got some code I wrote for a client based on Shale's token that I can clean up and submit as a
prototype. If you're interested, just let me know when it's time.

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

xsrf

Security related, target for GlassFish 3.1 M3

Comment by Ed Burns [ 30/Jun/10 ]

cat3

Comment by rogerk [ 01/Jul/10 ]

Hey Kito -

It's time. Let's see what you have. If you can also submit a proposal that
would be helpful as well.

-roger

Comment by rogerk [ 01/Jul/10 ]

This could probably reside in the core namespace - like f:token ?

Comment by Ed Burns [ 01/Jul/10 ]

Roger, please take a look at https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812 for more
valuable information.

Comment by rogerk [ 01/Jul/10 ]

Ahh yes - thanks for the pointer. Apparently there are many ways to skin this
cat ....

Comment by kito75 [ 14/Jul/10 ]

Created an attachment (id=255)
Sample CSRF Solution (JSF 1.2)

Comment by kito75 [ 14/Jul/10 ]

Created an attachment (id=256)
Sample CSRF Solution (JSF 1.2) – the other file is for avoiding double submits

Comment by kito75 [ 14/Jul/10 ]

I have attached two samples:

  • jsf2token.war – sample UIToken component specifically for avoiding double submits (but would
    probably handle CSRF attacks too)
  • jsf2csrf.war – sample solution for handing Cross-site Request Forgery (CSRF) attacks only.

The source for both is in the WEB-INF/classes directory.

The token approach uses a standard JSF component that outputs a hidden field in the form. The hidden
field is created based on a server-generated secret key plus other information, such as the current view
id. What's a little different is that a phase listener decodes the component before Apply Request Values.
The goal here was to check the token before any other decoding takes place. Also, the token isn't
released until after Invoke Application to ensure that application processing has occurred.

For JSF 2, I think either enhancing UIForm, providing an alternate UIForm, or using a ClientBehavior
might be a better option than a separate component. Using UIForm would avoid the need to handle
decoding in the PhaseListener.

The CSRF approach is a little different. It still generates a special token based on a server-generated
secret key, but it does so based on the session, not on the view. It then appends the token to every JSF-
generated request through ViewHandler.getActionURL(). It uses a PhaseListener to ensure that every
incoming request has a valid token.

It's possible to combine these approaches, but I like the way the CSRF approach doesn't require anything
on the part of the developer. The caveat is that since it's session-based, it's probably not secure as a
form-based approach. Also, a form-based variant is required to avoid double-submits.

I'm not familiar with back button solutions, so I can't comment on how this code is applicable.

Comment by kito75 [ 14/Jul/10 ]

We should also consider the Seam <s:token> approach
(http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF). This is
component-based approach by Dan Allen with two key artifacts:

This approach also uses a cookie to ensure the requests are coming from the same browser, which is a
nice feature (but it should be optional). It also has explicit support for client-side state saving, which
my solution does not.

Comment by rogerk [ 22/Jul/10 ]

re-target

Comment by rogerk [ 23/Jul/10 ]

I've created a separate spec issue for CSRF:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869
as it solves a different problem.

Comment by rogerk [ 13/Aug/10 ]

target

Comment by rogerk [ 13/Aug/10 ]

Starting

Comment by rogerk [ 27/Aug/10 ]

reset priority

Comment by rogerk [ 13/Sep/10 ]

target 2.2

Comment by joshbrookes [ 18/May/11 ]

This issue has remained untouched since mid-Sept of 2010. Is this still being targeted for development or is there a recommended 3rd-party utility that can be used with Mojarra?

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by codylerum [ 23/Mar/15 ]

While Seam is out of date, https://deltaspike.apache.org/documentation/jsf.html#_double_submit_prevention is a more current solution.

Inclusion into 2.3 would be a huge help to a common problem.





[JAVASERVERFACES_SPEC_PUBLIC-329] Add new single HTML radio button component that isn't bound to a list Created: 05/Feb/08  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: rdelaplante Assignee: Unassigned
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File radio buttons.png    
Issuezilla Id: 329
Status Whiteboard:

cat2 renderkitdoc size_medium importance_small


 Description   

The selectOneRadio component requires that all radio buttons be grouped
together. This is very inflexible when creating user interfaces. Many times I
have encountered screens where I need multiple radio buttons in the same group,
but each radio button exists in a separate area of the screen. This can be done
in HTML easily, but not with JSF's default component set.

I've read that Apache MyFaces has created a component to solve this issue, and
so has Sun's Woodstock component set. Please standardize this fundamental
component in JSF 2.0 so that all implementations come with it.



 Comments   
Comment by rdelaplante [ 05/Feb/08 ]

Created an attachment (id=122)
Example form where this component would be useful

Comment by Ed Burns [ 09/Sep/08 ]

Per 20080827 EG Meeting, push to 2.1

Comment by Ed Burns [ 10/Sep/08 ]

Very early in the development of JSF 2.0, the EG decided we didn't have enough
resources to add new components and that, since components are extensible
anyway, our time would be better spent working on the top five features of 1.
making components easier to develop 2. having first class ajax support for
custom components 3. reducing the configuration burden 4. providing better error
handling and developer experience 5. providing for better interoperability
between 3rd party jsf components.

Comment by rdelaplante [ 10/Sep/08 ]

From my experience, this is the only missing component that maps directly to
HTML. I think this is different from adding fun and useful new components.

In my web apps that don't use sophisticated components such as calendars, I
prefer to use the basic h:* input components so that I don't have to force
hundreds of KB downloads on my users. I style with my own CSS. Since JSF
doesn't offer a radio button component where I can specify the html group name
as an attribute, I have to introduce hundreds of KB download of CSS and
JavaScript to my users by adding a component suite.

Comment by rdelaplante [ 10/Sep/08 ]

This was most noticeable when creating a slim UI for mobile web browsers. If I
wanted to create a UI such as the one in the attached screenshot, mobile users
(smart phones on slow networks) would have to wait 2+ minutes while the
component suite's CSS and JavaScript would download. If JSF had a built in
radio button component that maps to HTML, then this wouldn't be a problem.

Comment by rdelaplante [ 17/Sep/08 ]

I have found a solution for the problem outlined in this ticket without
requiring the addition of a new component. I noticed that issue #229 has added
two new attributes to selectManyCheckbox. All that is missing from
selectOneRadio is a name attribute.

<h:selectOneRadio id="notifyOff" value="OFF" name="notifyType"/>
<h:selectOneRadio id="notifyEmail" value="EMAIL" name="notifyType"/>
<h:selectOneRadio id="notifySMS" value="SMS" name="notifyType"/>

The name attribute is what makes the Woodstock Component Suite's radio button
usable for me, because it lets me have control of the screen layout as shown in
the attached screenshot. If you can add a name attribute to the 2.0 spec that
would be really great!

Comment by rdelaplante [ 17/Sep/08 ]

I meant to refer to issue #228 instead of #229

Comment by rdelaplante [ 23/Mar/09 ]

Here are some examples of how developers have solved this issue:

http://webdev2.sun.com/woodstock-tlddocs/webuijsf/radioButton.html
http://www.icefaces.org/docs/v1_7_2sp1/tld/ice/radio.html
http://myfaces.apache.org/tomahawk-project/tomahawk12/tlddoc/t/radio.html
http://software.topcoder.com/catalog/c_component.jsp?comp=26817861&ver=1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by rdelaplante [ 20/Apr/12 ]

I like how the Trinidad and IceFaces radio button works. Essentially what they've done is extend the existing h:selectOneRadio and added a new layout constant value called "spread" which tells it to not render itself. Then they created a new t:radio component that renders a single radio button and its label wherever you place it. The t:radio has a "for" attribute that points back to the main selectOneRadio, and an "index" attribute that tells it which of the select items to output. It works with JSF's built-in AJAX and I love it. My only issue is that I can't use it in a ui:repeat loop, but I suspect that is a JSF spec issue related to findComponent. I'd also like to be able to choose if the label is rendered to the left or right of the radio button, or not render the label at all.

<t:selectOneRadio id="upgradesRadio" layout="spread" value="#

{model.upgradeSelection}

">
<f:selectItems value="#

{model.availableUpgrades}

" var="upgrade" itemLabel="#

{upgrade.description}

"/>
<f:ajax/>
</t:selectOneRadio>

... custom HTML layout ...

<t:radio for="upgradesRadio" index="0"/>

... custom HTML layout ...

<t:radio for="upgradesRadio" index="1"/>

Comment by rdelaplante [ 30/Aug/13 ]

Please PLEASE get this done in JSF 2.3, we've been waiting way too long for this. With a perfect solution in Trinidad that works well with the existing h:selectOneRadio design, I don' understand why this keeps getting left undone release after release. Search Google for people using JSF and radio buttons and you'll find a lot of misery.

Comment by rdelaplante [ 11/Jul/14 ]

I was working with the t:radio component from Trinidad recently and discovered an inflexibility. It always renders a label with the radio button and so I had difficulty implementing the layout and wrapping dictated by a web designer. Also, they wanted part of the label text to have different font styling. I was unable to embed any kind of HTML tags in the label text loaded from the backing bean (such as a span or div) because it always escapes the label text.

If you implement this feature in JSF 2.3 (please do!), it would be nice to have the option to output just the radio button without the label, and also the option to not escape the text in the label.

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-49] JS function for "give me the clientId" Created: 04/Oct/04  Updated: 26/Jan/15

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript
Affects Version/s: 2.0
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: cagatay_civici
Resolution: Unresolved Votes: 9
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Attachments: Text File changebundle.txt    
Issuezilla Id: 49
Status Whiteboard:

EGTop5 effort_hard cat2 jsdoc size_medium importance_small draft


 Description   

EB> R1 something you can stick in your page, that will evaluate to the full,
EB> absolute, clientId of the named thing when the page is rendered. Like
EB> this:

AVK> <h:button id="button1"
AVK> onclick="button_setEnabled(button2,
AVK> false);button_clicked(button1);return"
AVK> ... />
AVK> <h:button id="button2" ... " />

AVK> then I want the result of the first one to be

AVK> <input type="submit" id="myform:button1"
AVK> onclick="button_setEnabled('myform:button2', false);
AVK> button_clicked('myform:button1'); return;"
AVK> ... />

EB> R2 This thing can be presenent in an attribute value, or as template
EB> text.

AVK> Definitely needed in an attribute value, for the method invocation. I
AVK> don't know whether it is necessary in tempate text. I have a feeling
AVK> some JavaScript interpreters barf if you mention the id before the
AVK> element is present.

EB> R3 This thing must only work within the scope of a naming
EB> container. In other words, I can't use this mechanism to refer
EB> to something in form B if I'm inside Form A.

EB> R4 This thing must work in a multi-include page scenario

EB> R5 This thing must work in a portlet scenario



 Comments   
Comment by Ed Burns [ 23/Feb/05 ]

push to 2.0

Comment by Ed Burns [ 09/Sep/08 ]

EGTop5

Comment by Ed Burns [ 12/Sep/08 ]

effort_hard

Comment by Ed Burns [ 21/Oct/08 ]
      • Issue 293 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 21/Oct/08 ]

Change summary

Comment by Ed Burns [ 06/Nov/08 ]

Given the #

{component}

and #

{compositeComponent}

implicit objects, and the ability to use them on the
server side, in XHTML, and in resources, having the ability to say #

{component.clientId}

would be nice. To
do this, we need to add to UIComponent, String getClientId(). This just does
FacesContext.getCurrentInstance() and calls the other getClientId().

Comment by Ed Burns [ 06/Nov/08 ]

Created an attachment (id=163)
Fix for this bug, first iteration.

Comment by Ed Burns [ 28/Jul/09 ]

Push out to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

jsdoc

Comment by Ed Burns [ 27/Apr/10 ]

no sig change

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

target

Comment by Ed Burns [ 04/Feb/12 ]

Remove from consideration for 2.2

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting to Critical, verify if it is already done or not.





[JAVASERVERFACES_SPEC_PUBLIC-1] multi-component validation Created: 16/Jul/04  Updated: 01/Aug/14

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.0
Fix Version/s: None

Type: Improvement Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 24
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

Operating System: All
Platform: All
URL: http://weblogs.java.net/pub/wlg/1625


Attachments: Zip Archive 1.zip     Text File changebundle.txt     PNG File radio buttons.png    
Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-626 Add standard way to modify browser hi... Open
depends on JAVASERVERFACES_SPEC_PUBLIC-1062 Non-Ajax File Upload Closed
Issuezilla Id: 1
Status Whiteboard:

EGTop5 effort_hard size_small importance_large


 Description   

Next spec should support multi-component validation.



 Comments   
Comment by Ed Burns [ 08/Dec/04 ]

move to 2.0

Comment by rdelaplante [ 05/Feb/08 ]

I will attach a screenshot to go with this comment:

I have a form where the validators for some fields depend on the submitted
values of other fields. For example, "re-enter e-mail address" needs to be
compared to the submitted value of "e-mail address". Both of these fields
should only be validated if "Send an email" radio button is selected. In my
validator code I use other components' getSubmittedValue() method which works
perfectly. getSubmittedValue has been deprecated, and the javadoc warns that it
should not be used. Why? If you take it out, I'll need to move the logic into
my action, and won't be able to "light up" the component's associated label to
indicate an error. One developer told me that this is an example of business
logic that belongs in an action. I disagree, this is validation logic that
belongs in the validator.

Comment by rdelaplante [ 05/Feb/08 ]

Created an attachment (id=121)
Form with multi field validators

Comment by rogerk [ 19/Aug/08 ]
      • Issue 60 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 09/Sep/08 ]

EGTop5

Comment by Ed Burns [ 12/Sep/08 ]

effort_hard

Comment by Ed Burns [ 21/Oct/08 ]
      • Issue 52 has been marked as a duplicate of this issue. ***
Comment by mojavelinux [ 03/Nov/08 ]

I don't think that cross-field validation is a difficult problem to solve from
the specification level. The reason cross-field validation is difficult today is
because each field is converted individually, just prior to being validated.
Therefore, when the validate() method is called on a UIInput component, there is
no guarantee that any other component in the form will have been converted at
that time. It depends on the relative placement of the components in the form, a
fact which should not be relied on in a validator.

The current strategy puts the onus of having to convert the related field(s) on
the validator that is attempting to perform a cross-field check. Naive
developers will simply ignore the converters on that field. The developers that
do use the proper converter logic may still get sloppy with exception handling.
Refer to either the EqualityValidator in Seam or Tomahawk to witness the
ridiculous amount of code that must be used to handle all of these concerns
properly.

A better way to implement validation is to first convert all of the components
in the form. Once all the conversions are complete, then the validators run. An
extra walk of the component tree can be avoided by putting the input components
that were converted into an ordered collection (or map) and then iterating over
that collection (or map) to apply the validators. Using this suggested strategy,
implementing a multi-component validator is no more difficult than implementing
a validator on a single component. The validator tag would need to provide some
way to declaratively refer to the related components, such as by ID or value
expression.

Frankly, I don't feel it is the responsibility of the specification to create a
multi-component validator solution. What the specification should do is make it
easy to create such a solution. With that said, I do believe it would be a good
idea to implement a couple of basic multi-component validators to demonstrate 1)
how it's done and 2) the ease in which it can be done with conversion and
validation happening in distinct steps. Reference validators would include an
equality validator (one or more components), a greater and less than validator,
and perhaps a switch validator (a boolean component toggles the required flag on
another component).

Comment by rdelaplante [ 03/Nov/08 ]

> Frankly, I don't feel it is the responsibility of the specification to create
> a multi-component validator solution. What the specification should do is
> make it easy to create such a solution.

IMO JSF should come complete out of the box and not require additional
frameworks to make it usable unless it is some other JSR built into Java EE 6
application servers.

Comment by rdelaplante [ 22/Jan/09 ]

The following comment was added to Ed Burns' blog about this ticket:

Hello, we're looking to JSR-303 BeanValidation to help with this. In
fact, Emmanuel Bernard, has been doing an excellent job and we're fully
ready to include it in JSF 2.0 when the Java EE 6 platform group
approves it for inclusion.

Ed

Posted by: edburns on January 21, 2009 at 09:27 AM
http://weblogs.java.net/blog/edburns/archive/2009/01/jsf_20_public_r.html

Comment by rdelaplante [ 22/Jan/09 ]

John Reynolds wrote about an interesting idea [1] where JSF's h:form tag can
have validator(s) attached to it, like any other input component. The form could
validate the submitted values of any combination of components using business
rules, and throw a ValidatorException when there is a problem. That is how
Wicket does "business form"/multi component validation [2] and it seems that
this would be a simple addition to JSF 2.0 or 2.1. JSR-303 BeanValidation is
definitely welcome, but I think this idea is just as important for JSF.

[1] http://weblogs.java.net/blog/johnreynolds/archive/2004/07/improve_jsf_by_1.html
[2] http://cwiki.apache.org/WICKET/validating-related-fields.html

Comment by Ed Burns [ 04/Feb/09 ]

Created an attachment (id=197)
Fix for this bug, first iteration.

Comment by Ed Burns [ 04/Feb/09 ]

Created an attachment (id=198)
Zip of changed files, in lieu of checkin.

Comment by Ed Burns [ 04/Feb/09 ]

I have attached a fix for this bug, based on the new event system in JSF 2.0

Comment by Ed Burns [ 05/Feb/09 ]

Fixed enough for 2.0

Comment by Ed Burns [ 23/Mar/11 ]

Marked fixed, but I am not convinced it's actually committed.

Comment by kito75 [ 19/Apr/11 ]

Ed, correct me if I'm wrong, but isn't this patch just a specific use case rather than a generic solution?

I would expect something like this:

<f:validatorGroup name="insidePanel" validator="#

{myBean.validatePanel}

"/>
<h:inputText id="input1" validator="#

{myBean.validateInput1}

" validatorGroup="insidePanel"/>
<h:inputText id="input2" validatorGroup="insidePanel"/>

In this scenario, myBean.validatePanel() would be called, but sent in a Map<String, Object> of values, where String is the component id. validatePanel() wouldn't be called, however, unless myBean.validateInput1() executed successfully.

Comment by arjan tijms [ 28/May/11 ]

Such a validator group does sound like a nice idea. Optionally, you could loose the name if the components are nested:

<f:validatorGroup validator="#{myBean.validatePanel}">
   <h:inputText id="input1" validator="#{myBean.validateInput1}" />
   <h:inputText id="input2" />
</f:validatorGroup>

For general purpose multi-component validation, requiring the components to use a hard coded ID might be problematic. These IDs may already be needed for other purposes. So in that case perhaps f:validatorGroup can take f:param children to indicate this, or the proposed validatorGroup attribute could include some kind of designator, e.g.:

<f:validatorGroup name="insidePanel" validator="#{myBean.validatePanel}"/>
<h:inputText validator="#{myBean.validateInput1}" validatorGroup="insidePanel:input1"/>
<h:inputText validatorGroup="insidePanel:input2"/>
Comment by Mark Struberg [ 16/May/12 ]

Just a side note from the spectator seats:

  • doing 'easy' multi-field validations should be done via JSR-303
  • doing more complex multi-field validations are more likely part of the business logic and can be implemented in a JSF action method much more easily (and without any side-effects).
Comment by kito75 [ 17/May/12 ]

Depending on JSR-303 seems naive to me. A lot of people simply don't use it, and if you have an existing application it's prohibitively expensive to convert it (if not impossible, perhaps do to political constraints or time constraints).

So we need a solution that works within the JSF validation mechanism, and action methods don't cut it. I've seen a people use the postValidate event for this, which does work, but it's not very elegant. Something like what Seam-Faces has would work out fine: http://docs.jboss.org/seam/3/faces/reference/snapshot/en-US/html_single/#validateForm. I would want it to work without CDI, though.

This is a major whole in the JSF spec – I've seen people use different solutions on almost every project.

Comment by john_waterwood [ 17/Aug/12 ]

I hope its still posible to do this for JSF 2.2. Everyone now does this in their own way and it's such a basic thing. Anyone noticed this is issue nr 1? Would be great if it finally can be closed.

Comment by Ed Burns [ 26/Jun/13 ]

Still on the radar for 2.3.

Comment by rdelaplante [ 11/Jul/14 ]

OmniFaces has support for this feature:

http://showcase.omnifaces.org/validators/validateMultiple

I also like their other helpful validators such as <o:validateAll>, <o:validateAllOrNone>, <o:validateEqual>, <o:validateOne>, <o:validateOneOrMore>, <o:validateOneOrNone>, <o:validateOrder> or <o:validateUnique>

Comment by Ed Burns [ 01/Aug/14 ]

Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical. Lets get this one done!





Generated at Tue Apr 28 06:15:16 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.