[JAVASERVERFACES_SPEC_PUBLIC-1238] Enhance component referencing / findComponent Created: 15/Nov/13  Updated: 18/Jan/17

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

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

Attachments: Text File 20170113-1208-2_3_x-wls-12_2_1-development-fss-client.txt     File 20170116-0432Z-JAVASERVERFACES_SPEC_PUBLIC-1238.diff     Java Source File AjaxBehaviorRenderer.java     Text File changebundle.txt     Text File changebundle.txt     File jsf-systest.war     File spec-1238-20170114.diff     File spec-1238.diff    

 Description   

Currently component referencing with the JSF API is very limited.
Keywords can currently only be used with f:ajax and not for e.g. outputLabel "for" attribute.
Also keywords cant be combined and we dont even have many keywords.

For PrimeFaces, i created a small modular API to enhance the search alogorithm as you can read here:
http://blog.primefaces.org/?p=2740

Noteable features are:

  • keywords can be used for all components
  • combinable keywords like @composite:@parent or @form:myId
  • currently a (limited) pluggable framework to allow new keywords for endusers

For the JSF API, a new artifact for resolving expression for findComponent (like ViewHandler etc.) would be great and can easily be enhanced by component libraries.
Maybe something like "ComponentExpressionResolver".

If its somehow possible, i would like to help to create and finalyze the API.

Sorry for Issue 1237 - please close it.



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

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

Comment by Ed Burns [ 13/Aug/14 ]

This area is very sensitive to performance problems.

Comment by tandraschko [ 26/Sep/15 ]

The performance won't be affected for existing applications as the new search expression logic is only used if the whole expression string contains a "@".
Some expressions are faster, some are slower but the overall performance is very good and i did a lot of optimization for it.

Would great to see it in the next API release. BootsFaces implemented a similiar API.
As i said, i would take care of it and would contribute my ideas to the JSF API.

Comment by stephanrauh [ 26/Sep/15 ]

I agree with Thomas. I consider the advanced search expressions very useful. So useful, that I implemented them in BootsFaces 0.8.0 myself. As for the performance considerations: granted, we should keep the performance in mind. However, I'm using the PrimeFaces search expressions for years now without noting a performance penalty. In particular, the expressions I use most frequently - @parent, @next and @previous - are implemented in a very efficient way.

Comment by balusc [ 20/Jun/16 ]

This is one of the things I'd like to see in JSF 2.3 as well. Community contribution is very welcome.

Comment by Ed Burns [ 10/Jan/17 ]

Diff of pull request 4.

Comment by Ed Burns [ 13/Jan/17 ]

Committed as b243817. Will roll back immediately if the build breaks.

Comment by Ed Burns [ 13/Jan/17 ]

This change appears to have broken the WLS 12.2.1 builds so I must revert it. I will move it to a topic branch.

Revert commit is 6e74667c.

Comment by Ed Burns [ 13/Jan/17 ]

Commit 3dade0c50300d62da59a7d30b693743903da7aed on topic branch has the work.

Comment by arjan tijms [ 13/Jan/17 ]

Was it the Spec1238IT test that failed? If so adding the following to the test might rectify it:

@JsfTest(value = JSF_2_3_0_M10, excludes = {WEBLOGIC_12_1_4, WEBLOGIC_12_2_1})
Comment by Ed Burns [ 13/Jan/17 ]

Thanks Arjan, yes it was that test that failed. But I don't want to exclude it on WLS. It should run on WLS if it is a truly backward compatible change, which it must be since it is not hidden behind a context param.

Comment by Ed Burns [ 16/Jan/17 ]

Ok, commit 3ab4cf8 has the fix that passes all tests. If it breaks the build this time, it is possible we may not have this feature in JSF 2.3.

Comment by Ed Burns [ 17/Jan/17 ]

Built with

webapp.projectStage=Development
webapp.stateSavingMethod=server
webapp.partialStateSaving=false
webapp.serializeServerState=false

Comment by Ed Burns [ 17/Jan/17 ]

Commit dcca156 has the @Ignore of the failing tests.

Comment by Ed Burns [ 18/Jan/17 ]

Commit c1eff0f removes the @Ignore and reverts the change that was causing them to fail.





[JAVASERVERFACES_SPEC_PUBLIC-1423] Dynamic resource loading in ajax requests Created: 16/Jun/16  Updated: 15/Jan/17  Resolved: 28/Nov/16

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

Type: New Feature Priority: Major
Reporter: tandraschko Assignee: balusc
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently if you dynamically add components via java code on a ajax postback, and the component type was not available in the initial request, the component probably missing it's required scripts/styles.
The same applies for dynamic ui:includes with a EL as src attribute.

The problem actually occurs with any JSF library.

The initial solution in PF was custom JS which checks if the script is included, otherwise we loaded the required styles/scripts.

The new solution is the following:

  • remember all resources with a RESTORE_VIEW phaselistener
  • in our PrimePartialResponseWriter (before RENDER_RESPONSE), we loop the current resources and create a diff
  • for the diff (new resources), we ask the resourceHandler#createResource for the URL and pass them to the client via ajax eval tag

AFAIK MyFaces Core already implemented something similiar.

Probably it's enough the describe the feature in the specs, there is no need to adding new API classes.
A param to deactive the feature woudl be great.



 Comments   
Comment by balusc [ 20/Jun/16 ]

Related:

Comment by stiemannkj1 [ 01/Jul/16 ]

In order to understand this issue better, I created a reproducer here: https://github.com/stiemannkj1/dynamic-resource-loading-ajax-reproducer

As tandraschko said, the problem occurs when you try to do something like the following:

Application application = FacesContext.getCurrentInstance().getApplication();
// exampleComponent has an @ResourceDependency on example.js
UIComponent exampleComponent = application.createComponent(ExampleComponent.COMPONENT_TYPE);
UIComponent parent = actionEvent.getComponent().getParent();
parent.getChildren().add(exampleComponent);

When that code is run, the @ResourceDependency s of exampleComponent are not loaded.

The problem also occurs when the src attribute of a ui:include is changed during Ajax, and the included ui:composition contains a component with an @ResourceDependency (the resource dependency is never loaded):

<h:form>
    <ui:include id="include" src="#{bean.include}" /><br />
    <h:commandButton value="Toggle Include" actionListener="#{bean.toggleInclude}">
        <f:ajax render="@form" />
    </h:commandButton>
</h:form>
public void toggleInclude() {

    if ("includeText.xhtml".equals(getInclude())) {
        // Contains example:component which has an @ResourceDependency on example.js
        setInclude("includeExample.xhtml");
    }
    else {
        setInclude("includeText.xhtml");
    }
}

I'll try to add some comments about how to implement this feature in a way that will work for JSF portlets soon.

- Kyle

Comment by stiemannkj1 [ 05/Jul/16 ]

The solution proposed by BalusC's would work for portlets, but it would need to be modified. The server-side solution of keeping a list of rendered resources somehow (likely using the JAVASERVERFACES_SPEC_PUBLIC-1404 solution) and doing a diff of what's rendered or not rendered would work fine with portlets. However the client-side aspect of "...passing resource path to JS and have it check if it's already in DOM and if not, then dynamically create script element." would need to be modified slightly. The problem with relying on the resource path is that portlet containers have full control of URLs and there is no guarantee that a resource URL will appear in the DOM in a parseable form. On top of that, resource URLs in Liferay and Pluto (the Portlet Container reference implementation) provide the resource library and name as parameters: portal/url?ln=library-name&javax.faces.resource=resource-name.js. Finally, in a portlet environment those parameter names are supposed to be prefixed with the portlet's namespace. Therefore, relying on the resource path on the client-side would be too hard (too many possible corner cases). Instead I propose that resources loaded during Ajax be loaded via and API like this:

resourceLoader.load('resource-library:resource-name', 'some/url/to/resource-name.js');

// resourceLoader.load() does something like this:
// if (!loadedResourceSet.contains('resource-library:resource-name')) {
//     // dynamically load the resource
// }

This would also require that resources loaded during a non-Ajax request be added to the loadedResourceSet:

<script type="text/javascript" src="some/url/to/resource-name.js" />
<script>
    resourceLoader.addLoadedResource('resourceLibrary:resourceName');
</script>

Finally, since the portlet container might need to be made aware that a resource has been loaded via Ajax, jsf.js would need to fire an event like resourceLoaded which would contain the resource URL and resource id.

Comment by balusc [ 22/Jul/16 ]

JAVASERVERFACES_SPEC_PUBLIC-1404 has been implemented. There's now a ResourceHandler#markResourceRendered() and isResourceRendered(). It should be trivial to re-mark the resources as rendered during restore view phase, provided that any dynamic resources are properly been added as component resources. I'm currently looking for the best place for that in API/impl.

Comment by balusc [ 22/Jul/16 ]

I created a bunch of test cases in order to reproduce and inspect the problem in below cases performed in the same view, invoked in arbitrary amount and order:

  • component resource added via view.addComponentResource(context, script, "head").
  • component resource added via view.addComponentResource(context, script, "body").
  • component resource added via parent.getChildren().add(componentWithResourceDependency).
  • component resource added via dynamic include referring component with resource dependency.

In all cases (at least in Mojarra) the view is properly restored with information about which resources have already been added during previous postbacks (via restore dynamic actions). In other words, view.getComponentResources() returns the correct information already. Indeed a diff on this during pre render view would have been sufficient in order to detect new resources. It looks like UIViewRoot#addComponentResource() is the best place to collect this information and PartialViewContext#processPartial() is the best place to render missing script resources (only if getRenderAll() is false). I was thinking about reusing update id="javax.faces.ViewHead" which is currently unimplemented in Mojarra's jsf.js. It merely throws a JS error saying that browsers doesn't support replacing head itself: https://github.com/javaserverfaces/mojarra/blob/a3f6431b9bde82b689540fc44ae0925baea2a9b7/jsf-api/src/main/resources/jsf.js#L1401 This is true, but browsers actually support manipulating head's contents (i.e. create script element and add it to head), so we could go on this route.

Issues yet to investigate:

  • does that also work for stylesheet resources
  • how exactly to implement processPartial() + javax.faces.ViewHead update
  • how would that work in Portlets as it doesn't seem to have a notion of "HTML head"
  • should we provide fallback when stateless view is used
Comment by balusc [ 22/Jul/16 ]

Those are the test cases: https://java.net/projects/mojarra/sources/git/revision/dcf22c7d30ec251fc34942b7bb5cfdb72a80931f

Comment by balusc [ 25/Jul/16 ]

I implemented the changes locally and got it running as intented. It also works for stylesheets and the fallback is mentioned in jsf.ajax.response() by explicitly stating "new elements" (i.e. when it does not exist in head, append it). Here are the API changes:

UIViewRoot#addComponentResource() (this should actually have been done as per issue 1404)

* <div class="changed_added_2_3"><p>The resource <code>Renderer</code> must ensure of the following:
* <ul><li>Do not render when {@link ResourceHandler#isResourceRendered(FacesContext, String, String)}
* returns <code>true</code>.</li>
* <li>After rendering, call {@link ResourceHandler#markResourceRendered(FacesContext, String, String)}.</li></ul></div>

UIViewRoot#processEvent()

* <p class="changed_added_2_3">
* If the argument <code>event</code> is an instance of {@link PostRestoreStateEvent} and 
* {@link PartialViewContext#isAjaxRequest()} returns <code>true</code>, then loop over all component resources
* and call {@link ResourceHandler#markResourceRendered(FacesContext, String, String)} for each of them.
* </p>

PartialViewContext#processPartial()

* <div class="changed_added_2_3"><p>When the indicated <code>phaseId</code>
* equals {@link PhaseId#RENDER_RESPONSE} and all components have been
* rendered, then perform the following tasks:
* <ol><li>
* If {@link PartialViewContext#isRenderAll()} returns <code>false</code>, 
* then render any component resource of {@link UIViewRoot} whose
* {@link ResourceHandler#isResourceRendered(FacesContext, String, String)}
* returns <code>false</code> in an update element with an identifier of
* <code>javax.faces.ViewHead</code>.</li>

jsf.ajax.response()

* <li>If an <code>update</code> element is found in the response with the identifier
* <code>javax.faces.ViewHead</code>:
* <pre><code>&lt;update id="javax.faces.ViewHead"&gt;
*    &lt;![CDATA[...]]&gt;
* &lt;/update&gt;</code></pre>
* <span class="changed_modified_2_3">append new elements from the <code>CDATA</code> contents from the
* response to the document's <code>head</code> section</span>.</li>

If there are no objections I will push the changes.

Comment by stiemannkj1 [ 25/Jul/16 ]

balusc,

1. How do you determine that a resource does not exist in the head already? From your previous comments, it seems like the list of resources is checked on the server-side before adding the resources. Is that the case, or is there client-side code which checks for duplicate resources?

2. Are the head (<update id="javax.faces.ViewHead">) scripts loaded before any markup (<update id="some:element:Id">) scripts? The head scripts should be loaded before the markup scripts to ensure that the markup scripts can utilize the head scripts. For example, consider a primefaces component which relies on jQuery. The component is added to a page which does not have jQuery loaded, and the component markup includes a script which relies on jQuery. If jQuery isn't loaded before this script, the component will fail with a JavaScript error. In Mojarra 2.2.13, jsf.js worked around a similar issue* by loading external scripts synchronously.

* The issue was that scripts in the partial response should still be executed in order of appearance whether they were external or inline, so that scripts in the partial response could depend on other scripts in the partial response.

Comment by balusc [ 25/Jul/16 ]

1. Perhaps "new elements" statement in jsf.ajax.response() is not clear enough? Maybe "non-existing elements" is clearer?
2. Good point, I will take this into account.

I have by the way changed loadScript for 2.3 and 2.2.14 as per https://java.net/jira/browse/JAVASERVERFACES-4024

Comment by balusc [ 26/Jul/16 ]

Updated API proposal:

UIViewRoot#processEvent()

 * <p class="changed_added_2_3">
 * If the argument <code>event</code> is an instance of {@link PostRestoreStateEvent} and 
 * {@link PartialViewContext#isPartialRequest()} returns <code>true</code>, then loop over all component resources
 * and call {@link ResourceHandler#markResourceRendered(FacesContext, String, String)} for each of them.
 * Finally, delegate to super.
 * </p>

PartialViewContext#processPartial() (this is indeed more than necessary for the issue, but I noticed this information is nowhere detailed so it had to be added anyway)

 * <div class="changed_added_2_3">
 * <p>When the indicated <code>phaseId</code> equals {@link PhaseId#RENDER_RESPONSE}, then perform the following
 * tasks in sequence:
 * <ol><li>If {@link #isResetValues()} returns <code>true</code>, then call 
 * {@link UIViewRoot#resetValues(FacesContext, Collection)}, passing {@link #getRenderIds()}.</li>
 * <li>If {@link #isRenderAll()} returns <code>false</code>, then render any component resource of
 * {@link UIViewRoot} whose {@link ResourceHandler#getRendererTypeForResourceName(String)} does not return 
 * <code>null</code>, and whose {@link UIComponent#getChildCount()} is zero, and whose
 * {@link ResourceHandler#isResourceRendered(FacesContext, String, String)} returns <code>false</code>, in an
 * <code>update</code> element with an identifier of <code>javax.faces.Resource</code>.</li>
 * <li>Process the components.</li>
 * <li>Obtain the state by calling {@link StateManager#getViewState} and write out it as an <code>update</code>
 * element with an identifier of <code>&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;&lt;SEP&gt;javax.faces.ViewState</code>
 * where <code>&lt;VIEW_ROOT_CONTAINER_CLIENT_ID&gt;</code> is the return from
 * {@link UIViewRoot#getContainerClientId(FacesContext)} on the view from whence this state originated, and
 * <code>&lt;SEP&gt;</code> is the currently configured {@link UINamingContainer#getSeparatorChar(FacesContext)}.
 * </li>
 * <li>If {@link #isRenderAll()} returns <code>false</code>, then write out each script of {@link #getEvalScripts()}
 * as an <code>eval</code> element.</li>
 * </ol></div>

jsf.ajax.response()

 * <li class="changed_added_2_3">If an <code>update</code> element is found in the response with the
 * identifier <code>javax.faces.Resource</code>:
 * <pre><code>&lt;update id="javax.faces.Resource"&gt;
 *    &lt;![CDATA[...]]&gt;
 * &lt;/update&gt;</code></pre>
 * append any element found in the <code>CDATA</code> contents which is absent in the document to the document's <code>head</code> section.
 * </li>

If there are no objections I will push the changes.

Comment by balusc [ 26/Jul/16 ]

For convenience I will also add UIViewRoot#getComponentResources(FacesContext) which returns all component resources without the need to know or specify all targets.

Comment by stiemannkj1 [ 26/Jul/16 ]

Thanks balusc, the JSDoc is very clear now.

However, as I mentioned above, checking whether a resource is loaded on the client-side will not work the same way for portlets. But, I've realized that the solution in my comment is probably overkill for JSF in webapps. Instead, the JSF portlet bridge would need an extension point in jsf.js where the bridge could determine whether a resource element should be appended to the head. The bridge would also need the opportunity to modify aspects of the element (for example adding or removing attributes) before adding it to the head section. These aren't really pressing concerns, so we can talk about them more when the implementation is closer to being completed. But I want to make sure that this feature will be compatible with portlets before the issue is closed.

Comment by balusc [ 26/Jul/16 ]

Indeed, you should be able to continue using UIViewRoot#addComponentResource() without much worrying.

Comment by balusc [ 27/Jul/16 ]

API has been added https://java.net/projects/mojarra/sources/git/revision/43e3c3ee16542deb36bf2fb09411b7fe1ed29003

API will be implemented as per https://java.net/jira/browse/JAVASERVERFACES-4169

Comment by lu4242 [ 25/Oct/16 ]

Sorry for reopen this topic again (cannot reopen
JAVASERVERFACES_SPEC_PUBLIC-1423), but I notice something that was not
specified fully. The javadoc of PartialViewContext.processPartial(...)
says this:

"... When the indicated phaseId equals PhaseId.RENDER_RESPONSE,
then perform the following tasks in sequence: ..."

"... 5. If isRenderAll() returns false, then write out each
script of getEvalScripts() as an eval element. ..."

The problem is as the javadoc is written, the <eval> scripts are
executed at last, or in other words after the nodes are updated. But
The resource loading should be done "before" the ajax update is applied,
otherwise a javascript exception could be thrown, because the <update>
block could contain references to the resources to be loaded.

Please note the intention of getEvalScripts() is correct (<eval> blocks
created by developers should be executed normally after <update> blocks),
but in this case we want something to load resources dynamically.

The most simple solution is replace getEvalScripts() with two methods:
getFirstEvalScripts() and getLastEvalScripts() or something like that.

Comment by balusc [ 27/Oct/16 ]

Reopening because API needs to be clarified at several points.

1. UIViewRoot#getComponentResources() must specify ordering of head/form/body resources
2. Probably jsf.ajax.response jsdoc needs to be clarified as to update/resources/eval processing order

Comment by balusc [ 27/Oct/16 ]

How about this modification of getComponentResources()?

 * <p class="changed_added_2_3">
 * Return an unmodifiable ordered <code>List</code> of all {@link UIComponent} resources of all supported targets.
 * Each <code>component</code> in the <code>List</code> is assumed to represent a resource instance. The ordering
 * is the same as the resources would appear in the component tree.
 * </p>

Is this sufficient?

Comment by stiemannkj1 [ 27/Oct/16 ]

I like the JavaDoc, however, I'm not sure that there is enough information in the partial response to deal with "form" and "body" resources. "form" and "body" resources are rendered after the markup in the body and form renderers. In other words, those resources can depend on the markup being rendered before being run (and sometimes they do). Because of this, it's probably necessary to do things in this order:

1. Add "head" CSS.
2. Add/Run "head" JS.
3. Process <update> markup section to deal with markup.
4. Add "form" CSS.
5. Add/Run "form" JS.
6. Add "body" CSS.
7. Add/Run "body" JS.
8. Process <eval> section.

Alternatively, the form and body renderers could be relied upon to add their resources to the <update> markup section (as they already do), and only the "head" resources could be rendered in the javax.faces.Resource section. I think that is the best solution. It would also simplify the implementation greatly (Mojarra already handles this) compared to the first methodology I mentioned.

Comment by balusc [ 28/Nov/16 ]

UIViewRoot#getComponentResources(FacesContext) ordering has been fixed and javadoc has been updated as per https://java.net/projects/mojarra/sources/git/revision/4b3e7752018ae54d09d54c25fce18c6684375c1c

As to explicit form/body JS resource processing order in ajax updates, that would after all have been a remarkably designed component resource in first place (brittle script code) and it would very likely expose problems in other scenarios.

Comment by stiemannkj1 [ 06/Jan/17 ]

balusc, in my reproducer for this issue, adding a component to the component tree dynamically fails to add its resource dependencies. The code is here: https://github.com/stiemannkj1/dynamic-resource-loading-ajax-reproducer/blob/master/src/main/webapp/dynamic.xhtml. I'm pretty sure this was working at some point, but it doesn't work with any of the recent milestones (or the SNAPSHOT of master). Is there something I'm missing?

- Kyle

Comment by stiemannkj1 [ 07/Jan/17 ]

balusc, I need to do a little more testing, but I believe that this feature is compatible with portlets. However, I needed to make one minor change in jsf.js to make it work: scripts and stylesheets need to retain the attributes that they are rendered with in the partial response. I believe this change would be an improvement in general anyway. I've implemented the change here: https://github.com/stiemannkj1/mojarra/commit/e5dd1c35139341b792942ba4445cc2d842c4244e. Please let me know what you think. I will thoroughly test the change on Monday.

Comment by balusc [ 08/Jan/17 ]

Kyle, I just checked the reproducer. As to dynamically adding component, you have declared @ResourceDependency on the ExampleRenderer and then called createComponent() without specifying the desired renderer type.

If you fix below line in the managed bean

```
UIComponent exampleComponent = application.createComponent(ExampleComponent.COMPONENT_TYPE);
```

to be

```
UIComponent exampleComponent = application.createComponent(FacesContext.getCurrentInstance(), ExampleComponent.COMPONENT_TYPE, ExampleComponent.RENDERER_TYPE);
```

then it will work.

As to dynamic include, everyhing works just fine for me (I converted the project to be Servlet compatible and tested with 2.3.0-m10 on Tomcat 8.5.9).

Comment by balusc [ 08/Jan/17 ]

As to proposed change in jsf.js, I did a quick test on servlet30 tests and only servlet30/systest has failed with an error implying that a component which is ajax-updated multiple times got its value appended instead of overwritten. I haven't debugged it yet, but the request is sound and I will look closer.

Comment by stiemannkj1 [ 09/Jan/17 ]

balusc, thanks for the pointers. I've updated my reproducer and PR according to your comments and they both work correctly now. I sent a PR for review here: https://github.com/jsf-spec/mojarra/pull/6

I've tested this fix (for retaining dynamic script and style attrs) against the following modules:

  • servlet40
  • servlet31
  • servlet30-isolated
  • servlet30
  • javaee8
  • javaee7
  • javaee6web
  • javaee6

As per the instructions here, I also sent this patch to the issues@javaserverfaces.java.net.

Comment by Manfred Riem [ 10/Jan/17 ]

Applied to 2.3 trunk,

commit 31b1b44eac421286b8a555aba410335823141a27
Author: Manfred Riem <manfred.riem@oracle.com>
Date: Tue Jan 10 09:35:41 2017 -0700

Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1423

Comment by tandraschko [ 15/Jan/17 ]

@balusc
Could you please post a example partial response xml, how a dynamic resource loading looks like?
I would like to implement early JSF 2.3 in PrimeFaces and our ajax client must support this. Neil already provided a patch for the new parameter namespacing.





[JAVASERVERFACES_SPEC_PUBLIC-1419] Support new Html5 events like oninput Created: 07/Jun/16  Updated: 09/Jan/17

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

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


 Description   

e.g. HtmlInputText#EVENT_NAMES should contain oninput

We should actually check the list, all JSF components and add missing events:
http://www.tutorialspoint.com/html5/html5_events.htm

IMO it's important for 2.3 to be more compliant with HTML5.



 Comments   
Comment by WarriorDog [ 30/Jul/16 ]

I"d suggest this one http://www.w3schools.com/tags/ref_eventattributes.asp

Comment by WarriorDog [ 09/Jan/17 ]

PF issue related to this: https://github.com/primefaces/primefaces/issues/1493





[JAVASERVERFACES_SPEC_PUBLIC-329] Add new single HTML radio button component that isn't bound to a list Created: 05/Feb/08  Updated: 29/Dec/16  Resolved: 28/Sep/16

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

Type: Improvement Priority: Critical
Reporter: rdelaplante Assignee: balusc
Resolution: Fixed Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: PNG File radio buttons.png    
Issuezilla Id: 329
Status Whiteboard:

cat2 renderkitdoc size_medium importance_small


 Description   

The selectOneRadio component requires that all radio buttons be grouped
together. This is very inflexible when creating user interfaces. Many times I
have encountered screens where I need multiple radio buttons in the same group,
but each radio button exists in a separate area of the screen. This can be done
in HTML easily, but not with JSF's default component set.

I've read that Apache MyFaces has created a component to solve this issue, and
so has Sun's Woodstock component set. Please standardize this fundamental
component in JSF 2.0 so that all implementations come with it.



 Comments   
Comment by rdelaplante [ 05/Feb/08 ]

Created an attachment (id=122)
Example form where this component would be useful

Comment by Ed Burns [ 09/Sep/08 ]

Per 20080827 EG Meeting, push to 2.1

Comment by Ed Burns [ 10/Sep/08 ]

Very early in the development of JSF 2.0, the EG decided we didn't have enough
resources to add new components and that, since components are extensible
anyway, our time would be better spent working on the top five features of 1.
making components easier to develop 2. having first class ajax support for
custom components 3. reducing the configuration burden 4. providing better error
handling and developer experience 5. providing for better interoperability
between 3rd party jsf components.

Comment by rdelaplante [ 10/Sep/08 ]

From my experience, this is the only missing component that maps directly to
HTML. I think this is different from adding fun and useful new components.

In my web apps that don't use sophisticated components such as calendars, I
prefer to use the basic h:* input components so that I don't have to force
hundreds of KB downloads on my users. I style with my own CSS. Since JSF
doesn't offer a radio button component where I can specify the html group name
as an attribute, I have to introduce hundreds of KB download of CSS and
JavaScript to my users by adding a component suite.

Comment by rdelaplante [ 10/Sep/08 ]

This was most noticeable when creating a slim UI for mobile web browsers. If I
wanted to create a UI such as the one in the attached screenshot, mobile users
(smart phones on slow networks) would have to wait 2+ minutes while the
component suite's CSS and JavaScript would download. If JSF had a built in
radio button component that maps to HTML, then this wouldn't be a problem.

Comment by rdelaplante [ 17/Sep/08 ]

I have found a solution for the problem outlined in this ticket without
requiring the addition of a new component. I noticed that issue #229 has added
two new attributes to selectManyCheckbox. All that is missing from
selectOneRadio is a name attribute.

<h:selectOneRadio id="notifyOff" value="OFF" name="notifyType"/>
<h:selectOneRadio id="notifyEmail" value="EMAIL" name="notifyType"/>
<h:selectOneRadio id="notifySMS" value="SMS" name="notifyType"/>

The name attribute is what makes the Woodstock Component Suite's radio button
usable for me, because it lets me have control of the screen layout as shown in
the attached screenshot. If you can add a name attribute to the 2.0 spec that
would be really great!

Comment by rdelaplante [ 17/Sep/08 ]

I meant to refer to issue #228 instead of #229

Comment by rdelaplante [ 23/Mar/09 ]

Here are some examples of how developers have solved this issue:

http://webdev2.sun.com/woodstock-tlddocs/webuijsf/radioButton.html
http://www.icefaces.org/docs/v1_7_2sp1/tld/ice/radio.html
http://myfaces.apache.org/tomahawk-project/tomahawk12/tlddoc/t/radio.html
http://software.topcoder.com/catalog/c_component.jsp?comp=26817861&ver=1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by rdelaplante [ 20/Apr/12 ]

I like how the Trinidad and IceFaces radio button works. Essentially what they've done is extend the existing h:selectOneRadio and added a new layout constant value called "spread" which tells it to not render itself. Then they created a new t:radio component that renders a single radio button and its label wherever you place it. The t:radio has a "for" attribute that points back to the main selectOneRadio, and an "index" attribute that tells it which of the select items to output. It works with JSF's built-in AJAX and I love it. My only issue is that I can't use it in a ui:repeat loop, but I suspect that is a JSF spec issue related to findComponent. I'd also like to be able to choose if the label is rendered to the left or right of the radio button, or not render the label at all.

<t:selectOneRadio id="upgradesRadio" layout="spread" value="#

{model.upgradeSelection}

">
<f:selectItems value="#

{model.availableUpgrades}

" var="upgrade" itemLabel="#

{upgrade.description}

"/>
<f:ajax/>
</t:selectOneRadio>

... custom HTML layout ...

<t:radio for="upgradesRadio" index="0"/>

... custom HTML layout ...

<t:radio for="upgradesRadio" index="1"/>

Comment by rdelaplante [ 30/Aug/13 ]

Please PLEASE get this done in JSF 2.3, we've been waiting way too long for this. With a perfect solution in Trinidad that works well with the existing h:selectOneRadio design, I don' understand why this keeps getting left undone release after release. Search Google for people using JSF and radio buttons and you'll find a lot of misery.

Comment by rdelaplante [ 11/Jul/14 ]

I was working with the t:radio component from Trinidad recently and discovered an inflexibility. It always renders a label with the radio button and so I had difficulty implementing the layout and wrapping dictated by a web designer. Also, they wanted part of the label text to have different font styling. I was unable to embed any kind of HTML tags in the label text loaded from the backing bean (such as a span or div) because it always escapes the label text.

If you implement this feature in JSF 2.3 (please do!), it would be nice to have the option to output just the radio button without the label, and also the option to not escape the text in the label.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by rdelaplante [ 19/Aug/15 ]

Another consideration for this component is the ability to bind the value to a Boolean. I've had numerous customers provide screen layouts with two radio buttons and specific wording that essentially boil down to yes/no or on/off, and I end up changing the wording to make it work with a checkbox instead. Some customers don't like that so I have to write backing bean code to read the value from the radio button component and store it in my model manually.

Comment by rdelaplante [ 25/Aug/15 ]

I'm monitoring the thread about this ticket on the JSF expert group mailing list but don't think I can reply to it so I'm posting my comments here. Specifically I'm commenting on Manfred's post about it being simple enough to register your own renderer and recommending that this ticket be closed as "Won't Fix". Also on Manfred's remark about a new component being overkill.

I created this ticket seven years ago and wrote most of the comments. I no longer recommend my original solution from the earliest comments. Instead I recommend the Tomahawk solution where they added a new value to the h:selectOneRadio layout attribute called "spread" which tells it to not render anything. They also created a new t:radio component which has a for attribute that points to the h:selectOneRadio component's id, and an index attribute to specify which SelectItem to use. IceFaces implemented the same solution.

Two component suites implemented the same solution which work well for me in my applications. It sounds like Manfred has a simpler idea. Can you please describe it?

As a developer who has been using JSF to create web applications for at least seven years now, I think that I am qualified to say that JSF does not currently and never has supported HTML radio buttons. The h:selectOneRadio component can only be used in trivial use cases which happens to be never, not even once, in all the years I've been using JSF. If it weren't for the Tomahawk and IceFaces solutions (crutches IMO) then developers like myself would not have been able to use JSF in our applications and wouldn't still be using JSF today.

Ed has asked me to volunteer to implement this. I've agreed to give it a shot but I really don't know the source code and would very much prefer that a real expert do it.

Comment by balusc [ 08/Aug/16 ]

I'll take it on me.

Comment by balusc [ 08/Aug/16 ]

Summarized: best approach would be to modify the existing renderer in such way so that at least the below cases are possible:

1:

<h:dataTable value="#{bean.items}" var="item">
    <h:column>
        <h:selectOneRadio group="foo" value="#{bean.selectedItem}">
            <f:selectItem itemValue="#{item}" />
        </h:selectOneRadio>
    </h:column>
</h:dataTable>

2:

<ui:repeat value="#{bean.items}" var="item">
    <h:outputLabel for="radioId" value="#{item.label}" />
    <h:selectOneRadio id="radioId" group="foo" value="#{bean.selectedItem}">
        <f:selectItem itemValue="#{item.value}" />
    </h:selectOneRadio>
    <br/>
</ui:repeat>

3:

<h:selectOneRadio group="foo" value="#{bean.selectedItem}">
    <f:selectItem itemValue="one" />
    <f:selectItem itemValue="two" />
    <f:selectItem itemValue="three" />
</h:selectOneRadio>
<h:selectOneRadio group="foo" />
<h:selectOneRadio group="foo" />

4:

<h:selectOneRadio group="foo" value="#{bean.selectedItem}">
    <f:selectItem itemValue="one" />
</h:selectOneRadio>
<h:selectOneRadio group="foo">
    <f:selectItem itemValue="two" />
</h:selectOneRadio>
<h:selectOneRadio group="foo">
    <f:selectItem itemValue="three" />
</h:selectOneRadio>

5:

<h:selectOneRadio group="foo" value="#{bean.selectedItem}">
    <f:selectItems value="#{['one', 'two', 'three']}" />
</h:selectOneRadio>
<h:selectOneRadio group="foo" />
<h:selectOneRadio group="foo" />

The group attribute is new. When group is specified, it must render solely a <input type="radio"> element (no table, no list). The group value must be relative to the UIForm and represent the common HTML name.

If there are multiple components with same group in the UIForm, and the value attribute and/or UISelectItem child is absent, then the one of the first component must be considered. The UISelectItem values will be assigned to the components having same group in the same order as components appear in the UIForm.

If the UISelectItem has a item label, then a <label> will be rendered directly after the <input> element, without any additional markup.

Comment by kito75 [ 06/Sep/16 ]

+1 for this approach

Comment by balusc [ 28/Sep/16 ]

https://java.net/projects/mojarra/sources/git/revision/1edee483ce009c929d11f8c5a53dc11688c10cf5

Comment by balusc [ 28/Sep/16 ]

Implementation follows in https://java.net/jira/browse/JAVASERVERFACES-4188

Comment by balusc [ 29/Dec/16 ]

When https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1433 is enabled, the <h:selectOneRadio group="..." required="true"> displays multiple required message, one per component, instead of only once. Due to this, UISelectOne#processValidators() needed to be altered to cover this case, which is done in this commit: https://java.net/projects/mojarra/sources/git/revision/554d49e57c62143287521cef879b3444601cca5a

Improved implementation and IT follows in https://java.net/jira/browse/JAVASERVERFACES-4188





[JAVASERVERFACES_SPEC_PUBLIC-217] Add a styleClass attribute to h:column Created: 12/Oct/06  Updated: 23/Dec/16  Resolved: 23/Dec/16

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

Type: Improvement Priority: Major
Reporter: dmlloyd Assignee: Unassigned
Resolution: Fixed Votes: 10
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File issue217.patch     Text File JAVASERVERFACES_SPEC_PUBLIC-217.patch    
Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-627 Inconsistent column styles handling w... Open
Issuezilla Id: 217
Status Whiteboard:

cat2 renderkitdoc size_small importance_small


 Description   

Add a styleClass attribute to h:column and relegate the columnClasses attribute
from h:dataTable to a purpose similar to what rowClasses does: cycle through
each item in the list repeatedly (the use case being the ability to apply
alternating styles, like differently-colored even and odd columns, without
requiring knowledge of the number of columns).

There should be nothing in the <h:dataTable> attribute list that is dependant
upon the actual number of columns appearing inside of the table. All
information related to specific columns should be associated with each column's
corresponding <h:column> entity. Indeed, this is already the case with the sole
exception of the columnClasses attribute.

This is related to: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=426



 Comments   
Comment by dmlloyd [ 13/Oct/06 ]

Incidentally, adding a styleClass attribute to the <h:column> tag can be done
without breaking backwards compatibility. Changing the behavior of
columnClasses will be somewhat more difficult. You may want to create a new
attribute called columnCycleClasses or something - or maybe not, given that the
1.2 JSF implementation implemented the columnClasses attribute incorrectly
(until just now), and said implementation happens to concur with my proposed
behavior.

Comment by dmlloyd [ 26/Jan/07 ]

Created an attachment (id=110)
Implement a styleClass property on <h:column>

Comment by Ed Burns [ 15/Oct/08 ]

I've asked the Mojarra team if they think this is ok to do.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by mojavelinux [ 01/Mar/10 ]

Update milestone and component.

Comment by mojavelinux [ 01/Mar/10 ]

In addition to the styleClass attribute, the style attribute should be added as
well. Assigning a style to a column is something that simply cannot be done with
the current <h:dataTable>/<h:column> component pair.

Comment by Ed Burns [ 03/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

renderkit

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Mark Struberg [ 12/May/11 ]

hi!

just like to push this up since I already came across this issue a few times.
Today a colleague of mine had this again: he looked at <h:column> where he found the footerClass and headerClass attributes, but no styleClass for h:column. The columnClasses attribute in <h:dataTable> is not a full replacement since you cannot do data based css assignment.

This is e.g needed if you have a accounting balance and a cash column with debit and credit values, and like to show all credits in green and debits in red.
Of course you can do this with <span> but it is not really intuitive why there is no styleClass on the <td> at all.

Comment by i_oss [ 12/May/11 ]

+1 (also for Dan's style-attribute)

Additionally i'd like to propose that we also add a possibility to add a styleClass/style per row, that can depend on the current var-value, instead of having to calculate the classes for all rows upfront. (There is also no way to add a style-attribute per row). Unfortunately rowClasses is already taken. While rowStyleClass would be perfect I think it is to close to rowClasses.
so:

<h:dataTable var="item" value="..." 
        rowStyle="#{item.important ? 'font-weight: bold' : ''}"
        rowStyleClass='trilternate#{component.rowIndex%3}'>

Not so important: Introduce varstatus as for ui:repeat / c:forEach, even if you can calculate index/last/first/etc. from #

{component}

, I think most template authors will not know that + it gets ugly.

Eventually!!! document, that 'global'-column-styling should be done with <f:facet name="colgroups">, if possible (less to render).

Comment by codylerum [ 03/Oct/13 ]

+1

Defining classes one per column in order on the datatable via columnClasses is far to brittle. RichFaces has provided this for years in their rich:column via styleClass http://docs.jboss.org/richfaces/4.3.X/4.3.0.Final/vdldoc/

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major, because of higher vote count

Comment by codylerum [ 13/Feb/16 ]

With Richfaces sun-setting in June 2016 it would be very nice to pick this feature up in 2.3

This is really the only feature that keeps me from using the native JSF datatable

Comment by codylerum [ 23/Jun/16 ]

I've gone ahead and implemented styleClass on column and rowClass on datatable.

This aligns with now Richfaces named the properties.

https://github.com/codylerum/mojarra/tree/JAVASERVERFACES_SPEC_PUBLIC-217

I'm going to need some review and pointers to know if I've updated the docs correctly.

Comment by Ed Burns [ 23/Dec/16 ]

commit 3a28c88c330e76c5f8817659d220eccf52f3a432
Author: xinyuan.zhang <xinyuan.zhang@oracle.com>
Date: Mon Dec 12 12:52:40 2016 +0800

https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-217
modified: jsf-api/doc/column-props.xml
modified: jsf-api/doc/standard-html-renderkit.xml
modified: jsf-api/doc/table-props.xml
modified: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/BaseTableRenderer.java
modified: jsf-ri/src/main/java/com/sun/faces/renderkit/html_basic/TableRenderer.java

https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-217





[JAVASERVERFACES_SPEC_PUBLIC-1433] Add Option to expand meaning of required="true" for UIInput Created: 29/Nov/16  Updated: 21/Dec/16  Resolved: 21/Dec/16

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

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


 Description   

When you say required="true" on a UIInput component, the validation
must always take place, even when there is no entry in the request
corresponding to that component.

Background:

Consider this login page:

<h:inputText id=“userName” required=“true” 
             value=“#{backingBean.userName}” />

<h:inputSecret id=“password” required=“true” 
               validator=“#{backingBean.validatePassword}” 
               value=“#{backingBean.password}” />

<h:commandButton action=“/views/authenticatedUser.xhtml” />

If the postback is hacked such that the userName is present as a request
parameter, but the password is not, the password validator would be
bypassed. If the password validator is used as the entry point to
perform authentication, this could cause problems.

Now, it must be said that using a validator on a password field as the
entry point to perform authentication is a particular design choice.
This design choice runs a bit counter to the stated purpose of the
validation system, which is to ensure syntactic and some level of
semantic validity of fields. There are other ways to perform
authentication that do not rely on the validation system for this
purpose.

Nonetheless, we would like to accomodate this use case.

Proposal:

For JSF 2.3, I propose the following.

Modify PDF section 3.5.4 to read:

Spec> *The render-independent property required is a shorthand for the
Spec> function of a required validator. If the value of this property is
Spec> true, **there is an entry in the request payload corresponding to
Spec> this component**, and the component has no value, the component is
Spec> marked invalid and a message is added to the FacesContext
Spec> instance.*

Modify the JavaDoc for UIInput.validate(). Modify the first bullet
point to read:

Spec> Retrieve the submitted value with getSubmittedValue(). If this
Spec> returns null, and the
Spec> javax.faces.component.UIInput.ALWAYS_PERFORM_VALIDATION_WHEN_REQUIRED_IS_TRUE
Spec> context-parameter is set to true (ignoring case), examine the
Spec> value of the "required" property. If the value of "required" is
Spec> true, continue as below. If the value of "required" is false, the
Spec> "required" attribute is not set, exit without further
Spec> processing. If the context-paramater is not set, or is set to
Spec> false (ignoring case) exit without further processing. (This
Spec> indicates that no value was submitted for this component.)

With these changes, the javadoc for UIInput.validateValue() can remain
unchanged.



 Comments   
Comment by Ed Burns [ 20/Dec/16 ]

Work progressing on feature branch with of this JIRA.

Comment by Ed Burns [ 20/Dec/16 ]

Commit 07bc46d on feature branch has the fix.

Comment by Ed Burns [ 21/Dec/16 ]

The spec and impl changes have been pushed to master. I'll close this when the tree remains clear.

Comment by Ed Burns [ 21/Dec/16 ]

Tests seem to be clean, so closing this.

Passed

com.sun.faces.test.javaee8.uiinput.Spec1433IT.testSpec1433





[JAVASERVERFACES_SPEC_PUBLIC-1400] ui:repeat does not resolve (nested structures of) map.values Created: 19/Aug/15  Updated: 23/Oct/16

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

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

Checked with Windows 6.1 "7" and 6.3 "8.1"
and Java 1.8 "8"



 Description   

Given a class containing a map

Map<Integer, AccountNode> _children = new LinkedHashMap<>();

AccountNode wraps an object Account inside, which can be obtained by a getter.

The values of this map might be accessed by this getter

public Collection<AccountNode> getChildren() {
    return _children.values();
}

This should be used from facelets like in following code

 <c:forEach items ="#{treeController.rootNode.children}" var="child">
    <p>#{child.account.name}</p>
</c:forEach>

Using the tag handler "forEach", everything is fine.
But moving on to the component "repeat", the app fails.

<ui:repeat value ="#{treeController.rootNode.children}" var="child">
    <p>#{child.account.name}</p>
</ui:repeat>

"/index.xhtml: The class 'java.util.LinkedHashMap$LinkedValues' does not have the property 'account'."

Workaround: If the values get copied into another list, "repeat" works fine too.

public Collection<AccountNode> getChildren() {
    return new ArrayList<AccountNode>(_children.values());
}


 Comments   
Comment by muellermi [ 23/Oct/16 ]

Will this become obsolete due to the extended collection / map handling?





[JAVASERVERFACES_SPEC_PUBLIC-1404] Add API to check if a resource dependency is already rendered Created: 03/Sep/15  Updated: 26/Jul/16  Resolved: 22/Jul/16

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

Type: New Feature Priority: Major
Reporter: balusc Assignee: balusc
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

https://java.net/projects/javaserverfaces-spec-public/lists/jsr372-experts/archive/2015-03/message/4

Proposal

/** 
 * <p>Returns a mutable set of component identifiers representing
 * component resources which are already rendered. Component
 * identifiers have the form <code>library:name</code>, or when
 * the library is absent, just <code>name</code>.
 * <p>Component resource renderers must consult this set if a given
 * component resource is already rendered or not, and add the
 * resource identifier if it's about to render the component resource.
 * <p>E.g.
 * <pre>
 * if (!view.getRenderedComponentResources().add("javax.faces:jsf.js")) {
 *     // Encode component resource.
 * }
 * </pre>
 */
public Set<String> getRenderedComponentResources() {}

In case of Mojarra, this should be used in a.o. ScriptRenderer#encodeEnd() and StyleSheetRenderer#encodeEnd().



 Comments   
Comment by balusc [ 20/Jun/16 ]

Related: https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1423

Comment by stiemannkj1 [ 02/Jul/16 ]

In Liferay Faces we've solved a similar issue with a new class called ResourceVerifier. In order to avoiding rendering certain resources, we wrap each resource renderer with a ResourceRendererUtilImpl which avoids rendering the resource if ResourceVerifier.isDependencySatisfied() returns true:

@Override
public void encodeEnd(FacesContext facesContext, UIComponent uiComponent) throws IOException {

    // ...get the resourceVerifierFactory.
    ResourceVerifier resourceVerifier = resourceVerifierFactor.getResourceVerifer();

    if (!resourceVerifier.isDependencySatisfied(facesContext, uiComponent)) {
        super.encodeEnd();
    }
}

This works for us and is basically the same thing BalusC recommended:

In case of Mojarra, this should be used in a.o. ScriptRenderer#encodeEnd() and StyleSheetRenderer#encodeEnd().

One of the benefits of the ResourceVerifier solution is that the factories allow ResourceVerifier to be wrapped in order to create a delegation chain. In Liferay Faces, we use ResourceVerifier s to suppress resources like Bootstrap when running in Liferay (since Liferay includes Bootstrap). If the spec were to adopt a solution like this, the default ResourceVerifier implementation could simply perform the check mentioned in the ticket (we actually do this in Liferay Faces Bridge):

@Override
public boolean isDependencySatisfied(FacesContext facesContext, UIComponent uiComponent) {

    String library = uiComponent.getAttributes().get("library");
    String name = uiComponent.getAttributes().get("name")
    return facesContext.getViewRoot().getRenderedComponentResources().contains(library + ":" + name);
}

What do the experts think? I think something like ResourceVerifier is necessary for Liferay Faces specifically because we don't have access to the map of rendered resources. But would it be helpful or overkill to add something like ResourceVerifier to JSF on top of (or in place of) the proposed API?

Comment by balusc [ 19/Jul/16 ]

Looks good. That method could just end up in existing ResourceHandler API.

Comment by balusc [ 19/Jul/16 ]

How about those new methods in ResourceHandler?

/**
 * Mark given component resource as rendered.
 * The default implementation stores the resource identifier as context attribute.
 * @param context the {@link FacesContext} for this request.
 * @param componentResource The {@link UIComponent} representing a {@link Resource} instance.
 * @since 2.3
 */
public void markComponentResourceRendered(FacesContext context, UIComponent componentResource) {
    // TODO
}

/**
 * Returns whether given component resource has been rendered.
 * The default implementation checks if the resource identifier has been stored as context attribute.
 * @param context the {@link FacesContext} for this request.
 * @param componentResource The {@link UIComponent} representing a {@link Resource} instance.
 * @return Whether given component resource has been rendered.
 * @since 2.3
 */
public boolean isComponentResourceRendered(FacesContext context, UIComponent componentResource) {
    // TODO
}

It can replace getRenderedComponentResources() altogether.

Comment by balusc [ 21/Jul/16 ]

Improved proposal as per EG mailing.

/**
 * <p class="changed_added_2_3">
 * Mark the resource as identified by given resource and library name as rendered. The default implementation must
 * ensure that {@link #isResourceRendered(FacesContext, String, String)} will return <code>true</code> when the 
 * resource has already been rendered during the render response phase of the current view.
 * </p>
 * @param context The {@link FacesContext} for this request.
 * @param resourceName The name of the resource.
 * @param libraryName The name of the library in which the resource resides, may be <code>null</code>.
 * @since 2.3
 */
public void markResourceRendered(FacesContext context, String resourceName, String libraryName) {
    String resourceIdentifier = libraryName + ":" + resourceName;
    Set<String> resourceIdentifiers = (Set<String>) context.getAttributes().computeIfAbsent(ResourceHandler.class.getName(), k -> new HashSet<>());
    resourceIdentifiers.add(resourceIdentifier);
}

/**
 * <p class="changed_added_2_3">
 * Returns whether the resource as identified by given resource and library name has been rendered. The default
 * implementation must return <code>true</code> when the resource has been marked as rendered via
 * {@link #markResourceRendered(FacesContext, String, String)} during the render response phase of the current view.
 * </p>
 * @param context The {@link FacesContext} for this request.
 * @param resourceName The name of the resource.
 * @param libraryName The name of the library in which this resource resides, may be <code>null</code>.
 * @return Whether the resource as identified by given resource and library name has been rendered.
 * @since 2.3
 */
public boolean isResourceRendered(FacesContext context, String resourceName, String libraryName) {
    String resourceIdentifier = libraryName + ":" + resourceName;
    Set<String> resourceIdentifiers = (Set<String>) context.getAttributes().get(ResourceHandler.class.getName());
    return resourceIdentifiers != null && resourceIdentifiers.contains(resourceIdentifier);
}
Comment by balusc [ 22/Jul/16 ]

API has been added: https://java.net/projects/mojarra/sources/git/revision/fef9b4e12596c0b6c3dfe206c1c03fb571123596

API will be implemented in Mojarra as per https://java.net/jira/browse/JAVASERVERFACES-4166

Comment by balusc [ 26/Jul/16 ]

UIViewRoot#addComponentResource() javadoc has been improved:

     * <div class="changed_added_2_3"><p>The resource <code>Renderer</code> must ensure of the following:
     * <ul>
     * <li>Do not render when {@link ResourceHandler#isResourceRendered(FacesContext, String, String)}
     * returns <code>true</code>.</li>
     * <li>After rendering, call {@link ResourceHandler#markResourceRendered(FacesContext, String, String)}.</li>
     * </ul>
     * </div>

https://java.net/projects/mojarra/sources/git/revision/e814cd125fa811d1fd69a5d828a783966d08cc16





[JAVASERVERFACES_SPEC_PUBLIC-1427] Add public API constants for missing predefined postback parameters Created: 06/Jul/16  Updated: 06/Jul/16  Resolved: 06/Jul/16

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

Type: Improvement Priority: Major
Reporter: balusc Assignee: balusc
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

While working on https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790, I noticed that a few predefined (ajax) postback request parameter names are nowhere defined as constants. It are the following:

  • javax.faces.source
  • javax.faces.behavior.event
  • javax.faces.partial.event

I propose to add the missing constants in below classes:

  • javax.faces.source should be added to ClientBehaviorContext
  • javax.faces.behavior.event should be added to ClientBehaviorContext
  • javax.faces.partial.event should be added to PartialViewContext


 Comments   
Comment by balusc [ 06/Jul/16 ]

https://java.net/projects/mojarra/sources/git/revision/dd96d7e456f429a75f0ba4040e084c63e8d5ae6d





[JAVASERVERFACES_SPEC_PUBLIC-1424] Tag to declare and import constants in EL scope Created: 20/Jun/16  Updated: 27/Jun/16  Resolved: 27/Jun/16

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

Type: New Feature Priority: Major
Reporter: balusc Assignee: balusc
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is a commonly requested feature from the community. OmniFaces has o:importConstants, PrimeFaces Extensions has pe:importConstants and pe:importEnum. EL 3.0 offers ImportHandler#importClass(). It would be nice to offer a standard JSF solution such as <f:importConstants>. It's relatively trivial to implement.

Use case:

public enum Gender { MALE, FEMALE, UNKNOWN; }
<f:importConstants type="com.example.Gender" />
<h:selectOneMenu value="#{person.gender}">
    <f:selectItems value="#{Gender}" />
</h:selectOneMenu>


 Comments   
Comment by balusc [ 21/Jun/16 ]

As per mailing list discussion:

  • Enforce it as child of <f:metadata> (like viewparam).
  • Put constant values in application scope, not request/view/session.
  • Allow configuration/override via faces-config.xml.

Additional detail:

  • Use var attribute to override name of scoped variable.
Comment by balusc [ 27/Jun/16 ]

<f:importConstants> has been implemented https://java.net/projects/mojarra/sources/git/revision/7e903356fb88df14228f7cf24130c3dd59f0350a

Only configuration/override via faces-config.xml has not been implemented. After all, I'm not really seeing how that's useful.





[JAVASERVERFACES_SPEC_PUBLIC-941] reduce number of times rendered attribute value expression is evaluated Created: 31/Jan/11  Updated: 22/Jun/16  Resolved: 26/Jan/15

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

Type: Bug Priority: Critical
Reporter: rogerk Assignee: Manfred Riem
Resolution: Won't Fix Votes: 15
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days

Status Whiteboard:

size_medium importance_medium


 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 ]

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.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 26/Jan/15 ]

As per EG discussion I am closing this as "Won't fix".

Comment by balusc [ 22/Jun/16 ]

For sake of completeness, here's the EG discussion link: https://java.net/projects/javaserverfaces-spec-public/lists/jsr372-experts/archive/2015-01/message/79





[JAVASERVERFACES_SPEC_PUBLIC-1422] Improve UISelectMany to automatically convert based on select items when type is java.util.Collection Created: 11/Jun/16  Updated: 17/Jun/16  Resolved: 17/Jun/16

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

Type: Improvement Priority: Major
Reporter: balusc Assignee: balusc
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Currently, http://docs.oracle.com/javaee/7/api/javax/faces/component/UISelectMany.html states that it won't make any attempt to obtain the converter when the value is of type java.util.Collection. It is technically however possible to automatically convert based on select items.

 * <li class="changed_added_2_0"><p>A <code>java.util.Collection</code>.
 * Do not convert the values. <span class="changed_modified_2_3">Instead,
 * convert the provided set of available options to string, exactly as done
 * during render response, and for any match with the submitted values, add
 * the available option as object to the collection.</span></p></li>


 Comments   
Comment by balusc [ 14/Jun/16 ]

https://java.net/projects/mojarra/sources/git/revision/8f102043307e371056f4cbb983a2b5caf620ef1f

Comment by balusc [ 17/Jun/16 ]

Scratch previous commit which was taken over from MyFaces. It didn't properly cover cases when a collection contains items of different types (bad practice, but technically not impossible). Here are the improvements: https://java.net/projects/mojarra/sources/git/revision/bbf7f0e0546b376d6fb8f927f6b2703f5152b184





[JAVASERVERFACES_SPEC_PUBLIC-1420] Provide portable way to attach behaviors to a composite / base implementation for behaviors Created: 07/Jun/16  Updated: 07/Jun/16

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

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


 Description   

Implementing behaviors in a component library is currently not as easy as implementing components.

1) There is no abstract behavior base available
2) No common way to handle state saving like the StateHelper
3) No common way to attach a behavior to a component
4) No common, portable and easy way to attach a behavior to a composite

It would be a great goal to create a abstract base for behaviors, which fixes the common problems.
In PrimeFaces, i developed it via:

  • AbstractBehavior; base class which handles the attributes and state saving - similar to getStateHelper and PropertyKeys

https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java

  • AbstractBehaviorHandler; attach the behavior to the target component or composite; currently with a hack for Mojarra and MyFaces

https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/base/AbstractBehaviorHandler.java

Example implemtation of p:ajax:
https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/ajax/AjaxBehavior.java
https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/ajax/AjaxBehaviorHandler.java






[JAVASERVERFACES_SPEC_PUBLIC-1113] onselect attribute is only supported on INPUT and TEXTAREA elements, not on SELECT elements Created: 06/Jun/12  Updated: 18/Mar/16  Resolved: 18/Mar/16

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

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

Attachments: Text File changebundle.txt    

 Description   

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



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 02/Sep/15 ]

Change bundle looks good, r=mriem. Bauke please go ahead with the commit.

Comment by balusc [ 03/Sep/15 ]

Applied to 2.3 trunk

svn commit -m "https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1113, remove onselect from SELECT components, r=mriem"
Sending        jsf-api/doc/standard-html-renderkit.xml
Sending        jsf-ri/conf/share/html_basic.taglib.xml
Transmitting file data ..
Committed revision 15112.
Comment by Manfred Riem [ 03/Sep/15 ]

Hi Bauke,

Can you effect the change you did in standard-html-renderkit.xml in standard-html-renderkit-base.xml instead as it is used to generated the former.

Thanks!

Comment by balusc [ 04/Sep/15 ]
svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1113, remove onselect from SELECT components, r=mriem"
Sending        jsf-api/doc/standard-html-renderkit-base.xml
Transmitting file data .
Committed revision 15120.
$ svn add jsf-api/doc/input-props-noselect.xml 
A         jsf-api/doc/input-props-noselect.xml
$ svn commit -m "JAVASERVERFACES_SPEC_PUBLIC-1113, remove onselect from SELECT components, r=mriem"
Adding         jsf-api/doc/input-props-noselect.xml
Transmitting file data .
Committed revision 15121.
Comment by balusc [ 18/Mar/16 ]

Closing out fixed issue.





[JAVASERVERFACES_SPEC_PUBLIC-939] behavior issues with "INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL" setting Created: 31/Jan/11  Updated: 10/Feb/16  Resolved: 10/Feb/16

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Duplicate Votes: 6
Labels: None
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


 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 ]

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

Comment by balusc [ 11/Oct/12 ]

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

Comment by dennishoersch [ 14/Jan/13 ]

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.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by balusc [ 10/Feb/16 ]

Duplicates https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-671





[JAVASERVERFACES_SPEC_PUBLIC-1411] Duplicate detail and summery message in f:messages tag for input fields Created: 17/Dec/15  Updated: 17/Dec/15

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

Type: Improvement Priority: Minor
Reporter: belal.galal Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Apache Tomcat 8.0.26, Mojarra implementation for JSF 2.2.8, Windows OS, Eclipse IDE



 Description   

When adding the attribute required="true" and then added a value to the attribute requiredMessage for input fields,for example, in a form that contains <h:messages>, the error messages will contain a duplicate detail and summary messages for the required input field. I wonder if the requiredMessage can be divided to be requiredMessageDetail and requiredMessageSummary in the input components.






[JAVASERVERFACES_SPEC_PUBLIC-1408] Query parameters added through f:param are encoded twice without use percent encoding Created: 11/Sep/15  Updated: 11/Sep/15

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

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


 Description   

Reported in:

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

We have an interesting behaviour when rendering h:outputLink with nested f:param elements: in the param data, the output href string has spaces encoded with a "+" rather than the expected "%20". For example:

<h:outputLink value="login.xhtml"><h:outputText value="Login page" /><f:param name="username" value="This is a test" /></h:outputLink>
creates the following:
<a href="login.xhtml?username=This+is+a+test">Login page</a>

This already seems to have been discussed in https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1019

I tried some examples with Mojarra 2.2.12 and it renders the same as MyFaces, but I notice that in this case:

<h:outputLink value="box1.xhtml?id=some value">

the space is percent encoded (space replaced by %20).

But the query params coming from f:param for h:link, h:outputLink and h:commandLink are encoded using java.net.URLEncoder.encode(...).

In JSF 2.2 spec renderkit doc for component-family: javax.faces.OutcomeTarget renderer-type: javax.faces.Button there is a section titled:

"Algorithm to obtain the url to which the user-agent should issue a GET request when clicked"

It says this:

"... The entire target URL string must be processed by a call to the encodeResourceURL() method of the ExternalContext. The name of the UIParameter goes on the left hand side, and the value of the UIParameter on the right hand side. The name and the value must be URLEncoded. Each UIParameter instance is separeted by an ampersand, as dictated in the URL spec. ..."

In this case we have a situation where the same string is encoded multiple times:

  • Call to URLEncoder.encode(...) or similar for each parameter provided by f:param tag
  • In ResponseWriter.writeURIAttribute(...)

ExternalContext.encodeResourceURL() internally calls httpServletResponse.encodeURL(...), but this is not used to do the url encoding (it is called later on the same algorithm, so that part is fine).

This issue needs to be discussed at spec level.

The problem is the call to URLEncoder.encode(...) do the same as writeURIAttribute(...), so the same code is executed twice for the same task. It looks like the first call to URLEncoder.encode(...) is not necessary (at least in MyFaces calls this method, probably by historical reasons). It is not clear who is responsible to do the character encoding for the URL. At the end all this happens on the Renderer class, so the clarification is about the moment where the URL encoding should happen.






[JAVASERVERFACES_SPEC_PUBLIC-1080] New Component APIs to manage EL context as it applies to components. Created: 05/Mar/12  Updated: 09/Sep/15  Resolved: 09/Sep/15

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

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

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

 Description   

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

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



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

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

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

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

Ed

Comment by Manfred Riem [ 20/Mar/12 ]

Ed,

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

Manfred

Comment by Ed Burns [ 21/Mar/12 ]

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

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

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

Is also blue, and that's from r9769.

Can you please point me to the failing job?

I'll fix it right away, of course.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 09/Sep/15 ]

Too large of a scope.





[JAVASERVERFACES_SPEC_PUBLIC-984] Component context management Created: 21/Apr/11  Updated: 08/Sep/15  Resolved: 08/Sep/15

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

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

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

size_large importance_large


 Description   

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

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

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

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

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

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

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



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

Carry forward to 2.2 Sprint 9.

Comment by Ed Burns [ 16/Dec/11 ]

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

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

In other words:

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

Is that correct?

Comment by Ed Burns [ 16/Dec/11 ]

First draft of API committed to trunk.

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

Comment by Ed Burns [ 14/Mar/13 ]

Re-opening per Andy's request.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 08/Sep/15 ]

Contacted the reporter and he is OK to close this out as "Incomplete"





[JAVASERVERFACES_SPEC_PUBLIC-1126] XSD for composite components incomplete Created: 27/Jul/12  Updated: 04/Sep/15  Resolved: 04/Sep/15

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

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


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

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

Comment by Manfred Riem [ 04/Sep/15 ]

Asked reporter over email if it is OK to be closed out.

Comment by Manfred Riem [ 04/Sep/15 ]

Response was OK to close.





[JAVASERVERFACES_SPEC_PUBLIC-1029] viewParam value lost after validation errors Created: 02/Aug/11  Updated: 04/Sep/15

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

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

Tags: state, validation

 Description   

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

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

The following reproduces this:

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

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

    <h:body>

        <h:messages />

        #{viewParamBean.id} <br/>

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

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

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

    private long id;    
    private String text;

    public void actionMethod() {

    }

    public long getId() {
        return id;
    }

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

    public String getText() {
        return text;
    }

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

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

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

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

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

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

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

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



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





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

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

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

Operating System: All
Platform: All


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

size_small importance_medium


 Description   

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

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

public class HtmlStylesheetRenderer extends Renderer implements
ComponentSystemEventListener
{

public void processEvent(ComponentSystemEvent event)

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

......
}

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



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

Move to 2.1

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Hanspeter Duennenberger [ 19/Nov/10 ]

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

Thus the below code would look like:

public void processEvent(ComponentSystemEvent event)

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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 02/Sep/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-807, Need to pass FacesContext instance to system event listeners"
Sending jsf-api/src/main/java/javax/faces/event/ComponentSystemEvent.java
Sending jsf-api/src/main/java/javax/faces/event/ExceptionQueuedEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PostAddToViewEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PostConstructApplicationEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PostConstructCustomScopeEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PostConstructViewMapEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PostKeepFlashValueEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PostPutFlashValueEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PostRenderViewEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PostRestoreStateEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PostValidateEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PreClearFlashEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PreDestroyApplicationEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PreDestroyCustomScopeEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PreDestroyViewMapEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PreRemoveFlashValueEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PreRemoveFromViewEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PreRenderComponentEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PreRenderViewEvent.java
Sending jsf-api/src/main/java/javax/faces/event/PreValidateEvent.java
Sending jsf-api/src/main/java/javax/faces/event/SystemEvent.java
Transmitting file data .....................
Committed revision 15107.





[JAVASERVERFACES_SPEC_PUBLIC-776] <h:form> should support method=GET Created: 24/Mar/10  Updated: 27/Aug/15  Resolved: 27/Aug/15

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

Type: Improvement Priority: Critical
Reporter: lincolnbaxter Assignee: Manfred Riem
Resolution: Won't Fix Votes: 13
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

Operating System: All
Platform: All


Issuezilla Id: 776
Status Whiteboard:

size_medium importance_medium


 Description   

Use Case: Imagine a simple search form with dropdown filters. Publicly
accessible, but server-side state saving is enabled for security reasons.

  • visit yoursite.com/search (which is a JSF search form)
  • do a search
  • see results screen which itself has a populated search box
  • wait for session timeout
  • click search
  • blammo

or even simpler:

  • visit yoursite.com/search (which is a JSF search form)
  • wait for session timeout
  • click search
  • blammo

Due to the fact that the JSF form is rendered and always does a POST back, there
is no way to prevent this aside from the typical "refresh the page every few
minutes before session times out," which I do not consider a great solution
because it means you're keeping sessions open as long as people sit on that page.

If <h:form> supported the method="GET" attribute and behavior, people could
avoid this situation entirely. Basically turning the form into a way to bind and
validate input (no value change listeners, most likely) but still get
functionality of inputs and action methods. It would nicely address this kind of
simple use case.



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

Requires impl change. Move to 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by kito75 [ 20/Apr/11 ]

This is pretty important – people have complained about the ViewExpiredException in this scenario to me before at talks; this would fix that problem.

It's also something that newbies expect to be supported.

Comment by lincolnbaxter [ 20/Apr/11 ]

I would vote for this if I could... it's a big issue.

Comment by arjan tijms [ 08/May/12 ]

This was targeted for JSF 2.2, but is it still considered for that release?

GET support is obviously still very important for a variety of use cases. JSF 2.0 has added great support for GET in general, but unfortunately h:form is still missing.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 27/Aug/15 ]

As per EG discussion closing it as "Won't fix".

Use regular form plus f:viewParam does the trick.





[JAVASERVERFACES_SPEC_PUBLIC-910] Can't render a multiline <selectone_radio/> or <selectmany_c.b.l/> Created: 15/Nov/10  Updated: 24/Aug/15  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
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


 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 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





HTML5 Support (JAVASERVERFACES_SPEC_PUBLIC-1090)

[JAVASERVERFACES_SPEC_PUBLIC-1076] HTML5 Sectioning and Heading Created: 22/Feb/12  Updated: 24/Aug/15  Resolved: 13/Aug/14

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

Type: Sub-task Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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



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

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

Comment by Ed Burns [ 13/Aug/14 ]

Passthru elements are sufficient here.





[JAVASERVERFACES_SPEC_PUBLIC-932] PreValidate/PostValidate events are not published properly Created: 31/Jan/11  Updated: 24/Aug/15  Resolved: 12/Aug/14

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

Type: Bug Priority: Trivial
Reporter: rogerk Assignee: Unassigned
Resolution: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 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



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

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





[JAVASERVERFACES_SPEC_PUBLIC-648] Make it possible to ask a Renderer for its family and renderer-type. Created: 10/Oct/09  Updated: 24/Aug/15  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 648
Status Whiteboard:

cat2 javadoc size_medium importance_medium


 Description   

It would be nice if the renderer would be able to tell the world, and even know itself, what its family and
renderer-type are. This is handy when decorating renderkits.



 Comments   
Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

size_medium importance_medium

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-600] support binding-attribute for composite-component Created: 03/Aug/09  Updated: 24/Aug/15  Resolved: 04/Aug/14

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

Type: Bug Priority: Trivial
Reporter: ntruchsess Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 600
Status Whiteboard:

cat2 frame size_small importance_large


 Description   

I'd like to access the composite's root component from the managed bean by using
the standard attribute 'binding' for this:

<html xmlns:ez="http://java.sun.com/jsf/composite/ezcomp">
<ez:mytag binding="#

{bean.comp}

"/>
</html>

will not assign anything to bean.comp

I'm not shure whether this is a spec or an implementation-issue. (3.5.1
Component Binding doesn't mention composite-components and the chapters about
composite-comp don't mention binding, so in theory this is supposed to work,
isn't it?)



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "implementation" subcomponent.

Comment by Ed Burns [ 24/Feb/10 ]

Damn. That's a great idea. I love it. Unfortunately it's too big for 2.0 Rev a, but it's
very easy to implement and natural.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

Component bindings are discouraged, so we will not be adding them here.





[JAVASERVERFACES_SPEC_PUBLIC-580] remove method for UI component tree Created: 25/Jun/09  Updated: 24/Aug/15  Resolved: 12/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: mojavelinux Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 580
Status Whiteboard:

size_medium importance_medium


 Description   

I would like to propose that we add some way to have a server-side component
tree removed from the session in the same way that there is a @Remove method on
a stateful session bean. As you know, the component tree is only cleaned up when
it falls out of the component tree queue in the session (LRU). However, there
are times in the application when it is clear to the developer based on a
navigation event that the user is departing a page and will not restore it in
the future. I suggest that we introduce the method remove() on UIViewRoot that
removes the component tree from the session immediately.

I didn't really envision this mechanism as a way to prevent the user from going
backwards. There are much less drastic and more elegant ways to deal with that
problem.

The developer would have to be aware of the consequences, but I see it more
something a framework will leverage.



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by mojavelinux [ 18/Dec/09 ]

Update target milestone to 2.1

Comment by mojavelinux [ 18/Dec/09 ]

Update subcomponent to Components/Renderers

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

leave unchanged





[JAVASERVERFACES_SPEC_PUBLIC-1204] h:commandLink behaves different from h:commandButton Created: 08/Jul/13  Updated: 24/Aug/15  Resolved: 13/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

glassfish 4.0,


Tags: html5

 Description   

If a submit button is generated, browser will perform some extra tasks in HTML5 when the button is clicked. For example, browser may need to validate the form, and include input fields for this form (but out of form in DOM structure). When a link is generated, script is used to perform submission. The extra tasks performed by the form will not be performed.

Given the new html5 validation support, validation could be moved to client side. The tasks performed by browser could be important. I suggest to generate a hidden button if link is requested. When link is clicked, the event is routed to the hidden button. By this way, the browser action is always invoked.

-jason



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

This is a spec issue and must be brought to the expert group.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 13/Aug/14 ]

I'm not sure if you are asking for client side validation support or for a smaller change in how buttons work. If you are still interested in this, please file another issue that is more narrowly defined.





[JAVASERVERFACES_SPEC_PUBLIC-764] Layout manager components Created: 09/Mar/10  Updated: 24/Aug/15  Resolved: 12/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 764
Status Whiteboard:

size_medium importance_small


 Description   

We need some layout manager components. Lincoln suggested looking at these:

http://livedocs.adobe.com/flex/3/langref/mx/containers/HBox.html
http://livedocs.adobe.com/flex/3/langref/mx/containers/VBox.html



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

Move to unscheduled.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1228] Consider UIInputFile as a means to deal with the problem of the "value" attribute with respect to state saving. Created: 08/Oct/13  Updated: 24/Aug/15  Resolved: 13/Aug/14

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

Type: New Feature Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: 4 days
Time Spent: Not Specified
Original Estimate: 4 days

Issue Links:
Related
is related to JAVASERVERFACES-3037 h:inputFile Ajax File Upload: Works e... Closed

 Description   

JSF 2.2 added file upload but did so by leveraging the javax.faces.Input component-family with the newly-defined javax.faces.File renderer-type. There is one aspect in which this may be problematic: the storing of the "value" property in component state. Please see JAVASERVERFACES-3037.



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

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

Comment by Ed Burns [ 13/Aug/14 ]

Impl issue marked as Cannot Reproduce.





[JAVASERVERFACES_SPEC_PUBLIC-926] UIInput change Created: 31/Jan/11  Updated: 24/Aug/15  Resolved: 12/Aug/14

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

Type: Bug Priority: Trivial
Reporter: rogerk Assignee: Unassigned
Resolution: Won't Fix Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 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 »



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

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

Comment by Ed Burns [ 12/Aug/14 ]

Too fundamental to change this at this point in the technology lifecycle.





[JAVASERVERFACES_SPEC_PUBLIC-441] Subforms Created: 21/Aug/08  Updated: 24/Aug/15  Resolved: 25/Feb/15

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

Type: Bug Priority: Major
Reporter: mwessendorf Assignee: Unassigned
Resolution: Won't Fix Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 441
Status Whiteboard:

EGTop5 cat2 size_medium importance_medium draft

Tags: 2_3_wontfix

 Description   

For some reason several JSF libs provide a subform component:
-Trinidad
-Tomahawk
-Tobago
-ADF Faces
...

Why not making this component standard ?
Also, don't forget the required interface (see issue # 322)



 Comments   
Comment by Ed Burns [ 09/Sep/08 ]

EGTop5

Comment by Ed Burns [ 15/Oct/08 ]

Change target milestone to 2.0

Comment by Ed Burns [ 04/Aug/09 ]

Pushing out to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

Move these to unscheduled because we need to target them correctly. 2.next isn't
specific enough.

Comment by kito75 [ 24/Feb/10 ]

Changed subcomponent to Components/Renderers.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Manfred Riem [ 01/Aug/14 ]

Closing resolved issue out





[JAVASERVERFACES_SPEC_PUBLIC-1243] Use bean-like name as converter-id when @FacesConverter "value" attribute is omitted Created: 19/Dec/13  Updated: 24/Aug/15  Resolved: 23/Jan/15

Status: Closed
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Validation/Conversion
Affects Version/s: 2.2
Fix Version/s: None

Type: New Feature Priority: Critical
Reporter: kithouna Assignee: Manfred Riem
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: 2_3_wontfix

 Description   

The JavaDoc of @FacesValidator's "value" attribute states:

If no value is specified, or the value is null, the value is taken to be the return of calling getSimpleName on the class to which this annotation is attached and lowercasing the first character.

It would be nice to have this feature for @FacesConverter as well.

See also JAVASERVERFACES_SPEC_PUBLIC-703



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 23/Jan/15 ]

While on the surface it looks possible to do this change, in reality it is not. The specification currently specifies that if the value attribute is omitted the forClass attribute is taken for registration. This allows you to register a Converter for the Object.class type.

Or in other words, the requested change is not possible because the FacesConverter forClass attribute defaults to Object.class which means if you currently annotate a converter with just @FacesConverter it already has a meaning as illustrated below.

@FacesConverter => @FacesConverter(forClass = Object.class)

So I am closing this as "Won't fix"





[JAVASERVERFACES_SPEC_PUBLIC-677] Document more clearly the automatic UIPanel behavior for f:facet (was: f:facet can have more than one child) Created: 01/Dec/09  Updated: 24/Aug/15  Resolved: 24/Aug/15

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

Type: Task Priority: Critical
Reporter: Jakob Korherr Assignee: Manfred Riem
Resolution: Fixed Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt    
Issuezilla Id: 677
Status Whiteboard:

cat2 vdldoc size_small importance_small


 Description   

Testing mojarra we found out that <f:facet> now can have more than one children,
which will automatically be put in a UIPanel.

However, the spec never mentions that fact.



 Comments   
Comment by mojavelinux [ 18/Dec/09 ]

Update milestone to 2.0 Rev a

This actually became a requirement to support <f:metadata>, so the rule is
loosely implied in that section.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 04/Mar/10 ]
      • Issue 522 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 22/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by Ed Burns [ 30/Jun/10 ]

I did some more research on this, digging into the JSF 1.0 (JSR-127) archive. Here's what I found:

On Wed, 13 Nov 2002, Craig McClanahan wrote:

CM> However, I believe the APIs would be simpler if we actually required
CM> the value pointed at by a "named child" name to be, in fact, a
CM> single component. In the cases where you really would like to use a
CM> collection, it's straightforward to use something like a UIPanel
CM> with arbitrarily nested contents – my "Grid" and "List" renderers
CM> in jsf-pseudo follow this sort of design pattern.

CM> Therefore, I'm proposing that, in the map of "named child" nodes,
CM> the key must be specified (and unique within parent), and the value
CM> must be a single UIComponent. If we decide that the "named list"
CM> notion is also useful, we can relax the latter constraint.

On Fri, 15 Nov 2002 Adam Winer wrote:

AW> The most common use case is that each name/role has either
AW> zero or one corresponding component.

AW> There's an open question of whether it's worth the added complexity
AW> to support a List of components per name/role, but I've not found this
AW> to be especially helpful.

I'm reluctant to change this beyond more clearly documenting the behavior of Mojarra to automatically
fabricate a UIPanel in the case of multiple children within a UIPanel.

Jacob, is this OK? If so, I'd like to change the Summary to:

Document more clearly the automatic UIPanel behavior for f:facet.

Comment by Jakob Korherr [ 02/Jul/10 ]

Yes, of course this is OK for me!

It would just be great to have some documentation about this new feature. For
example one question that would really be necessary to answer is: is this
behavior only supported on facelets or also on JSP?

Thanks!

Comment by Ed Burns [ 02/Aug/10 ]

fix summary as described

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by paul_dijou [ 13/Jun/12 ]

I was going to post a similar issue but I just found this one. I agree that the spec and Mojarra are not synchronized on that point.

Any news about the status of this issue? Will the spec be reviewed to allow several child inside a facet and wrap them automatically inside a javax.faces.component.UIPanel ?

Regards

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 24/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-677, Document more clearly the automatic UIPanel behavior for f:facet (was: f:facet can have more than one child)"
Sending jsf-ri/conf/share/facelets_jsf_core.taglib.xml
Transmitting file data .
Committed revision 15040.





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

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

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

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

 Description   

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

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

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

E.g.

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

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

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

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

}


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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

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

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

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

Comment by Ed Burns [ 17/Aug/15 ]

"Properties" is a hot button topic. It was recently booted out of Java SE 9. This is a decent writeup: http://blog.joda.org/2014/11/no-properties-in-java-language.html





[JAVASERVERFACES_SPEC_PUBLIC-1279] UIInput.isEmpty() lacks specification Created: 15/May/14  Updated: 12/Aug/15  Resolved: 12/Aug/15

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

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

Attachments: Text File changebundle.txt    
Issue Links:
Related
is related to JAVASERVERFACES-3241 java.lang.IndexOutOfBoundsException: ... Closed

 Description   

This method should have a specification.

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

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


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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 12/Aug/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1279, UIInput.isEmpty() lacks specification"
Sending jsf-api/src/main/java/javax/faces/component/UIInput.java
Transmitting file data .
Committed revision 14990.





[JAVASERVERFACES_SPEC_PUBLIC-1341] Default value for viewParam Created: 10/Dec/14  Updated: 19/Jun/15

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

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


 Description   

What about allowing the definition of a default value for a view-parameter?

Example

Defining number of displayed items (pagination feature) as a view-parameter but still keeping default value within xhtml and not java bean.

Following example is a very clean approach provinding a default value.

<f:viewParam name="pageSize" value="#{bean.pageSize}" default="10"/>
<p:dataTable rows="#{bean.pageSize}"/>

Currently there are two workarounds which have no clean separation between markup and java code:

Workaround 1

Passing the default value to bean.

<f:viewParam name="pageSize" value="#{bean.pageSize}"/>
<f:event type="preRenderView" listener="#{bean.initPreRenderView(10)"/>
<p:dataTable rows="#{bean.pageSize}"/>
private int pageSize;

public void initPreRenderView(int pageSize)
{
	if (this.pageSize == 0)
		this.pageSize == pageSize;
}

Workaround 2

Hardcoding the default value in bean. But markup should be responsible and not bean.

<f:viewParam name="pageSize" value="#{bean.pageSize}"/>
<p:dataTable rows="#{bean.pageSize}"/>
private int pageSize = 10; 


 Comments   
Comment by djmj [ 19/Jun/15 ]

When using `ìncludeViewParams=true` on a link or command or using programmatically `getBookmarkableURL` the view parameters who's value equal their default value can be ignored.

This solves the problem of irrelevant parameters appended to link components. This behavior can be optional or optionally be deactivated using a param like `index.xhtml?appendDefaultValues=true`

A `<h:link>` with `<f:param name="pageSize" value="10">` can be ignored in the final URL.





[JAVASERVERFACES_SPEC_PUBLIC-1376] Missing StateHolder in Behaviour API for usage in dataTable and alike Created: 22/May/15  Updated: 22/May/15

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

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


 Description   

Recently I came across the fact that the Behaviour API is not using the StateHolder.

This means that EL Expressions in attributes of custom ClientBehaviours are executed during the buildView step and not during the 'rendering' (getScript() ) of the clientBehaviour.

As a consequence, the EL can't reference a var defined in the dataTable.






[JAVASERVERFACES_SPEC_PUBLIC-1364] UIRepeat and UIData supports Map Created: 19/Feb/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

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

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Issue Links:
Cloners
is cloned by JAVASERVERFACES-3836 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1103 UIRepeat and UIData supports Iterable Resolved

 Description   

In reference to JAVASERVERFACES_SPEC_PUBLIC-1103 Bauke Scholtz commented the following:

Would be even more cool if it transparently recognizes Map like c:forEach so we don't need value="#{bean.map.entrySet()}" everytime.

Splitting this off from 1103; it's strongly related but a different (additional) type.



 Comments   
Comment by arjan tijms [ 19/Feb/15 ]

When discussing support for Iterable, the wish for Map also came up.

Comment by arjan tijms [ 07/Mar/15 ]

For this change the spec document needs to be updated, specifically section 4.1.3.2.

This section currently (in the 2.3 branch) contains the following text:

The current value identified by the value property is normally of type DataModel. [P1-start-uidataModel]However, a DataModel wrapper instance must automatically be provided by the JSF implementation if the current value is of one of the following types:
java.util.List
Array of java.util.Object
java.sql.ResultSet (which therefore also supports javax.sql.RowSet) 
javax.servlet.jsp.jstl.sql.Result
java.util.Collection
java.lang.Iterable
Any other Java object is wrapped by a DataModel instance with a single row.[P1-end]

The updated text in section 4.1.3.2 after this update would be the following:

The current value identified by the value property is normally of type DataModel. [P1-start-uidataModel]However, a DataModel wrapper instance must automatically be provided by the JSF implementation if the current value is of one of the following types:
java.util.List
Array of java.util.Object
java.sql.ResultSet (which therefore also supports javax.sql.RowSet) 
javax.servlet.jsp.jstl.sql.Result
java.util.Collection
java.lang.Iterable
java.util.Map (uses the wrapper for java.lang.Iterable by providing access to java.util.Map#entrySet())
Any other Java object is wrapped by a DataModel instance with a single row.[P1-end]
Comment by Manfred Riem [ 24/Mar/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1364, UIRepeat and UIData supports Map"
Sending spec/frame/standardUserInterfaceComponents.fm
Transmitting file data .
Committed revision 1166.





[JAVASERVERFACES_SPEC_PUBLIC-1103] UIRepeat and UIData supports Iterable Created: 23/May/12  Updated: 08/Mar/15  Resolved: 02/Mar/15

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Fixed Votes: 13
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File changebundle.txt    
Issue Links:
Duplicate
duplicates FACELETS-240 UIRepeat 'value' attribute and Collec... Resolved
Related
is related to JAVASERVERFACES-3785 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
is related to JAVASERVERFACES_SPEC_PUBLIC-1078 Have DataModel implementations regist... Reopened
is related to JAVASERVERFACES_SPEC_PUBLIC-1364 UIRepeat and UIData supports Map Resolved

 Description   

I encountered a problem attempting to set the ui:repeat "value" attribute to an
instance that was a subclass of java.util.Set (specifically Hibernate's
PersistentSet class): the UIRepeat class treated it like a scalar object.

An iteration tag like ui:repeat should work with all Collection types in my
opinion. In the UIRepeat.getDataModel() method it's possible to detect an
instance of Collection and make use of the ArrayDataModel by invoking the
toArray() method on the instance. In this way a new DataModel implementation
isn't needed. I've made this change in my own copy of Facelets and it works
beautifully.

Hibernate happens to use Sets quite a bit, so this was important to me. I'd be
happy to submit a patch.

This issue occurs in Facelets 1.2 as well.\



 Comments   
Comment by Aditya [ 10/Sep/12 ]

Not only just collections, ui:repeat should also support iterables as well for the value attribute.

Comment by Ertio lew [ 11/Mar/13 ]

ui:repeat should allow iterables to be used with them. Currently we are required to create a new list from iterable just to support ui:repeat. This limitation should be removed.

Comment by kithouna [ 27/Sep/13 ]

The collection / iterable to datamodel conversion should be abstracted and put in a global place. Now DataTable and UIRepeat do pretty much the same thing and differences crop up between them that benefit no one.

Then, we the users should be able to register additional datamodel converters, so we can register something like OmniFaces' IterableDataModel and they would be automatically used by DataTable, UIRepeat and others.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major

Comment by arjan tijms [ 17/Feb/15 ]

Not only just collections, ui:repeat should also support iterables as well for the value attribute.

I agree, and have adjusted the title of the issue to reflect that. If UIRepeat supports iterables, UIData should support that as well. Thanks for this suggestion!

Comment by Ed Burns [ 23/Feb/15 ]

Section 4.1.3.2 in the spec PDF must be updated as well for this issue to be considered closed. The relevant text in the latest version of the spec is the following:

The current value identified by the value property is normally of type DataModel. [P1-start-uidataModel]However, a
DataModel wrapper instance must automatically be provided by the JSF implementation if the current value is of one
of the following types:
java.util.List
Array of java.util.Object
java.sql.ResultSet (which therefore also supports javax.sql.RowSet)
javax.servlet.jsp.jstl.sql.Result
Any other Java object is wrapped by a DataModel instance with a single row.[P1-end]
Convenience implementations of DataModel are provided in the javax.faces.model package for each of the
above (see Section 4.2.1.4 “Concrete Implementations”), and must be used by the UIData component to create the
required DataModel wrapper.

Comment by Ed Burns [ 23/Feb/15 ]

I have some comments about the changebundle, but I'll add them on the impl issue JAVASERVERFACES-3785.

Comment by arjan tijms [ 23/Feb/15 ]

The relevant text in the latest version of the spec is the following:

The spec currently lists:

  • java.util.List
  • Array of java.util.Object
  • java.sql.ResultSet
  • javax.servlet.jsp.jstl.sql.Result
  • (Object wrapped as single row)

But java.util.Collection is missing, while this was added via a spec issue (JAVASERVERFACES_SPEC_PUBLIC-479).

The new list would therefor become:

  • java.util.List
  • Array of java.util.Object
  • java.sql.ResultSet
  • javax.servlet.jsp.jstl.sql.Result
  • java.util.Collection
  • java.lang.Iterable
  • (Object wrapped as single row)

Also, a similar list appears in UIRepeat, but I can't find anything about that in the spec.

The updated text in section 4.1.3.2 after this update (and after taking into account the change from 2.2) would be the following:

The current value identified by the value property is normally of type DataModel. [P1-start-uidataModel]However, a DataModel wrapper instance must automatically be provided by the JSF implementation if the current value is of one of the following types:

java.util.List
Array of java.util.Object
java.sql.ResultSet (which therefore also supports javax.sql.RowSet)
javax.servlet.jsp.jstl.sql.Result
java.util.Collection
java.lang.Iterable
Any other Java object is wrapped by a DataModel instance with a single row.[P1-end]

Comment by arjan tijms [ 25/Feb/15 ]

Patch for ui:repeat's taglib/tld doc

Comment by arjan tijms [ 02/Mar/15 ]

Oops, UIRepeat changes did not make it into previous bundle

Comment by Manfred Riem [ 02/Mar/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1103, UIRepeat and UIData supports Iterable"
Sending jsf-ri/conf/share
Sending jsf-ri/conf/share/ui.taglib.xml
Sending jsf-ri/conf/share/ui.tld
Transmitting file data ..
Committed revision 14464.





[JAVASERVERFACES_SPEC_PUBLIC-1363] Add cols attribute to selectManyCheckbox Created: 12/Feb/15  Updated: 12/Feb/15

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

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


 Description   

If a bigger list of checkboxes should be displayed, either the page gets very wide or height. It would be useful to display two or more columns of checkboxes. Frankly, the layout should be restricted to a spcified number of columns and automatically gets extended in height.

add attribute "cols" of type int to selectManyCheckBox. If omitted, assume a default of 1.

If layout="pagedirection" (vertical) than cols > 2 creates multiple cols of checkboxes. The checkboxes will be created from left to right until a count of "cols" is reached. Then the layout continues with the next line. Thus, the total height is apx. n/cols.

If layout="linedirection", than cols is ignored. Optionally, an attribute lines is used for this layout. Now n/lines cols will be created.



 Comments   
Comment by muellermi [ 12/Feb/15 ]

example:

layout="pagedirection"
[] item1
[] item2
[] item3
[] item4
[] item5

layout="pagedirection" cols="2"
[] item1 [] item2
[] item3 [] item4
[] item5

ayout="linedirection" lines="2"
[] item1 [] item2 [] item3
[] item4 [] item5





[JAVASERVERFACES_SPEC_PUBLIC-819] add "disabled" attribute for h:button Created: 11/Jun/10  Updated: 29/Jan/15  Resolved: 29/Jan/15

Status: Resolved
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: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File changebundle.txt     Zip Archive newfiles.zip    
Issuezilla Id: 819
Status Whiteboard:

size_small importance_small


 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 ]

assign to sheetal

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 06/Jun/11 ]

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

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor

Comment by Manfred Riem [ 29/Jan/15 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-819, add "disabled" attribute for h:button"
Sending jsf-api/build.xml
Adding jsf-api/doc/outcometargetbutton-props.xml
Sending jsf-api/doc/standard-html-renderkit-base.xml
Sending jsf-api/doc/standard-html-renderkit.xml
Sending jsf-ri/build.xml
Sending jsf-ri/conf/share/html_basic.taglib.xml
Transmitting file data ......
Committed revision 14272.





[JAVASERVERFACES_SPEC_PUBLIC-686] Missing public constant for INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL Created: 02/Dec/09  Updated: 12/Jan/15  Resolved: 12/Jan/15

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

Type: Bug Priority: Critical
Reporter: Ryan Lubke Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issue Links:
Blocks
is blocked by JAVASERVERFACES-3681 Implement JAVASERVERFACES_SPEC_PUBLIC... Closed
Issuezilla Id: 686
Status Whiteboard:

cat1 javadoc size_small importance_medium


 Description   

The UIInput has a public constant for this context parameter:
"javax.faces.VALIDATE_EMPTY_FIELDS"

But the one for "javax.faces.INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL"
has been forgotten...



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 16/Mar/10 ]

javadoc

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 ]

Even though this is a trivial change, because it modifies the signature, we must
move it to 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





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: 11/Dec/14

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

Type: Sub-task Priority: Minor
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: a11y, accessibility
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor

Comment by kito75 [ 11/Dec/14 ]

Ed, can you add the accessibility tag to this issue? I also would like to request the priority be bumped up. I'm going to have to do this for a client (over 500 pages that don't use aria-required and can't be changed) so I can prototype this.

Comment by Ed Burns [ 11/Dec/14 ]

I added the "accessibility" and "a11y" tags, though they were new tags. Are they the right ones?





[JAVASERVERFACES_SPEC_PUBLIC-1317] Clarify how h:link should encode the URL for UIParameters which resolve to a null-value Created: 11/Oct/14  Updated: 31/Oct/14

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

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


 Description   

Currently the tag spec for h:link does not say what happens if a h:link has a f:param child whose value resolves to null; for example:

<h:link outcome="test">
<f:param name="testParam" value="#

{myBean.testValue}"/>
<f:param name="testParam2" value="testValue"/>
</h:link>

If f:param should work inverse to f:viewParam, then any f:param with a null value should be skipped completely, so the above example should render a href attribute with value "test.xhtml?testParam2=testValue" when #{myBean.testValue}

resolves to null.

In fact this was the (unspecified) behavior of Mojarra 2.1.x, while 2.2.x now throws a null pointer exception (https://java.net/jira/browse/JAVASERVERFACES-3355).

This clarification would be a huge advantage when using GET parameters in JSF, especially in conjunction with View Parameters. If a View Parameter is omitted its value will be null. If you want to pass it to another page using f:param currently in 2.2 you always have to write custom code that makes sure it does not resolve to null to prevent runtime exceptions.






[JAVASERVERFACES_SPEC_PUBLIC-1195] cc.attrs not avaiable when rendering h:outputStyleSheet Created: 24/May/13  Updated: 23/Sep/14

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

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

Apache Tomcat 7.0.34 running in Windows 8


Tags: composite-component, outputStyleSheet

 Description   

Situation:
A composite component has its attributes declared with the "composite-attribute" tags, one of these attributes is "theme", used to specify the css file to be used by the component.

<composite:interface>
<composite:attribute name="theme" required="false" default="rose" />
...
</composite:interface>

At the component's implementation I try to import the css file using the "h:outputStyleSheet" tag.

<composite:implementation>
<h:outputStylesheet library="components" name="calendar/#

{theme}

/calendar.css" />
...
</composite:implementation>

Expected behavior:
If no attribute "theme" is specified by the page calling the component, "h:outputStylesheet" should import "calendar/rose/calendar.css". If a theme is specified it should import the specified theme.

Actual behavior:
"h:outputStylesheet" tries to import "calendar//calendar.css", no matter if a theme was specified or not.

My thoughts:
I tried to specify the theme directly inside the EL expression (name="#

{'rose'}

"), it worked, so it's not an expression problem. I think the cc.attrs variables are not available when "h:outputStylesheet" is processed.

There's a similar problem described in Stack Overflow:
http://stackoverflow.com/questions/7386344/evaluating-the-rendered-attribute-of-houtputstylesheet-inside-a-composite



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor

Comment by jpangamarca [ 23/Sep/14 ]

The same happens for h:panelGroup. I'm using JSF 2.2 (org.jboss.spec.javax.faces.jboss-jsf-api_2.2_spec, Implementation-Version: 2.2.6), Wildfly 8.1.0, WAR deployment.

Consumer:
<my:facelet hasPermission="#

{true}

" />

CC:

Doesn't work (gets rendered):

<h:panelGroup rendered="#

{!cc.attrs.hasPermission}

" layout="block">
<h:outputText value="Unauthorized" />
</h:panelGroup>

But this works:

<h:panelGroup rendered="#

{cc.attrs.hasPermission? false : true}

" layout="block">
<h:outputText value="Unauthorized" />
</h:panelGroup>





[JAVASERVERFACES_SPEC_PUBLIC-462] Support for WAI ARIA Created: 05/Sep/08  Updated: 19/Sep/14  Resolved: 04/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Fixed Votes: 2
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-1181 Add support for WAI-ARIA to standard ... Sub-task Open  
Issuezilla Id: 462
Status Whiteboard:

cat2 frame size_large importance_large draft


 Description   

http://www.w3.org/WAI/intro/aria



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by kito75 [ 24/Feb/10 ]

Changed subcomponent to Components/Renderers and issue type to ENHANCEMENT.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage rkit docs

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

Fixed in 2.2.

Comment by kito75 [ 19/Sep/14 ]

Ed, what is the Fixed Version for this? 2.3?





[JAVASERVERFACES_SPEC_PUBLIC-1300] UIViewRoot.getViewMap() require different publishEvent() variant. Created: 21/Aug/14  Updated: 16/Sep/14  Resolved: 21/Aug/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3375 ViewScopeEventListener not safe for u... Closed

 Description   

See JAVASERVERFACES-3375.

The javadoc for UIViewRoot.getViewMap() is very explicit about the arguments to publishEvent(). Because we are so specific, we should require calling the variant that takes the base class.






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

Status: Resolved
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: Critical
Reporter: Ed Burns Assignee: Manfred Riem
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Attachments: Text File changebundle.txt    
Issue Links:
Dependency
blocks JAVASERVERFACES-3180 Possible NPE in FormOmittedChecker Closed

 Description   

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

See JAVASERVERFACES-3180.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical

Comment by Manfred Riem [ 16/Sep/14 ]

Applied to 2.3 trunk,

svn commit -m "Fixes https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1267, Clarify meaning of null return from UIComponent.getFamily()"
Sending jsf-api/src/main/java/javax/faces/component/UIComponent.java
Transmitting file data .
Committed revision 13686.





[JAVASERVERFACES_SPEC_PUBLIC-1116] Add the possibility to change "rel" and "type" on <h:outputStylesheet> Created: 15/Jun/12  Updated: 11/Sep/14

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

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

All


Attachments: Zip Archive spec-1116.zip    
Tags: css, outputStylesheet

 Description   

Currently, when using a <h:outputStylesheet>, it will always generate a <link href="..." rel="stylesheet" type="text/css">, there is no way to change the value of the "rel" and "type" attributes on the generated HTML tag.

But HTML5 is here and next technologies have emerged, like LESS, SASS ans SCSS. It would be cool to keep the actual default values but add "rel" and "type" attributes to the JSF component "outputStylesheet" so we can override them if needed.



 Comments   
Comment by paul_dijou [ 29/Oct/12 ]

To see the fact that "type" and "rel" are hard-coded, just check that source code: https://maven.java.net/service/local/repositories/releases/archive/com/sun/faces/jsf-impl/2.1.3/jsf-impl-2.1.3-sources.jar/!/com/sun/faces/renderkit/html_basic/StylesheetRenderer.java (it's near the end).

Not sure even the new passthru attributes can change them...

Comment by paul_dijou [ 13/Nov/12 ]

Also, consider the same problem with script resources. New types like Coffeescript are now possible. As we can see at the beginning of https://maven.java.net/service/local/repositories/releases/archive/com/sun/faces/jsf-impl/2.1.3/jsf-impl-2.1.3-sources.jar/!/com/sun/faces/renderkit/html_basic/ScriptRenderer.java , also here the type is hard-coded.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 13/Aug/14 ]

I confirmed that this doesn't work, even with passthrough elements:

<h:outputStylesheet library="alibrary" name="favicon.ico" pt:rel="icon" pt:type="image/x-icon" />

Just outputs:

<link type="text/css" rel="stylesheet" href="/test-agnostic-renderKit-basic/faces/javax.faces.resource/favicon.ico?ln=alibrary" />

This clearly is not what is intended.





[JAVASERVERFACES_SPEC_PUBLIC-1308] UISelectOne and UISelectMany should validate arrays deeply. Created: 08/Sep/14  Updated: 08/Sep/14

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

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


 Description   

According to the specification, UISelectOne and UISelectMany shall extend the standard validation behavior of UIInput by ensuring that the selected value is equal to the available options. I propose that the selected value must be deeply equal instead. In that way, the options may be arrays.






[JAVASERVERFACES_SPEC_PUBLIC-1073] Add file upload specific attributes to h:inputFile component tag Created: 14/Feb/12  Updated: 29/Aug/14

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

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


 Description   

This issue serves as a proposal for enhancing the new h:inputFile component tag with additional attributes.

The three attributes that I would like to propose are:

  • location: String indicating the directory that uploaded file should be copied to. If not specified, then the "location" specified in the Servlet 3.0 web.xml context parameter will be utilized.
  • maxFileSize: Integer representing the maximum number of bytes that the component will accept for an uploaded file. If not specified, then the "max-file-size" specified in the Servlet 3.0 web.xml context parameter will be utilized.
  • mimeTypes: Comma-delimited list of uploaded file mime types that are valid. If not specified, then all mime types are assumed to be valid.


 Comments   
Comment by Neil Griffin [ 24/Nov/12 ]

In the "What's new in JSF 2.2" presentation that Ed Burns gave at JavaOne 2012, he mentioned that h:inputFile can work with a standard JSF validator. So for the "maxFileSize" and "mimeTypes" attributes, perhaps it would be better to introduce a new f:validateFile component:

<h:inputFile>
<f:validateFile maxFileSize="1048576" mimeTypes="png,gif,jpg" />
</h:inputFile>

Comment by andy_bosch [ 24/Nov/12 ]

I like that idea. Would definitly makes sense!

Comment by muellermi [ 25/Nov/12 ]

What will happen if a file of same name exists in upload location?
The web developer may hook into.

I propose to add an additional attribute as hint to create a default behavior if not hooked in.

overwrite=allow|deny|rename

rename will append some chars to the filename (e.g. a simple count) to make it unique

Comment by Neil Griffin [ 26/Nov/12 ]

I think it is the case with every implementation of file upload that I have seen, that the file would be overwritten.

Comment by muellermi [ 26/Nov/12 ]

Hm, better to be a follower or on the cutting edge? Innovation lives from new ideas.
BTW, most file explorers, FTP uploads etc. offers options to prevent or allow overwrite or to keep both versions (rename).

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor

Comment by Neil Griffin [ 29/Aug/14 ]

I recently implemented my idea with the new alloy:inputFile and alloy:validateFile tags in Liferay Faces. For more info, see the Showcase demo.





[JAVASERVERFACES_SPEC_PUBLIC-1290] RFE: Add a var attribute to h:messages that enables the developer to fully control output styling Created: 11/Jul/14  Updated: 13/Aug/14

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

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


 Description   

Please see the OmniFaces messages component:

http://showcase.omnifaces.org/components/messages

"Control iteration markup fully by the new var attribute which sets the current FacesMessage in the request scope and disables the default table/list rendering."

<o:messages var="message">
<li class="#

{fn:toLowerCase(message.severity)}

">#

{message.summary}

</li>
</o:messages>



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1278] UIInput.validateValue() oversteps its authority Created: 15/May/14  Updated: 13/Aug/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3267 UIInput.isEmpty returns false for Sets Closed

 Description   

Consider this text from UIInput.validateValue():

ensure that the local value is not empty (where "empty" is defined as null or a zero-length String).

JAVASERVERFACES-3267 argues that it is a custom converter's responsibility to determine what is meant by "empty", rather than UIInput.



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1226] Inconsistent handling of null/undeclared attributes, especially with nested components Created: 07/Oct/13  Updated: 13/Aug/14

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

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

GF3 + JSF 2.1.26 or GF4 with JSF 2.2.3 with JDK7.0_45


Tags: composite, composite-component, null

 Description   

The origin is here: https://java.net/jira/browse/JAVASERVERFACES-2614, but it's mainly worth reading the summary further down here.

The reproducer is on git@github.com:fabmars/JSF2614.git .
We have an outer component:

test1.xhtml
<composite:interface>
<composite:attribute name="val1" type="java.lang.String"/>
<composite:attribute name="val2" type="java.lang.String"/>
<composite:attribute name="val3" type="java.lang.String" default="#{null}"/>
<composite:attribute name="val4" type="java.lang.String" default="#{null}"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<h:outputText value="Outer1: #{cc.attrs.val1 == null ? 'null' : (empty cc.attrs.val1 ? 'empty' : cc.attrs.val1)}" />
<h:outputText value="Outer2: #{cc.attrs.val2 == null ? 'null' : (empty cc.attrs.val2 ? 'empty' : cc.attrs.val2)}" />
<h:outputText value="Outer3: #{cc.attrs.val3 == null ? 'null' : (empty cc.attrs.val3 ? 'empty' : cc.attrs.val3)}" />
<h:outputText value="Outer4: #{cc.attrs.val4 == null ? 'null' : (empty cc.attrs.val4 ? 'empty' : cc.attrs.val4)}" />
</h:panelGrid>
<sr:test2 val1="#{cc.attrs.val1}" val2="#{cc.attrs.val2}" val3="#{cc.attrs.val3}" val4="#{cc.attrs.val4}" /> 
</composite:implementation>

And an inner component:

test2.xhtml
<composite:interface>
	<composite:attribute name="val1" type="java.lang.String"/>
	<composite:attribute name="val2" type="java.lang.String" default="#{null}"/>
	<composite:attribute name="val3" type="java.lang.String"/>
	<composite:attribute name="val4" type="java.lang.String" default="#{null}"/>
</composite:interface>

<composite:implementation>
	<h:panelGrid>
		<h:outputText value="Inner1: #{cc.attrs.val1 == null ? 'null' : (empty cc.attrs.val1 ? 'empty' : cc.attrs.val1)}" />
		<h:outputText value="Inner2: #{cc.attrs.val2 == null ? 'null' : (empty cc.attrs.val2 ? 'empty' : cc.attrs.val2)}" />
		<h:outputText value="Inner3: #{cc.attrs.val3 == null ? 'null' : (empty cc.attrs.val3 ? 'empty' : cc.attrs.val3)}" />
		<h:outputText value="Inner4: #{cc.attrs.val4 == null ? 'null' : (empty cc.attrs.val4 ? 'empty' : cc.attrs.val4)}" />
	</h:panelGrid>
</composite:implementation>

And the actual page:

jsf2614.xhtml
<sr:test1 val1="AAA" val2="BBB" val3="CCC" val4="DDD"/>
<sr:test1/>
<sr:test1 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/>
<sr:test2  val1="DDD" val2="EEE" val3="FFF" val4="GGG"/>
<sr:test2/>
<sr:test2 val1="#{null}" val2="#{null}" val3="#{null}" val4="#{null}"/>

When running one can notice a couple of odd things:

1st case:
On <sr:test1 .../>

  • feed <composite:attribute name="val1" type="java.lang.String"/> with null. Result: null
  • feed <composite:attribute name="val3" type="java.lang.String" default="# {null}"/> with null. Result: ""
    The developer, in the second line expects to get String var3 = null in the end. Instead he gets a real value.
    OK this is due to the mechanics of coertion but this is not consistent and imo should be fixed.


    2nd case:
    - Call the OUTER component dry <sr:test1/>. var1 isn't declared, so will be assumed null. In sr:test1 implementation is a call to <sr:test2 val1="#{cc.attrs.val1}"... The INNER(sr:test2) component is awaiting a String as val1 (<composite:attribute name="val1" type="java.lang.String"/>) and our non-declared attribute becomes "" (again) in the end! (see that lines 9 vs 13 of the output). In other words: feed a null to <composite:attribute name="val1" type="java.lang.String"/> directly, it stays null, feed it from a surrounding component, it becomes ""!


    3rd case:
    Calling directly the inner component <sr:test2/> and <sr:test2 val1="#{null}

    " val2="#

    {null}" val3="#{null}

    " val4="#

    {null}

    "/> produce totally different results (see lines 29-32 vs 33-36 of the output). This is confusing for the developer and I'm not even sure this is a "feature".



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1208] Allow page authors to define ordering of resources in the <head> Created: 10/Jul/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Components/Renderers, Facelets/VDL, Resources
Affects Version/s: 2.2
Fix Version/s: None

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


 Description   

Right now, developers have no control over the ordering of resources loaded in the HEAD of the document. This can cause problems with ordering of CSS, JavaScript resources, or browser behavior. Something like PrimeFaces' solution (http://blog.primefaces.org/?p=1433) is definitely needed.

I ran into this requirement trying to force IE to use "IE 8 Standards Mode". This requires a <meta> header, but it must be the first element in the <head>. This isn't possible without a custom component or a third-party library like PrimeFaces.. See http://social.msdn.microsoft.com/Forums/ie/en-US/afb57ce6-d149-4a09-8811-63c0645c92e6/force-ie8-to-render-in-ie8-standard-mode.



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

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





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

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

Type: Bug Priority: Major
Reporter: jasonzhang2002gmailcom Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
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

 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 ]

Can you please supply an example that reproduces the problem?

Comment by jasonzhang2002gmailcom [ 09/Jul/13 ]

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 ]

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.

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1184] Support using JSON for component updates instead of XML Created: 22/Apr/13  Updated: 13/Aug/14

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

Type: Improvement Priority: Major
Reporter: kito75 Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

One of the primary complaints about JSF is speed. We have paid a lot
of attention to optimizing server-side state over the past few years,
but we can also optimize the processing on the client. When a
component is updated via Ajax, currently we render the entire
component, even if only one property has changed. It would be much
more efficient if we sent only the changed properties via JSON and let
the client-side representation of the component update itself
accordingly. I have implemented a limited version of this for one of
my clients, and Ajax updates are noticeably faster. Updating the spec
to support this would not be a major change (because components would
opt-in to this feature), but it would have a dramatic affect on
client-side Ajax updates.

Initial EG thread: https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/105

I will post a more formal proposal later.



 Comments   
Comment by arjan tijms [ 11/May/13 ]

This sounds very useful! The title may not tell the whole story though; it's thus not just about JSON vs XML, but also about doing delta updates instead of full updates, right?

Comment by kito75 [ 13/May/13 ]

Arjun, you're exactly right.

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1152] javax.faces.model.SelectItem should have a field for a title attribute for the option item Created: 15/Dec/12  Updated: 13/Aug/14

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

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


 Description   

There is currently no way to set a title attribute on individual html <option> elements. This can be very useful to provide tootip hints if the options are a little cryptic.

It would be necessary to add itemTitle to javax.faces.model.SelectItem, UISelectItem, f:selectItem(s) and to have the ListboxRenderer render it. Several classes changed, but very simple changes to each one.

Given that title is an HTML specific term it might be preferable to call it itemTooltip rather than itemTitle.



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

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

Comment by Ed Burns [ 13/Aug/14 ]

I confirmed that the following does not work:

                <f:selectItem itemLabel="option 1" pt:label="tooltip" />

It should work.





[JAVASERVERFACES_SPEC_PUBLIC-1120] UIData (and related classes) doesn't respect contract for UIComponent process{Decodes, Validators, Updates} Created: 09/Jul/12  Updated: 13/Aug/14

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

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

N/A



 Description   

The javadoc descriptions in UIComponent for the abstract methods processDecodes, processValidators and processUpdates specifies: "Call the processX() method of all facets and children of this UIComponent, in the order determined by a call to getFacetsAndChildren()". UIData and other related components do not respect this.

Clearly, the problem is in the javadoc for UIComponent, which is much too restrictive.

This is important, firstly because obviously the spec should be self consistent, but also because it is very misleading when trying to understand how things fit together. The obvious place to look for information about what, in general, these methods do is the base class javadocs, but if this information is incorrect then from the start you are orientated in the wrong direction. This takes considerable effort to overcome.

Having a complete and accurate description of the responsibilities of the methods would, on the other hand, help understanding.



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1086] h:outputLabel doesn't determine ID of inputs for components which wraps input Created: 30/Mar/12  Updated: 13/Aug/14

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

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


 Description   

Sample:

The code in first snippet results in HTML markup below which is not valid. The for attribute of the label element must refer to a input element.

xhtml
<h:outputLabel value="Date" for="date" />
<rich:calendar id="date" .../>
html
<label for="form:date">Date</label>
<span id="form:date">
  <span id="form:datePopup">
    <input id="form:dateInputDate" name="form:dateInputDate" />
    ...

Issue description:

Some input components (like rich:calendar in the sample bellow) generates a HTML markup which does not have input element in the root of the component, but the input is wrapped instead.

On the other side, h:outputLabel expects that the input has ID=component.getClientId(), which refers to the root of the component (it is span element in case of rich:calendar).

If we would change the ID of the span and use the component.getClientId() for the input, the it would break AJAX mechanism, which expects that the root of the component (here it is the span) bears ID=component.getClientId().


Proposal:

This issue could be fixed by specifying new method component.getInputClientId() for all input components - it could default to clientId, but each component could define how to address its input when overridden.



 Comments   
Comment by lfryc [ 30/Mar/12 ]
JSF RI 2.1.5, LabelRenderer:85
        String forClientId = null;
        String forValue = (String) component.getAttributes().get("for");
        if (forValue != null) {
            forValue = augmentIdReference(forValue, component);
            UIComponent forComponent = getForComponent(context, forValue, component);
            if (forComponent == null) {
                // it could that the component hasn't been created yet. So
                // construct the clientId for component.
                forClientId = getForComponentClientId(component, context,
                                                      forValue);
            } else {
                forClientId = forComponent.getClientId(context);
            }
        }
Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1048] Provide mechanism for component to declare scoped variables Created: 01/Nov/11  Updated: 12/Aug/14

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

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


 Description   

In JSF a component can put a variable into a scope to make it usable for its child components, or possibly other components on the page.

E.g.

<ui:repeat value="#{someBean.items}" var="item">
    <h:outputText value="#{item.name}" />
</ui:repeat>

In this example the ui:repeat component selects a value from someBean.items and makes that available under the name item.

In order for tools to validate the correctness of the item.name expression, they currently make use of hardcoded knowledge of what well known components do. This means that components from libraries that are not explicitly supported by such tools can't be validated. Custom components made by users are thus never validated.

I would like to propose adding a mechanism to JSF for components to declare they make (scoped) variables available.

E.g.

@FacesComponent("components.CustomComponent")
public class CustomComponent extends UIComponentBase {

    @Attribute
    @VariableName(type="#{attributes.value[0]}" scope="component")
    private String var;

    @Attribute
    @VariableSource
    private List<Item> value;

In this example, the component declares that the var attribute is the name for data that is made available during the 'scope of the component' and that the type of this data is an element from the value attribute.

Additionally, it should also be possible that a fixed type is specified, e.g:

@FacesComponent("components.CustomComponent")
public class CustomComponent extends UIComponentBase {

    @Attribute
    @VariableName(type="com.example.SomeType" scope="component")
    private String var;

Of course the given syntax is just a quick sketch of the idea. Maybe @VariableExportName is a better name, @VariableSource might not be needed, etc.

This issue is somewhat related to JAVASERVERFACES_SPEC_PUBLIC-594



 Comments   
Comment by arjan tijms [ 02/Nov/11 ]

Issue JAVASERVERFACES_SPEC_PUBLIC-984 might also be somewhat related to this.

Comment by Ed Burns [ 01/Aug/14 ]

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





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: 12/Aug/14

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

Type: Sub-task Priority: Minor
Reporter: Hanspeter Duennenberger Assignee: Unassigned
Resolution: Unresolved Votes: 3
Labels: None
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 Closed
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-787 Restore ViewScope before templates ar... Closed

 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 ]

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

Comment by Hanspeter Duennenberger [ 03/Sep/12 ]

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 ]

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.

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1024] Allow parents of forms as render targets of ajax requests Created: 11/Jul/11  Updated: 12/Aug/14

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

Type: Bug Priority: Minor
Reporter: frederickkaempfer Assignee: Unassigned
Resolution: Unresolved Votes: 10
Labels: None
Remaining Estimate: 5 hours
Time Spent: Not Specified
Original Estimate: 5 hours

Tags: ajax, facelets, javascript

 Description   

Currently it is not possible to use parents of forms as render targets in <f:ajax/> or jsf.ajax.request. If an element containing one or more forms is specified in the render attribute, these forms' ViewState is not updated during the Ajax request. In my opinion it is not clear from the JSDocs, if parents of forms are allowed as render targets or not. Mojarra currently does not create an error in that case, however the jsf.ajax.request method does not create a ViewState field for descendant forms either.

Judging from the JSDoc the request method's execute parameter is not limited to forms and children of forms, it just takes a list of arbitrary client ids. It's also possible to specify '@all' for the whole view thus most likely a parent of multiple forms, which works as expected.

However the JSDoc for jsf.ajax.response states the following for ViewState updates:

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

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

locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response. Locate and update the javax.faces.ViewState value for all forms specified in the render target list.

This will clearly not work if only forms that are contained in the render target list directly are considered, because the list could also contain parents of forms.

For more information see the corresponding Mojarra bug report:

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



 Comments   
Comment by frederickkaempfer [ 12/Jul/11 ]

"Judging from the JSDoc the request method's execute parameter "

This was meant to be the render parameter.

Comment by frederickkaempfer [ 12/Sep/11 ]

This issue is related to (or even included in) http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790. Since this is obviously a spec bug and a fix is quite simple (updating all forms instead of only a subset defined by the render attribute on an ajax request, see Ed Burns' comment on 790) it would definitely be worth considering for 2.2.

Comment by arjan tijms [ 08/Jan/12 ]

Simple test case from duplicate issue JAVASERVERFACES-1788:

<h:panelGroup layout="block" id="group">
    <h:form>
        <h:commandLink value="Link A">
            <f:ajax />
        </h:commandLink>
    </h:form>
</h:panelGroup>

<h:form>
    <h:commandLink value="Link B">
        <f:ajax render=":group" />
    </h:commandLink>
</h:form>
  1. Press Link A - view state is submitted
  2. Press Link B, then Link A - view state is not submitted anymore
Comment by swathireddy12 [ 22/Aug/13 ]

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

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

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

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-1022] Support base classes as source class for SystemEvents Created: 05/Jul/11  Updated: 12/Aug/14

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

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


 Description   

Originally created on https://issues.apache.org/jira/browse/MYFACES-3185 by Carsten Dimmek:

Registering a system event listener in the faces-config need a concrete class like HtmlInputText. If you wan't to register a listener for let's say all UIInputs you need to explicit configure all subclasses.

<system-event-listener>
<system-event-listener-class>view.RequiredValidationListener</system-event-listener-class>
<system-event-class>javax.faces.event.PostValidateEvent</system-event-class>
<source-class>javax.faces.component.html.HtmlInputText</source-class>
</system-event-listener>

<system-event-listener>
<system-event-listener-class>view.RequiredValidationListener</system-event-listener-class>
<system-event-class>javax.faces.event.PostValidateEvent</system-event-class>
<source-class>javax.faces.component.html.HtmlInputSecret</source-class>
</system-event-listener>

etc.

Supporting base classes would be great:

<system-event-listener>
<system-event-listener-class>view.RequiredValidationListener</system-event-listener-class>
<system-event-class>javax.faces.event.PostValidateEvent</system-event-class>
<source-class>javax.faces.component.UIInput</source-class>
</system-event-listener>

a fine-grained configuration would be still possible through SystemEventListener.isListenerForSource(Object source)



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1018] h:button,h:commandButton: generate an HTML BUTTON if there is content. Created: 16/Jun/11  Updated: 12/Aug/14

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

Type: New Feature Priority: Minor
Reporter: ejp Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

All


Tags: HTML, button, input, render

 Description   

Visual representations of buttons appear to be presently crippled by the inability to include mixed content, e.g. a standard <BUTTON> with an image and a label. h:button and h:commandButton are presently specified only to render as an INPUT with an appropriate type. If there is content inside the tag could they please render as a BUTTON instead? so it works intuitively as expected? Or some other feature to the same end?



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1002] Order of isRendered and pushComponentToEL prevents rendered="#{}" based on component implicit object Created: 17/May/11  Updated: 12/Aug/14

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

Type: Bug Priority: Major
Reporter: Martin Kočí Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Current specification for lifecycles methods:
1) processDecodes
2) processValidators
3) processUpdates
4) encodeAll
4) encodeBegin

explicitly says that:

1) If the rendered property of this UIComponent is false, skip further processing.
2) call pushComponentToEL

But in that order of invocations it is impossible to achieve rendered like this:

<h:outputText rendered="#

{component.id eq 'outputTextId'}

" id="outputTextId" />

i.e. any rendered ValueEpression based on component itself.



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

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





[JAVASERVERFACES_SPEC_PUBLIC-958] Support explicitly defining the resource bundle for a composite component Created: 01/Apr/11  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_medium importance_small


 Description   

Composite components support defining an own ResourceBundle that is accessible via the EL expression "cc.resourceBundleMap". This resource bundle is found by naming convention. There should also be a way of explicitly defining the resource bundle for a composite component. The <cc:interface> tag could be extended with an "resourceBundle" attribute that contains the resource bundle name.



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

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





[JAVASERVERFACES_SPEC_PUBLIC-956] Support rendering of client behaviors inside simple composite components Created: 01/Apr/11  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_medium importance_medium


 Description   

It is already possible to attach behaviors to composite components that are retargeted to via <cc:clientBehavior> but is not possible to attach a behavior directly to a composite component, with no target).

UINamingContainer should implement ClientBehaviorHolder and support decoding of behaviors. It should be possible to configure the supported events using the <cc:clientBehavior> with no "name" attribute or maybe with the special keyword "@this" in the "targets" attribute.

The script of a behavior could be made available in the composite component implementation for example via an EL expression.

Example usage:

<cc:interface>
<cc:clientBehavior event="focus" />
</cc:interface>
<cc:implementation>
<fieldset onfocus="#

{cc.behaviorScript['focus']}

">
...



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

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





[JAVASERVERFACES_SPEC_PUBLIC-908] StylesheetRenderer RenderKit Docs Request Path Rendering Created: 05/Nov/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 908
Status Whiteboard:

size_small importance_medium


 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 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-888] UIInput.submittedValue returns Object, but Converter suggest only String is allowed Created: 23/Sep/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 888
Status Whiteboard:

size_medium importance_medium


 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 ]

Target for 2.2.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-796] Use the model value for a UIViewParameter only on a postbacks Created: 12/May/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 796
Status Whiteboard:

size_small importance_small


 Description   

Imagine you have a page with a required UIViewParameter called input. You will
get a validation error as long as you don't access the view with ?input=abc. Now
if you do that once, "abc" will be saved as the submittedValue in the state of
the UIViewParameter for every postback and thus will be available for every
further postback. If you now access the view again with a GET request
(non-postback), but without ?input=abc, you will again get a validation error.
However, if you hit any button or link on the view to generate another postback
to the view, the validation error will be gone, because UIViewParameter takes
the value from before ("abc") out of the model (managed-bean) and sets it in the
state. Thus you haven't provided it via ?input=abc, but you will now have a
value of "abc" for your UIViewParameter, which seems kinda wrong to me. The
solution to this one is to get the value from the model to set it as the
submittedValue in UIViewParameter only if the current request is a postback.
However I don't know if this really is an error or the expected behaviour. I
personally just think that it is weird.

Answer from Martin Marinschek: "I absolutely agree that we should do this only
on a postback - everything else is really, really weird behaviour."



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

Move to 2.1.

I agree with this approach.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-792] Cannot call UIComponent.getCurrentComponent() from UIComponent.restoreState() or UIComponent.saveState() Created: 11/May/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 792
Status Whiteboard:

size_medium importance_large

Tags: adf

 Description   

From jsr-314-open list:

The javadoc of UIComponent.processRestoreState() says this:

"....Perform the component tree processing required by the Restore View phase
of the request processing lifecycle for all facets of this component, all
children of this component, and this component itself, as follows.

  • Call the restoreState() method of this component.
  • Call pushComponentToEL(javax.faces.context.FacesContext,
    javax.faces.component.UIComponent).
  • Call the processRestoreState() method of all facets and children of this
    UIComponent in the order determined by a call to getFacetsAndChildren(). After
    returning from the processRestoreState() method on a child or facet, call
    popComponentFromEL(javax.faces.context.FacesContext)..."

The javadoc of UIComponent.processSaveState() says this:

".....Perform the component tree processing required by the state saving portion
of the Render Response phase of the request processing lifecycle for all facets
of this component, all children of this component, and this component itself, as
follows.

  • consult the transient property of this component. If true, just return null.
  • Call pushComponentToEL(javax.faces.context.FacesContext,
    javax.faces.component.UIComponent).
  • Call the processSaveState() method of all facets and children of this
    UIComponent in the order determined by a call to getFacetsAndChildren(),
    skipping children and facets that are transient. Ensure that
    popComponentFromEL(javax.faces.context.FacesContext) is called correctly after
    each child or facet.
  • Call the saveState() method of this component.
  • Encapsulate the child state and your state into a Serializable Object and
    return it....."

The question is: Doesn't suppose that when you call
UIComponent.getCurrentComponent() inside UIComponent.restoreState(), it returns
the "current component"?. There is one case when we need to do this call and is
on the wrapper used by UIComponent.subscribeToEvent(). The javadoc of this
method says this:

"....Install the listener instance referenced by argument componentListener as a
listener for events of type eventClass originating from this specific instance
of UIComponent. The default implementation creates an inner SystemEventListener
instance that wraps argument componentListener as the listener argument. This
inner class must call through to the argument componentListener in its
implementation of
SystemEventListener.processEvent(javax.faces.event.SystemEvent) and its
implementation of SystemEventListener.isListenerForSource(java.lang.Object)
must return true if the instance class of this UIComponent is assignable from
the argument to isListenerForSource...."

Both myfaces and mojarra has the wrapper described by the javadoc, and that one
is responsible to save/restore the system event listeners attached. To restore
the "component" reference required, both implementations call
UIComponent.getCurrentComponent() and both call processEvent but for the parent!.

It is obviously a bug (I don't see a valid reason why do the algorithm
described), if you look other methods like processDecodes, you see the right
pattern:

  • If the rendered property of this UIComponent is false, skip further
    processing.
  • Call pushComponentToEL(javax.faces.context.FacesContext,
    javax.faces.component.UIComponent).
  • Call the processDecodes() method of all facets and children of this
    UIComponent, in the order determined by a call to getFacetsAndChildren().
  • Call the decode() method of this component.
  • Call popComponentFromEL(javax.faces.context.FacesContext) from inside of a
    finally block, just before returning.
  • If a RuntimeException is thrown during decode processing, call
    FacesContext.renderResponse() and re-throw the exception.

I'll change myfaces algorithm to look like processDecodes(). But anyway, it is
necessary to do the proper change on mojarra and on spec javadoc.



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

LU> To restore the "component" reference required, both implementations
LU> call UIComponent.getCurrentComponent() and both call processEvent
LU> but for the parent!

Is the bug that we call processEvent on the parent, and not the
"correct" instance?

Comment by Ed Burns [ 18/May/10 ]

>>>>> On Tue, 11 May 2010 11:29:26 -0500, Leonardo Uribe said:

LU> In this case, I'm thinking the bug is do not include restoreState /
LU> saveState on the call. In other words, instead do this:

LU> * Call the restoreState() method of this component.
LU> * Call pushComponentToEL(javax.faces.context.FacesContext,
LU> javax.faces.component.UIComponent).
LU> * Call the processRestoreState() method of all facets and children of
LU> this UIComponent in the order determined by a call to
LU> getFacetsAndChildren(). After returning from the processRestoreState()
LU> method on a child or facet, call
LU> popComponentFromEL(javax.faces.context.FacesContext)..."

LU> Do the following

LU> * Call pushComponentToEL(javax.faces.context.FacesContext,
LU> javax.faces.component.UIComponent).
LU> * Call the restoreState() method of this component.
LU> * Call the processRestoreState() method of all facets and children of
LU> this UIComponent in the order determined by a call to
LU> getFacetsAndChildren(). After returning from the processRestoreState()
LU> method on a child or facet, call
LU> popComponentFromEL(javax.faces.context.FacesContext)..."

LU> In myfaces code, I found I did the latests in our pss algorithm. Really I
LU> discover this bug when I disable pss and try a tomahawk example. As it was
LU> described, both myfaces and mojarra fell in the ilusion the latest strategy
LU> was used.

Comment by Ed Burns [ 24/May/10 ]
      • Issue 799 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 26/May/10 ]

I made the change in my local workspace and am now re-running our automated test suite.

Comment by Ed Burns [ 26/May/10 ]

Hmm, I ran into a very strange case when I changed the code as you suggested.

Before the change: this works

nesting05.xhtml uses composite component

<ez:nesting6 id="nesting6" bean="#

{compositeBean}

" />

the composite component has this:

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

<composite:implementation>
<ez:nesting7 id="nesting7" action="#

{cc.attrs.bean.action}

"
actionListener="#

{cc.attrs.bean.actionListener}

"
validator="#

{cc.attrs.bean.validate}

"
valueChangeListener="#

{cc.attrs.bean.valueChange}

"
bean="#

{cc.attrs.bean}

"/>
</composite:implementation>

nesting7.xhtml has

<composite:interface>
<composite:attribute name="action" method-signature="String method()"
targets="form1:command" />
<composite:attribute name="actionListener" method-signature="void
method(javax.faces.event.ActionEvent)" targets="form2:command2" />
<composite:attribute name="validator" method-signature="void
validate(javax.faces.context.FacesContext, javax.faces.component.UIComponent, java.lang.Object)"
targets="form4:input" />
<composite:attribute name="valueChangeListener" method-signature="void
valueChange(javax.faces.event.ValueChangeEvent)" targets="form5:input2" />
<composite:attribute name="bean" type="com.sun.faces.composite.CompositeBean" />
</composite:interface>
<composite:implementation>
<h:form id="form1">
<h:commandButton id="command" value="action" />
</h:form>
<br />
<h:form id="form2">
<h:commandButton id="command2" value="actionListener" />
</h:form>
<br />
<h:form id="form3">
<h:commandButton id="command3" value="custom" action="#

{cc.attrs.bean.custom}

"/>
</h:form>
<br />
<h:form id="form4">
<h:inputText id="input" />
<h:commandButton id="command" value="valiator"/>
</h:form>
<br />
<h:form id="form5">
<h:inputText id="input2" />
<h:commandButton id="command" value="valueChange" />
</h:form>
</composite:implementation>

Clicking the action button with id "command" gives me:

Action invoked: nesting6:nesting7:form1:command.

With the change in place, I get a facelets error stating that "bean" is a required attribute, even
though it is, in fact, given on the using page, nesting05.xhtml.

Rather than investigate this further, I'm going to push this to 2.1.

Comment by lu4242 [ 28/May/10 ]

Strange. That example does not seems to be related. There is not any problems in
myfaces, because the only place where UIComponent.getCurrentComponent() is
called is from UIComponent system event listener wrapper. I think it is safe to
do the change (at least on myfaces codebase), because it is very unlikely this
scenario happens.

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 03/Nov/10 ]

2.2

Comment by Ed Burns [ 19/Dec/13 ]

2.3

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-772] f:selectItems value="#{myMap}" underspecified Created: 17/Mar/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Attachments: Text File issue-772-test.patch    
Issue Links:
Related
is related to JAVASERVERFACES-1687 Renderers for UISelectMany don't supp... Closed
Issuezilla Id: 772
Status Whiteboard:

size_medium importance_large


 Description   

The documentation of UISelectItems says:

Map - The keys of this object (once converted to Strings) are assumed to be
labels, and the values of this object (once converted to Strings) are assumed to
be values, of SelectItem instances that will be constructed dynamically and
added to the set of available options for the parent component, in the order
provided by an iterator over the keys.

This behavior comes from jsf 1.1, but in jsf 2.0 it was added some new
attributes (from f:selectItems tlddoc):

Version 2 of the specification introduces several new attributes, described
below. These are: var, itemValue, itemLabel, itemDescription, itemDisabled, and
itemLabelEscaped.

Now, what happen if some user do something like this:

<f:selectItems value="#

{myMap}

" var="item"
itemLabel="#

{item.value.someLabelProperty}

" itemValue="#

{item.value}

">

It just does not work, because there is no clear definition about what should
f:selectItems do in this case.

The proposal for solve this one is if var property is set and value implements
Map interface, use the entry object as var, so the user can choose between the
key and some attribute on the item value.



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

This is important for 2.0 Rev a.

Comment by Ed Burns [ 24/May/10 ]

up to p2

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 24/May/10 ]

Leonardo, please re-open this if I am misunderstanding you.

The tlddoc for f:selectItems states that the "value" attribute may be any Collection or array. Map is
neither.

There is a related mojarra issue filed to track the fact that using Map as the type of the enclosing
UISelectMany's value is not working, though, as you point out, it should work.

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

Comment by lu4242 [ 24/May/10 ]

The documentation of f:selectItems and UISelectItems class is in fact different.
I'm taking into account the documentation of UISelectItems as the valid one.
Since f:selectItems creates a UISelectItems instance, the behavior implemented
is the one described on UISelectItems.

If you try to use something like this:

<f:selectItems value="#

{someMap}

"/>

it works since jsf 1.1.

I'll reopen it, because anyway it is necessary to update the documentation.

Comment by Ed Burns [ 27/May/10 ]

Leonardo, we can either specify that the "var" attribute is unsupported for f:selectItems where value is
a Map, or we can push this to 2.1. I am constrained to these choice because to make "f:selectItems
var points to map" work needs a behavior change.

Your call.

Ed

Comment by Ed Burns [ 27/May/10 ]

2.1.

Comment by lu4242 [ 28/May/10 ]

Ok, sounds reasonable let it for 2.1

Comment by Ed Burns [ 01/Jun/10 ]

Created an attachment (id=236)
patch showing this issue

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-770] add component resources depending on the owner component state Created: 17/Mar/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 770
Status Whiteboard:

size_large importance_small


 Description   

All this text is extracted from jsr-314-open mailing list and it is put here as
reference.

[jsr-314-open] add component resources depending on the owner component state

Trying to use the new JSF 2.0 Resource Api I have found one case that maybe it
is of interest on this list.

Suppose a component that needs to add some specific javascript/css file based on
a value. In tomahawk we can do it something like this on the renderer:

if( tabbedPane.isClientSide() ){
addResource.addJavaScriptAtPosition(facesContext,
AddResource.HEADER_BEGIN, HtmlTabbedPaneRenderer.class, "dynamicTabs.js");

This code works because the response is buffered and post-processed.

The problem is how to do that with JSF 2.0?

One could think on use a listener attached to PreRenderComponentEvent, but this
event is called before encodeBegin, so it is useless in this case, because we
need to call it before the whole view is rendered.

Then, you can think do something like this:

@ListenerFor(systemEventClass = PreRenderViewEvent.class)
public class HtmlTabbedPaneRenderer extends HtmlRenderer
......

It does not work too. The reason is the listener is attached to the component
instance, and only the UIViewRoot instance receives the event. If we do the same
as f:event does when PreRenderViewEvent is found (suscribe the listener on
UIViewRoot) we lose the component we are referencing, because it is replaced by
UIViewRoot.

I can solve this one creating a wrapper for ViewHandler that publish a custom
event for all components before render view. but the big question is if jsf 2.0
should support this use case out of the box.

>> Cagatay Civici
>> Why not listening to PostAddToViewEvent with;
>>
>>
>> @ListenerFor(systemEventClass = PostAddToViewEvent.class)
>>public class HtmlTabbedPane extends UIComponentBase

{ >>}

>>
>> and in event listener;
>>
>> if(this.isClientSide()) {
>> viewroot.addComponentResource(...);
>>

Does not work too because in a postback, PostAddToViewEvent occur in the
following cases:

  • With Partial State Saving enabled when the view is build but before the state
    of the component is restored.
  • With Partial State Saving disabled when the view is "refreshed", because all
    component nodes are detached and attached to the tree.

Now suppose the component has a ValueExpression attached to the property, and
the value changes on Invoke Application Phase. With partial state saving the
tree was already build, so it doesn't catch the logic. With partial state saving
disabled, the event occur twice, the first time when the tree structure is
build, the second time when the view is updated, so again it doesn't work,
because if the resource component (it is transient too) was already added, it
cannot be removed later.

>> Ed Burns
>>
>>Please correct me if I'm wrong, but the problem you state above seems to
>>be just another example of the garden variety "conditional value changes
>>between requests or during a request".
>>

Yes and no. The difference with other examples of the garden is to add a
component resource, we need to do it in the right time, since it requires to
update the component tree adding components before render it, but after we know
which view will be rendered. Please note by a previous fix, all component
resources are transient.

As a side note, if someone wants to do this in a composite component he/she
probable do this:

<c:if test="#

{cc.attrs.....}

">
<h:outputStylesheet ..../>
</c:if>

And it works in myfaces because we have a fix for the c:if problem.

>> Do we need PreAddComponentResourceEvent and
>> PostAddComponentResourceEvent?

In my opinion is only necessary to add only one event. The right place is after
resolve PreRenderViewEvent, because only in that time we know the current
component tree is the view that will be rendered.

It is not possible to use PreRenderComponentEvent because it is called on
encodeBegin and the view header was already rendered.

It is not possible to use PreRenderViewEvent like this:

@ListenerFor(systemEventClass = PreRenderViewEvent.class)
public class HtmlTabbedPaneRenderer extends HtmlRenderer

because the listener is attached to the component when it is created, but the
event is only received by the current UIViewRoot. If we fix the algorithm on
Application class to attach this listener to the current UIViewRoot instance,
the source of the event will be UIViewRoot, and traverse the tree to find the
component is worse. Note other option is publish PreRenderViewEvent for all
child components, but after know the view that will be rendered.

In conclusion, for make this use case possible we need two things:

1. The right time to add the resource to the component tree.
2. The component with its state restored and updated.

Thinking more about it, another option about put this code could be on
vld.buildView method, but note when partial state saving is enabled this method
return immediately (maybe it is possible to change it).



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

Move to 2.1

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-756] <h:column> hides native HTML <td> tag attributes. Created: 02/Mar/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 756
Status Whiteboard:

cat2 renderkitdoc size_small importance_small


 Description   

There's no simple way of setting the HTML attributes on each column (width,
align, etc.) You have to go through CSS styles, which is a more complex way
(albeit better long-term way) of making static width tables / columns.

<h:column> should support the native HTML tag attributes applicable for <td>
elements:

A complete list of attributes can be found here
(http://w3schools.com/tags/tag_td.asp) but the most critical are:

align, valign



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-704] UIRepeat et al are not specified Created: 16/Dec/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 704
Status Whiteboard:

cat2 javadoc size_medium importance_large draft


 Description   

with JSF 2.0, thanks to Facelets, there is a <ui:repeat>. While I understand
that tags/rendering behavior is part of the internals of an implementation, I am
not really sure if the underlying/related components should be "hidden" by the
spec as well.

For instance: I noticed that in MyFaces the UIRepeat extends UIComponentBase and
implements NamingContainer, while with the JSF RI / Mojarra, the UIRepeat "just"
extends the UINamingContainer...

... and oh yes... I know that UINamingContainer extends UIComponentBase and
implements NamingContainer....

but instanceof UINamingContainer doesn't say TRUE for the MyFaces UIRepeat

See a community related discussion here:
http://markmail.org/message/wllfudu4ge7n5gxa



 Comments   
Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

javadoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 23/Jun/10 ]

triage

Comment by Ed Burns [ 19/Jul/10 ]

https://glassfish.dev.java.net/issues/show_bug.cgi?id=11785

On Mon Apr 12 15:57:00 +0000 2010, mohammadalavi MA wrote

MA> I've found 2 bugs in jsf 1.2 here's the list
MA>
MA>
MA> 1.when h:dataTable's parent is ui:repeat from facelet duplicated ids
MA> are generated for child component because UIData's
MA> isNestedWithinUIData method reports true
MA> only when the parent is an instance of UIData and UIRepeat is not.
MA> of course the problem happens because the UIData's getClientId method
MA> caches the parent client id when isNestedWithinUIData returns false
MA> if it never cache parent client id this problem wont happen.
MA>
MA> public String getClientId(FacesContext context) {
MA> if (context == null)

{ MA> throw new NullPointerException(); MA> }

MA> if (rowIndex >= 0)

{ MA> String cidBuilder = new StringBuilder(); MA> return cidBuilder.append(super.getClientId(context)) MA> .append(NamingContainer.SEPARATOR_CHAR).append(rowIndex) MA> .toString(); MA> }

else

{ MA> return super.getClientId(context); MA> }

MA> }
MA> 2.TableMetaInfo a static inner class in BaseTableRenderer is used for
MA> managing style for columns and rows, the getCurrentColumnClass method
MA> doesn't work as expected it doesn't repeat the styles when number of
MA> columns is grater than column classes it should be implemented as
MA> follows:
MA>
MA> public String getCurrentColumnClass() {
MA>
MA> String style = null;
MA> if (columnStyleCounter < columnClasses.length &&
MA> columnStyleCounter < columnCount)

{ MA> style = columnClasses[columnStyleCounter++]; MA> }

MA> if(columnStyleCounter >= columnClasses.length)

{ MA> columnStyleCounter = 0; MA> }

MA> return ((style != null && style.length() > 0) ? style : null);

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-634] Add an escape attribute to h:messages and h:message like in h:outputText Created: 22/Sep/09  Updated: 12/Aug/14

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

Type: Improvement Priority: Major
Reporter: rdelaplante Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 634
Status Whiteboard:

cat2 renderkitdoc size_small importance_medium


 Description   

I want to output an HTML link as part of my error message, but can't because the
HTML is escaped by h:messages. I searched Google for a workaround and found
many people have the same problem. There have even been tickets created against
JSF RI and MyFaces years ago.

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=746
http://issues.apache.org/jira/browse/MYFACES-155



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 24/Feb/10 ]

Target 2.0 Rev A

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

rk

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by kellerapps [ 18/Apr/11 ]

I understand the use case. I'm not convinced HTML is the best way to express this sort of thing. Maybe Message should be enriched to express link & emphasis.

Comment by bleathem [ 03/Apr/12 ]

RichFaces supports this attribute with it's rich:message component (see: http://docs.jboss.org/richfaces/latest_4_X/vdldoc/rich/message.html)

Primefaces also supports this attirbute in it's message tag:
http://blog.primefaces.org/?p=1894

It seems to me it's something the community is asking for, and should be rolled into the spec.

Comment by cagatay_civici [ 03/Apr/12 ]

I agree that this should be in spec, I've seen various posts in PrimeFaces forum and stackoverflow from users who are looking for this.

Comment by rdelaplante [ 04/Apr/12 ]

This isn't just for putting links in error messages, it can also be useful for rich error messages including bold and italic of some words.

Comment by rdelaplante [ 11/Jul/14 ]

This feature is implemented in OmniFaces:

http://showcase.omnifaces.org/components/messages

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-560] Add @AjaxResource to simplify use of the standard Ajax resource Created: 06/May/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 560
Status Whiteboard:

cat2 javadoc size_medium importance_small


 Description   

In order to use the standard JSF Ajax resource in a component or renderer, the
developer must use the following annotation:

@ResourceDependency (name="jsf.js", library="javax.faces",
target="head")

This requires that the developer remembers specific literal strings. I propose a
simple meta annotation:

@AjaxResourceDependency

Which includes the above parameters.



 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

This is something like a CDI stereotype.

Comment by Ed Burns [ 17/Mar/10 ]

javadoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

Leave unchanged





[JAVASERVERFACES_SPEC_PUBLIC-546] Add a way to check for the attributes set on a compositecomponent. Created: 23/Apr/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 546
Status Whiteboard:

cat2 frame size_small importance_small


 Description   

We probably need a way to conditionally add attributes to components in the implementation of a
compositecomponent (cc) or at least be able to check, if an attribute was set on the cc.
Especially it is not (easily) possible to find out by using EL, if an attribute on the cc has been set or
resolves to null/"" as #

{empty cc.attrs.attributename}

will be true eitherway.

Examples:
1) There are components which will change their behaviour if an attribute is set (even to null or "")
contrary to not being set.

2) There may be attributes which are not allowed to be set to null

3) Lets say I have a component
<c:set var="bean" value="#

{someBackingBean.selectedItem}

" />
<x:beanInput id="phoneNumber" />
<x:beanInput id="street" value="#

{bean.address.street}" />

implemented in this way:
...
<h:inputLabel id="#{id}Label" for="#{id}" />
<h:inputText id="#{id}" value="#{empty value ? bean[id] : value}" />
...
if #{bean.address.street}

is null, we will end up with a value bound to bean.street, which probably is not
the desired effect.

Two proposals:

  • add something like <f:insertAttribute name="attributename" value="attributenameOnCC" /> which
    will only add the attribute, if it was set on the cc
    This would also allow to have some sort of workaround for paththrough attributes.
    Example:
    <my:customcomponent onmouseoverLeft="alert('left')" onmouseoverRight="alert('right')" ... />
    with implementation:
    <h:sometag id="Leftone" ...>
    <c:foreach var="event" items="# {fx:split("mouseover,mouseout,click,focus,blur")}

    ">
    <f:insertAttribute name="on#

    {event}" value="on#{event}

    Left" />
    </c:foreach>
    </h:sometag>

  • Introduce a way to check if an attribute was set on the cc by EL. Something like
    cc.attrsIsSet.nameofattr => true/false.
    (with cc being available, developers could write EL-functions themselves, but it would be helpful to
    have an easier way to check it)


 Comments   
Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 17/Mar/10 ]

frame

Comment by Ed Burns [ 27/Apr/10 ]

no sig change

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

rogerk

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

Leave priority.





[JAVASERVERFACES_SPEC_PUBLIC-478] rendered attribute is overloaded Created: 02/Oct/08  Updated: 12/Aug/14

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

Type: Bug Priorit