<< Back to previous view

[JAVASERVERFACES_SPEC_PUBLIC-1272] Take advantage of Java SE 8 JSR-310 Time API in the javax.faces.convert package Created: 31/Mar/14  Updated: 31/Mar/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.2
Fix Version/s: 2.3

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

Tags:
Participants: Ed Burns

 Description   

JSF has had javax.faces.convert.DateTimeConverter since 1.0. Now that Java SE 8 has a new time API, we need to have another converter that supports this API.






[JAVASERVERFACES_SPEC_PUBLIC-1268] javax.faces.view.ViewScoped should be @NormalScoped(passivating=true) Created: 06/Mar/14  Updated: 16/Apr/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Managed Beans
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours

Issue Links:
Related
is related to JAVASERVERFACES-3191 Serialization and CDI Viewscope Open
Tags:
Participants: Ed Burns

 Description   

See JAVASERVERFACES-3191.



 Comments   
Comment by Ed Burns [ 16/Apr/14 08:32 PM ]

I was discussing this on IM with someone from ADF and they made a good point.

if you are managing data structures hanging off of the session on the application's behalf, you are responsible for providing a mechanism for the application to mark the sub pieces as dirty

This is a core requirement for solving this issue.

Comment by Ed Burns [ 16/Apr/14 09:12 PM ]

Another important point about this issue pertains to failover and view state. If you make it so @ViewScoped beans can be failed over, then you will also have to make it so view state can be failed over.

Blake Sullivan from ADF suggests using something like <https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/util/SubKeyMap.java> to store each view state as a separate session attribute.

SubKeyMap is a convenience for flattening out the individual view state entries into separate session attributes so that they can be individually dirtied, and thus are less prone to re-replication. You still have to replicate all the view state entries, but with this solution there is less of an update burden.





[JAVASERVERFACES_SPEC_PUBLIC-1267] Clarify meaning of null return from UIComponent.getFamily() Created: 13/Feb/14  Updated: 13/Feb/14

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

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Issue Links:
Dependency
blocks JAVASERVERFACES-3180 Possible NPE in FormOmittedChecker Closed
Tags:
Participants: Ed Burns

 Description   

Clarify meaning of null return from UIComponent.getFamily().

See JAVASERVERFACES-3180.






[JAVASERVERFACES_SPEC_PUBLIC-1266] Extract Facelets as Templating for Java EE Created: 11/Feb/14  Updated: 11/Feb/14

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

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

Tags:
Participants: Ed Burns




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

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

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

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

 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.






[JAVASERVERFACES_SPEC_PUBLIC-1261] inconsistent behavior with absolute contracts references like /contracts_dir/contract_name/resource.xhtml Created: 03/Feb/14  Updated: 03/Feb/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3146 absolute contract reference (e.g. tem... Closed
Tags:
Participants: Hanspeter Duennenberger

 Description   

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

Absolute references to resources in contracts is not supported by design. However, with contracts deployed in /webapp_root/contracts_dir/contract_name it is possible to reference such resources using the absolute reference /contracts_dir/contract_name/resource.xhtml. Moving the same contract out to a separate jar this reference cannot be resolved anymore.

Since such absolute references are not supported by design such absolute contracts references must be prevented no mather if the contract is deployed into /webapp_root/contracts_dir or in META-INF/contracts within a jar.






[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: 30/Jan/14

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

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

Tags:
Participants: Ed Burns

 Description   

See JAVASERVERFACES-3150.






[JAVASERVERFACES_SPEC_PUBLIC-1256] FacesContextWrapper should call FacesContext.setCurrentinstance(this) in its default constructor Created: 10/Jan/14  Updated: 23/Jan/14

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

Type: Improvement Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File changebundle.txt    
Tags:
Participants: Ed Burns, Hanspeter Duennenberger and Manfred Riem

 Description   

A common mistake when wrapping FacesContext is to forget to call FacesContext.setCurrentInstance(this) from within the constructor of the new CustomFacesContext extending FacesContextWrapper. Without that call, FacesServlet will use the wrapped FacesContext, but FacesContext.getCurrentInstance() would only return the wrapped RI's FacesContextImpl, but not the wrapper chain.

The call of FacesContext.setCurrentInstace(this) in the default constructor of FacesContextWrapper would prevent this mistake easily.



 Comments   
Comment by Ed Burns [ 22/Jan/14 08:26 PM ]

r=edburns.

Comment by Manfred Riem [ 22/Jan/14 09:28 PM ]

Applied to 2.2 branch,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES-3141, r=edburns, make sure the correct FacesContext is set by a wrapped FacesContext."
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Transmitting file data .
Committed revision 12783.

Comment by Manfred Riem [ 23/Jan/14 04:49 PM ]

Applied to 2.2 branch,

svn commit -m "Reverting as this violates the current TCK"
Sending jsf-api/src/main/java/javax/faces/context/FacesContextWrapper.java
Transmitting file data .
Committed revision 12786.

Comment by Manfred Riem [ 23/Jan/14 04:50 PM ]

Issue moved to the SPEC tracker as affecting the current fix violates tests in the TCK. Hence this has to wait for the next SPEC cycle.





[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: 22/Jan/14

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

Type: Improvement Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and Hanspeter Duennenberger

 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.






[JAVASERVERFACES_SPEC_PUBLIC-1254] contracts attribute too restrictive. Created: 22/Jan/14  Updated: 22/Jan/14

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

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

Issue Links:
Dependency
blocks JAVASERVERFACES-3139 relax restriction of where to place <... Closed
Tags:
Participants: Ed Burns

 Description   

The javadoc for the contracts attribute on <f:view> includes this text.

Any use of this attribute on a non-outer-most file must be silently ignored.

A customer stated this is overly restrictive. There are cases when it would be useful to allow a "last one wins" approach. This issue suggests changing the text to read:

Any use of this attribute on a non-outer-most file is undefined.






[JAVASERVERFACES_SPEC_PUBLIC-1253] Consider enabling abandoning a flow directly for another flow Created: 17/Jan/14  Updated: 17/Jan/14

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

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive i_spec_1253-reproducer.zip     Text File i_spec_1253.patch    
Tags:
Participants: Ed Burns

 Description   

Consider an app with this arrangement.

src/main/webapp/WEB-INF/faces-config.xml
src/main/webapp/flowA/flowA-flow.xml
src/main/webapp/flowA/flowA.xhtml
src/main/webapp/flowB/flowB-flow.xml
src/main/webapp/flowB/flowB.xhtml
src/main/webapp/flowC/flowC-flow.xml
src/main/webapp/flowC/flowC.xhtml
src/main/webapp/index.xhtml
src/main/webapp/site-template.xhtml

All .xhtml pages in this app are template clients of
site-template.xhtml. The site-template.xhtml has a row of buttons along
the top that allow immediate navigation to all of the flows. The intent
is that whatever flow you're in, you want to abandon it and enter the
new flow when the corresponding button is clicked. This is not a flow
call, but rather should be treated as an atomic "abandon/enter".

The current specification does not support this cleanly.



 Comments   
Comment by Ed Burns [ 17/Jan/14 08:16 PM ]

Diff of reproducer.

Comment by Ed Burns [ 17/Jan/14 08:18 PM ]

zip of reproducer.





[JAVASERVERFACES_SPEC_PUBLIC-1252] It should be possible to specify Resource Dependencies via XML Created: 14/Jan/14  Updated: 16/Jan/14

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

Type: Improvement Priority: Minor
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kito75

 Description   

From the portlet EG mailing list (Neil Griffin and Ed Burns)

NG> @Ed Burns: When you get a chance, could you please shed some light
NG> on why resource dependencies can only be done via JSF annotations,
NG> and not by faces-config.xml? Thx.

EB> I suppose it could be. It turned out to be easier to implement with
EB> annotations. I think you have discovered a wrinkle where our stated
EB> goal of having complete parity of functionality between annotations and
EB> XML is not met.






[JAVASERVERFACES_SPEC_PUBLIC-1250] Some not existing classes in chapter 5.4.1 Created: 03/Jan/14  Updated: 03/Jan/14

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

Type: Bug Priority: Major
Reporter: tremes Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and tremes

 Description   

In specified chapter in TABLE 5-3 there are mentioned following artifacts (among others):

javax.faces.view.ViewDeclarationFactory
javax.faces.view.facelets.FaceletFactory

I can't see these in 2.2.4 api. There's only javax.faces.view.ViewDeclarationLanguageFactory.



 Comments   
Comment by tremes [ 03/Jan/14 07:54 AM ]

And javax.faces.context.FlashFactory is likely missing.





[JAVASERVERFACES_SPEC_PUBLIC-1249] add "maxRepeats" attribute to ui:repeat. Created: 27/Dec/13  Updated: 27/Dec/13

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

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

Tags:
Participants: Ed Burns

 Description   

It would be very handy if there were a "maxRepeats" attribute on ui:repeat such that the repetition would terminate when either of the following two conditions was true.

1. the collection is empty

2. the maxRepeats value has been reached in terms of number of iterations.






[JAVASERVERFACES_SPEC_PUBLIC-1248] Allow EL in ResourceBundles used by JSF. Created: 27/Dec/13  Updated: 27/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Platform Integration (except for Bean Validator)
Affects Version/s: None
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

It would be nice if we could allow the use of EL expressions in ResourceBundles used by JSF.






[JAVASERVERFACES_SPEC_PUBLIC-1247] Disable implicit navigation within flows on a per-flow basis. Created: 27/Dec/13  Updated: 27/Dec/13

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

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

The ease of use of implicit navigation can be a boon for quick development, but it can also make it difficult to reason about flows when they get more complex. Consider adding a configuration element that disables implicit navigation in a flow.






[JAVASERVERFACES_SPEC_PUBLIC-1246] Prevent jumping into a flow without going through the front door. Created: 27/Dec/13  Updated: 27/Dec/13

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

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

Tags:
Participants: Ed Burns

 Description   

RS> One observation is with regards to access to flow scoped data. When
RS> using the provided buttons, everything works as it should, i.e. flow
RS> scoped data is created at the point of entering the flow and
RS> destroyed when the flow is exited. However, it is easy to bypass the
RS> entry and exit points. For example I can go directly to a page
RS> associated with a flow without entering the flow, and if the page
RS> tries to access flow data, the result would be
RS> ContextNotActiveException.

One could argue that such an exception is the right response. The
context is indeed not active. However, if you are not using any flow
scoped data, such an exception would not be thrown, and it would give
the impression that the navigation is supported.

I think we can add some language to the spec to detect these "jump in"
cases.



 Comments   
Comment by Ed Burns [ 27/Dec/13 05:59 PM ]

Rossen wrote:

When flows are defined under the web application's root, I can easily access
their source from a browser which is a security concern. I can see there is
an example that puts the flow definition under WEB-INF but the pages are
still under the web application root and hence the flow is in two different
places. It would be useful to be able to keep a flow with all its files in a
folder under WEB-INF.





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

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: 2.3

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

Tags:
Participants: Ed Burns

 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.






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

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: 2.3

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

Tags:
Participants: Ed Burns

 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.






[JAVASERVERFACES_SPEC_PUBLIC-1235] better integration of bv-groups Created: 31/Oct/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: gerhard_petracek Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gerhard_petracek

 Description   

in several cases different bv-groups should get used (in the validation-phase) depending on the triggered action.
(if there are e.g. multiple buttons in the same form which should lead to different bv-constraints.)

also see: https://issues.apache.org/jira/browse/EXTVAL-141






[JAVASERVERFACES_SPEC_PUBLIC-1231] Wrong name in spec for javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR Created: 16/Oct/13  Updated: 08/Nov/13

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: 2.3

Type: Bug Priority: Minor
Reporter: lu4242 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: lu4242

 Description   

Reported by Martin Koci in:

https://issues.apache.org/jira/browse/MYFACES-3790

In summary JSF 2.2 PDF section 3.5.3 Validation Registration has a reference to a config param javax.faces.validator.DISABLE_BEAN_VALIDATOR but the one used in both Mojarra and MyFaces is javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR.

Probably it was a change done with the objective of improve the meaning of the param. The param that should be used is javax.faces.validator.DISABLE_DEFAULT_BEAN_VALIDATOR






[JAVASERVERFACES_SPEC_PUBLIC-1224] HTML5 Form Validation Not Performed Before Ajax Submit Created: 30/Aug/13  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: rogerk

 Description   

Given an HTML5 form, with HTML% input types (such as email), form validation is not performed (for an invalid email entered) if the submit is over ajax.
This is because the current Ajax portion of the specification states specifically to collect form elements and pass on over ajax to server side.
We would need to specify (and implement) something to trigger form validation before even collecting elements for ajax submit.






[JAVASERVERFACES_SPEC_PUBLIC-1219] Specify behavior in case of abandoned flow. Created: 26/Aug/13  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 6 hours
Time Spent: Not Specified
Original Estimate: 6 hours

Issue Links:
Dependency
depends on JAVASERVERFACES-2997 None flow command actions navigation ... Closed
Tags:
Participants: Ed Burns

 Description   

Currently trying to navigate away from a flow by any means other than a flow-return or flow-call node will cause the navigation to silently fail. This approach has the nice property in that it prevents abandoned flows. Unfortunately, as JAVASERVERFACES-2997 shows, this approach is overly restrictive.

This issue calls for the spec to say what should happen when the flow is abandoned.



 Comments   
Comment by Ed Burns [ 26/Aug/13 05:11 PM ]

The fix for JAVASERVERFACES-2997 did the following.

When looking for a navigation match in the midst of the flow, if no other way of finding a match is found, look for an implicit match outside of the flow. If that's not found, look in the root navigation map using the same three step process in normal JSF navigation.





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

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

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
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
Tags:
Participants: Ed Burns

 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.






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

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

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

Tags:
Participants: Ed Burns

 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






[JAVASERVERFACES_SPEC_PUBLIC-1206] required attribute is not enforced for inputFile Created: 08/Jul/13  Updated: 10/Jul/13

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

Type: Bug Priority: Major
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0, Firefox


Issue Links:
Related
is related to JAVASERVERFACES-2923 required attribute is not enforced fo... Closed
Tags: file file_upload require
Participants: Ed Burns, jasonzhang2002gmailcom and Manfred Riem

 Description   

When I select file at browser or not, I always have a part at server side. If no file is selected, the Part.size is zero.



 Comments   
Comment by Manfred Riem [ 08/Jul/13 08:39 PM ]

Can you please supply an example that reproduces the problem?

Comment by jasonzhang2002gmailcom [ 09/Jul/13 01:19 AM ]

This can be reproduced easily.

@RequestScoped
@Named
public class Test
{
	Part file;
	String str;
	public String getStr()
	{
		return str;
	}
	public void setStr(String str)
	{
		this.str = str;
	}
	public Part getFile()
	{
		return file;
	}
	public void setFile(Part file)
	{
		this.file = file;
	}
	public String save()
	{
		System.out.println("save is called");
		return null;
	}
}
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:h="http://xmlns.jcp.org/jsf/html"
	xmlns:f="http://xmlns.jcp.org/jsf/core"
	xmlns:c="http://xmlns.jcp.org/jsp/jstl/core"
	xmlns:ui="http://xmlns.jcp.org/jsf/facelets">
	
<h:body>
	<h:messages>
	</h:messages>
	<h:form enctype="multipart/form-data">
		<h:inputFile value="#{test.file}" id="file" required="true"></h:inputFile>
		<h:inputText value="#{test.str}" id="string" required="true"></h:inputText>
		<h:commandButton value="submit" action="#{test.save}">
		</h:commandButton>
	</h:form>
</h:body>
</html>
Comment by Ed Burns [ 09/Jul/13 08:33 PM ]

Manfred and I investigated this and determined that UIInput.isEmpty() doesn't correctly handle this case when there is a Part that is empty.

UIInput.isEmpty() was added in support of JAVASERVERFACES_SPEC_PUBLIC-426.





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

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

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

Tags:
Participants: Ed Burns

 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.






[JAVASERVERFACES_SPEC_PUBLIC-1201] Require that the cookie used to store the Flash key is setHttpOnly(true) Created: 02/Jul/13  Updated: 02/Jul/13

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Issue Links:
Dependency
depends on JAVASERVERFACES-2911 For JSF 2.2 and beyond, do setHttpOnl... Closed
Tags:
Participants: Ed Burns

 Description   

Require that the cookie used to store the Flash key is setHttpOnly(true)






[JAVASERVERFACES_SPEC_PUBLIC-1188] Specify what should happen if the same flow is defined both in XML and via @FlowDefinition Created: 29/Apr/13  Updated: 08/Nov/13

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

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

Tags:
Participants: Ed Burns

 Description   

The spec for FlowHandler.addFlow() requires an IllegalStateException be thrown if there is already a flow with the same identification as the one trying to be added.

The spec does not say the ordering in which flows should be added

XML then Java
Java then XML

This needs to be clarified.






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

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

Type: Bug Priority: Major
Reporter: Bruno Borges Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Bruno Borges, Ed Burns, Frank Caputo and jyeary

 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 05:34 AM ]

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 06:29 AM ]

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 06:37 AM ]

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 03:21 PM ]

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 04:01 PM ]

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 08:43 PM ]

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.





Support for WAI ARIA (JAVASERVERFACES_SPEC_PUBLIC-462)

[JAVASERVERFACES_SPEC_PUBLIC-1181] Add support for WAI-ARIA to standard input components Created: 10/Apr/13  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Ajax/JavaScript, Components/Renderers
Affects Version/s: 2.2
Fix Version/s: 2.3

Type: Sub-task Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kito75

 Description   

In cases where ARIA attributes have a reasonable mapping to existing component-level properties (eg. aria-required can be mapped to <h:inputText>'s required attribute, aria-invalid can be mapped to the EditableValueHolder's valid state), we should enhance the standard Renderers to automatically render the ARIA attributes. For other ARIA attributes, passthrough attributes can be used.

This task requires an analysis of the input controls to determine which ones need changes, but generally speaking any UI component that maps to a native HTML widget should support aria-invald and aria-rquired attributes, and possibly aria-readonly. For a full list of support states and properties, see: http://www.w3.org/TR/wai-aria/states_and_properties#state_prop_def.

Original thread: http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2013-03/message/124






[JAVASERVERFACES_SPEC_PUBLIC-1173] Handle gracefully the case of a link to flow based page copied to new browser tab Created: 16/Mar/13  Updated: 08/Nov/13

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

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

Tags:
Participants: Ed Burns

 Description   

> LU> Hi
> LU> I have been checking the proposal for OutcomeTarget navigation in deep. In few
> LU> words, the critical point is what clientWindowTransition() should do and how
> LU> to encode GET links properly.
>
> LU> Let's consider again this use case :
>
> LU> (suppose the flow document id is flowDoc2)
>
> LU> <faces-flow-definition id="flow2">
> LU> <flow-return id="exit2">
> LU> <navigation-case>
> LU> <from-outcome>exit1</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
>
> LU> (suppose the flow document id is flowDoc1)
>
> LU> <faces-flow-definition id="flow1">
> LU> <flow-return id="exit1">
> LU> <navigation-case>
> LU> <from-outcome>mainpage</from-outcome>
> LU> </navigation-case>
> LU> </flow-return>
> LU> </faces-flow-definition>
>
> LU> Suppose we are in /flow2/mypage.xhtml and there is a link to exit the flow. How
> LU> it should looks like? according to what I can deduct from the spec it should
> LU> be something like this:
>
> LU> http://localhost:8080/myapp/mainpage.xhtml?jffi=exit2&jftfdi=flowDoc2
>
> LU> In theory the link should work as long as the flow stack is:
>
> LU> flow2
> LU> flow1
> LU> root
>
> LU> But what happen if I copy the link into a new browser tab?
>
> That is not supposed to work because, by definition, the flow system is
> entirely built on ClientWindow, which, by definition is bound to a
> browser view (such as a tab or window).
>

Yes, I know it does not work, it should not work, but the problem is how faces
flow fails under such circumstance.

When this could happen? a session expiration is a good example. Since there
is no ViewState, there will not be ViewExpiredException, and the link will be
sent by the user without notice.

The point is if that scenario happens (which is probably), faces flow should be
able to recognize the situation with a simple check and do something like
throw an exception or exit the flow.

Other situation when this is relevant is what happen if you hit the same link
twice. The first time it gets out of the flow, but the second time you
are already
out. Again it is up to the user detect that kind of failure doing its
own logic to
check if the request is valid, but faces flow could do it for you just checking
one query param.

In a previous conversation, it was mentioned that "... a flow has a single front
door ..." and that it has "... well defined entry and exit points
...". My concern
here is that theorically it is possible to enter into a flow without go through
the start node, and there are simple exit cases with "unknown" results.






[JAVASERVERFACES_SPEC_PUBLIC-1172] ClientWindow: deal gracefully with multiple client windows having the same id Created: 13/Mar/13  Updated: 08/Nov/13

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

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

Tags:
Participants: Ed Burns

 Description   

AS> + * <p>In addition to the hidden field already described. The runtime
AS> + * must ensure that any component that renders a hyperlink that causes
AS> + * the user agent to send a GET request to the Faces server when it is
AS> + * clicked has a query parameter with a name and value specified in
AS> + * {@link ResponseStateManager#CLIENT_WINDOW_URL_PARAM}. This
AS> + * requirement is met by several of the "encode" methods on {@link AS> + * javax.faces.context.ExternalContext}. See {@link AS> + * javax.faces.context.ExternalContext#encodeActionURL(java.lang.String) AS> + * } for details.</p>

AS> What is the expected behavior when the end user creates a second browser
AS> tab/window with an existing window id? For example, this can happen by:

AS> - Bookmarking an url with a window id and opening that URL in multiple tabs.
AS> - Copying and pasting an url from one tab into a second tab.
AS> - (On some browsers) Using the browser's "New Window" action.

AS> For each of the above cases, each window/tab should be assigned its own
AS> unique id, even though it would require additional work to determine
AS> when a client window id has been copied across windows/tabs






[JAVASERVERFACES_SPEC_PUBLIC-1171] Specify interaction of Stateless and CSRF protection Created: 13/Mar/13  Updated: 08/Nov/13

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

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and kithouna

 Description   

LU> 2. Stateless views that needs to be protected against CSRF attack, must
LU> include its token in javax.faces.ViewState field as if it was the view
LU> state, but only contains the info related to the secret stored in session
LU> or encoded/encrypted when client side state saving is used. In few words
LU> if the view is protected, javax.faces.ViewState generation may requires
LU> additional steps.



 Comments   
Comment by kithouna [ 14/Mar/13 09:31 AM ]

Don't stateless views also loose the implicit CSRF protection offerd by the required view state Id that stateful views have?





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

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

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

Tags:
Participants: Ed Burns

 Description   

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



 Comments   
Comment by Ed Burns [ 27/Feb/13 02:08 PM ]

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

Comment by Ed Burns [ 27/Feb/13 02:11 PM ]

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 08:53 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1159] Add support for WAI-ARIA aria-live property for portions of the page updated via <f:ajax> Created: 28/Jan/13  Updated: 08/Nov/13

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

Type: New Feature Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: accessibility
Participants: Ed Burns and kito75

 Description   

Currently, JSF doesn't have any explicit support for WAI-ARIA (http://www.w3.org/WAI/intro/aria.php), except for the role attribute. <f:ajax> should be updated to use the aria-live attribute at the very least.

See EG thread here: http://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2013-01/message/5



 Comments   
Comment by kito75 [ 01/Mar/13 04:27 AM ]

After looking at this in more detail, there are several attributes that one may need to apply to the element that's being updated by an Ajax:

  • role
  • aria-live
  • aria-busy
  • aria-atomic
  • aria-relevant

(See http://www.w3.org/TR/wai-aria-practices/#LiveRegions)

Only the page author (and possibly the component being re-rendered) know which attributes should be set, and what the values should be. Since the regions are denoted with these attributes up-front, perhaps there's not much for <f:ajax> to do after all, because the page author can either use pass-through attributes or HTML5-friendly markup to specify these attributes on the component that needs to be updated.

Comment by Ed Burns [ 27/Mar/13 03:28 AM ]

I like this idea, targeting for 2.3.





[JAVASERVERFACES_SPEC_PUBLIC-1128] All form controls sent as request params when @none specified for execute. Created: 01/Aug/12  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jasonzhang2002gmailcom, kithouna and rogerk

 Description   

A clarification is needed to state that no form controls should be sent if the 'execute' option is @none.
Currently, all form controls are encoded and sent regardless.



 Comments   
Comment by rogerk [ 01/Aug/12 02:32 PM ]

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

Comment by jasonzhang2002gmailcom [ 01/Aug/12 07:41 PM ]

In ajax call, all render parameters (@this, ids, @none) should be respected. The current implementation sends the whole form. All input controlls are evaluated(validated, and model are updated).

Comment by kithouna [ 07/Mar/13 09:55 AM ]

Isn't this perhaps a special case of JAVASERVERFACES_SPEC_PUBLIC-1098?





[JAVASERVERFACES_SPEC_PUBLIC-1117] "value" attribute for "h:command*" components should be marked as "required" Created: 18/Jun/12  Updated: 08/Nov/13

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

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags:
Participants: Ed Burns, nikolaj_a and paul_dijou

 Description   

Take a look at <https://maven.java.net/service/local/repositories/releases/archive/javax/faces/javax.faces-api/2.0/javax.faces-api-2.0-javadoc.jar/!/vdldocs/facelets/h/commandButton.html>, and also the same page for commandLink. In both cases, the "value" attribute is listed as not required. The spec must be modified to show that it is required.



 Comments   
Comment by paul_dijou [ 19/Jun/12 05:39 PM ]

I can understand for commandButton (since it's always generate a <input> tag and not a <button> tag, which is sad btw), but why also for commandLink? You should be authorize to nest an outputText (or several of them), or graphicImage, or any combo of those, inside a commandLink. No need for "value" in that case since those components would be the value inside the <a> tag generated.

Comment by nikolaj_a [ 19/Sep/12 07:39 AM ]

Also, the browsers will render a default text, dependent on the browser and language of the user, if the value attribute is left out. This is most likely not the desired result, but there is already a fallback in case this attribute is left out.





[JAVASERVERFACES_SPEC_PUBLIC-1098] f:ajax exeucte always sends all the fields of the wrapping form Created: 08/May/12  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 8
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms, Darious3, kithouna and rogerk

 Description   

f:ajax doesn't obey the 'execute' attribute but always sends all the fields in a form. Mojarra does, however, only process the listed fields as supposed. However, excess fields shouldn't be sent because it increases request size.

Recplicate with:

<h:form id="form1">
<h:commandButton>
<h:inputText id="field1" />
<h:inputText id="field1x" />
<f:ajax execute="field1" />
</h:commandButton>
</h:form>

On button click, both fields are sent (but only field1 would be processed).

See for further info: http://stackoverflow.com/questions/3889894/jsf-2-0-why-does-fajax-send-all-the-form-fields-and-not-only-those-marked-with

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



 Comments   
Comment by Darious3 [ 18/Aug/12 03:02 PM ]

PrimeFaces has recently implemented this, would be great to have this in the spec.

Comment by kithouna [ 28/Jan/13 09:27 AM ]

Must have feature for JSF 2.3. This really shouldn't be that hard, should it?

Comment by arjan tijms [ 31/Jan/13 02:30 PM ]

An implementation duplicate: JAVASERVERFACES-1841





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

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

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

Issue Links:
Duplicate
duplicates JAVASERVERFACES-2406 Add "rendered" attribute description ... Closed
Tags:
Participants: Ed Burns

 Description   

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

Sample file attached...






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

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: 2.3

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

File 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
Participants: Ed Burns and Manfred Riem

 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 01:58 AM ]

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 06:14 PM ]

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 04:04 PM ]

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.





HTML5 Support (JAVASERVERFACES_SPEC_PUBLIC-1090)

[JAVASERVERFACES_SPEC_PUBLIC-1076] HTML5 Sectioning and Heading Created: 22/Feb/12  Updated: 08/Nov/13

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

Type: Sub-task Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns

 Description   

See: http://dev.w3.org/html5/spec/Overview.html#sectioning-content-0

HTML5 includes support for declaring page sections. JSF 2.0 includes support for declaring page sections. The challenge for JSF 2.2 is to expand the way that JSF 2.0 declares page sections so that HTML5 support is obtained for the smallest amount of developer effort. The impacted elements are:

article
aside
nav
section

h1
h2
h3
h4
h5
h6
hgroup






[JAVASERVERFACES_SPEC_PUBLIC-1070] Add ExternalContext#setFlash(Flash) method Created: 13/Feb/12  Updated: 08/Nov/13

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

Type: Improvement Priority: Major
Reporter: Neil Griffin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1071 Portlet bridge unable to wrap Flash i... Resolved
Tags:
Participants: Ed Burns and Neil Griffin

 Description   

Due to an incongruity between the JSF and Portlet lifecycles, I would like to propose adding the ExternalContext#setFlash(Flash) method to ExternalContext.

There is precedent for a method like this, for example ExternalContext#setRequest(Object) and ExternalContext#setResponse(Object):
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#setRequest(java.lang.Object)
http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#setResponse(java.lang.Object)

For more information and justification, please refer to these issues:
https://issues.apache.org/jira/browse/PORTLETBRIDGE-201
https://issues.apache.org/jira/browse/PORTLETBRIDGE-207



 Comments   
Comment by Ed Burns [ 20/Mar/13 09:37 PM ]

Set fixVersion to 2.3.





[JAVASERVERFACES_SPEC_PUBLIC-1059] f:selectItem escapeItem attribute should be itemEscaped Created: 05/Dec/11  Updated: 08/Nov/13

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

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

Tags:
Participants: rogerk

 Description   

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






[JAVASERVERFACES_SPEC_PUBLIC-1053] VDL Docs Need Clarification for f:view afterPhase Attribute Created: 23/Nov/11  Updated: 08/Nov/13

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

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

Tags:
Participants: rogerk

 Description   

The VDL docs state this for f:view afterPhase :

"MethodBinding pointing to a method that takes a javax.faces.event.PhaseEvent and returns void. This method will be called after every phase except for restore view."

This should be clarified to:

"MethodBinding pointing to a method that takes a javax.faces.event.PhaseEvent and returns void. This method will be called after every phase except for restore view on an initial request."



 Comments   
Comment by rogerk [ 23/Nov/11 05:00 PM ]

Fix Version





[JAVASERVERFACES_SPEC_PUBLIC-1049] UIColumn and PreValidate / PostValidate events Created: 07/Nov/11  Updated: 17/Dec/13

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

Type: Bug Priority: Minor
Reporter: jperealc_isban Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Tags: UIColumn processValidators PreValidate PostValidate UIData spec
Participants: jperealc_isban

 Description   

Javadoc of PreValidateEvent / PostValidateEvent:
Components with children must publish this event before/after processing their child nodes in UIComponent.processValidators(javax.faces.context.FacesContext). This is especially important for iterating components such as UIData, and form components, such as UIForm.

UIColumn is a component with children, so it must publish PreValidate/PostValidate events as the javadoc of those events specifies.

But javadoc for UIData's processValidators() method, explicitly skips the processing of UIColumn components, and only specifies processing of its facets and children.

This is incoherent.






[JAVASERVERFACES_SPEC_PUBLIC-1047] Conditional Layout in a template based on the existence of a definition of a region ( ui:define name="foo") in a view Created: 29/Oct/11  Updated: 17/Dec/13

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

Type: New Feature Priority: Minor
Reporter: lamine_ba Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-971 Multi-templating System Closed
Tags:
Participants: lamine_ba

 Description   

In a template, I want to have the ability to hide the layout of a region ( <ui:insert name="foo"/> ) if the view does not provide any definition for it ( <ui:define name="foo">). In a pseudo language, we can translate it into :

  • template.xhtml
#if ( <ui:define name="left"> exists in view) 

  <div id="leftcolumn">
      <ui:insert name="left"/>
  </div>

#endif

#else 
  <img src='placeholder.gif'>

using Facelets, maybe we can translate that into :

<ui:exists condition="left">

  <div id="leftcolumn">
      <ui:insert name="left"/>
  </div>

 </ui:exists>
 
<ui:exists condition="not left">

 <img src='placeholder.gif'>

</ui:exists>

Joomla 1.5 has a corresponding exists tag : <jdoc:exists condition="{region}"/> and web designers use it like this

<jdoc:exists condition="left"/>
<jdoc:exists condition="left and right and top"/>
<jdoc:exists condition="left or right"/>
<jdoc:exists condition="not left"/>


 Comments   
Comment by lamine_ba [ 29/Oct/11 05:04 PM ]

Related issues

1) http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971
2) http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1046

The condition is always evaluated to true if the template is highlighted so that we can see the whole regions and the whole UI design.

Comment by lamine_ba [ 30/Oct/11 04:14 PM ]

How to translate this complex Joomla templating conditional layout with Facelets ?

<?php if ($this->countModules('user1') || $this->countModules('user2')
 || $this->countModules('user3')) { ?>

<?php if ($this->countModules('user1') and $this->countModules('user2')
  and $this->countModules('user3')) {

  $width1 = "33%";

} else if (($this->countModules('user1') and $this->countModules('user2')) 
  or ($this->countModules('user1') and $this->countModules('user3'))
  or ($this->countModules('user2') and $this->countModules('user3'))) {

$width1 = "50%";

} else {

 $width1 = "100%";

}
?>

<div style="float:left; width: <?php echo $width1; ?>">

<jdoc:include type="modules" name="user1" style="rounded" />

</div>

<div style="float:left; width: <?php echo $width1; ?>">

<jdoc:include type="modules" name="user2" style="rounded" />

</div>

<div style="float:left; width: <?php echo $width1; ?>">

<jdoc:include type="modules" name="user3" style="rounded" />

</div>

<?php } ?>




[JAVASERVERFACES_SPEC_PUBLIC-1046] Template highlighting Created: 29/Oct/11  Updated: 17/Dec/13

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

Type: New Feature Priority: Minor
Reporter: lamine_ba Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-971 Multi-templating System Closed
Tags:
Participants: lamine_ba and ova2

 Description   

When the projectStage is set to development, I want to have the ability to see visually the regions of a template by sending the highlight=true request parameter.

You can see this feature in live Here

1) http://jsfmtsystem.appspot.com/faces/templateDetails.xhtml?template=xen&highlight=true

This Feature was added in the apply(FaceletContext ctxObj, UIComponent parent)
method of the InsertHandler class of Facelets and the code looks like this:

HtmlOutputText text=new HtmlOutputText();

text.setValue(this.name);

text.setStyle("color:red;font-weight:bold;
                background:white;border:1px dashed red;
                text-align:center;display:block;
                margin-left:auto;margin-right:auto;");

parent.getChildren().add(text);


 Comments   
Comment by lamine_ba [ 29/Oct/11 03:09 PM ]

Related Issues : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971

Comment by ova2 [ 14/Mar/12 02:00 PM ]

This should be configurable via config. param in web.xml.

Comment by lamine_ba [ 19/Mar/12 07:01 PM ]

Hi Oleg,

Thanks for your comment and I like very much your idea of making this feature configurable via web.xml but you know, a better and more radical idea would be to just close it. I don't need it anymore since my JAX-RS web application framework and my cloud web-based editor can do this very smartly in the client side. And to tell you the truth, I'm definitely out of the whole JSF server side stuff and there is no way for me to come back to it.

1) http://www.flickr.com/photos/laminba2003/6997477745/in/photostream/lightbox/
2) Source : http://www.flickr.com/photos/laminba2003/6851349994/in/photostream/lightbox/
3) Preview : http://www.flickr.com/photos/laminba2003/6851355160/in/photostream/lightbox/





[JAVASERVERFACES_SPEC_PUBLIC-1045] Flash created in ExceptionHandler not work Created: 27/Oct/11  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.0, 2.1
Fix Version/s: 2.3

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

Tags:
Participants: lu4242

 Description   

Original issue created on

https://issues.apache.org/jira/browse/MYFACES-3358

by Keith Wong:

------------------------------------------------

I have a custom ExceptionHandler for handling ViewExpiredException as occurred in session timeout or application restart. I have to tell the user in the redirected page the reason for being redirected. Here is the handler:

public void handle() throws FacesException {
for (Iterator<ExceptionQueuedEvent> i=getUnhandledExceptionQueuedEvents().iterator(); i.hasNext(); ) {
ExceptionQueuedEventContext context = i.next().getContext();
Throwable t = context.getException();
if (t instanceof ViewExpiredException) {
FacesContext ctx = FacesContext.getCurrentInstance();
ViewExpiredException vee = (ViewExpiredException)t;
try { ctx.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, vee.getClass().getName(), vee.getMessage())); Flash flash = ctx.getExternalContext().getFlash(); flash.put("expiredViewId", vee.getViewId()); flash.setKeepMessages(true); ctx.getApplication().getNavigationHandler().handleNavigation(ctx, null, "/login?faces-redirect=true"); ctx.renderResponse(); }
finally { i.remove(); }
}
}
super.handle();
}

In the login.xhtml, it has #{flash.expiredViewId} and <f:messages> but both are empty when displayed.

------------------------------------------------

Unfortunately the code proposed does not work by spec. See JSF 2.0 section 12.3. In few words, the problem is handle() is called after the current phase is processed, so flash scope has been already processed. Maybe in this case it is possible to call Flash.doPostPhaseActions(FacesContext) and doPrePhaseActions(FacesContext) to wrap flash operations inside handle() method, but we can't do anything from MyFaces point of view. Maybe it should be possible to do something on the spec, because it sounds like a common use case.

Really it is curious people trying to create custom ExceptionHandler implementations using JSF usually finds problems like this one and others, for example if you try to create a jsf page to handle jsf errors. It is worth to take a look to this API, to see if in practice requires some fixes to make it more practical.






[JAVASERVERFACES_SPEC_PUBLIC-1040] Outstanding PhaseListener.afterPhase() calls for the current phase should be made before any requested redirect actually takes place Created: 19/Oct/11  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle, Navigation
Affects Version/s: 2.1
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: Matt Benson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Matt Benson

 Description   

See email thread beginning at http://java.net/projects/javaserverfaces/lists/dev/archive/2011-10/message/5 .






Restore ViewScope before templates are processed with buildView (JAVASERVERFACES_SPEC_PUBLIC-787)

[JAVASERVERFACES_SPEC_PUBLIC-1034] disentangle ViewScope state handling from UIViewRoot.saveState()/restoreState() methods to better control ViewScope state handling Created: 16/Aug/11  Updated: 17/Dec/13

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

Type: Sub-task Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1087 CDI portable extension for @ViewScoped Resolved
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-787 Restore ViewScope before templates ar... Closed
Tags:
Participants: Darious3, Ed Burns and Hanspeter Duennenberger

 Description   

With JAVASERVERFACES_SPEC_PUBLIC-787 a new method restoreViewScopeState was added to UIViewRoot to allow restore ViewScope before buildView is called. But there is no matching saveViewScopeState method.

This issue proposes adding also a method saveViewScopeState() method to UIViewRoot and save the ViewScope state no longer as part of UIViewRoot's state array but rather as an element of the rawState Object[]. Looking at StateManagementStrategyImpl.saveView() - that always returns new Object[] { null, stateMap }; I see element[0] is used to store component structure (full state saving only?). So an additional third element could keep the ViewScope state built from saveViewscopeState() - and restoreState would use thrid rawState element as argument to restoreViewScopeState().

That would allow more flexibility e.g if some impl. or adapter/bridge needs to handle ViewScope state differently. By wrapping UIViewRoot and overriding save-/restoreViewScopeState() methods that would be possible. Currently ViewScope state is bound to UIViewRoot state structure.



 Comments   
Comment by Darious3 [ 18/Aug/12 03:08 PM ]

Would this also help the much needed CDI implementation of @ViewScoped?

Comment by Hanspeter Duennenberger [ 03/Sep/12 03:29 PM ]

Could be, if CDI needs to support @ViewScoped, there must be a way to hook into view-scope state saving and restoring. By explicitly define when and how ViewScope state is saved and restored this would also allow other DI frameworks to provide the @ViewScoped beans. But then I think this will be a spec change and I guess it will not make it into 2.2.

Comment by Ed Burns [ 04/Sep/12 02:30 PM ]

You are right that we need to de-couple the implementation of @ViewScoped on top of CDI from code in UIViewRoot. More API needs to be done.





[JAVASERVERFACES_SPEC_PUBLIC-1028] Clarify partial state save/restore traversal requirements Created: 02/Aug/11  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_small importance_medium

Tags:
Participants: aschwart and Ed Burns

 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 05:01 PM ]

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 03:49 PM ]

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 03:32 PM ]

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 04:41 PM ]

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

Comment by Ed Burns [ 22/Dec/11 05:00 PM ]

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 07:32 PM ]

Move to sprint 11





[JAVASERVERFACES_SPEC_PUBLIC-1011] ResourceELResolver does not encode the URL with ExternalContext.encodeResourceURL() Created: 26/May/11  Updated: 17/Dec/13

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

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

File Attachments: Text File SPEC-1011-ResourceELResolver.patch    
Tags:
Participants: Hanspeter Duennenberger and rogerk

 Description   

The getValue() method says:

  • If one of the above steps resulted in the creation of a {@link Resource}
  • instance, call <code>ELContext.setPropertyResolved(true)</code> and return
  • the result of {@link javax.faces.application.Resource#getRequestPath()}

Taken from: http://java.net/jira/browse/JAVASERVERFACES-1878



 Comments   
Comment by Hanspeter Duennenberger [ 15/Jun/11 02:27 AM ]

Hi Ed.

Here an updated patch for this ResourceELResolver issue.

Actually I opened this issue as a mojarra impl bug, but Roger has closed JAVASERVERFACES-1878 and created this one instead.

I'm not sure if that is right - I mean, if ResourceELResolver is affecting the spec, why is it then not in package javax.faces.el? Or is resource handling subject to bigger change for JSF 2.2?

Anyway, the attached patch contains the changes to fix this issue and a little correction in javadoc.

regards
Hanspeter





[JAVASERVERFACES_SPEC_PUBLIC-1007] Explicit support for dynamic component tree manipulation Created: 22/May/11  Updated: 17/Dec/13

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

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: components
Participants: arjan tijms, Ed Burns, kennardconsulting and Manfred Riem

 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 03:32 PM ]

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 05:34 PM ]

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

Comment by arjan tijms [ 16/Jul/11 12:26 PM ]

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 09:21 PM ]

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 01:37 PM ]

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 11:06 PM ]

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 07:16 AM ]

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 02:42 PM ]

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"





[JAVASERVERFACES_SPEC_PUBLIC-989] Programmatic manipulation of list items Created: 25/Apr/11  Updated: 17/Dec/13

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

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_large importance_large

Tags:
Participants: Ed Burns and lamine_ba

 Description   

JB> 3) programmatically manipulation of an item in a displayed list -
JB> The <ui:repeat/> is ok, but ASP.NET ups the ante once again by
JB> letting you raise a method on the backing class to easily manipulate
JB> the child components for the current row

JB> Example tag

JB> <asp:Repeater ID="rptEvents" runat="server"
JB> OnItemDataBound="handleRepeaterRow" >

JB> .... child components here

JB> </ asp:Repeater>

JB> Corresponding method on the backing class

JB> protected void handleRepeaterRow(object sender,
JB> System.Web.UI.WebControls.RepeaterItemEventArgs e)

JB> this is REALLY powerful as it provides an excellent way to solve
JB> issue #2 plus a whole lot more



 Comments   
Comment by lamine_ba [ 25/Apr/11 12:23 PM ]

One solution of this problem could be to attach to the <ui:repeat> component an event or an action to be executed?
Now the missing piece is the intention of the developer? What he want to do in the server side? what does he need?

1) The current index
2) The current Object
3) the current UI representation of the current object

Comment by lamine_ba [ 27/Apr/11 10:36 AM ]

JB> Yes to all of the above. As proposed in the JIRA item I think the ability to call a method on the <ui:repeat /> would be optimal. Forgive my pseudo code but maybe something like this:

public void handleRepeatItem(Object currentObjectFromCollection, UIComponent currentContainerHoldingChildComponents)

MLB> Thus you can programmaticaly create an UI representation for your object and attach this representation to its UI container (Builder Pattern). From a programmer perspective, I can only appreciate this solution which is really scalable at the condition you don't keep the UI reference (UIComponent currentContainerHoldingChildComponents). Once we have this feature, I bet that any programmer will say " Oh! I love it so much. I have now the freedom to do whatever I want" and I bet that any web designer will say " Oh! I hate it so much. I can't program and I can't help. Who can save a wretch like me? "





[JAVASERVERFACES_SPEC_PUBLIC-988] Dynamic include problem Created: 25/Apr/11  Updated: 17/Dec/13

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

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_large importance_large

Tags:
Participants: Ed Burns and lamine_ba

 Description   

JB> 2) the "dynamic UI include" problem - This is a scenario where you
JB> have several different types of include files and need to show a
JB> list of items (each "item" being the include template) where the
JB> list is only know at runtime. Let's make up a specific example here
JB> to illustrate:

JB> You have an event registration system that sells tickets online:

JB> - A user can buy multiple tickets (and different types of tickets)
JB> as part of the purchase process

JB> - Each ticket purchased has to have totally different information
JB> filled out

JB> - There are many different types of tickets (e.g.: attendee,
JB> sponsor, exhibitor, etc)

JB> - every time they "add a ticket" (it considers what kind of ticket
JB> they selected and adds that type of form to the list of forms that
JB> will need to be completed before proceeding with the purchase)

JB> Now obviously in this example you could build a "dynamic" template
JB> that based on an input variable renders itself differently and put
JB> this inside a <ui:repeat/> - or for that matter you could
JB> programmatically insert the elements comprising each type of form
JB> into the control tree. The problems with these approaches is that
JB> you're back to server programming for every little UI change (not to
JB> mention you've got one big component with potentially hundreds of
JB> pieces of logic in it). ASP.NET solves this by allowing you to
JB> define a .ascx file (much like a facelet include) and then
JB> programmatically include them into something akin to a JSF
JB> panelGroup. Then on postback you simply get an enumeration of the
JB> items and loop through them to retrieve the values of the class
JB> that's bound to the child components. Now with a lot of trickery and
JB> a ton of time for each implementation you can get something close
JB> with JSF but it's not at all intuitive or easy.



 Comments   
Comment by lamine_ba [ 26/Apr/11 01:00 PM ]
  • The JSF framework is a set of abstractions for building different types of web applications.
  • A business application is a set of polymorphic systems.
  • Different types of Customers
  • Different types of Contracts
  • Different types of Y

which leads to this recurrent design

public abstract class Y {
}


public class XY extends Y{
}

which once applied in an event registration system brings something like this

public abstract class Ticket {         
}


public class SponsorTicket extends Ticket {
}


public class AttendeeTicket extends Ticket {
}


public class Reservation {

      public void addTicket(Ticket ticket) {
      }         
      public void removeTicket(Ticket ticket) {
      }
      public Collection<Ticket> getTickets() {
      }
 }

Let's make something interesting now and let's override the toString() method to return the type of a ticket.

public class SponsorTicket extends Ticket {
        
     public String toString() {
            return "SponsorTicket";
     }
}


public class AttendeeTicket extends Ticket {

      public String toString() {
             return "AttendeeTicket";
       }

}

This technique is powerful in a polymorphic system once coupled with the power of a template engine to generate dynamic content following a pattern like this one :

return-value${dynamic-value}
  • Let's design now our form web pages using the Velocity Template Engine
  • Reservation page

dynamic include of the derivate forms based on the toString() return value.

#foreach($ticket in $reservation.tickets)
    #set($template="form" + $ticket + ".vm")         
    #include($template)
   #end
  • formSponsorTicket.vm
label 1 : <input type="text" value=".."/>
label 2 : <input type="text" value=".."/>
label 3 : <input type="text" value=".."/>
label 4 : <input type="text" value=".."/>
label 5 : <input type="text" value=".."/>

Because we have a polymorphic system, the forms will have some fields in common. Thus to avoid the duplication, it is better to create a common page (formTicket.vm) like we did for the abstract class Ticket.

#foreach($ticket in $reservation.tickets)
      #include("formTicket.vm")                                                
      #set($template="form" + $ticket + ".vm")
      #include($template)
#end

..............................................................................

  • Let's design now our form web pages using the Facelets Template Engine
  • Reservation Page
<ui:repeat value="#{reservation.tickets}" var="ticket">
       <ui:include src="formTicket.xhtml"/>                 
       <ui:include src="form${ticket}.xhtml"/>                 
</ui:repeat>

Common Page : formTicket.xhtml

label 1 : <h:inputText  value=".."/>
label 2 : <h:inputText  value=".."/>

Page : formSponsorTicket.xhtml

label 3 : <h:inputText  value=".."/>
label 4 : <h:inputText  value=".."/>
label 5 : <h:inputText  value=".."/>

-------------------------------------------------------------------------

Comparison of the solutions

The two solutions are the same even if I'm using two different template engines and what is quite amazing is that none of them works. Why? Because when you include a file in a iteration, you still get the whole context as model. No way to use the current object being iterated as model thus making you unable to do something like this

<ui:repeat value="#{reservation.tickets}" var="ticket"> 
    <ui:include src="formTicket.xhtml"/> (var="ticket" not used)
    ....................................................
</ui:repeat>

Velocity :

<input type="text" value="${ticket.property1}"/>

Facelets :

<h:inputText  value="#{ticket.property1}"/>

Jason, You are doing a binding in your managed beans because you want to have a way to get this reference and as you may know, binding means coupling, maintenance nightmare, a change here and a change there.

To overcome this problem without using the problematic programmatic approach, we should have a way to set the model to use for the template to be included, something like this

<ui:include src="formTicket.xhtml" model="${ticket}"/>

Reservation Page

<ui:repeat value="#{reservation.tickets}" var="ticket">
     <ui:include src="formTicket.xhtml"    model="#{ticket}"/> 
     <ui:include src="form#{ticket}.xhtml"  model="#{ticket}"/>
</ui:repeat>

Another alternative would be to use the JSF composite components feature which is the opposite side of the dynamic include approach
and one possible solution to leverage if the JSF runtime was able to generate dynamically the xml tags by following a pattern like this

<namespace:#{tag-value}>

So instead of creating a facelets view for each type of ticket, we will create a composite component for each type of ticket and write something like this in the reservation page

Reservation Page

<ui:repeat value="#{reservation.tickets}" var="ticket">
    <ez:formTicket    model="#{ticket}"/>   (formTicket.xhtml)
    <ez:form#{ticket}  model="#{ticket}"/>  (formSponsorTicket.xhtml...)
</ui:repeat>

Composite component (formSponsorTicket.xhtml)

<composite:interface>
    <composite:attribute name="model" required="true"/>
</composite:interface>

<composite:implementation>

    label 3 : <h:inputText  value=" #{cc.attrs.model.property1}"/>
    label 4 : <inputText  value="#{cc.attrs.model.property2}"/>
    label 5 : <inputText  value="#{cc.attrs.model.property3}"/>

</composite:implementation>

If the dynamic tags generation is impossible for JSF, we can still make some if.........

<ui:repeat value="#{reservation.tickets}" var="ticket">
      <c:if test="#{ticket == 'SponsorTicket'}">
         <ez:formSponsorTicket    model="#{ticket}"/>.
       </c:if>
           ......
</ui:repeat>

we have two solutions and two possible new issues.

1) Facelets inclusion improvement
2) EL support for generating dynamic xml tags

These solutions have been realized from a page author perspective.

Comment by lamine_ba [ 27/Apr/11 10:41 AM ]

JB> Proposed solutions certainly appear valid – but this may actually be a little easier. If item 989 (http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-989) is implemented you could quite simply use that function to programmatically add the dynamic include to the control tree. This of course assumes that you can read, compile and include a facelet file programmatically (which I believe I’ve seen somewhere?)

MLB> Again Jason, thus you can programmatically create an UI representation for your object and attach this representation to its UI container
But this time the UI representation is not created directly from your java code. You take it from a resource, from a facelets file written maybe by a web designer. And the algorithm of your handleRepeatItem(Object currentObjectFromCollection, UIComponent currentContainerHoldingChildComponents) method will look something like that:

1)for the currentObjectFromCollection, find its UI resource file (facelets file)
2) load the resource file, compile it and create an UI representation from it
3) Attach the UI representation to its UI container : currentContainerHoldingChildComponents.add(representation)

But at this point, If I were you, I would say " Hey I don't see anymore what JSF did for me and the abstraction it brings to ease the job. Why do I have my hands dirty? Why things shouldn't be simpler as to give the resource name to the JSF runtime which will manage the details for me and create an UI representation (UIComponent) from my resource ".

javax.faces.Application class

public abstract class Application {

 public UIComponent createComponent(FacesContext context,
                                       Resource componentResource) {
}

public UIComponent createComponent(Resource resource) {
  // a simplification of the first method which use the current context

}


public UIComponent createComponent(String resourceName) { 

 // unification, componentType and resourceName must be supported

}

}

To move further Take a look at these issues below because they are related

Where to find the resources : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-809

Jason, you are managing 40 developers to develop business applications? Are these applications modular? How do you divide the work among your developers? How do you do the integration of the pieces (modules)? How do you reuse your past work when developing a new application? Do you always start from scratch?

Support for modular, reusable fragments of web applications : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532
Plugin System : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-970

Have you a web designer in your team?

Multi-templating : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971





[JAVASERVERFACES_SPEC_PUBLIC-987] Solve "Cascading Dropdown Problem" Created: 25/Apr/11  Updated: 17/Dec/13

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 1.1, 1.2, 2.0, 2.1
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File 20110510-i_spec_987.patch    
Status Whiteboard:

size_large impotance_large

Tags:
Participants: Ed Burns, i_oss, Jakob Korherr and lamine_ba

 Description   

>>>>> On Sat, 23 Apr 2011 18:41:42 +0000, Jason Bonifay said:

JB> 1) the classic "cascading drop down problem" - this is a scenario
JB> where the first dropdown is dynamically populated with values and
JB> the selection available in the second dropdown is dependent on the
JB> value selected in the first dropdown (e.g.: select a country then
JB> the list of cities are dynamically populated). Important to note
JB> here - if dropdown #1 has static values this problem obviously
JB> trivial, the challenge arises from a dynamically defined list being
JB> dependent on the selected value from a parent list the is also
JB> dynamically defined. ASP.NET solves this (and other problems) by
JB> defining several "page lifecycle functions" akin to JSF but let's
JB> you easily override functions in the backing classes (i.e.:
JB> "page_init", "page_load" etc) to programmatically control where to
JB> populate each dropdown. Remember - You can't paint the values in
JB> dropdown #2 until you can retrieve the selected index from dropdown
JB> #1 - but you can't retrieve the selected index until you first fill
JB> the options so the framework can then bind the selected index.



 Comments   
Comment by lamine_ba [ 25/Apr/11 12:10 PM ]

One of the solutions to the "Cascading Dropdown problem " is to make the UISelect components aware of each other by adding a parent-child relations. If a selection occurs in the parent (change event), the child is update automatically. The JSF framework will send an Ajax call to invoke a method in the managed bean like for example : load_childs(parent_id ). By parent_id, I mean the value selected in the parent combo, the id of a country for example to invoke a method like load_cities(country_id ) for example. The selected value is the only thing a developer needs in order to run successfully his data access logic. A developer must provide in the UI the method to be called for the partial update. The JSF framework will manage transparently the interaction (display,update,remove,disable) with a client side approach. no UI binding in your managed beans thus making your application scalable.
one selection and multiple selection must be managed.

Comment by lamine_ba [ 27/Apr/11 10:38 AM ]

JB> Agreed. This seems to be the way that other frameworks (and the manual work-around I’ve implemented) are solving it and it seems to work quite well

MLB> Yes it is my opinion, the idea has already been tested and it works quite well. So, let's implement it..

Comment by i_oss [ 27/Apr/11 05:05 PM ]

Sorry I don't quite understand the problem, isn't the setter of <h:selectXXX value="#{my.selectionSetter}"/> the method you are looking for? if you change the items of dropdown #2 in the value-setter of #1, it should just work the way described above.

So I am not sure, which lifecylce-phase is missing here? Maybe if someone could point out at which time in the lifecycle "page_init" and "page_load" would take place?

Comment by lamine_ba [ 28/Apr/11 06:18 AM ]

we are talking about doing something like this : http://www.coderanch.com/t/510988/JSF/java/ajax-update-selectOneMenu.

"page_init" and "page_load" functions belong to ASP.NET lifecycle.

our problem is to update dynamically a dropdown based on a selection made on another dropdown (change event). and the solution should be something like this.

<h:selectOneMenu value="#{bean.country}" id="countries">  
        <f:selectItems value="#{bean.countries}" />  
        <f:ajax event="change" render="cities"  />  
    </h:selectOneMenu>  


   <h:selectOneMenu value="#{bean.city}" id="cities">  
        <f:selectItems value="#{bean.cities}" />  
    </h:selectOneMenu>
@ManagedBean
  public class Bean {
   
  private Long country;
  private Long city;

  ............................................

  }
Comment by i_oss [ 29/Apr/11 05:26 AM ]

so it just should be:

(apart from Long probably not being very userfriendly in the rendered page )

public void setCountry(Long country) {
    // put checks for changes here, if it is a long running operation...
    this.cities = whateverToGetTheCitiesFor(country);
    this.country = country;
}

Or am I missing something here?

Still I'd like to know where page_init and page_load would be added to the lifecycle?

Comment by lamine_ba [ 29/Apr/11 10:58 AM ]

i_oss> (apart from Long probably not being very userfriendly in the rendered page )

You can choose whatever you want. I often use the Long type for my id and my primary key.

public class Country {

   @Id
   private Long id; // choose whatever you want, Long,Integer,String,....
   private String name;
}

i_oss>

public void setCountry(Long country) {
    // put checks for changes here, if it is a long running operation...
    this.cities = whateverToGetTheCitiesFor(country);
    this.country = country;
}

And you are saving three states which can be a good thing when you have the need to cache your data in order to prevent multiple time access

@ManagedBean
  public class Bean {
   
  private Long country;             //1
  private Long city;                //2
  private List<SelectItem> cities;  //3
  ............................................

  }

and you have created two methods

public List<SelectItem> whateverToGetTheCitiesFor(Long id country) {
}

public List<SelectItem> getCities() {   
   return cities;
}

which could be just one method

public List<SelectItem> getCities() {   
   // call your DAO here
}

Your solution is not my solution and that is the reason why I have just created a skeleton. The only thing I need myself is to be able to know the id of the country and the id of the city that have been selected. ( value="#{bean.country}", value="#{bean.city}").

i_oss> Or am I missing something here?

Yes, you are really missing something here. We are talking about ASP.net, not about JSF

JB>ASP.NET solves this (and other problems) by
JB> defining several "page lifecycle functions" akin to JSF but let's
JB> you easily override functions in the backing classes (i.e.:
JB> "page_init", "page_load" etc) to programmatically control where to
JB> populate each dropdown. Remember - You can't paint the values in
JB> dropdown #2 until you can retrieve the selected index from dropdown
JB> #1 - but you can't retrieve the selected index until you first fill
JB> the options so the framework can then bind the selected index.

This issue is not really an issue because you can create a working solution with JSF in 5 minutes. We were just unaware that we could realize it without using a programmatic approach. Its only merit is that it helps us find some ideas in how to ease the job and as soon as we have finished to describe them, it will be closed.

Comment by lamine_ba [ 01/May/11 09:06 AM ]
  • Cascading Dropdown implementation with JSF 2.0

  • The entities
public class Country {

	private Long id;
	private String name;	
	
}

public class City {

	private Long id;
	private String name;
	private Country country;
	
}
  • The DAO
public interface Dao {

public List<Country> getCountries();
	
public List<City> getCities(Long country_id);

}
  • The Managed Bean
@ManagedBean
public class Bean {

	private Long country_id=new Long(0);  // select the first option in the combo 
	private Long city_id=new Long(0);    // select the first option in the combo
	private @Inject Dao dao;
	
	public List<SelectItem> getCountries() {
		
		List<SelectItem> items=new ArrayList<SelectItem>();
		for(Country country:dao.getCountries())
			items.add(new SelectItem(country.getId(),country.getName()));
		return items;
	}
	
	public List<SelectItem> getCities() {
		
		List<SelectItem> items=new ArrayList<SelectItem>();
		for(City city: dao.getCities(country_id))
			items.add(new SelectItem(city.getId(),city.getName()));
		return items;
	}
	
	-----------------------------------------------------------------

}
  • The Facelets view
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html">

<h:head>

<h:outputScript name="jsf.js" library="javax.faces"/> 

</h:head>

<body>

<h:form>

<h:selectOneMenu value="#{bean.country_id}" id="countries">
        <f:selectItem itemLabel="-- Select a Country -- " itemValue="0"/>  
        <f:selectItems value="#{bean.countries}" />  
        <f:ajax event="change"  render="cities" /> 
</h:selectOneMenu>  

 <h:selectOneMenu value="#{bean.city_id}" id="cities">
        <f:selectItem itemLabel="-- Select a City -- " itemValue="0"/>    
        <f:selectItems value="#{bean.cities}" /> 
 </h:selectOneMenu>
 

</h:form>

</body>

</html>
  • The Conclusion

And That's all. we have created a cascading dropdown without using a programmatic approach like this ugly one. (http://www.juurlink.org/2011/02/dynamic-dependent-list-boxes/). We select a country in the first combo and automatically an ajax request is fired behind the scenes to update the other combo. This feature is really a powerful one until the idea to add a commandButton in your form to make a postback and save things, comes to you.

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

<h:head>

<h:outputScript name="jsf.js" library="javax.faces"/> 

</h:head>

<body>

<h:form>

<h:selectOneMenu value="#{bean.country_id}" id="countries">
        <f:selectItem itemLabel="-- Select a Country -- " itemValue="0"/>  
        <f:selectItems value="#{bean.countries}" />  
        <f:ajax event="change"  render="cities" /> 
</h:selectOneMenu>  

 <h:selectOneMenu value="#{bean.city_id}" id="cities">
        <f:selectItem itemLabel="-- Select a City -- " itemValue="0"/>    
        <f:selectItems value="#{bean.cities}" /> 
 </h:selectOneMenu>
 
<h:commandButton action="#{bean.save}"  value="Save">

</h:form>

</body>

</html>

And boum! you get a validation error. Sadly, the combo displaying your cities is saying that the value you have picked in its list is not a valid one because this same value is not anymore in its list". Isn't it a craziness statement?. After some long and hard hours debugging the jsf.js file and looking at the tree printed in the console by my PhaseListener, I came accross no rationale idea. Everything was fine. The partial view processing and rendering were done perfectly and the state of the combo was updated and saved. And suddenly when I was about to loose hope, comes this ironical idea : "Hey put the managed bean in the session scope".

@ManagedBean
@SessionScoped
public class Bean {

  public String save() {

    ----------------------

  }
}

and definitely that was the solution.......

Comment by lamine_ba [ 01/May/11 09:33 AM ]
  • Cascading Dropdown Implementation with JSF 2.2

  • The @SelectionModel annotation

creating SelectItem objects is a recurrent and tedious task for a developer. We must automate it. The developer will save time and we will gain in performance because we have a double iteration, one for creating a list of SelectItem objects and another iteration for creating from this same list another list of UISelectItem components. With this annotation, we can cut the first.

@SelectionModel(value="id",label="name")
on a method returning a list or a Collection of Country means virtually

new SelectItem(country.getId(),country.getName())
for each country.

@ManagedBean
@SessionScoped
public class Bean {

	
        @SelectionModel(value="id",label="name")
	public List<Country> getCountries() {
	  
           return dao.getCountries();	
	}
	
        @SelectionModel(value="id",label="name")
	public List<City> getCities() {
		
	   return  dao.getCities(country_id))
	
	}
	
	-----------------------------------------------------------------

}

If we bring a convention on how to get the value and the label on objects, we can make this annotation optional which will be again for us a gain of time and clarity.

@ManagedBean
@SessionScoped
public class Bean {

	
 	public List<Country> getCountries() {
	  
           return dao.getCountries();	
	}
	
 
	public List<City> getCities() {
		
	   return  dao.getCities(country_id))
	
	}
	
	-----------------------------------------------------------------

}
Comment by Ed Burns [ 10/May/11 09:33 AM ]

In progress prototype

Comment by i_oss [ 10/May/11 11:08 AM ]

The @SelectionModel is a nice idea.
At the moment you can avoid using SelectItems already by:
1) A Converter, and a sensible toString method on your beans (so this is the current "convention" for not using SelectItems and/or Annotations)
Drawbacks: This can't be tuned on a per <h:select...> basis, so the labels would always be the same and the value would be the full bean
2) Use itemValue and itemLabel on the <f:selectItems...>
Drawbacks: The template developer then has to know what value is expected, and how to build the label from the bean.

In case we create @SelectionModel, I think value and label should be EL with a implicit varname for the items in the list
for example: @SelectionModel(value="#{item.id}", label="#{item.firstname} #{item.lastname}")

Comment by lamine_ba [ 10/May/11 12:24 PM ]

Hi Imre. Yes The @SelectionModel is a nice idea to avoid using SelectItems. I had this idea because I was unaware that this annotation already exists in JSF 2.0 through another representation more cleaner, more simpler and more transparent.

2) Use itemValue and itemLabel on the <f:selectItems...>

public List<Country> getCountries() {
        return dao.getCountries();
}
<f:selectItems value="#{bean.countries}" 
var="country" itemValue="#{country.id}" itemLabel="#{country.name}" />

I prefer now this way which makes my annotation obsolete and there is no way to get an annotation through the Expression Language. But It would be wonderful to have such feature in the EL api.

2) Use itemValue and itemLabel on the <f:selectItems...>
Drawbacks: The template developer then has to know what value is expected, and how to build the label from the bean.

Yes I agree and that is why we want to bring a convention in JSF 2.2. In the real life, every man has an ID (fingerprint, DNA) and a name. In the software life, most of the objects we display are entities. So if we don't provide the information on how to resolve the ItemValue or the ItemLabel, their values will be resolved by invoking getId() and getName() on our objects.

JSF 2.2

public List<Country> getCountries() {
        return dao.getCountries();
}
<f:selectItems value="#{bean.countries}"/>

means virtually

<f:selectItems value="#{bean.countries}" var="country" 
itemValue="#{country.id}" itemLabel="#{country.name}" />

The var attribute like the ItemValue and ItemLabel is now optional and by default its value is equal to 'it'.

<f:selectItems value="#{bean.countries}" itemValue="#{it.id}" itemLabel="#{it.name}" />

so adhere to our JSF 2.2 convention and you will save time.

Comment by Ed Burns [ 10/May/11 03:13 PM ]

The most recent patch, a collaboration from Lamine and I, but mostly Lamine, shows one way to do this.

Comment by i_oss [ 10/May/11 03:34 PM ]

Hi Lamine, only a short note

<f:selectItems value="#{bean.countries}"/>

at the moment is equivalent to

<f:selectItems var="country" itemValue="#{country}" itemLabel="#{country.toString()}"/>

With the #{country} being coerced to/from String with a converter (if needed and existing).
So I don't think we want to change the convention that already exists, possibly breaking existing apps.

Comment by lamine_ba [ 11/May/11 06:07 AM ]

Hi Imre, I'm really sorry, I haven't thought about that.

There is already a behavior for

<f:selectItems value="#{bean.countries}"/>

If we change that, the existing apps will break and that is not really a good thing.

So I will just keep this part of my writing of course if you don't see any problem with it

The var attribute is now optional and by default its value is equal to 'it'.

<f:selectItems value="#{bean.countries}" itemValue="#{it.id}" itemLabel="#{it.name}" />
Comment by Jakob Korherr [ 12/May/11 12:27 PM ]

> The var attribute is now optional and by default its value is equal to 'it'.

Why are we using the term "it" here exactly? Should it mean "item"? In that case I would propose naming it "item" instead of "it", because "item" is a LOT more significant than "it" (and it's just two more letters...).

Comment by lamine_ba [ 12/May/11 07:56 PM ]

Hi Jakob. Why are we using the term "it"? That is a very good question. It is just something I have borrowed to Groovy.

Inside each closure, Groovy defines a default variable,
it, for one argument passed to the closure. This makes
it very easy to have a single parameter for your closures without
having to explicitly declare it. The it variable works
just like Perl’s $_ variable in subroutines:

namePrinter = { println "Hello, ${it}!" };
namePrinter("John"); // prints "Hello, John!"

If you prefer, we can name it "item". It is also a very nice proposal. I'll be happy with whatever name you'll choose as long as the var attribute is optional. That is the only thing I want.

Comment by Jakob Korherr [ 13/May/11 02:36 AM ]

Hi Lamine,

Thanks a lot for the clarification. I did not know that!

Nevertheless, I prefer "item" over "it". It really is a lot more significant in this case, because most attributes of <f:selectItems> which will use this implicit var are starting with the term "item" --> "itemLabel", "itemValue".

So it would be very great, if we could change that!

Comment by lamine_ba [ 13/May/11 10:31 AM ]

You are right Jakob and I vote for "item". Don't worry, nothing has been done yet. It was just an idea we were testing.

Comment by Ed Burns [ 09/Aug/11 08:06 PM ]

I don't think we made the var attribute optional after all.





[JAVASERVERFACES_SPEC_PUBLIC-984] Component context management Created: 21/Apr/11  Updated: 08/Nov/13

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

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

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

size_large importance_large

Tags:
Participants: aschwart and Ed Burns

 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 01:19 AM ]

Carry forward to 2.2 Sprint 9.

Comment by Ed Burns [ 16/Dec/11 06:34 PM ]

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 08:33 PM ]

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 06:46 PM ]

Re-opening per Andy's request.





[JAVASERVERFACES_SPEC_PUBLIC-973] [JSR-303 integration] sorted violation messages Created: 15/Apr/11  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.1
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: gerhard_petracek Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Ed Burns and gerhard_petracek

 Description   

A BV-engine returns a set of violations.
The violations are unsorted (not deterministic) which might be confusing for users and more difficult for UI tests.
Therefore, the found violations (provided by BV) should be sorted.



 Comments   
Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-972] [JSR-303 integration] @Valid support for custom types Created: 15/Apr/11  Updated: 08/Nov/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.1
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: gerhard_petracek Assignee: Unassigned
Resolution: Unresolved Votes: 5
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-543 @Valid and JSF Sub-task Open  
Tags:
Participants: Ed Burns, gerhard_petracek and Jakob Korherr

 Description   

see https://issues.apache.org/jira/browse/EXTVAL-96



 Comments   
Comment by Jakob Korherr [ 15/Apr/11 03:49 AM ]

This issue is related to JAVASERVERFACES_SPEC_PUBLIC-543

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-948] JSF Security Created: 15/Mar/11  Updated: 08/Nov/13

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

Type: New Feature Priority: Major
Reporter: luisalves00 Assignee: Unassigned
Resolution: Unresolved Votes: 19
Σ Remaining Estimate: 1 week Remaining Estimate: 1 week
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 1 week Original Estimate: 1 week

Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-971 Multi-templating System Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-446 How to Provide JAAS Authorization in ... Sub-task Open  
Status Whiteboard:

size_large importance_medium

Tags:
Participants: arjan tijms, john_waterwood, lamine_ba and luisalves00

 Description   

Add native authentication and access-control to JSF.

Related projects:
http://jsf-security.sourceforge.net/



 Comments   
Comment by arjan tijms [ 17/May/11 10:59 AM ]

>Add native authentication and access-control to JSF.

I'm not sure if JSF itself should implement any authentication, but it IMO should definitely integrate better with the existing security infrastructure offered by Java EE and the Servlet spec in particular.

Currently, JSF can work with Java EE's form-based authentication, but posting to j_security_check and using input elements with j_username and j_password names feels a little awkward. I'm sure a more native JSF solution would be possible here, possibly taking advantage of Servlet 3.0's programmatic login.

The securityScope proposed by the linked project is interesting, although with the latest EL revision it's now possible to call several of the existing methods in HttpServletRequest from EL.

Some like Tomhawk's enabledOnUserRole and visibleOnUserRole attributes may also be worth considering.

Comment by lamine_ba [ 01/Dec/11 12:41 PM ]

As arjan tijms wrote, the goal of JSF were never to provide a security system. In fact, its goal is to provide the right abstraction that one can use safely to integrate with the existing security infrastructure.

Here is one proposal about how this abstraction must be implemented. for the moment, we will keep it simple :

  • Authentication

We must take inspiration into SeamLoginModule

<h:form id="login">
 
   <h:panelGrid columns="2">
       <h:outputLabel for="username">Username</h:outputLabel>
        <h:inputText id="username" value="#{identity.username}"/>
         <h:outputLabel for="password">Password</h:outputLabel>
         <h:inputSecret id="password" value="#{identity.password}"/>
    </h:panelGrid>
 
<h:commandButton value="Login" action="#{identity.login}"/>
 
</h:form>
  • Authorization

We must have a view-level security in order to prevent non-authenticated users from accessing restricted views ". And this authorization part can be achieved using the f:viewAction component with this simple action : "if the user is not logged in, go to login.xhtml ". We must just come with this standard action that one can reference in his views.

<f:view>
<f:metadata>

<f:viewAction  execute="#{identity.checkLogin}" />

</f:metadata>
</f:view>

As a convention, the default page for the security redirection is login.xhtml but this value must be configurable. No, no need to make it configurable, we can write this behaviour in a default faces-config.xml

<navigation-rule>
    <from-view-id>*</from-view-id>
    <navigation-case>
        <from-action>#{identity.checkLogin}</from-action>
        <if>#{not identity.LoggedIn}</if>
        <to-view-id>/login.xhtml</to-view-id>
        <redirect/>
    </navigation-case>
</navigation-rule>

And the developers can override it with their own faces-config.xml.
This issue blocks 971-Multi-templating. A JSF developer can download a template. But without a security model, I cannot ask the template authors to design a login form for them.

Comment by john_waterwood [ 06/Oct/12 02:31 PM ]

Is this still planned for 2.2? Some level of support is really important for a web framework imho.





[JAVASERVERFACES_SPEC_PUBLIC-947] Relative Resources Created: 09/Mar/11  Updated: 08/Nov/13

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

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

File 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 Open
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-900 Images resources in css with relative... Resolved
is duplicated by JAVASERVERFACES-1189 #{resource['...']} not usable in <ui:... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1079 Add method ResourceHandler.isResource... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-548 Resource localization is too rigid an... Sub-task Resolved Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-884 Support library prefix in resource URLs Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-996 The resources folder should be either... Sub-task Resolved Ed Burns  
Status Whiteboard:

size_small importance_medium

Tags:
Participants: Ed Burns, Hanspeter Duennenberger, Jakob Korherr, lamine_ba and lu4242

 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 04:18 AM ]

add duplicate links.

Comment by Jakob Korherr [ 13/Jun/11 08:01 AM ]

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 03:53 PM ]

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 01:25 AM ]

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 03:05 PM ]

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 02:19 PM ]

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 08:20 PM ]

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 08:16 PM ]

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 07:54 PM ]

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 09:48 PM ]

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 04:25 PM ]

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 04:28 PM ]

Added sample_broken.zip

Comment by Ed Burns [ 29/Feb/12 06:11 PM ]

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 09:08 PM ]

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 09:14 PM ]

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 11:59 PM ]

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 08:20 PM ]

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 lamine_ba [ 21/Mar/12 01:13 PM ]

For what it's worth, JSF 2.0 has already a support for Relative Resources but only if you use a prefix mapping in your application. There is a bug in the implementations and it is in how they are interpreting the information in order to create the resource. you can solve this problem by wrapping the default ResourceHandler to correct the mistake in the createResource method. If I put this into practice and reuse the sample war, I will first correct the example by respecting the structure of a resource library. So Here is how things should be laid on.

Structure

  • resources
    • css
      • style.css
      • included.css
    • images
      • header.png
      • expert-draft-bg.png

Now Let's use the style in our Facelets Page

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

The generated URL will be : http://localhost:8080/faces/javax.faces.resource/style.css?ln=css.

and the browser will after use http://localhost:8080/faces/javax.faces.resource/ to load the other resources referenced in this css file. So to have them correctly loaded here is how you should reference them

-style.css : First Version

@import url(included.css?ln=css);
body{
  background-image:url(expert-draft-bg.png?ln=images);
}
div#header{
  background-image:url(header.png?ln=images);
}

-style.css : Second Version

@import url(css/included.css);
body{
  background-image:url(images/expert-draft-bg.png);
}
div#header{
  background-image:url(images/header.png);
}

In this last variation, the one I currently use in my application, The ResourceHandler must be intelligent enough to know that the libraryName will be null and that its value will be inside the resource name ( images/expert-draft-bg.png, css/included.css).





[JAVASERVERFACES_SPEC_PUBLIC-942] Allow JSF application artifacts to be delivered as OSGi bundles Created: 31/Jan/11  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Text File message.txt    
Status Whiteboard:

size_large importance_large

Tags:
Participants: rogerk

 Description   

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=edburns):

Created an attachment (id=878)
Unix Mail file of discussion on this topic

The term "JSF artifacts" has multiple meanings,
and I'm sorry about that. I've changed the status to "JSF application
artifacts" to reflect its intended meaning, which is: converters, validators,
components, etc. In short, any code a developer would write as part of a JSF
application that conforms to some sort of JSF contract.






[JAVASERVERFACES_SPEC_PUBLIC-941] reduce number of times rendered attribute value expression is evaluated Created: 31/Jan/11  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 15
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns and rogerk

 Description   

The rendered attribute is an Achilles heal of JSF performance. JSF abuses the
value expression used in rendered attributes. It's expected that the value
expression is going to be resolved more than once on a request because by nature
it is a pass-through construct and because the value it is representing is
likely contextual (meaning it can change as the application changes). However,
in the case of the render attribute, it's a little bit out of control. Any
getter method bound to a rendered attribute is being called way too many times.
This could easily be solved by being more frugal about when it is consulted.

For example, the rendered value expression is resolved in encodeChildren,
encodeBegin (or encodeParentAndChildren) and again at encodeEnd of most
components. We should state that when a component is first addressed during
encoding (perhaps in encodeBegin) that is when the rendered attribute should be
evaluated. Then the resolved value simply cannot change again in that phase.
(The exception would be a row in UIData, which the rendered attribute would need
to be resolved once per component per row).

We should also consider having encodeAll check the rendered attribute and not
encodeBegin. Or, we could keep the current contract the same but deprecate
encodeBegin, encodeChildren, encodeEnd and getRendersChildren so that most
people start using encodeAll instead so that isRendered gets called only once
per component per render phase execution.



 Comments   
Comment by Ed Burns [ 01/Jul/13 01:56 PM ]

Set fixVersion to 2.3. I think this may be better handled by having a way to advise the EL to start caching expression evaluations for the current thread and have a way to turn off that caching at the end of the JSF lifecycle.





[JAVASERVERFACES_SPEC_PUBLIC-939] behavior issues with "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" setting Created: 31/Jan/11  Updated: 24/Dec/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by JAVASERVERFACES-3098 Regression in UIComponentBase#saveAtt... Closed
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: balusc, dennishoersch, rogerk and vabp

 Description   

currently - where INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL is FALSE - we
have the following behavior:

Imaging two elements, bound to some managed bean (e.g in sessionScope)

<inputText id="one" />
<inputText id="two" required="true" />

Enter this:
one => FOO
two => BAR
HIT_ENTER (e.g submit the form)

now remove all the values
one =>
two =>
HIT_ENTER (e.g submit the form)

the rendered result is that BOTH fields are empty and there is an error-msg
for the required one.

Now when "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" is set to TRUE, we
have the following behavior
(same components used):

Enter this:
one => FOO
two => BAR
HIT_ENTER (e.g submit the form)

now remove all the values
one =>
two =>
HIT_ENTER (e.g submit the form)

the rendered result is that ONLY the required field is empty (and it has a
warning msg).
The other one - b/c submitted value is NULL is getting the real value, which has
been pushed into the bean before (=>FOO)

=> Is this really the intention ?

Do we really want to show the "original" data ? Today we don't, we just provided
the entered stuff/wrong_value (e.g nothing in this particular case)

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=mwessendorf%40java.net):

ah, ok.

basically the fix is this:

public Object getValue()
{
FacesContext fc = getFacesContext();
if (fc != null && fc.isValidationFailed())

{ return getStateHelper().get(PropertyKeys.value); }

else

{ return getStateHelper().eval(PropertyKeys.value); }

}

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=mwessendorf%40java.net):

IMO you shouldn't return something different from getValue because validation
failed!

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=rlubke):

It's returning the local value that would have been pushed to the model if
validation hadn't failed. That behavior seems correct based on the problem report.

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=gabfest):

let's say validation doesn't fail, but for some reason the developer calls
renderResponse in a valueChangeListener. Shouldn't the local value still get
shown when you rerender?
[ Show » ]
gabfest added a comment - 02/Dec/09 11:16 AM let's say validation doesn't fail, but for some reason the developer calls renderResponse in a valueChangeListener. Shouldn't the local value still get shown when you rerender?

ADDITIONAL COMMENTS (http://java.net/jira/secure/ViewProfile.jspa?name=rlubke):

Fair point.



 Comments   
Comment by vabp [ 15/May/12 08:55 PM ]

Can this please be addressed? It is significantly impact our in-production system.

Comment by balusc [ 11/Oct/12 02:51 PM ]

Issue 2262 is related http://java.net/jira/browse/JAVASERVERFACES-2262

Comment by dennishoersch [ 14/Jan/13 07:48 PM ]

Is there any decision made?

We're using the 'interpretion' of a submitted value as null, but the redisplay of the old value is a problem for us too.





[JAVASERVERFACES_SPEC_PUBLIC-937] Disable implicit navigation for JSF 1.x applications Created: 31/Jan/11  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Navigation
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.3

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

Status Whiteboard:

size_small importance_medium

Tags:
Participants: rogerk

 Description   

Currently, implicit navigation seems to be enabled for all applications that
are deployed on a container with Mojarra 2.0, even when they have a JSF 1.x
configuration. Because some of the action methods in our 1.x applications can
return an outcome that isn't defined in the navigation rules in faces-
new view (one that possibly doesn't even exist) instead of doing nothing, like
Mojarra 1.2 did.

It would be great for maintaining compatibility with 1.x applications if
implicit navigation is disabled when a 1.x configuration is found. Adding a
context initialization parameter to explicitly disable implicit navigation
could also be useful.
Description
Currently, implicit navigation seems to be enabled for all applications that are deployed on a container with Mojarra 2.0, even when they have a JSF 1.x configuration. Because some of the action methods in our 1.x applications can return an outcome that isn't defined in the navigation rules in faces- new view (one that possibly doesn't even exist) instead of doing nothing, like Mojarra 1.2 did. It would be great for maintaining compatibility with 1.x applications if implicit navigation is disabled when a 1.x configuration is found. Adding a context initialization parameter to explicitly disable implicit navigation could also be useful.



 Comments   
Comment by rogerk [ 31/Jan/11 08:27 AM ]

Additional comments from http://java.net/jira/secure/ViewProfile.jspa?name=omolenkamp

Ok, Bugzilla / some javascript / my browser somehow strips a line starting at
config dot xml. Last attempt:

"Because some of the action methods in our 1.x applications can
return an outcome that isn't defined in the navigation rules in faces dash
config dot xml, Mojarra 2.0 will in such a case redirect to a new view (one
that possibly doesn't even exist) instead of doing nothing, like
Mojarra 1.2 did."





[JAVASERVERFACES_SPEC_PUBLIC-936] Set FACELETS_REFRESH_PERIOD to -1 if project stage is Production Created: 31/Jan/11  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_small

Tags:
Participants: rogerk

 Description   

In most common cases there not need to reload Facelet from .xhtml in production
environment. Currently FACELETS_REFRESH_PERIOD has value 2 (if it is not set
explicitly) even in production - for simplification of configuration managenent
it should be set to -1 like:

if (refreshParam == null && stage == production)
refreshPeriod = -1
else
refreshPeriod = refreshParam






[JAVASERVERFACES_SPEC_PUBLIC-932] PreValidate/PostValidate events are not published properly Created: 31/Jan/11  Updated: 17/Dec/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk

 Description   

In UIComponentBase implementation, PreValidate/PostValidate events are
published as below:

Application app = context.getApplication();
app.publishEvent(context, PreValidateEvent.class, this);
// Process all the facets and children of this component
Iterator kids = getFacetsAndChildren();
while (kids.hasNext()) { UIComponent kid = (UIComponent) kids.next(); kid.processValidators(context); }
app.publishEvent(context, PostValidateEvent.class, this);

This makes overrided methods of subclasses cannot publish these events
properly. For example in UIInput as below:

super.processValidators(context);
if (!isImmediate()) { executeValidate(context); }

You can see, the PostValidate event for UIInput will always be published BEFORE
its own actual validating






[JAVASERVERFACES_SPEC_PUBLIC-931] Messages component has inconsistent root tag Created: 31/Jan/11  Updated: 17/Dec/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_small importance_medium

Tags:
Participants: rogerk

 Description   

When the messages component is rendered initially with no messages, it renders as a <div
id="messages">, but when messages are required, a <ul id="messages"> is rendered instead.

This makes it difficult to perform an ajax update of messages.

The preferred output would retain the outer <div> tag and optionally render the <ul> within it.

(There may be similar output with the message component.)






[JAVASERVERFACES_SPEC_PUBLIC-930] f:ajax not working when response contains CDATA / ui:debug Created: 31/Jan/11  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk and werpu12

 Description   

when calling an action-method that returns a string (viewId), f:ajax tries to
update the whole page with the new view.

This fails, when the source of the new view contains an xml-comment (CDATA) like
the one that gets automatically inserted through ui:debug.

when trying to update a page this way, an alert-box is shown, saying that update
failed.
Description
when calling an action-method that returns a string (viewId), f:ajax tries to update the whole page with the new view. This fails, when the source of the new view contains an xml-comment (CDATA) like the one that gets automatically inserted through ui:debug. when trying to update a page this way, an alert-box is shown, saying that update failed.
Show »

Sort Order: Ascending order - Click to sort in descending order



 Comments   
Comment by werpu12 [ 06/Mar/12 03:05 PM ]

I dont see this as a spec bug, the problem there probably is that the CDATA is not escaped correctly on the server by the partial response writer.
In MyFaces we do double buffering just for this issue, to avoid unescaped CDATAs in the ajax response.





[JAVASERVERFACES_SPEC_PUBLIC-926] UIInput change Created: 31/Jan/11  Updated: 17/Dec/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk

 Description   

We had an issue with UIInput type components regarding validation. If the user
entered a lot of spaces in the Input field, the UIInput validator accepted the
value as "filled out".

We suggest to change the isEmpty function in the javax.faces.component.UIInput
class to:

private static boolean isEmpty(Object value) {

if (value == null) { return (true); } else if ((value instanceof String) &&
(((String) value).trim().length() < 1)) { return (true); } } else if (value.getClass().isArray()) {
if (0 == java.lang.reflect.Array.getLength(value)) { return (true); }
} else if (value instanceof List) {
if (((List) value).isEmpty()) { return (true); } }
}
return (false);
}

Where we trim the value before examining the length of it: (((String)
value).trim().length(), so a lot of space will not be a valid value.

Thanks.
Description
We had an issue with UIInput type components regarding validation. If the user entered a lot of spaces in the Input field, the UIInput validator accepted the value as "filled out". We suggest to change the isEmpty function in the javax.faces.component.UIInput class to:
private static boolean isEmpty(Object value) {
if (value == null) { return (true); } else if ((value instanceof String) &&
(((String) value).trim().length() < 1)) { return (true); } } else if (value.getClass().isArray()) {
if (0 == java.lang.reflect.Array.getLength(value)) { return (true); }
} else if (value instanceof List) {
if (((List) value).isEmpty()) { return (true); } }
}
return (false);
}
Where we trim the value before examining the length of it: (((String) value).trim().length(), so a lot of space will not be a valid value. Thanks.
Show »






[JAVASERVERFACES_SPEC_PUBLIC-913] Unlabeled Navigation in HTML_BASIC RenderKit Docs Created: 30/Nov/10  Updated: 17/Dec/13

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

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

Status Whiteboard:

size_small importance_small

Tags:
Participants: rogerk

 Description   

The navigation left-hand frame does not label the values as "family" and "renderer type". Some kind of label is needed so that the reader understands that the documentation is organized as a breakdown of Renderers which are denotes not only by a string value called a Renderer Type but another string value called a Component Family. It is difficult enough to figure out what the purpose of component family is and conceptualize a use case. Also, for one new to JSF it is not intuitive what this documentation should be used for. The newbie JSF developer is going to be focused on JSF tags and that is not what is covered by these docs per se. Per the Faces config schema a renderer is denoted by a renderer type, component family and an implementation class. I do not see a a correlation to this in the docs. If one clicks on a particular rendered link, there is nothing on the page which even mentioned the name of the renderer. This documentation set, which is really cool that its auto-generated, and probably accurate and detailed, is not providing the value that is needed for the developer. If the automated tempaltes/tools can be changed to fix some of the labeling problems and if a human can write an overview page which comes up first I think it would remedy the issue.
matthew.stevens@sun.com 2004-02-16






[JAVASERVERFACES_SPEC_PUBLIC-912] FacesMessage.Severity should be Serializable Created: 15/Nov/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 912
Status Whiteboard:

size_small importance_medium

Tags:
Participants: Ed Burns and ramiromagalhaes

 Description   

A DESCRIPTION OF THE REQUEST :
FacesMessage.Severity is a typesafe enumeration with the meaning to describe the
severity of an error message displayed using JSF. As a typesafe enumeration, it
is basically a simple class reference without any transient meaning. This class
is unfortunately not serializable.

JUSTIFICATION :
In order to create error pages which contain jsf style error descriptions (a
summary, a detail, and a severity), it can be clever to add a FacesMessage as a
managed bean with e.g. session scope. As such, it will fail a web session to be
serialized e.g. in failover or server redeployment situations.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Make it serializable. Implement FacesMessage.Severity.readResolve as described
in Joshua Bloch, Effective Java Programming Language Guide, 2001, Addison
Wesley, Item 21.

CUSTOMER SUBMITTED WORKAROUND :
Store two strings regarding the error description. Hardcode or otherwise encode
the severity.

(Due to the construction of FacesMessage, you cannot instantiate it with a null
Severity field without encountering a NPE)

      • (#1 of 1): 2005-09-20 22:30:34 EDT girish.manwani@sun.com


 Comments   
Comment by ramiromagalhaes [ 14/Apr/11 09:49 AM ]

This is a duplication of JAVASERVERFACES_SPEC_PUBLIC-921.

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-910] Can't render a multiline <selectone_radio/> or <selectmany_c.b.l/> Created: 15/Nov/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 910
Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns and rogerk

 Description   

Name: gm110360 Date: 03/17/2004

A DESCRIPTION OF THE REQUEST :
It would be nice to "wrap" a radio list or checkbox list when using a
<selectone_radio/> tag or <selectmany_checkboxlist/> tag.

I mean: when the collection binded to <selectitems/> is too large, we could ask
to the renderer to render it on more than one line.

JUSTIFICATION :
Better presentation of large collection of radio or checkbox lists

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
(o) Item 1 (o) Item 2 (o) Item 3
(o) Item 4 (o) Item 5 (o) Item 6
...
(o) Item n-1 (o) Item n

with, for example, another attribute: <selectone_radio rows="4">...</>
ACTUAL -
(o) Item 1 (o) Item 2 (o) Item 3 ... (o) Item n-1 (o) Item n

---------- BEGIN SOURCE ----------
<h:selectmany_checkboxlist id="complications" layout="LINE_DIRECTION">
<f:selectitem itemLabel="Aucune" itemValue="0"/>
<f:selectitem itemLabel="D�c�s" itemValue="1"/>
<f:selectitem itemLabel="Infarctus Q" itemValue="2"/>
<f:selectitem itemLabel="Infarctus non-Q" itemValue="3"/>
<f:selectitem itemLabel="PAC urgent" itemValue="4"/>
<f:selectitem itemLabel="R�occlusion" itemValue="5"/>
<f:selectitem itemLabel="H�matome inguinal" itemValue="6"/>
<f:selectitem itemLabel="Dissection iliof�morale" itemValue="7"/>
<f:selectitem itemLabel="Pseudoan�vrysme" itemValue="8"/>
<f:selectitem itemLabel="Fistule AV f�morale" itemValue="9"/>
<f:selectitem itemLabel="Atteinte crurale" itemValue="10"/>
<f:selectitem itemLabel="R�paration vasculaire" itemValue="11"/>
<f:selectitem itemLabel="H�morragie" itemValue="12"/>
<f:selectitem itemLabel="AVC" itemValue="13"/>
<f:selectitem itemLabel="Transfusion" itemValue="14"/>
<f:selectitem itemLabel="R�action anaphylactique" itemValue="15"/>
<f:selectitem itemLabel="FV" itemValue="16"/>
<f:selectitem itemLabel="Infection" itemValue="17"/>
<f:selectitem itemLabel="OAP" itemValue="18"/>
<f:selectitem itemLabel="D�collement p�ricarde" itemValue="19"/>
</h:selectmany_checkboxlist>

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
May use <selectone_menu/> or a <selectmany_menu/> tag instead (but is slower to
do in some cases)

May also use 'layout="PAGE_DIRECTION"', but not always beautiful

I may write another component too (but is time-consuming & use of a non-standard
component)
(Incident Review ID: 240440)
======================================================================



 Comments   
Comment by rogerk [ 16/Nov/10 08:05 AM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-909] I18N - improve case where locale info is dropped using redirect or GET request Created: 15/Nov/10  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Lifecycle
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.3

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

Operating System: All
Platform: Sun


Issuezilla Id: 909
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns and sheetalv

 Description   

Craig and Peter can provide more information - this was seen as part
of using creator by customers using i18n features and multiple locales.

For JSF, the architectural issue is that the locale selected by the
user (or the application) is dropped under two circumstances:

  • When a redirect is used to navigate from one page to another
  • When a GET request is used (such as when you use the
    "Bookmarkable URLs" technique

for creator, what is needed is to support changing the locale at runtime for
the whole user-session (i.e. all user-pages) out-of-the-box. It seems
that this is currently not supported if the application
has multiple pages and redirects are used between page-transitions.

      • (#1 of 1): 2006-05-03 12:00:21 EDT ken.frank@sun.com

Taken over from CR6421300



 Comments   
Comment by sheetalv [ 16/Nov/10 01:53 PM ]

target

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-908] StylesheetRenderer RenderKit Docs Request Path Rendering Created: 05/Nov/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 908
Status Whiteboard:

size_small importance_medium

Tags:
Participants: rogerk

 Description   

The renderkit docs specify StykesheetRenderer directly renders the request path
gotten from Resource.getRequestPath(), when it should pass through
ExternalContext.encodeResourceURL() taking into account portlets.
the change has been done in implemetation (Mojarra) see:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1860



 Comments   
Comment by rogerk [ 05/Nov/10 11:57 AM ]

triage

Comment by rogerk [ 16/Nov/10 01:04 PM ]

triage





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

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

Type: Improvement Priority: Critical
Reporter: mwessendorf Assignee: Unassigned
Resolution: Unresolved Votes: 5
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

Tags:
Participants: mwessendorf, rogerk and werpu

 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 01:06 AM ]

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 01:26 AM ]

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 02:35 AM ]

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 06:33 AM ]

triage

Comment by rogerk [ 16/Nov/10 01:03 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-903] ResponseWriter markup enhancements Created: 29/Oct/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 903
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, kellerapps and rogerk

 Description   

Make the ResponseWriter responsible for ensuring the proper xmlns declarations are sent to the user
agent.



 Comments   
Comment by Ed Burns [ 29/Oct/10 09:31 AM ]

2.2

Comment by rogerk [ 16/Nov/10 08:05 AM ]

triage

Comment by kellerapps [ 18/Apr/11 12:56 PM ]

JSF components should support safe HTML. gwt recently added this. Should this be a separate issue?





[JAVASERVERFACES_SPEC_PUBLIC-902] ViewDeclarationLanguage selection enhancements Created: 29/Oct/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 902
Status Whiteboard:

size_large importance_medium

Tags:
Participants: Ed Burns

 Description   

Leonardo had suggested an elaborate XML syntax for VDL selection in http://lists.jboss.org/pipermail/jsr-
314-open-mirror/2010-October/000456.html. It's clear that we need something in this space, but not
clear what the best idea is.



 Comments   
Comment by Ed Burns [ 29/Oct/10 09:23 AM ]

target 2.2

Comment by Ed Burns [ 03/Nov/10 02:10 PM ]

There is some useful content on this issue at https://javaserverfaces.dev.java.net/issues/show_bug.cgi?
id=747





[JAVASERVERFACES_SPEC_PUBLIC-897] New getSessionId() for ExternalContext Created: 15/Oct/10  Updated: 17/Dec/13

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

Type: Bug Priority: Major
Reporter: nick_belaevski Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 897
Status Whiteboard:

size_small importance_small

Tags:
Participants: Ed Burns, nick_belaevski and rogerk

 Description   

Please add getSessionId() method for ExternalContext. It's useful to provide
session handling for Flash-based components.



 Comments   
Comment by rogerk [ 27/Oct/10 02:42 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-894] allow to specify default value for h:message(s) errorClass etc. in MessageBundle Created: 14/Oct/10  Updated: 17/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Validation/Conversion
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: domdorn Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 894
Status Whiteboard:

size_small importance_medium

Tags:
Participants: domdorn and Ed Burns

 Description   

h:message and h:messages define errorClass, infoClass etc. attributes.
To have a common look and feel in the whole webapplication, the developer
currently has to specify these attributes on each occurrence of the tag in the
view or create a custom component that wraps h:message(s)

It should be possible to define a default value for
errorClass, infoClass etc. through MessageBundles like its possible
to override converter/validation messages.

As far as I've looked into this, it would simply require the
com/sun/faces/MessageRenderer (or other impls) to first lookup the key in the
MessageBundle.



 Comments   
Comment by Ed Burns [ 14/Oct/10 08:19 AM ]

This is another good one. I like it.





[JAVASERVERFACES_SPEC_PUBLIC-892] ui:repeat requires document "begin" and "end" properties Created: 12/Oct/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 892
Status Whiteboard:

size_small importance_medium

Tags:
Participants: lu4242 and rogerk

 Description   

It was notice that ui:repeat implementation has "begin" and "end" properties,
but there are not mentioned in the javadoc.

After talk with Martin Marinschek, the conclusion was this is an undocumented
feature, but it is provided by Mojarra.



 Comments   
Comment by rogerk [ 27/Oct/10 02:39 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-891] converter and validator attributes TLD doc misleading Created: 07/Oct/10  Updated: 17/Dec/13

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

Type: Bug Priority: Major
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 891
Status Whiteboard:

size_small importance_medium

Tags:
Participants: Hanspeter Duennenberger and rogerk

 Description   

UIOutput converter attribute allows assigning a literal to specify the
converterId of the converter to be used or a ValueExpression evaluating to an
instance of Converter.
TLD doc only mentions the ValueExpression as allowed type and also the
Description does not mention the possibility to pass the converterId.

The same is missing for validator attributes on input components - TLD doc only
mentions teh MethodExpression but says nothing about the literal validatorId
that can be used too.



 Comments   
Comment by rogerk [ 27/Oct/10 02:39 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-889] <ui:repeat> inner variable can't be transmitted to a composite. Created: 26/Sep/10  Updated: 17/Dec/13

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

Type: Bug Priority: Major
Reporter: grunt2000 Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 889
Status Whiteboard:

size_medium importance_small

Tags:
Participants: grunt2000 and rogerk

 Description   

This source code based on a <c:forEach> loop is able to work:

<c:forEach var="adresse" items="#{assoCtrl.association.adresses}">
<territoire:adresse adresse="#{adresse}" />
</c:forEach>


But this one, based on an <ui:repeat> loop, fails:

<ui:repeat var="adresse" value="#{assoCtrl.association.adresses}">
<territoire:adresse adresse="#{adresse}" />
</ui:repeat>

This message is received:
"<territoire:adresse> The following attribute(s) are required, but no values
have been supplied for them: adresse. "


As a test, I changed the content of my loop that way:
<ui:repeat var="adresse" value="#{assoCtrl.association.adresses}">
<!-- The address content is: #{adresse} -->
</ui:repeat>

And found that the HTML page is displayed, no Exception thrown by JSF 2.0.3
then. (I see that content on the HTML page that is created: <!-- The address
content is: Adresse [nom: , complément de nom: null, complément de voie: null,
voie: , code postal: 00000, ville: , pays: France, commentaire: null, types
adresse: []] -->).

Therefore, I think that the transmission of the var parameter of <ui:repeat> is
faulty when an inner composite is targeted. I made some tries by promoting the
value part of <ui:repeat> to various scopes, but without success.

Regards,
Grunt.



 Comments   
Comment by rogerk [ 27/Oct/10 02:38 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:02 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-888] UIInput.submittedValue returns Object, but Converter suggest only String is allowed Created: 23/Sep/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 888
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, lu4242 and rogerk

 Description   

The current conversion model is not good enough on some cases when it
is required the submitted value be something different than String, or on
more complex components that requires to send information from multiple html
"input" components.
This issue has been discussed earlier on myfaces list, as you can
see on the comments at the end of this mail:

To understand what's missing, I'll resume how the current conversion model
works. This could be redundant, but the intention is expose the reasons about
why it is wanted to extend the current model in a understandable way.

Every component that is used as a input has at least one "value binding" to a
bean. In UIInput, the user just set "value" property with an EL expression to
indicate that the value sent should be assigned to that expression.

Now suppose a form with this component that is submitted. The input component
should first create the "submittedValue" from the information available on
request parameter map. This is done on UIComponent or Renderer decode() method.
Then, this value is converted to the type required by the "value binding",
through Converter interface and later, if conversion fails by some reason, the
information stored on "submittedValue" will be used to render the component later.

Therefore, "submittedValue" must satisfy three conditions:

1. It should contain all info sent by the component through request parameter
map, otherwise the renderer will not be able to render the component correctly.
2. It should be on a way that can be converted to the type indicated by "value
binding", that means the submittedValue type should be a public class, so the
renderer can instantiate it and conversion model can process it.
3. The component should be responsible to define the type used by submitted
value, according to its needs.

Now, let's take a look at the current Converter interface:

public interface Converter

{ /** * used to map the submittedValue to the "value binding". */ Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException; /** * used to convert the "value binding" into a String to be used * on the renderer. */ String getAsString(FacesContext context, UIComponent component, Object value) throws ConverterException; }

Note that JSF provide some converters for the most common types, so the user can
specify which converter use or let JSF decide which one fits best, using
the converters registered with "forClass" mapping. Yes, that's ok, but only for
components with only one "<input>". In that case, assume String as submitted
value type looks better and keep things simple.

Things start to get confusing when you see the signature of
UIInput.getSubmittedValue():

public Object getSubmittedValue()

Does the conversion model did not make the assumption that String is the only
type to be used by submittedValue?

But this assumption fails when a more complex component is required. The typical
example is a component that handles date/time values. In that case, the
date/time value can be decomposed into its elements (year, month, day, hour,
minutes ....). In this case, a component developer could want to send all that
info into multiple "<input>" parameters through request parameter map. So, to
use the model proposed, all that information should be used to encode a String,
just to later decode it on the converter used to construct the "value binding"
required, but later it will be decoded/encoded by the renderer again to render
the component.

The proposal to put into consideration is do the following modifications on jsf:

  • Add a class called BusinessConverter (maybe you can find other name but for
    now let it as is) :

public interface BusinessConverter

{ public Object getBusinessValue(FacesContext context, UIComponent component, Object submittedValue); public Object getAsSubmittedValue(FacesContext context, UIComponent component, Object value); }

Really is similar to Converter interface but does not force submittedValue to be
String, instead it lets it open.

  • Add the following methods to Application class :

public abstract void addBusinessConverter(Class<?> submittedClass,
Class<?> targetClass,
String converterClass);

public abstract void addBusinessConverter(String businessConverterId,
String businessConverterClass);

public abstract Converter createBusinessConverter(Class<?> submittedClass,
Class<?> targetClass);

public abstract Converter createBusinessConverter(String businessConverterId);

public abstract Iterator<String> getBusinessConverterIds();

public abstract Iterator<Class<?>> getBusinessConverterTypes(Class<?>
submittedClass);

Again, it is similar to converter methods on Application class, but in this case
it takes into consideration the submittedClass. Therefore, a component that
define as submittedClass java.util.Date, could retrieve the converters that can
handle this conversion. From some point of view, the current Converter interface
is a particular case when submittedClass is java.lang.String.

  • Add the following methods to UIOutput class :

public BusinessConverter getBusinessConverter();

public void setBusinessConverter(BusinessConverter converter);

/**

  • Return the value type the submitted value will take on
  • decode() method. In my opinion, allow just one submittedValueType is
  • enough.
    */
    public Class<?> getSubmittedValueClass();

The idea is provide a way to configure business converter, just like Converter.
Note this implies change some stuff on UIInput too.

  • Add an annotation @FacesBusinessConverter.
  • Add a component f:businessConverter in the same way as f:converter.

I would like to put into consideration this idea. My personal opinion is this
should be included at the spec level for two reasons:

  • It is clear there is a contradiction between UIInput.getSubmittedValue() and
    Converter interface.
  • It could be good to have a common repository for business converters, and use
    JSF annotations to register it.

I have some code I'm working but it is better to know if you think it is worth
or not before continue. If it is necessary I can help with the implementation.

Suggestions are welcome

best regards,

Leonardo Uribe

Note: As an historical comment, currently, Trinidad has a workaround for handle
handle "oracle types", from the binding layer, using an interfaces called
TypedConverter as you can see below:

package org.apache.myfaces.trinidadinternal.convert;

public interface TypeConverter

{ /** * converts the given Object into an instance of the * targetType. * @return an instance of the targetType. */ Object convert(Object source, Class<?> targetType); }

The idea behind this interface is provide a way that trinidad can "understand"
specific types and include them when are resolved, but note this class is not
part of trinidad api. The reason is this is just an internal workaround.

COMMENTS FROM OTHER PEOPLE SUPPORTING THIS ISSUE:

Martin Koci

MK>> maybe this is a stupid question but:
MK>>
MK>> >From UIInput javadoc:
MK>>
MK>> ... decoded value of this component, usually but >>>not necessarily a
MK>> String<<<, must be stored - but not yet converted - using
MK>> setSubmittedValue() ....
MK>>
MK>> from UIInput.getConvertedValue:
MK>>
MK>> ... and the submitted value is a >>>String<<<, locate a Converter as
MK>> follows
MK>>
MK>> Question: why is Converter tied only to String? Whole specification
MK>> speaks about submitted value as of "raw representation of value from
MK>> client" but not necessarily String. And 3.3 Conversion Model: "This
MK>> section describes the facilities provided by JavaServer Faces to support
MK>> type conversion between server-side Java objects and their (typically
MK>> String-based) representation in presentation markup."
MK>> But Converter.getAsObject expects only String as this "raw
MK>> representation" and "typically String-based" formulation from spec now
MK>> means "always String-based".
MK>> It seems to me that Converter introduces unnecessary dependency on
MK>> String-based representation - even ResponseWriter.write* accepts
MK>> java.lang.Object as value ....
MK>>
MK>> What I try to do is JSF-based server view with custom NOT-string based
MK>> protocol where "raw representations from client" can be java object like
MK>> Integer or more complex. Creating of:
MK>>
MK>> interface Converter2 { MK>> Object getAsObject(FacesContext,UIComponent,Object) MK>> Object getAsRepresentation(FacesContext,UIComponent,Object) MK>> }
MK>>
MK>> solves my problem but I must reprogram significant part of JSF api.

Martin Marinschek

MM>> MK>> So on JSF level conversion String <-> Object is unable to solve this
MM>> MK>> problem - I simply need Object <-> Object conversion which is not
MM>> MK>> supported yet.
MM>>
MM>> Yes, this is true - this is obviously a spec problem.
MM>>
MM>> If the submitted value is an object, it should also be allowed to
MM>> convert it. A converter is more than just a string to object (and
MM>> back) converter, it is an artefact which transforms information from
MM>> its representation for output (and this output could be anything, and
MM>> certainly doesn't have to be string based) to its representation which
MM>> the business model (or also an artefact within JSF, like a validator)
MM>> understands.
MM>>
MM>> So I agree. This hasn't come up so far cause nobody uses non string
MM>> based output models for JSF.
MM>>
MM>> Note that my notion of a business converter (discussed on this mailing
MM>> list a while ago) for converting between a business model
MM>> representation and a representation in a JSF artefact like the
MM>> renderer (e.g. you use joda.Date in the business model, but the JSF
MM>> date picker renderer only understands the normal java date) is also
MM>> hinting in the direction that such an additional converter API would
MM>> be necessary. I discussed this with the EG (and also Ed privately),
MM>> and there wasn't much interest for adding this.



 Comments   
Comment by Ed Burns [ 19/Oct/10 01:15 PM ]

Target for 2.2.

Comment by rogerk [ 27/Oct/10 02:47 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:02 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-882] Specification talks about non existing APIs Created: 09/Sep/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 882
Status Whiteboard:

size_small importance_medium

Tags:
Participants: mwessendorf and rogerk

 Description   

I opened this version of the spec:

Version: 2.0 Rev A
Status: Final Release
Release: 9 July 2010

It talks about FacesContext.isPartialRequest() - Note this method does not
exist. A similar is available on PartialViewContext.

Also it talks about FacesContext.isAjaxRequest() AND
PartialViewContext.isAjaxRequest() - Note: the first one does not exist as well



 Comments   
Comment by mwessendorf [ 09/Sep/10 05:50 AM ]

Also from reading the PartialViewContext JAvaDoc it is not clear (to me) what
the main difference is between the two.

Comment by rogerk [ 27/Oct/10 02:37 PM ]

triage - partially fixed





[JAVASERVERFACES_SPEC_PUBLIC-879] Decoder that act as separate functionality Created: 29/Aug/10  Updated: 19/Dec/13

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

Type: Improvement Priority: Critical
Reporter: vladperl Assignee: Unassigned
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 879
Status Whiteboard:

size_large importance_large draft

Tags:
Participants: rogerk and vladperl

 Description   

I suggest to introduce concept of decoders as functionality that works
independently from rendering functionality. JSF already has dedicated Renderer
class. So it makes sense to do the same thing for decoding functionality.
The first benefit from this approach would be possibility to send data from
client directly to decoder, skipping on the way to it necessity to use JSF
components and JSF life cycle. JSF developers will be able to create more
stateless JSF applications and use Javascript libraries in more flexible than
now manner.

The first usage of decoder would be the following kind of scenario:

client side:
jsf.ajax.post({data:{'dataHolder.value': value1}, render: 'input1');

server side:
if (isDataRequest(context.getExternalContext().getRequestHeaderMap())) { Decoder.handleDataRequest(context); context.responseComplete(); }

...
ValueExpression ve = getValueExpression(context, key);
ve.setValue(context.getELContext(), o.get(key));
...

Note: The first argument of the method "post" would be optional and called "url".
In case if developer need to customize handling of data from client we will use
this argument as way to identify decoder that will handle the data.

Complete signature of the Javascript method could be defined something like this:
jsf.ajax.post([url], [data], [handleAs], [render], [onSuccess(data)],
onError(data)]);



 Comments   
Comment by vladperl [ 29/Aug/10 08:38 PM ]

The following link seems could be used as supporting point:
http://forums.java.net/jive/thread.jspa?messageID=481227

Comment by rogerk [ 27/Oct/10 02:35 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:02 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-877] allow declarative configuration of ELContextListener in faces-config Created: 19/Aug/10  Updated: 19/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Configuration/Bootstrapping
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: manuelbernhardt Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 877
Status Whiteboard:

size_small importance_small

Tags:
Participants: manuelbernhardt and rogerk

 Description   

Currently the only way of registering an ELContextListener seems to be programmatically via
Application#addELContextListener().

It would be interesting to allow declarative configuration via a key (e.g. el-context-resolver) in the
<application> section of the faces-config schema.



 Comments   
Comment by rogerk [ 27/Oct/10 02:34 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:02 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-875] Add Facelets attribute to limit EL scope to explicitly declared parameters Created: 13/Aug/10  Updated: 19/Dec/13

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 875
Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns and rogerk

 Description   

>>>>> On Mon, 09 Aug 2010 21:08:00 -0400, Ryan de Laplante said:

R> It would be nice have a new attribute on ui:composition and ui:decorate
R> that tells it to NOT allow the template have access to the global EL
R> context. Instead, only the ui:insert and ui:param values within the
R> ui:composition or ui:decorate would be accessible to the template.
R> This I would enable me to allow my customers to input their own facelet
R> templates from the web UI of the SaaS application.



 Comments   
Comment by rogerk [ 13/Aug/10 11:40 AM ]

eval

Comment by rogerk [ 27/Oct/10 02:33 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:01 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-874] Clarify Executing Element Id In Ajax Request Created: 05/Aug/10  Updated: 19/Dec/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 0
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

Tags:
Participants: rogerk and werpu12

 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 08:08 AM ]

Evaluate

Comment by rogerk [ 27/Aug/10 06:13 AM ]

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

Comment by rogerk [ 16/Nov/10 01:01 PM ]

triage

Comment by werpu12 [ 06/Mar/12 03:15 PM ]

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.





[JAVASERVERFACES_SPEC_PUBLIC-873] Add pre and post ajax transaction function callbacks Created: 03/Aug/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 873
Status Whiteboard:

size_small importance_medium

Tags:
Participants: Ed Burns and rogerk

 Description   

Use case: say the user wants to use some effect to fade in/out the content to be updated via Ajax. It
would be nice to have a way to install pre-request and post request callback functions. On the post
request, we need to have actually two functions. One when we have the response but have not yet done
the replacement, and another after we have done the replacement.



 Comments   
Comment by rogerk [ 27/Oct/10 02:32 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:00 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-872] The View Metadata tag is not processed unless at least one <f:viewParam> is defined Created: 29/Jul/10  Updated: 19/Dec/13

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

Type: Bug Priority: Critical
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Unresolved Votes: 5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 872
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: arjan tijms, Ed Burns, lincolnbaxter and rogerk

 Description   

Section 2.2.1 of the JSF 2 spec requires that if no view-parameters exist in the
view-metadata, that the render response phase be invoked immediately following
the current phase on a GET request. This prevents custom metadata from being
provided that may require lifecycle processing (view-actions, for example.)

This is a hindrance to creating custom metadata-since even if a tool (such as
prettyfaces) wishes to add custom url-parameter handling (or custom action
invocation), it must also add an empty view-param in order to trigger the
lifecycle. Also, not many people expect this behavior, since it is relatively
counter-intuitive.

I propose defining a new contract that would allow for individual meta-data
components to determine whether or not the full lifecycle should be invoked:

public interface ViewMetadata {
/**

  • If true, the full faces lifecycle will be invoked; if false, the
  • lifecycle will skip directly to render-response, unless another
  • {@link ViewMetadata} object requests that the lifecycle be executed.
    */
    public boolean requiresLifecycle();
    }

This new contract would still honor the behavior of previous implementations,
and should be mostly backwards compatible (because unless the custom tag
requests the lifecycle, it will still be skipped.)

The current spec verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. Call
ViewMetadata.getViewParameters(). If the result is a non-empty Collection, do
not call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."



 Comments   
Comment by lincolnbaxter [ 29/Jul/10 08:26 AM ]

I'd like to revise my proposal; I now oppose my original suggestion of adding a
new interface:

Solution:

It's possible we could just get away with changing the verbiage a little bit in
order to resolve this issue, thereby avoiding changes to any existing, or adding
any new APIs. (Note the **starred** change.) The change is very subtle, and
not very invasive, but perfectly addresses this situation.

The current spec verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. ***Call
ViewMetadata.getViewParameters()***. If the result is a non-empty Collection,
do not call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."

Proposed verbiage:

2.2.1 - "If the request is not a postback, try to obtain the
ViewDeclarationLanguage from the ViewHandler, for the current viewId. If no such
instance can be obtained, call facesContext.renderResponse(). Otherwise, call
getViewMetadata() on the ViewDeclarationLanguage instance. If the result is
non-null, call createViewMetadata() on the ViewMetadata instance. ***Call
ViewMetadata.getChildren()***. If the result is a non-empty Collection, do not
call facesContext.renderResponse(), otherwise do call
facesContext.renderResponse(). If it turns out that the previous call to
createViewMetadata() did not create a UIViewRoot instance, call createView() on
the ViewHandler. Call renderResponse() on the FacesContext."

Comment by rogerk [ 27/Oct/10 02:32 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

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

Comment by arjan tijms [ 20/Mar/13 03:56 PM ]

I think this is an exact duplicate of JAVASERVERFACES_SPEC_PUBLIC-762.





[JAVASERVERFACES_SPEC_PUBLIC-871] Need events before and after the entire JSF lifecycle processing Created: 26/Jul/10  Updated: 19/Dec/13

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

Type: Improvement Priority: Major
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 871
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, lincolnbaxter and rogerk

 Description   

In order to facilitate custom contexts and other extensions, it would be helpful
if there were events to mark the beginning and end of the JSF lifecycle.

PreExecuteLifecycleEvent
PostExecuteLifecycleEvent

This would enable bean/transaction/security creating/interception at a time that
is independent of phase listeners, which present ordering problems when users
create custom phase listeners, and also cause issues when dealing with exception
handling, since exception handlers are created outside of the faces lifecycle:

https://jira.jboss.org/browse/SEAMFACES-42



 Comments   
Comment by rogerk [ 27/Oct/10 02:29 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-870] Need a PreNavigate system event Created: 26/Jul/10  Updated: 19/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Navigation
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC


Issuezilla Id: 870
Status Whiteboard:

size_medium importance_small

Tags:
Participants: lincolnbaxter and rogerk

 Description   

In order to properly intercept and extend navigation, it would be helpful to
have a PreNavigateEvent that included the current target navigation case (as
returned by:

public abstract NavigationCase getNavigationCase(FacesContext context, String
fromAction, String outcome);

public class PreNavigateEvent extends SystemEvent
{
public NavigationCase getNavigationCase() {...}
}



 Comments   
Comment by rogerk [ 27/Oct/10 02:28 PM ]

triage

Comment by rogerk [ 16/Nov/10 01:00 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-865] Ajax inside a DataTable (getClientId append rowIndex) Created: 10/Jul/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 865
Status Whiteboard:

size_medium importance_large draft

Tags:
Participants: cipriandobra, lu4242 and rogerk

 Description   

Comments from [jsr-314-open] Ajax inside a DataTable:

Cagatay Civici

I've faced with an issue in our app I'd like to share when trying to update the
datatable itself from a command element located inside a column. Case is to
select a row, execute logic and update the datatable. Basic code:

<h:dataTable id="cars" var="car" value="#{tableBean.carsSmall}">
<h:column>
<f:facet name="header">
Model
</f:facet>
<h:outputText value="#{car.model}" />
</h:column>

<h:column>
<f:facet name="header">
Action
</f:facet>
<h:commandButton value="Some Action"
actionListener="#{tableBean.handleRowAction(car)}">
<f:ajax render="cars" />
</h:commandButton>
</h:column>
</h:dataTable>

As datatable has a rowIndex >= 0 during rendering of commandButton f:ajax
defines the component id to render as cars:{rowIndex} where I should expect
"cars" only. This is due to UIData.getClientId implementation as UIData
adds rowIndex for unique row ids. This causes an issue with a nested f:ajax case.

Andy Schwartz

Ids specified by <f:ajax> are relative to containing component - in this case,
relative to the <h:commandButton>. This makes is easy to specify
execute/render ids for components within the same NamingContainer (which is by
far the most common case). In the case of iterating components like
<h:dataTable> or <ui:repeat>, this means that execute/render ids refer to
components within the same row.

There is a way out of this... You can specify an absolute id by prefixing the id
with ":". At that point the id starts from the root of the component tree and
you can specify any number of colon-separated segments to descend into each
naming container. (This matches the syntax used by findComponent().)

Of course, specifying absolute paths is at a minimum difficult, and in some
cases, just plain impossible to do (eg. when reusing content across multiple
pages). In Trinidad we use a double-colon prefix ("::") to reference up one
level in the NamingContainer hierarchy - similar to ".." in file system paths.
I suggested exposing this when we were working on the <f:ajax> spec, but this
topic got shelved until 2.1.

Dan has captured some of our thinking here:

http://seamframework.org/Documentation/JSF21#H-ReevaluateComponentReferencingMechanismP2

More here:

http://seamframework.org/Documentation/JSFEnhancementComponentReferencing

Oh, and... for the particular use case that you describe above, I think that it
is very important that the JSF implementations give some warning when a
referenced component is not found, at least when running in development project
stage. Not sure which implementation you are testing, but it might make sense
to log bugs against MyFaces/Mojarra if this is failing silently in development mode.

Martin Marinschek

> Ids specified by <f:ajax> are relative to containing component - in this
> case, relative to the <h:commandButton>. This makes is easy to specify
> execute/render ids for components within the same NamingContainer (which is
> by far the most common case). In the case of iterating components like
> <h:dataTable> or <ui:repeat>, this means that execute/render ids refer to
> components within the same row.

Yes, but what Cagatay totally correctly refers to is that the table is
certainly not in a row - how can the table be in a row of itself? This
is semantical nonsense.

We should never include the row-index in the client-id of the table
itself. For this, we need to revise the client-id generation
algorithm.

Without actually having tried it, I think that it is easy to do so, as
we have a UIComponentBase.getContainerClientId() to create the
client-id of the children - when this method is called, we append the
row-index, if getClientId() itself is called, we don´t. Does this
sound reasonable to you guys?

I think we can regard this as an implementation bug - Catagay, can you
open issues for Mojarra and MyFaces?

Leonardo Uribe

I just want to note a side effect of this change: getContainerClientId() was
introduced
in jsf 1.2, but code written in jsf 1.1 uses getClientId(). If we apply this change,
all libraries for jsf 1.2 needs to be updated. I think we can do this for jsf
2.0 but my
question is if we should apply this change on jsf 1.2 branch. Components written for
jsf 1.1 that extends from UIData will not work correctly with this change.

Martin Marinscheck

> Components
> written for
> jsf 1.1 that extends from UIData will not work correctly with this change.

ah, well - if they override the UIData functionality. Yes, you are
right. Well, not sure how we should handle this properly. Maybe we
should leave this for 2.0.

Andy Schwartz

Yes, but what Cagatay totally correctly refers to is that the table is
certainly not in a row - how can the table be in a row of itself? This
is semantical nonsense.

Ugh, yes, of course. For a moment there it slipped my mind that the UIData
component is indeed found as part of the relative id search. I was thinking
that only the stamped components would be considered valid execute/render
targets when a row index is set. But, since we spec'ed findComponent()
semantics for execute/render, the UIData would indeed be found, and, yes, we
should use the correct client id.

Leonardo Uribe

Added issue on myfaces:

MYFACES-2744 UIData.getClientId() should not append rowIndex, instead use
UIData.getContainerClientId()



 Comments   
Comment by rogerk [ 13/Jul/10 04:01 PM ]

triaged

Comment by rogerk [ 16/Nov/10 01:00 PM ]

triage

Comment by cipriandobra [ 11/Aug/11 05:25 PM ]

A simple workaround is to place the dataTable inside a h:panelGroup and use its id.





[JAVASERVERFACES_SPEC_PUBLIC-864] ExceptionHandler.getRootCause() should use isAssignableFrom() Created: 08/Jul/10  Updated: 19/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Uncategorized
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Bug Priority: Major
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: https://issues.apache.org/jira/browse/MYFACES-2796


Issuezilla Id: 864
Status Whiteboard:

size_small importance_small

Tags:
Participants: Jakob Korherr and rogerk

 Description   

The spec (javadoc) of ExceptionHandler.getRootCause() currently says the
following: "Unwrap the argument t until the unwrapping encounters an Object
whose getClass() is not equal to FacesException.class or
javax.el.ELException.class. If there is no root cause, null is returned."

I think instead of checking for equals() we should check for isAssignableFrom(),
because there are a lot of sub-classes (especially for ELException), which
should also be unwrapped.

See also the related MyFaces-issue at
https://issues.apache.org/jira/browse/MYFACES-2796



 Comments   
Comment by rogerk [ 27/Oct/10 02:28 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-861] Portlets + ajax API Created: 30/Jun/10  Updated: 19/Dec/13

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

Type: Bug Priority: Major
Reporter: werpu12 Assignee: Unassigned
Resolution: Unresolved Votes: 4
Σ Remaining Estimate: 1 week, 3 days Remaining Estimate: 1 week, 3 days
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: 1 week, 3 days Original Estimate: 1 week, 3 days
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1069 Portlet incompatibilities with jsf.js Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-966 Make finding components involved by <... Sub-task Open  
Issuezilla Id: 861
Status Whiteboard:

size_small importance_large

Tags:
Participants: ganeshpuri, rogerk, tedgoddard and werpu12

 Description   

Currently there is no clean standardized way to detect a portlet szenario for
the ajax apis and the attached scripts.
The main difference is as far as I know how the portlets are handled that we
have an identifier on the element identifying the portlets viewroot.

We need a publc api which allows to detect the portlet identifier so that
further processing is eased.
Also the apis have to be checked if they are portlet szenario save in their
specifications (which they probably are as soon as we have the portlet
identifier determination routine in).

Probably a public api like jsf.util.getViewRootId() suffices, which would under
normal szenarii return a "" and in a portlet scenario would return the root
identifier.



 Comments   
Comment by rogerk [ 30/Jun/10 07:30 AM ]

triage and target.

Comment by ganeshpuri [ 30/Jun/10 09:29 PM ]

Hi Werner,
Enhanced portlet support in JSF 2.1 would be extremely helpful. Do you have a
running JSF 2.0 + portlet scenario? Is the JSF 2.0 portlet bridge ready to run?
If we try to implement portlet features it would be helpful to be able to test
them
Best regards,
Ganesh

Comment by rogerk [ 01/Jul/10 12:04 PM ]

re-target

Comment by rogerk [ 01/Jul/10 12:05 PM ]

re-target

Comment by werpu12 [ 06/Jul/10 02:47 PM ]

I have not really a running scenario, I did some small prototying in this area a
while ago, after I checked what portlets do to a running applicaton, and it came
down to following issues:

a) First jsf.js or something else needs to allow a method to pass the viewRoot
identifier within a portlet szenario to the associated javascripts (I did an el
function to do that in my prototype, which then also was the root of a component
index, but that was already user space.

For convenience methods a functionality to get the client id of a component
within the current naiming container also is desireable (but not entirely
needed) that has been requested as far as I could see in another issue.

The biggest issue simply is on how to get the client identifier for your
viewRoot and the components so that you can adjust your jsf.ajax requests
accordingly and make subqueries on your portlet dom subtree.

The second issue which is really spec related is, how do you handle on protocol
level and on client side level, <updates> etc.. on head, body and viewroot in a
portlet scenario.

I am not sure if the portlet bridge really deals with that (I doubt it though),
because in case of render="@all" usually a update on ViewRoot is issued with
head and body replacement accordingly (which in case of the body replacement
definitely will destroy the portlet, in case of the head replacement not too
much will happen because only the javascrips will be evaluated anew)

But that might also be something which has to be covered within the portlet
bridge and an associated ppr response writer, which simply wont allow a viewroot
or body replacement.

Comment by rogerk [ 26/Aug/10 03:40 AM ]

triage

Comment by rogerk [ 16/Nov/10 01:00 PM ]

triage

Comment by tedgoddard [ 21/Apr/11 09:58 AM ]

This JIRA appears to describe an API for obtaining the javax.faces.ViewState. This would be very useful in a number of cases:

  • obtaining the ViewState key as a stable value during page rendering would allow it to be directly written into rendered output removing the need for post processing of the response (for server-side state saving only)
  • the ViewState key could be guaranteed to be made available to each form, fixing some Ajax and full page refresh interoperability bugs
  • the ViewState key could be used to implement View "scope" objects without making use of the ViewMap directly, given that the ViewMap is not available until after the UIViewRoot has been restored (for instance, handling bean values affecting ui:include would be simplified)




[JAVASERVERFACES_SPEC_PUBLIC-860] com.sun.faces literal string value in public FaceletContext public API Created: 29/Jun/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 860
Status Whiteboard:

size_small importance_small

Tags:
Participants: Ed Burns

 Description   

public abstract class FaceletContext extends ELContext {

// The key in the FacesContext attribute map
// for the FaceletContext instance.
public static final String FACELET_CONTEXT_KEY =
"com.sun.faces.facelets.FACELET_CONTEXT";



 Comments   
Comment by Ed Burns [ 29/Jun/10 12:09 PM ]

triage

Andy suggested a typesafe utility method.

I think that's too big for now, so I'll settle for just changing the value of the string and specifying that the
old value must be supported as well.

Comment by Ed Burns [ 30/Aug/10 12:11 PM ]

Move these to 2.2





[JAVASERVERFACES_SPEC_PUBLIC-821] ExternalContext.getRealPath() on startup and shutdown Created: 21/Jun/10  Updated: 19/Dec/13

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

Type: Bug Priority: Major
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-1009 Make it so ExternalContext.getRealPat... Closed
Issuezilla Id: 821
Status Whiteboard:

size_small importance_large

Tags:
Participants: Ed Burns and Jakob Korherr

 Description   

Looking at the methods which are valid to be called on application startup or
shutdown on ExternalContext, it seems like it was forgotten to include
getRealPath(String path), because all methods which are valid to be called only
rely on the ServletContext and this one also only relies on the ServletContext
(or on the PortletContext in a Portlet environment).

However since the behavior of all methods which are not documented as "valid to
call this method during application startup or shutdown" is undefined, it is
valid to implement this method also for startup and shutdown in JSF 2.0, but it
should be added in the spec javadoc that this one must be available for startup
and shutdown.



 Comments   
Comment by Ed Burns [ 22/Jun/10 09:02 PM ]

edburns

Comment by Ed Burns [ 22/Jun/10 09:45 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 10:35 PM ]

2.1

Comment by Ed Burns [ 24/Jun/10 02:41 PM ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 02:55 PM ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 12:11 PM ]

Move these to 2.2





[JAVASERVERFACES_SPEC_PUBLIC-820] Resolve Resource URLs in UIComponents Created: 20/Jun/10  Updated: 19/Dec/13

Status: Open
Project: javaserverfaces-spec-public
Component/s: Resources
Affects Version/s: 2.0
Fix Version/s: 2.3

Type: Improvement Priority: Major
Reporter: razib Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?messageID=395511


Issuezilla Id: 820
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, razib and rogerk

 Description   

The purpose of this enhancement request is to make it easier to reference
resource URLs in custom components.

In JSF 2, a great EL shortcut was introduced to get the url for resources using
the resource implicit object (e.g. #resource['/library/image.jpg']). But there
is no easy programmatic way of resolving resource URLs inside a custom
component. For example if an image resource lies inside
META-INF/resources/library/image.jpg, there is no convenient way of referencing
the path of the image when writing an "img" tag inside my UIComponent.

Ideally such method should exist in ResourceHandler and users can invoke it
using
facesContext.getApplication().getResourceHandler().getRequestPath("image.jpg","library"),
but resource handler has no such method to find a resource in META-INF/resources.

In lieu of this, you can do the following (Suggested by Ed Burns):

ResourceHandler rh = facesContext.getApplication.getResourceHandler();
Resource r = rh.createResource("image.jpg", "library");
rh.getRequestPath();

This would work, but it is not as nice as getResourceHandler().getRequestPath().

This will give Component developers some ease, especially when there are
implementing components that deal with javascript extensively.

Thanks.



 Comments   
Comment by razib [ 20/Jun/10 11:44 PM ]

This is an enhancement request.

Comment by Ed Burns [ 22/Jun/10 09:02 PM ]

edburns

Comment by Ed Burns [ 22/Jun/10 09:44 PM ]

triage

Comment by rogerk [ 27/Oct/10 02:25 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-819] add "disabled" attribute for h:button Created: 11/Jun/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 819
Status Whiteboard:

size_small importance_small

Tags:
Participants: Ed Burns and rogerk

 Description   

From issue 714:

  • VDLDocs for h:button don't mention a disabled attribute, but the h:link one does have the disabled
    attribute. My guess would be that both should have this attribute?


 Comments   
Comment by Ed Burns [ 11/Jun/10 08:23 PM ]

assign to sheetal

Comment by rogerk [ 27/Oct/10 02:25 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:36 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-816] ViewHandler.initView() called too late Created: 28/May/10  Updated: 19/Dec/13

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

Type: Bug Priority: Major
Reporter: michael_kurz Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 816
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, michael_kurz and rogerk

 Description   

In my examples I have a phase listener that outputs all request parameters . I
accidentially did this before restore view and got some strange behaviour. With
MyFaces 2.0, reading the request parameters before the restore view phase kills
german umlauts. This happens because the character encoding is calculated and
set in the request at the beginning of restore view but after the before phase
listeners are executed.

As this is not happening with Mojarra, I set a breakpoint in
ServletRequest.setCharacterEncoding and saw that they are setting this somewhere
at the beginning of the lifecycle.

The spec says the following about this problem:

*) Spec section 2.2.1: "The JSF implementation must perform the following tasks
during the Restore View phase of the request processing lifecycle: Call
initView() on the ViewHandler. This will set the character encoding properly for
this request. ....."

*) Spec section 7.5.1: "The initView() method must be called as the first method
in the implementation of the Restore View Phase of the request processing
lifecycle, immediately after checking for the existence of the FacesContext
parameter...."

In my understanding, the phase listeners belong to the lifecycle and not to the
phases. This would mean that according to the spec ViewHandler.initView() should
be called AFTER the invocation of the before phase listeners, which is too late.



 Comments   
Comment by Ed Burns [ 22/Jun/10 09:05 PM ]

sheetalv

Comment by rogerk [ 27/Oct/10 02:24 PM ]

triage

Comment by Ed Burns [ 06/Jun/11 05:34 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-810] Access to component ancestor chain during Facelets handler processing Created: 25/May/10  Updated: 19/Dec/13

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

Type: Improvement Priority: Major
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 5
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 810
Status Whiteboard:

size_large importance_medium

Tags: adf
Participants: aschwart, Ed Burns and rogerk

 Description   

We have various JSP tag implementations that walk up the component ancestor chain during tag execution
for one reason or another. While porting these tags to Facelets, we have been forced to work around the
fact that Facelets does not connect the ancestor chain until after children have been processed.

While it may be too late to change Facelets behavior now, it would be helpful to provide access to the
ancestor chain through some API so that Facelets handlers can interact with parent/ancestor components.



 Comments   
Comment by Ed Burns [ 27/May/10 10:58 AM ]

2.1.

Comment by Ed Burns [ 01/Jun/10 07:42 AM ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 01:30 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:02 PM ]

edburns