Java.net JIRAhttps://java.net/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+JAVASERVERFACES_SPEC_PUBLIC+AND+status+%3D+Open+ORDER+BY+priority+DESC
An XML representation of a search requesten6.2.3626015-04-2014[JAVASERVERFACES_SPEC_PUBLIC-1029] viewParam value lost after validation errorshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1029
javaserverfaces-spec-public<p>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 <b>will</b> be queried for its value.</p>
<p>In effect, the retained value is typically lost when the model is in request scope.</p>
<p>The following reproduces this:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>viewparam.xhtml</b></div><div class="codeContent panelContent">
<pre class="code-xml">&lt;html xmlns=<span class="code-quote">"http://www.w3.org/1999/xhtml"</span>
<span class="code-keyword">xmlns:h</span>=<span class="code-quote">"http://java.sun.com/jsf/html"</span>
<span class="code-keyword">xmlns:f</span>=<span class="code-quote">"http://java.sun.com/jsf/core"</span>
&gt;
<span class="code-tag">&lt;f:metadata&gt;</span>
<span class="code-tag">&lt;f:viewParam id=<span class="code-quote">"id"</span> name=<span class="code-quote">"id"</span> value=<span class="code-quote">"#{viewParamBean.id}"</span>/&gt;</span>
<span class="code-tag">&lt;/f:metadata&gt;</span>
<span class="code-tag">&lt;h:body&gt;</span>
<span class="code-tag">&lt;h:messages /&gt;</span>
#{viewParamBean.id} <span class="code-tag">&lt;br/&gt;</span>
<span class="code-tag">&lt;h:form&gt;</span>
<span class="code-tag">&lt;h:inputText value=<span class="code-quote">"#{viewParamBean.text}"</span> &gt;</span>
<span class="code-tag">&lt;f:validateLength minimum=<span class="code-quote">"2"</span>/&gt;</span>
<span class="code-tag">&lt;/h:inputText&gt;</span>
<span class="code-tag">&lt;h:commandButton value=<span class="code-quote">"test"</span> action=<span class="code-quote">"#{viewParamBean.actionMethod}"</span>/&gt;</span>
<span class="code-tag">&lt;/h:form&gt;</span>
<span class="code-tag">&lt;/h:body&gt;</span>
<span class="code-tag">&lt;/html&gt;</span>
</pre>
</div></div>
<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>ViewParamBean.java</b></div><div class="codeContent panelContent">
<pre class="code-java">@ManagedBean
@RequestScoped
<span class="code-keyword">public</span> class ViewParamBean {
<span class="code-keyword">private</span> <span class="code-object">long</span> id;
<span class="code-keyword">private</span> <span class="code-object">String</span> text;
<span class="code-keyword">public</span> void actionMethod() {
}
<span class="code-keyword">public</span> <span class="code-object">long</span> getId() {
<span class="code-keyword">return</span> id;
}
<span class="code-keyword">public</span> void setId(<span class="code-object">long</span> id) {
<span class="code-keyword">this</span>.id = id;
}
<span class="code-keyword">public</span> <span class="code-object">String</span> getText() {
<span class="code-keyword">return</span> text;
}
<span class="code-keyword">public</span> void setText(<span class="code-object">String</span> text) {
<span class="code-keyword">this</span>.text = text;
}
}
</pre>
</div></div>
<p>If you call the Facelet with viewparam.xhtml?id=12 it will display the 12 onscreen. If you then input something valid, e.g. <em>aaaaa</em>, 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 <em>a</em>), the id will be permanently lost. Entering valid input afterwards will not bring it back.</p>
<p>The implementation of encodeAll of UIViewParameter in Mojarra highlights what's happening:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>UIViewParameter.java</b></div><div class="codeContent panelContent">
<pre class="code-java"><span class="code-keyword">public</span> void encodeAll(FacesContext context) <span class="code-keyword">throws</span> IOException {
<span class="code-keyword">if</span> (context == <span class="code-keyword">null</span>) {
<span class="code-keyword">throw</span> <span class="code-keyword">new</span> NullPointerException();
}
<span class="code-comment">// <span class="code-keyword">if</span> there is a value expression, update view parameter w/ latest value after render
</span> <span class="code-comment">// QUESTION is it okay that a <span class="code-keyword">null</span> string value may be suppressing the view parameter value?
</span> <span class="code-comment">// ANSWER: I'm not sure.
</span> setSubmittedValue(getStringValue(context));
}
<span class="code-keyword">public</span> <span class="code-object">String</span> getStringValue(FacesContext context) {
<span class="code-object">String</span> result = <span class="code-keyword">null</span>;
<span class="code-keyword">if</span> (hasValueExpression()) {
result = getStringValueFromModel(context);
} <span class="code-keyword">else</span> {
result = (<span class="code-keyword">null</span> != rawValue) ? rawValue : (<span class="code-object">String</span>) getValue();
}
<span class="code-keyword">return</span> result;
}
</pre>
</div></div>
<p>Because <em>hasValueExpression()</em> in <em>getStringValue()</em> 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).</p>
<p><b>Expected behavior:</b> After validation errors occur, the model should not be consulted (e.g. as implemented by Mojarra's <em>HtmlBasicRenderer#getCurrentValue</em>)</p>
JAVASERVERFACES_SPEC_PUBLIC-1029viewParam value lost after validation errorsBugCriticalOpenUnresolvedarjan tijmsarjan tijmsTue, 2 Aug 2011 21:22:48 +0000Fri, 4 Sep 2015 18:20:57 +00002.1Components/Renderers1515<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Critical</p>Rank0|i004an:Rank (Obsolete)697Tagsstatevalidation[JAVASERVERFACES_SPEC_PUBLIC-947] Relative Resourceshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-947
javaserverfaces-spec-public<p><a href="https://issues.apache.org/jira/browse/MFCOMMONS-29" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MFCOMMONS-29</a></p>
<p>The features of this ResourceHandler include the following:</p>
<ul class="alternate" type="square">
<li>relative paths between resources (css files referencing images<br/>
without using #resource<span class="error">&#91;&#39;..&#39;&#93;</span>)</li>
<li>caching resources in the client (disabled if ProjectStage == Development)</li>
<li>GZIP compression and local cache in tmp dir (disabled if<br/>
ProjectStage == Development)</li>
<li>i18n (supporting country code and language).</li>
</ul>
<p>In addition, it does NOT support ValueExpressions in resource files<br/>
for performance reasons.</p>
<p>The most important feature, in my opinion, is how the resource URL is<br/>
built, e.g. /faces/javax.faces.resource/de_AT/$/some/library/$/my/resource.css</p>
<p>... because it permits resources referencing other resources without<br/>
#</p>
{resource['...']}
<p> (e.g. css files referencing images or other css<br/>
files). With the standard ResourceHandler this is 1) annoying if you<br/>
have to change the files you get from your designer and 2) a<br/>
performance bottleneck, because resources with ValueExpressions are<br/>
not cached and also regenerated for each request.</p>
<p>Furthermore, the resource URL contains the locale and thus you have no<br/>
problems with cached resources if a users changes the locale, because<br/>
he/she will get a new URL and thus a new resource (the right one). </p>JAVASERVERFACES_SPEC_PUBLIC-947Relative ResourcesNew FeatureCriticalOpenUnresolvedEd BurnsEd BurnsWed, 9 Mar 2011 14:04:21 +0000Fri, 4 Sep 2015 21:03:33 +00002.2Resources2475 days5 days5 days5 days2 hours<p>add duplicate links.</p><p>Just found out that ICEFaces actually provides a tool for processing url() references in css files which are served by JSF 2.0. For example, this tool creates url(#</p>
{resource['org.site.lib/images/background.png']}
<p>) out of url(../images/background.png).</p>
<p>This shows the big impact of this issue, I think.</p>
<p>See <a href="http://wiki.icefaces.org/display/ICE/ACE+CSS+URL+Mapping" class="external-link" rel="nofollow">http://wiki.icefaces.org/display/ICE/ACE+CSS+URL+Mapping</a> for more details!</p>
<p>We seriously need to fix this with JSF 2.2! Such (annoying) preprocessing should not be necessary.</p><p>Hi Jakob,</p>
<p>it would be usefull if there was a way to specify resources depending on the active ProjectStage - e.g. for css and Javascript files, to allow using packaged resources normally but uncompressed css/javascript when ProjectStage is set to Development. </p>
<p>I was discussing this once with someone and we ended up in a possible solution for that to put additional includeProjectStage/excludeProjectStage condition attributes on @ResourceDependency annotation and probably also same attributes on outputStylesheet/outputScript tags.</p>
<p>Might be this ends up in an additional independent issue, but as you are going to work on ResourceHandling anyway I feel adding it here is ok.</p>
<p>regards<br/>
Hanspeter</p><p>In MyFaces and Tomahawk a custom hack is used to check if the project stage is Development and if a resource under META-INF/internal-resources (or in tomahawk META-INF/uncompressed-js-resources), just take this instead the compressed version used in Production stage.</p>
<p>I believe that it could be more simple to assume a "mirror uncompressed" location, and in practice use some plugin to compress the resources, and add the logic on the default (or custom) ResourceHandler algorithm.</p>
<p>EB&gt; This approach breaks down when there is not a 1:1 mapping between<br/>
EB&gt; compressed and non-comporessed resources. For example, when you<br/>
EB&gt; want all your JS in one compressed file at Production time, and want<br/>
EB&gt; several smaller, non-compressed files, at Development time.</p><p>Hi Hanspeter,</p>
<p>This is a very, very nice idea! I will prototype that in my relative-resource-handler at apache-extras (see <a href="http://code.google.com/a/apache-extras.org/p/relative-resource-handler/" class="external-link" rel="nofollow">http://code.google.com/a/apache-extras.org/p/relative-resource-handler/</a>).</p>
<p>Also: Since I will have more time in the next two weeks, I really do hope to get some work done for the spec!</p>
<p>Regards,<br/>
Jakob</p><p>Hi Jakob,</p>
<p>any progress here? </p>
<p>I wanted to add something about the ProjectStage dependent resources. There might be two options for it:</p>
<p>1. use a project stage dependent resource path in the jar (similar to Locale handling with fallback). This is useful if the resource is the same name but only compressed for production, e.g.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
myJs/some.js
myJs/production/some.js (compressed some.js)
</pre>
</div></div>
<p>2. because the JS files may get pretty big, we would like to use multiple JS files for development but combine/compress a number of such JS files to one for production. This means the number of resource dependencies change depending on project stage.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
myJs/funct-a.js
myJs/funct-b.js
myJs/funct-c.js
myJs/{production/}funct-all.js (compressed combination of funct-*.js files)
</pre>
</div></div>
<p>So for example, it should be possible to state one component needs funct-a.js and funct-b.js when in project stage Development and only funct-all.js when in project stage Production.</p>
<p>I think possibility 1 is a little closer to what Leonardo mentioned about the MyFaces specific hack. <br/>
I really would like to have a specified way to handle project-stage specific resources, this might need some discussion in expert group though.</p>
<p>Cheers<br/>
Hanspeter</p>
<p>Hi Hanspeter,</p>
<p>Currently I am trying to convince a professor at Vienna university of technology to let me write about the relative resource handler for my bachelor thesis. If this will be accepted, I will have a lot more time for the resource handler.</p>
<p>The idea is really very, very great and I'd like to do some prototyping here. However, I don't know if we should really follow a convention-over-configuration approach. I am actually not sure if we can find a convention for the resource name that will fit in most scenarios. Maybe we need some configuration mechanism here...</p>
<p>Regards,<br/>
Jakob</p><p>Hi all.</p>
<p>For multiple skins or theme support it will be necessary that the resource path may contain an optional skin or theme-path part. </p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
Skin-one
/resources/skin-one/css/main.css
Skin-two
/resources/skin-two/css/main.css
</pre>
</div></div>
<p>The reference to this resource could be:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;h:outputStylesheet name=<span class="code-quote">"main.css"</span> library=<span class="code-quote">"css"</span> /&gt;
</pre>
</div></div>
<p>I have kind of such an implementation, but it is probably to much integrated with our Skin interface. It should be a more general solution.</p>
<p>Regards<br/>
Hanspeter</p><p>Hi hanspeter,</p>
<p>You are totally right! In my resource handler I called it "support for multi-tenancy", however, this is not implemented yet.</p>
<p>Actually you need to add every information you need to determine the correct resource into the resource path, thus it somehow is a REST url. I also added a resource-version to the path in order to deal with resource-update-browser-cache problems.</p>
<p>Regards,<br/>
Jakob</p>
<p>Jakob, can you please hack upon this sample war to make it show the problem? The current war does use relative resources, but the browser is able to resolve them. Can you make it so the browser cannot resolve them?</p><p>Hi Ed,</p>
<p>Your sample is somehow funny. You use a css file in webapp/resources/library/style.css using relative paths like this: url(../../included.css) and url(../../expert-draft-bg.png). The two referenced resources, of course, are located two folders up in the directory tree (directly in webapp).</p>
<p>Now as it would seem to be logical that this works, it really is a coincidence. You see, style.css is loaded via the following url:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
http:<span class="code-comment">//localhost:8080/faces/javax.faces.resource/style.css?ln=library</span>
</pre>
</div></div>
<p>Thus, included.css and expert-draft-bg.png are loaded by the browser using the following urls:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
http:<span class="code-comment">//localhost:8080/included.css
</span>http:<span class="code-comment">//localhost:8080/expert-draft-bg.png</span>
</pre>
</div></div>
<p>The 1st ".." removed "javax.faces.resource" and the 2nd ".." removed "faces" (however, you would actually think that the 1st ".." removes library and the 2nd ".." removes "resources"). This, of course, only works because tomcat (or any other servlet container) serves the two files directly, and it has nothing to do with the JSF resource handler (e.g. ValueExpressions won't work!).</p>
<p>Now, there are a number of possibilities to break the example:<br/>
1) use <b>.jsf instead of /faces/</b> FacesServlet mapping<br/>
2) locate the two resources in the same folder as style.css (while removing the ".." sequences in style.css)<br/>
3) locate the two resources in the classpath (META-INF/resources)<br/>
...</p>
<p>I used the 2nd of the above options in my sample_broken.zip.</p>
<p>Here, style.css still gets loaded via:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
http:<span class="code-comment">//localhost:8080/faces/javax.faces.resource/style.css?ln=library</span>
</pre>
</div></div>
<p>But now the browser tries to locate included.css and expert-draft-bg.png using these urls:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
http:<span class="code-comment">//localhost:8080/faces/javax.faces.resource/included.css
</span>http:<span class="code-comment">//localhost:8080/faces/javax.faces.resource/expert-draft-bg.png</span>
</pre>
</div></div>
<p>Which does NOT work, because the library request parameter is missing. My approach (<a href="http://code.google.com/a/apache-extras.org/p/relative-resource-handler/" class="external-link" rel="nofollow">http://code.google.com/a/apache-extras.org/p/relative-resource-handler/</a>) creates an url in which the library is included in the url path, thus this will work.</p>
<p>If you have any further questions, please ask!</p>
<p>Regards,<br/>
Jakob</p><p>Added sample_broken.zip</p><p>Thanks for demonstrating to me exactly how this is broken.</p>
<p>Now I can proceed to better see how to fix it!</p><p>Looking at your relative-resource handler, it is immediately apparent that the ability for the relative resources to even work is based on how you are encoding the library name differently from what is specified. As stated in the javadocs for RelativeResourceHandler, you have to use </p>
<p> META-INF/relative-resources.xml</p>
<p>to declare libraries and we can't accept that requirement in the spec. Also, the stated limitation of only being able to work with prefix mapped JSF runtimes is unacceptable.</p>
<p>I can see why you made these decisions and how they enable the nice features of your Relative ResourceHandler, but we need to figure out how to do what you request without making unacceptable compromises.</p><p>Jakob, what is the main reason for being dissatisfied with this syntax for relative resources?</p>
<p>css_master.css:</p>
<p>@import url(#</p>
{resource['this:layout.css']}
<p>);</p>
<p>Is it performance? </p>
<p>The need to have the libraryName configured in relative-resources.xml does only exist, because I needed a way to enable the RelativeResourceHandler only for certain libraries. This would not be necessary if the standard ResourceHandler already uses the "relative-mechanism" (for all libraries).</p>
<p>There are many reasons:</p>
<p>1) Acceptance: There is no other framework (at least which I know of), in which you cannot use relative paths between resources as they would work in the file system. Nearly every IDE supports "resource-exists-checks" in css files with relative paths in the file system, and these IDEs will mark #</p>
{resource[]}
<p> url references as errors. Every server (http or servlet container), CDN,... supports relative paths in the URLs like a normal file system, why should JSF do this differently?</p>
<p>2) Effort: You need quite a lot of time to change a big CSS framework (which you will get from your designers) into a working JSF version. And remember, next day the designer may change something, then you will get a new version of the whole CSS framework, and the work starts again...</p>
<p>3) Performance: Actually, having ValueExpressions in resource files is not only a performance killer, it also gives the developer the impression as if she could change resource file contents in every request, whereas she really cannot, because the resource will get cached by the browser/proxy.</p>
<p>I actually would not use the current JSF ResourceHandler because of these points and instead let tomcat (or even weblets) handle my resources, because they both support relative paths like a calm.</p><p>A resource path from Jakob's impl looks like<br/>
"/javax.faces.resource/1.0.0/en_US/css/style.css". Does that 1.0.0<br/>
refer to library version or resource version?</p>
<p> Here's a clue, from RelativeResourceHandler#132.</p>
<p> // skip version in url (first part, only there to avoid cache problems on updates)<br/>
final int versionSlash = resourceName.indexOf('/');</p>
<p>But that still doesn't answer my question. What does the 1.0.0 mean?</p>
<p>Jakob's ResourceHandler.createResource() allows the entire resourceId to<br/>
be in the "resourceName", which it re-interprets according to its own<br/>
rules if it determines that the library is not a JSF 2.0 style resource<br/>
library.</p>
<blockquote>
<p>JK&gt; The need to have the libraryName configured in<br/>
JK&gt; relative-resources.xml does only exist, because I needed a way to<br/>
JK&gt; enable the RelativeResourceHandler only for certain libraries. This<br/>
JK&gt; would not be necessary if the standard ResourceHandler already uses<br/>
JK&gt; the "relative-mechanism" (for all libraries).</p></blockquote>
<p>Ok, let's say we make relative libraries the default for prefix mapped<br/>
applications. If we have a jar in the classpath that contains a library<br/>
that is arranged according to the JSF 2.0 spec for resource libraries,<br/>
we now we need some way to detect that case and use the JSF 2.0 style<br/>
arrangement, right?</p>
<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Critical</p>DuplicateJAVASERVERFACES_SPEC_PUBLIC-884JAVASERVERFACES_SPEC_PUBLIC-900JAVASERVERFACES-1189RelatedJAVASERVERFACES_SPEC_PUBLIC-1079JAVASERVERFACES_SPEC_PUBLIC-548JAVASERVERFACES_SPEC_PUBLIC-884JAVASERVERFACES_SPEC_PUBLIC-996Rank0|i004d3:Rank (Obsolete)708Status Whiteboard<p>size_small importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-559] Support for the "Synchronizer Token" pattern (avoiding double submits)https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-559
javaserverfaces-spec-public<p>This is a very common web application problem<br/>
(<a href="http://www.javajunkies.org/index.pl?lastnode_id=3361&amp;node_id=3355" class="external-link" rel="nofollow">http://www.javajunkies.org/index.pl?lastnode_id=3361&amp;node_id=3355</a>) &#8211; avoiding<br/>
double submits. Struts had built-in support for this. JSF-related implementations:</p>
<ul>
<li>Apache Shale &lt;s:token&gt; component:<br/>
<a href="http://shale.apache.org/shale-core/tagreference.html" class="external-link" rel="nofollow">http://shale.apache.org/shale-core/tagreference.html</a></li>
<li>MyFaces Orchestra (patch): <a href="https://issues.apache.org/jira/browse/ORCHESTRA-40" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/ORCHESTRA-40</a></li>
<li>JBoss Seam &lt;s:token&gt; component (primary goal is to avoid cross-site<br/>
scripting):<br/>
<a href="http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF" class="external-link" rel="nofollow">http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF</a></li>
</ul>
<p>Spring Web Flow, Struts 2, and Grails 1.1<br/>
(<a href="http://www.grails.org/1.1+Release+Notes" class="external-link" rel="nofollow">http://www.grails.org/1.1+Release+Notes</a>) also support this natively.</p>
<p>I'd really like to see this in JSF 2.1 at the very latest.</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-559Support for the "Synchronizer Token" pattern (avoiding double submits)New FeatureCriticalOpenUnresolvedkito75kito75Tue, 5 May 2009 18:39:18 +0000Fri, 11 Sep 2015 13:37:14 +00002.0Lifecycle1312<p>Move to 2.1. Also make this handle Dan's concern here:</p>
<p>DA&gt; It's crucial that the enablement of this feature be accompanied by a<br/>
DA&gt; secure token being exchanged in the case of server-side state<br/>
DA&gt; saving.</p><p>Prepare to delete "spec" subcomponent.</p><p>Move these to unscheduled because we need to target them correctly. 2.next isn't <br/>
specific enough.</p><p>cat2</p><p>lifecycle</p><p>Transaction token has been requested many times over the years.</p><p>I've got some code I wrote for a client based on Shale's token that I can clean up and submit as a <br/>
prototype. If you're interested, just let me know when it's time.</p><p>These are targeted at 2.1.</p><p>triage</p><p>GlassFish 3.1 M6 at the latest.</p><p>xsrf</p>
<p>Security related, target for GlassFish 3.1 M3</p><p>cat3</p><p>Hey Kito - </p>
<p>It's time. Let's see what you have. If you can also submit a proposal that<br/>
would be helpful as well.</p>
<p>-roger</p><p>This could probably reside in the core namespace - like f:token ?</p><p>Roger, please take a look at <a href="https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812" class="external-link" rel="nofollow">https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=812</a> for more <br/>
valuable information.</p><p>Ahh yes - thanks for the pointer. Apparently there are many ways to skin this<br/>
cat ....</p><p>Created an attachment (id=255)<br/>
Sample CSRF Solution (JSF 1.2)</p><p>Created an attachment (id=256)<br/>
Sample CSRF Solution (JSF 1.2) &#8211; the other file is for avoiding double submits</p><p>I have attached two samples:</p>
<ul>
<li>jsf2token.war &#8211; sample UIToken component specifically for avoiding double submits (but would<br/>
probably handle CSRF attacks too)</li>
<li>jsf2csrf.war &#8211; sample solution for handing Cross-site Request Forgery (CSRF) attacks only.</li>
</ul>
<p>The source for both is in the WEB-INF/classes directory.</p>
<p>The token approach uses a standard JSF component that outputs a hidden field in the form. The hidden <br/>
field is created based on a server-generated secret key plus other information, such as the current view <br/>
id. What's a little different is that a phase listener decodes the component before Apply Request Values. <br/>
The goal here was to check the token before any other decoding takes place. Also, the token isn't <br/>
released until after Invoke Application to ensure that application processing has occurred.</p>
<p>For JSF 2, I think either enhancing UIForm, providing an alternate UIForm, or using a ClientBehavior <br/>
might be a better option than a separate component. Using UIForm would avoid the need to handle <br/>
decoding in the PhaseListener.</p>
<p>The CSRF approach is a little different. It still generates a special token based on a server-generated <br/>
secret key, but it does so based on the session, not on the view. It then appends the token to every JSF-<br/>
generated request through ViewHandler.getActionURL(). It uses a PhaseListener to ensure that every <br/>
incoming request has a valid token. </p>
<p>It's possible to combine these approaches, but I like the way the CSRF approach doesn't require anything <br/>
on the part of the developer. The caveat is that since it's session-based, it's probably not secure as a <br/>
form-based approach. Also, a form-based variant is required to avoid double-submits.</p>
<p>I'm not familiar with back button solutions, so I can't comment on how this code is applicable.</p><p>We should also consider the Seam &lt;s:token&gt; approach <br/>
(<a href="http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF" class="external-link" rel="nofollow">http://seamframework.org/Community/NewComponentTagStokenAimedToGuardAgainstCSRF</a>). This is <br/>
component-based approach by Dan Allen with two key artifacts:</p>
<ul>
<li>UIToken <a href="http://grepcode.com/file/repository.jboss.com/maven2/org.jboss.seam/jboss-seam-" class="external-link" rel="nofollow">http://grepcode.com/file/repository.jboss.com/maven2/org.jboss.seam/jboss-seam-</a><br/>
ui/2.2.0.GA/org/jboss/seam/ui/component/UIToken.java</li>
<li>TokenRendererBase<br/>
<a href="http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.seam/jb" class="external-link" rel="nofollow">http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.seam/jb</a><br/>
oss-seam-ui/2.2.0.CR1/org/jboss/seam/ui/renderkit/TokenRendererBase.java#TokenRendererBase</li>
</ul>
<p>This approach also uses a cookie to ensure the requests are coming from the same browser, which is a <br/>
nice feature (but it should be optional). It also has explicit support for client-side state saving, which <br/>
my solution does not.</p><p>re-target</p><p>I've created a separate spec issue for CSRF:<br/>
<a href="https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869" class="external-link" rel="nofollow">https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=869</a><br/>
as it solves a different problem.</p><p>target</p><p>Starting</p><p>reset priority</p><p>target 2.2</p><p>This issue has remained untouched since mid-Sept of 2010. Is this still being targeted for development or is there a recommended 3rd-party utility that can be used with Mojarra? </p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Critical</p><p>While Seam is out of date, <a href="https://deltaspike.apache.org/documentation/jsf.html#_double_submit_prevention" class="external-link" rel="nofollow">https://deltaspike.apache.org/documentation/jsf.html#_double_submit_prevention</a> is a more current solution.</p>
<p>Inclusion into 2.3 would be a huge help to a common problem.</p><p>Kito, can you take charge of this issue and look for an implementation strategy? Thanks!</p><p>Sure, I can. </p><p>fyi:<br/>
DeltaSpike keeps the valid token in a window-scoped bean -&gt; there is only one known token per window/tab -&gt; there is no impact on the state of the component tree and it isn't possible to "reactivate" a previous key -&gt; ds:preventDoubleSubmit just renders the current key.</p>Issuezilla Id559.0Rank0|i002pj:Rank (Obsolete)440Status Whiteboard<p>cat2 frame size_medium importance_large cat3 draft</p>[JAVASERVERFACES_SPEC_PUBLIC-1315] Simplify EL resolver chain by using CDIhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1315
javaserverfaces-spec-publicJAVASERVERFACES_SPEC_PUBLIC-1315Simplify EL resolver chain by using CDIImprovementCriticalOpenUnresolvedarjan tijmsManfred RiemWed, 8 Oct 2014 20:59:37 +0000Thu, 20 Aug 2015 16:08:51 +0000EL02<p>Make sure the appropriate spec text is added for:</p>
<p>application - describe that this only does EL resolving<br/>
applicationScope<br/>
externalContext<br/>
facesContext<br/>
session - describe that this only does EL resolving (core CDI does the @Inject for session)<br/>
view<br/>
viewScope</p><p>This is the current overview of the EL implicit variables handled by CDI:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>* application
*+ applicationScope (applicationMap)
cc
component
+ cookie (requestCookieMap)
*+? externalContext
*+ facesContext
flash
flowScope
header
headerValues
initParam
param
paramValues
request
requestScope
resource
* session
+ sessionScope (sessionMap)
*+ view (view root)
*+ viewScope (viewMap)
* = Implemented via issue 1315 (this issue)
+ = Implemented via issue 1316
? = new implicit EL variable
</pre>
</div></div>
<p>Preliminary implementation of entries not yet committed in the 2.3 trunk: <a href="https://github.com/omnifaces/mojarra/commit/1fa3ad6f0919eedc613cf21d4390a9d20c80e39c" class="external-link" rel="nofollow">https://github.com/omnifaces/mojarra/commit/1fa3ad6f0919eedc613cf21d4390a9d20c80e39c</a></p><p>r=mriem</p><p>Applied to 2.3 trunk:</p>
<p>svn commit -m "<a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1315" title="Simplify EL resolver chain by using CDI" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1315">JAVASERVERFACES_SPEC_PUBLIC-1315</a>, moved qualifiers to new annotation package. r=mriem"<br/>
Adding jsf-api/src/main/java/javax/faces/annotation<br/>
Adding jsf-api/src/main/java/javax/faces/annotation/ApplicationMap.java<br/>
Adding jsf-api/src/main/java/javax/faces/annotation/RequestCookieMap.java<br/>
Adding jsf-api/src/main/java/javax/faces/annotation/SessionMap.java<br/>
Adding jsf-api/src/main/java/javax/faces/annotation/ViewMap.java<br/>
Sending jsf-ri/src/main/java/com/sun/faces/cdi/ApplicationMapAnnotationLiteral.java<br/>
Sending jsf-ri/src/main/java/com/sun/faces/cdi/RequestCookieMapAnnotationLiteral.java<br/>
Sending jsf-ri/src/main/java/com/sun/faces/cdi/SessionMapAnnotationLiteral.java<br/>
Sending jsf-ri/src/main/java/com/sun/faces/cdi/ViewMapAnnotationLiteral.java<br/>
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectApplicationMap2Bean.java<br/>
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectApplicationMapBean.java<br/>
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectRequestCookieMap2Bean.java<br/>
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectRequestCookieMapBean.java<br/>
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectSessionMap2Bean.java<br/>
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectSessionMapBean.java<br/>
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectViewMap2Bean.java<br/>
Sending test/javaee8/cdi/src/main/java/com/sun/faces/test/javaee8/cdi/InjectViewMapBean.java<br/>
Transmitting file data ................<br/>
Committed revision 15029.</p>BlocksJAVASERVERFACES-3478JAVASERVERFACES_SPEC_PUBLIC-1386JAVASERVERFACES_SPEC_PUBLIC-1387JAVASERVERFACES_SPEC_PUBLIC-1388JAVASERVERFACES_SPEC_PUBLIC-1389JAVASERVERFACES_SPEC_PUBLIC-1390JAVASERVERFACES_SPEC_PUBLIC-1391JAVASERVERFACES_SPEC_PUBLIC-1392JAVASERVERFACES_SPEC_PUBLIC-1393JAVASERVERFACES_SPEC_PUBLIC-1394JAVASERVERFACES_SPEC_PUBLIC-1311JAVASERVERFACES_SPEC_PUBLIC-1322JAVASERVERFACES_SPEC_PUBLIC-1325JAVASERVERFACES_SPEC_PUBLIC-1328JAVASERVERFACES_SPEC_PUBLIC-1331JAVASERVERFACES_SPEC_PUBLIC-1332JAVASERVERFACES_SPEC_PUBLIC-1334JAVASERVERFACES_SPEC_PUBLIC-1383JAVASERVERFACES_SPEC_PUBLIC-1384JAVASERVERFACES_SPEC_PUBLIC-1385RelatedJAVASERVERFACES_SPEC_PUBLIC-1316Rank0|i0fjfj:Rank (Obsolete)90629[JAVASERVERFACES_SPEC_PUBLIC-1298] Resolve backward incompatible change regarding PartialResponseWriter.writePreamble()https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1298
javaserverfaces-spec-public<p>Issue <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069" title="Portlet incompatibilities with jsf.js" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1069"><del>JAVASERVERFACES_SPEC_PUBLIC-1069</del></a> was introduced to cover a problem with jsf.js and Portets. Unfortunately, the resolution was backward incompatible for parties that implement ResponseWriter.</p>JAVASERVERFACES_SPEC_PUBLIC-1298Resolve backward incompatible change regarding PartialResponseWriter.writePreamble()BugCriticalOpenUnresolvedEd BurnsEd BurnsMon, 11 Aug 2014 18:18:22 +0000Thu, 10 Sep 2015 16:16:46 +00002.2Ajax/JavaScript02<p>These were done at the request of the portlet community:</p>
<p><a href="http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069</a></p>
<p>And in fact Blake did weigh in on this way back then:</p>
<p><a href="https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/49" class="external-link" rel="nofollow">https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/49</a></p>
<blockquote>
<p>B&gt; I guess I would question whether any fixes for 1) or 2) are<br/>
B&gt; necessary. The proposal before is to make non-backwards compatible<br/>
B&gt; behavior changes. For such a change, I would want to see some clear<br/>
B&gt; benefits. In this case, the Bridge has a work-around. It doesn't<br/>
B&gt; sound like the work-around is hurting performance--nor does it sound<br/>
B&gt; like the Bridge is being asked to do something outside of its<br/>
B&gt; purview--which in this case is turning a document-oriented page into<br/>
B&gt; a fragment.</p></blockquote>
<p>And Neil Griffin replied with a justification:</p>
<p><a href="https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/57" class="external-link" rel="nofollow">https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-02/message/57</a></p>
<p>But there the discussion appears to have ended. It looks like we ended<br/>
up going with Neil's suggestions.</p>
<p>Let me clarify why Blake asserts this is a backward incompatible change.</p>
<p>In JSF 2.1, the writing of the XML preamble was the responsibility of the PartialResponseWriter.startDocument().</p>
<p>In JSF 2.2, we moved that out into PartialResponseWriter.writePreamble(), removing it from PartialResponseWriter.startDocument(). This means that any code that was counting on the XML preamble having been written based on a JSF 2.1 runtime will fail when running against a JSF 2.2 runtime.</p><p>To clarify further, this change was guaranteed to be incompatible because all pre-2.2 code had to rely on startDocument() writing any necessary XML declaration or docType as the new methods:</p>
<p>writePreamble</p>
<p>public void writePreamble(String preamble)<br/>
throws IOException<br/>
Write a string containing the markup specific preamble. No escaping is performed. The default implementation simply calls through to Writer.write(java.lang.String) .</p>
<p>The implementation makes no checks if this is the correct place in the response to have a preamble, nor does it prevent the preamble from being written more than once.</p>
<p>Parameters:<br/>
preamble - Text content of the preamble<br/>
Throws:<br/>
IOException - if an input/output error occurs<br/>
Since:<br/>
2.2<br/>
writeDoctype</p>
<p>public void writeDoctype(String doctype)<br/>
throws IOException<br/>
Write a string containing the markup specific doctype. No escaping is performed. The default implementation simply calls through to Writer.write(java.lang.String) .</p>
<p>The implementation makes no checks if this is the correct place in the response to have a doctype, nor does it prevent the doctype from being written more than once.</p>
<p>Parameters:<br/>
doctype - Text content of the doctype<br/>
Throws:<br/>
IOException - if an input/output error occurs<br/>
Since:<br/>
2.2</p>
<p>Did not exist before 2.2 and therefore could never have been called. This reason should have been sufficient on its own to have precluded the current design as minor releases are not allowed to break compatibility and even major releases should have a could have a good reason for doing so. In this cases, even the justification was sorely lacking:</p>
<p>"For JSF 2.2 portlet alignment, I think it's important (from a design perspective) to fix servlet environment assumptions in the JSF API or Spec. If such assumptions are present in a JSF implementation, then the portlet bridge can simply perform overrides at the proper extension points. The solutions below seem reasonable to me, since they appear to be implementation details that do not affect existing JSF applications."</p>
<p>It should be pointed out that:<br/>
1) The rationale is incorrect--the problem in this case wasn't that the JSF ResponseWriter was servlet-oriented, but rather, that the ResponseWriter assumed that startDocument() would actually begin writing a new document. In the Portlet case, the bridge wanted to write its own envelope content and then embed the payload from the wrapped writer inside this content. When the envelope was XML, the XML declaration and doctype caused problems.</p>
<p>2) The bridge had already worked around this problem by parsing the beginning of the wrapped content and discarding the XML declaration and docType. Since this content was at the beginning of the output of the wrapped content, this was actually pretty fast. The advantage of the change was that it made this aspect of the Portlet bridge easier to re-implement and faster (though this part isn't performance critical).</p>
<p>To make this worse, the rest of the design was messed up:</p>
<p>1) the two new methods should never have been public as an application calling these methods can only cause harm. This is because<br/>
a) In order to pass the correct parameters, the application would have to know the implementation of the ResponseWriter<br/>
b) If the application passes different parameters than the ResponseWriter expects, bad things can happen</p>
<p>The point of adding these methods as hooks for a ResponseWriter implementation could have been met with protected methods, thus avoiding potential new sources of error.</p>
<p>These problems are compounded by the lack of documentation surrounding the new contract in the javadoc for the class.</p>
<p>While it is clear that we should have never added these methods in the first place, let alone in the current fashion, we are stuck with trying to make these work the best we can. To that end we have two approaches:</p>
<p>Simple:</p>
<p>Admit that this was a bad idea. Make the new methods no-ops, go back to the old behavior and put the portlet bridge code back as well. This is by far the smallest change.</p>
<p>Change the incompatibility from the callers of the ResponseWriters (application developers) to the ResponseWriter implementations. This is actually less compatible than making the apis no-ops.</p>
<p>1) Document that while writeDocType and writePreamble are public, they should only be called by ResponseWriter implementations. Application developers should continue to only call startDocument<br/>
2) Document that neither writeDocType not writePreamble should be called after startDocument, that writePreamble should preceed any call to writeDocType and implementations are allowed, but not required to throw an IllegalStateException if this occurs.<br/>
3) Require that ResponseWriter implementations call writePreamble if writeDocType is called without a preceeding call to writePreamble and both<br/>
a) This ResponseWriter supports docTypes <br/>
b) This ResponseWriter supports a preamble<br/>
4) Require that ResponseWriter implementations call writeDocType if startDocument is called without a preceeding call to writeDocType (which will then cause the correct preamble to be written, if necessary)<br/>
5) Allow the ResponseWriter to throw IllegalArgumentExceptions if the parameters passed to writePreamble or writeDocument </p>
<p>This is still an incompatible change for ResponseWriter implementors, who now need to maintain state. Note that if we had made the new methods protected and simply requried that the ResponseWriter implementations call these methods from startDocument, the change would have still been incompatible (as we are placing a new requriement on ResponseWriter implemetors), but much simpler overall, as the expectations for subclassers calling things correctly are less sever than for application developers.</p>
<blockquote>
<p>This is still an incompatible change for ResponseWriter implementors, who now need to maintain state. Note that if we had made the new methods protected and simply requried that the ResponseWriter implementations call these methods from startDocument, the change would have still been incompatible (as we are placing a new requriement on ResponseWriter implemetors), but much simpler overall, as the expectations for subclassers calling things correctly are less sever than for application developers.</p></blockquote>
<p>Looking at the Java EE compatibility guidelines &lt; <a href="https://java.net/projects/javaee-spec/pages/CompatibilityRequirements" class="external-link" rel="nofollow">https://java.net/projects/javaee-spec/pages/CompatibilityRequirements</a> &gt;, I don't see anything that forbids making formerly public methods protected. Blake, if we were to do this and required your steps 1) and 2) above, would that be sufficient?</p>RelatedJAVASERVERFACES-3366Rank0|i0e12n:Rank (Obsolete)81823[JAVASERVERFACES_SPEC_PUBLIC-1380] Utilize @FacesDataModel for existing DataModel wrappershttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1380
javaserverfaces-spec-public<p><a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1078" title="Have DataModel implementations registrable" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1078">JAVASERVERFACES_SPEC_PUBLIC-1078</a> introduced a mechanism to register and lookup DataModel wrappers for (collection) types.</p>
<p>The components <tt>UIData</tt> and <tt>UIRepeat</tt> only utilize this mechanism as a "last resort". Meaning that a type that needs wrapping is first checked against a chain of types for which build-in wrappers are available. Only if none of these match is the <tt>@FacesDataModel</tt> mechanism consulted.</p>
<p>To have a more consistent model and most importantly allow overrides of build-in wrappers <tt>@FacesDataModel</tt> should always be consulted and there should be no build-in wrappers anymore.</p>
<p>Since this has backwards compatibility consequences, the best course of action may be to put this new behavior behind a switch and retain the old behavior as well.</p>JAVASERVERFACES_SPEC_PUBLIC-1380Utilize @FacesDataModel for existing DataModel wrappersNew FeatureCriticalOpenUnresolvedarjan tijmsarjan tijmsSun, 19 Jul 2015 22:24:47 +0000Thu, 10 Sep 2015 15:05:02 +000001RelatedJAVASERVERFACES_SPEC_PUBLIC-1078Rank0|i0h8jj:Rank (Obsolete)100529[JAVASERVERFACES_SPEC_PUBLIC-1342] Support @Inject of current flow like "@Inject Flow currentFlow"https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1342
javaserverfaces-spec-public<p>CDI Conversation scope is injectable into @ConversationScoped beans like this:</p>
<p>@Inject<br/>
Conversation currentConversation</p>
<p>The same should be true for the current Flow for @FlowScoped beans.</p>JAVASERVERFACES_SPEC_PUBLIC-1342Support @Inject of current flow like "@Inject Flow currentFlow"New FeatureCriticalOpenUnresolvedarjan tijmsEd BurnsFri, 12 Dec 2014 17:16:10 +0000Mon, 10 Aug 2015 16:36:22 +00002.2Flow01Rank0|i0g6zb:Rank (Obsolete)94444[JAVASERVERFACES_SPEC_PUBLIC-1360] Address corner cases as a result of issue #1127https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1360
javaserverfaces-spec-public<p>The issue here is that the optimization intended by 1127 cannot be guaranteed in light of two important cases.</p>
<p>case_Ajax</p>
<p> Multiple rapid Ajax submits cause the view tree to be shared across multiple concurrent requests.</p>
<p>case_MultiSubmit</p>
<p> Multiple rapid non-Ajax submits cause the view tree to be shared across multiple concurrent requests.</p>JAVASERVERFACES_SPEC_PUBLIC-1360Address corner cases as a result of issue #1127BugCriticalOpenUnresolvedEd BurnsManfred RiemTue, 3 Feb 2015 19:15:47 +0000Wed, 26 Aug 2015 15:10:57 +000001Rank0|i0ggyv:Rank (Obsolete)96062[JAVASERVERFACES_SPEC_PUBLIC-1265] Clarify that a piece of text in the navigation handler section of the spec only pertains when inside of a flow.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1265
javaserverfaces-spec-public<p>Consider this spec text, from section 7.4.2:</p>
<blockquote>
<p>If the &lt;to-view-id&gt; element is a non-view flow node, resolve it to a vdl view identifier by following the algorithm in Section 7.4.2.1 "Requirements for Explicit Navigation in Faces Flow Call Nodes other than ViewNodes".</p></blockquote>
<p>That text only pertains to navigation within a flow. This restriction must be explicitly called out.</p>JAVASERVERFACES_SPEC_PUBLIC-1265Clarify that a piece of text in the navigation handler section of the spec only pertains when inside of a flow.BugCriticalOpenUnresolvedEd BurnsEd BurnsFri, 7 Feb 2014 22:26:34 +0000Fri, 4 Sep 2015 17:07:53 +00002.2Flow13<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Critical</p>RelatedJAVASERVERFACES-3130Rank0|i0062v:Rank (Obsolete)986[JAVASERVERFACES_SPEC_PUBLIC-1244] Reword requirements for EL expressions inlined in Facelets pages, but outside of components.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1244
javaserverfaces-spec-public<p>Text copied from <a href="https://java.net/jira/browse/JAVASERVERFACES-3094" title="EL expressions referencing a composite attribute inside a facet of a composite component are not rendered" class="issue-link" data-issue-key="JAVASERVERFACES-3094"><del>JAVASERVERFACES-3094</del></a></p>
<blockquote>
<p>The JSF spec (2.1) requires in section 10.3.1 that "The runtime must ensure that EL expressions that appear in the page without being the right-hand-side of a tag attribute<br/>
are treated as if they appeared on the right-hand-side of the value attribute of an &lt;h:outputText /&gt; element in the <a href="http://java.sun.com/jsf/html" class="external-link" rel="nofollow">http://java.sun.com/jsf/html</a> namespace." This should also work in this case.</p></blockquote>
<p>This text is problematic with respect to c:set and friends.</p>
<p>I suggest we soften the above language to make it clear that we don't need to have UIOutput instances in the tree. Rather, we just need it to render as if we did.</p>JAVASERVERFACES_SPEC_PUBLIC-1244Reword requirements for EL expressions inlined in Facelets pages, but outside of components.BugCriticalOpenUnresolvedEd BurnsEd BurnsThu, 19 Dec 2013 17:41:22 +0000Thu, 10 Sep 2015 16:20:51 +00002.02.12.2Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF013 days3 days<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i005y7:Rank (Obsolete)965[JAVASERVERFACES_SPEC_PUBLIC-1185] Pass Through attribute should have priority when renderinghttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1185
javaserverfaces-spec-public<p>Tried the following code:</p>
<div class="code panel" style="border-style: solid;border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><b>index.xhtml</b></div><div class="codeContent panelContent">
<pre class="code-java">
&lt;a href=<span class="code-quote">"anotherPage_fake.xhtml"</span> jsf:outcome=<span class="code-quote">"/anotherPage.xhtml"</span>&gt;Another Page&lt;/a&gt;
</pre>
</div></div>
<p>The href attribute rendered contains the value <b>anotherPage_fake.xhtml</b>. In this case (and similar others), the pass through attribute should have priority in the rendering process, if it will compete with a static attribute.</p>JAVASERVERFACES_SPEC_PUBLIC-1185Pass Through attribute should have priority when renderingBugCriticalOpenUnresolvedEd BurnsBruno BorgesThu, 25 Apr 2013 06:20:55 +0000Wed, 19 Aug 2015 17:50:07 +0000Facelets/VDL45<p>Digging more into Pass Through Attributes, I find this feature one of the best things I've ever seen in JSF in years, because it could bring development/designer preview without the need to run an app server. A feature that several frameworks permit, such as Apache Wicket and Tapestry. But if Pass Through Attributes doesn't override regular attributes, then it becomes not interesting.</p>
<p>The spec is not clear about this, and I think it should be provided an Errata, with a change in the current implementation.</p>
<p><b>Sample A</b></p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
&lt;script type=<span class="code-quote">"text/javascript"</span>
src=<span class="code-quote">"../../js/jQuery.js"</span>
p:src=<span class="code-quote">"${facesContext.externalContext.requestContextPath}/js/jQuery.js"</span>&gt;<span class="code-tag">&lt;/script&gt;</span>
</pre>
</div></div>
<p><b>Sample B</b></p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;script type=<span class="code-quote">"text/javascript"</span> src=<span class="code-quote">"../../js/jQuery.js"</span>&gt;</span>
&lt;f:passThroughAttribute
name=<span class="code-quote">"src"</span>
value=<span class="code-quote">"${facesContext.externalContext.requestContextPath}/js/jQuery.js"</span> /&gt;
<span class="code-tag">&lt;/script&gt;</span>
</pre>
</div></div>
<p>Either samples should end up with this:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;script type=<span class="code-quote">"text/javascript"</span> src=<span class="code-quote">"/myapp-1.0-SNAPSHOT/js/jQuery.js"</span>&gt;</span><span class="code-tag">&lt;/script&gt;</span>
</pre>
</div></div><p>Pass through attributes have priority as specified in the “Rendering Pass Through Attributes” section of the overview of the standard HTML_BASIC render kit: <a href="https://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_behavior_encoding" class="external-link" rel="nofollow">https://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_behavior_encoding</a></p>
<p>In &lt;a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml"&gt;Another Page&lt;/a&gt; the href attribute becomes a pass through attribute and thus has priority.</p><p>Hi Frank, thanks for pointing that out, but I disagree that "static" attributes should have priority when faced against calculated/dynamic attributes such as jsf:outcome.</p>
<p>If an element has both attributes (a static like 'href', and a dynamic as 'jsf:outcome'), the general idea is that the static attribute is for static preview/prototyping only, and should be replaced by the calculated value.</p>
<p>This is how other web frameworks have been doing for years.</p><p>The link you specified has some very specific text about priority.</p>
<blockquote><p>The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence. Pass through attributes are rendered as if they were passed to ResponseWriter.writeURIAttribute().</p></blockquote>
<p>Unless I am reading this incorrectly, the <em>jsf:outcome</em> should take precedence over the static <em>href</em> attribute. I am on the fence on this though. I think that the pass through attributes are a great addition to the framework. However, if the renderer has the attribute defined, it can be set dynamically using EL. In this case, pass through attributes are simply duplicating the <em>renderer specific attributes</em>. This is for the case of the JSF components.</p>
<p>What advantages do we gain from the pass through taking precedence over the <em>renderer specific attributes</em> if they duplicate each other? I would say that the <em>renderer specific attributes</em> should take precedence.</p>
<p>In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as <em>href</em>.</p><blockquote>
<p>In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.</p></blockquote>
<p>This is what I'm looking for. I don't want to loose the "previability" of the page.</p><p>From the spec section cited by John and Frank:</p>
<blockquote><p>The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence.</p></blockquote>
<p>Consider Bruno's original markup:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;a href=<span class="code-quote">"anotherPage_fake.xhtml"</span>
jsf:outcome=<span class="code-quote">"/anotherPage.xhtml"</span>&gt;Another Page&lt;/a&gt;
</pre>
</div></div>
<p>Because this is an &lt;a&gt; element with a jsf:outcome attribute, it is treated as an h:link, specified in the following. </p>
<p><a href="http://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html" class="external-link" rel="nofollow">http://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html</a></p>
<p>Perhaps the root problem here is that there is another set of attributes that must be considered, separate from the set of renderer specific attributes. This is the set of attributes that the renderer itself must use when rendering the component. Let's call these <b>renderer required</b> attributes. I suggest that the spec be modified to define the term renderer required attributes, and to say that renderer required attributes take precedence over pass through attributes on the markup.</p>
<p>Unfortunately, there is no runtime representation of the set of renderer required attributes, so it's not possible for the spec to say that, though. We would need to have a way for each renderer to declare its set of renderer required attributes, then we could require the ResponseWriter to act accordingly based on the priority.</p>
<p>There is no conflict because "href" is <b>not</b> a renderer specific attribute.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Critical</p>RelatedJAVASERVERFACES_SPEC_PUBLIC-1270Rank0|i005lr:Rank (Obsolete)909[JAVASERVERFACES_SPEC_PUBLIC-1202] cc:attributes type attribute: fallback case: use what the ELResolver returns.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1202
javaserverfaces-spec-public<p><a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-745" title="Type of #{cc.attrs.test} cannot be obtained if test resolves to null" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-745"><del>JAVASERVERFACES_SPEC_PUBLIC-745</del></a> amended the language for the Composite Component Attributes ELResolver's getType() method. </p>
<p>An additional change is needed for correctness to the cc:attribute tag's type attribute. The existing language states:</p>
<blockquote>
<p>Declares that this attribute must be a ValueExpression whose expected type is given by the value of this attribute. If not specified, and no "method-signature" attribute is present, java.lang.Object is assumed. This attribute is mutually exclusive with the "method-signature" attribute. If both attributes are present, the "method-signature" attribute is ignored. </p></blockquote>
<p>This needs to be changed. Instead of assuming java.lang.Object, the system must use the return from the CC attribute ELResolver's getType() method.</p>
JAVASERVERFACES_SPEC_PUBLIC-1202cc:attributes type attribute: fallback case: use what the ELResolver returns.BugCriticalOpenUnresolvedEd BurnsEd BurnsWed, 3 Jul 2013 18:24:34 +0000Thu, 10 Sep 2015 16:21:51 +00002.2Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF012 hours2 hours<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i005pj:Rank (Obsolete)926[JAVASERVERFACES_SPEC_PUBLIC-49] JS function for "give me the clientId"https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-49
javaserverfaces-spec-public<p>EB&gt; R1 something you can stick in your page, that will evaluate to the full,<br/>
EB&gt; absolute, clientId of the named thing when the page is rendered. Like<br/>
EB&gt; this:</p>
<p>AVK&gt; &lt;h:button id="button1" <br/>
AVK&gt; onclick="button_setEnabled(<b>button2</b>, <br/>
AVK&gt; false);button_clicked(<b>button1</b>);return"<br/>
AVK&gt; ... /&gt;<br/>
AVK&gt; &lt;h:button id="button2" ... " /&gt;</p>
<p>AVK&gt; then I want the result of the first one to be </p>
<p>AVK&gt; &lt;input type="submit" id="myform:button1"<br/>
AVK&gt; onclick="button_setEnabled('myform:button2', false); <br/>
AVK&gt; button_clicked('myform:button1'); return;"<br/>
AVK&gt; ... /&gt;</p>
<p>EB&gt; R2 This thing can be presenent in an attribute value, or as template<br/>
EB&gt; text.</p>
<p>AVK&gt; Definitely needed in an attribute value, for the method invocation. I<br/>
AVK&gt; don't know whether it is necessary in tempate text. I have a feeling<br/>
AVK&gt; some JavaScript interpreters barf if you mention the id before the<br/>
AVK&gt; element is present. </p>
<p>EB&gt; R3 This thing must only work within the scope of a naming<br/>
EB&gt; container. In other words, I can't use this mechanism to refer<br/>
EB&gt; to something in form B if I'm inside Form A.</p>
<p>EB&gt; R4 This thing must work in a multi-include page scenario</p>
<p>EB&gt; R5 This thing must work in a portlet scenario</p><p>Operating System: All<br/>
Platform: Sun</p>JAVASERVERFACES_SPEC_PUBLIC-49JS function for "give me the clientId"New FeatureCriticalOpenUnresolvedcagatay_civiciEd BurnsMon, 4 Oct 2004 10:56:45 +0000Mon, 26 Jan 2015 15:27:48 +00002.0Ajax/JavaScript93<p>push to 2.0</p><p>EGTop5</p><p>effort_hard</p><ul>
<li>
<ul>
<li>
<ul>
<li>Issue 293 has been marked as a duplicate of this issue. ***</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>Change summary</p><p>Given the #</p>
{component}
<p> and #</p>
{compositeComponent}
<p> implicit objects, and the ability to use them on the <br/>
server side, in XHTML, and in resources, having the ability to say #</p>
{component.clientId}
<p> would be nice. To <br/>
do this, we need to add to UIComponent, String getClientId(). This just does <br/>
FacesContext.getCurrentInstance() and calls the other getClientId().</p>
<p>Created an attachment (id=163)<br/>
Fix for this bug, first iteration.</p><p>Push out to 2.1</p><p>Prepare to delete "spec" subcomponent.</p><p>Move these to unscheduled because we need to target them correctly. 2.next isn't <br/>
specific enough.</p><p>cat2</p><p>jsdoc</p><p>no sig change</p><p>These are targeted at 2.1.</p><p>triage</p><p>target</p><p>Remove from consideration for 2.2</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting to Critical, verify if it is already done or not.</p>Issuezilla Id49.0Rank0|i002af:Rank (Obsolete)372Status Whiteboard<p>EGTop5 effort_hard cat2 jsdoc size_medium importance_small draft</p>[JAVASERVERFACES_SPEC_PUBLIC-1414] f:validateWholeBean should allow the user to select the copy strategy (a copier attribute)https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1414
javaserverfaces-spec-public<p>Payara 4.1</p>JAVASERVERFACES_SPEC_PUBLIC-1414f:validateWholeBean should allow the user to select the copy strategy (a copier attribute)ImprovementCriticalOpenUnresolvedUnassignedanghelleonardFri, 12 Feb 2016 05:48:36 +0000Fri, 12 Feb 2016 10:02:04 +000001Rank0|i0jkxj:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-1193] Declaring component attributes via annotationshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1193
javaserverfaces-spec-public<p>As of <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-594" title="Add tagName attribute to @FacesComponent annotation" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-594"><del>JAVASERVERFACES_SPEC_PUBLIC-594</del></a>, custom components can be declared to be useable in Facelets via the <tt>@FacesComponent</tt> annotation. Via this it's no longer required to have an entry in a taglib.xml file.</p>
<p>However, if the component author wishes to declare the component's attributes (for documentation, tooling, etc), XML still has to be used.</p>
<p>I therefor would like to propose declaring these attributes via annotations as well.</p>
<p>E.g.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">@FacesComponent(value=<span class="code-quote">"components.CustomComponent"</span>, createTag=<span class="code-keyword">true</span>)
<span class="code-keyword">public</span> class Foo <span class="code-keyword">extends</span> UIComponentBase {
@Attribute
<span class="code-object">String</span> color; <span class="code-comment">// will be injected with getAttributes(<span class="code-quote">"color"</span>)
</span>
@Attribute(description=<span class="code-quote">"This will determine the ..."</span>, required=<span class="code-keyword">true</span>)
<span class="code-object">String</span> style;
@Attribute(description=<span class="code-quote">"The cost of ... "</span>, <span class="code-keyword">default</span>=<span class="code-quote">"100"</span>)
<span class="code-object">Integer</span> cost;
}
</pre>
</div></div>JAVASERVERFACES_SPEC_PUBLIC-1193Declaring component attributes via annotationsNew FeatureCriticalOpenUnresolvedarjan tijmsarjan tijmsSat, 11 May 2013 16:11:56 +0000Mon, 17 Aug 2015 17:22:38 +0000Components/Renderers46<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Critical</p><p>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.<br/>
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.<br/>
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?</p>
<p>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.</p><p>"Properties" is a hot button topic. It was recently booted out of Java SE 9. This is a decent writeup: <a href="http://blog.joda.org/2014/11/no-properties-in-java-language.html" class="external-link" rel="nofollow">http://blog.joda.org/2014/11/no-properties-in-java-language.html</a></p>Rank0|i005nj:Rank (Obsolete)917Tagsannotationannotationsease-of-useease_of_developmentno-xml[JAVASERVERFACES_SPEC_PUBLIC-1321] Leverage HTTP2 Server Push from JSFhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1321
javaserverfaces-spec-public<p>Because JSF 2.3 is allowed to depend on Java EE 8, we can take advantage of Servlet 4.0 features such as server push.</p>JAVASERVERFACES_SPEC_PUBLIC-1321Leverage HTTP2 Server Push from JSFNew FeatureCriticalOpenUnresolvedEd BurnsEd BurnsMon, 13 Oct 2014 14:08:33 +0000Mon, 8 Aug 2016 08:51:50 +0000Lifecycle02<p>Currently, JSF 2.3 already features JSR356 websocket based push as per <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1396" class="external-link" rel="nofollow">https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1396</a></p>Rank0|i0fkpz:Rank (Obsolete)90838[JAVASERVERFACES_SPEC_PUBLIC-1316] Support @Inject on JSF artifactshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1316
javaserverfaces-spec-publicJAVASERVERFACES_SPEC_PUBLIC-1316Support @Inject on JSF artifactsNew FeatureCriticalOpenUnresolvedarjan tijmsManfred RiemThu, 9 Oct 2014 19:51:25 +0000Mon, 8 Aug 2016 08:50:11 +0000060 minutes1 hour<p>Make sure the following artifacts are mentioned in the spec PDF when describing @Inject support</p>
<ul class="alternate" type="square">
<li>applicationMap</li>
<li>externalContext</li>
<li>facesContext</li>
<li>session (delegating that responsibility back to default CDI runtime)</li>
<li>sessionMap</li>
<li>view</li>
<li>viewMap</li>
<li>converters annotated with @FacesConverter (and managed = true)</li>
<li>validators annotated with @FacesValidator (and managed = true)</li>
<li>behaviors annotated with @FacesBehavior (and managed = true)</li>
<li>requestCookieMap</li>
</ul>
<p>Do you have any plans to support Component, Behavior and Validator?</p><p>In Progress <img class="emoticon" src="https://java.net/jira/images/icons/emoticons/wink.gif" height="16" width="16" align="absmiddle" alt="" border="0"/></p><p>Note @Inject on UIComponent instances will not be done as the view state is managed outside of CDI.</p><blockquote><p>Note @Inject on UIComponent instances will not be done as the view state is managed outside of CDI.</p></blockquote>
<p>IFF there would be an <tt>@ComponentScope</tt> then as a side-effect of that it <b>may</b> became feasible to allow injection of the <tt>UIComponent</tt> instances.</p><p>Injection of <tt>@FacesContext</tt> is currently not done properly. It's currently request scoped, but it should actually be "faces context scoped", as an (error) dispatch can create a new <tt>FacesContext</tt> within the very same request. The current approach will throw ISE from <tt>assertNotReleased()</tt> when the <tt>FacesContext</tt> is being referenced in EL.</p>BlocksJAVASERVERFACES_SPEC_PUBLIC-527JAVASERVERFACES_SPEC_PUBLIC-1309JAVASERVERFACES_SPEC_PUBLIC-1323JAVASERVERFACES_SPEC_PUBLIC-1327JAVASERVERFACES_SPEC_PUBLIC-1333JAVASERVERFACES_SPEC_PUBLIC-1335JAVASERVERFACES_SPEC_PUBLIC-1345JAVASERVERFACES_SPEC_PUBLIC-1349JAVASERVERFACES_SPEC_PUBLIC-1350JAVASERVERFACES_SPEC_PUBLIC-1351JAVASERVERFACES_SPEC_PUBLIC-1353DependencyJAVASERVERFACES_SPEC_PUBLIC-1283RelatedJAVASERVERFACES_SPEC_PUBLIC-763JAVASERVERFACES_SPEC_PUBLIC-1315JAVASERVERFACES_SPEC_PUBLIC-1287Rank0|i0fjpj:Rank (Obsolete)90674[JAVASERVERFACES_SPEC_PUBLIC-1150] Add @ClientWindowScopedhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1150
javaserverfaces-spec-public<p>JSF 2.2 added ClientWindow capabality. There should be a corresponding CDI scope.</p>JAVASERVERFACES_SPEC_PUBLIC-1150Add @ClientWindowScopedNew FeatureCriticalOpenUnresolvedEd BurnsEd BurnsTue, 4 Dec 2012 14:09:18 +0000Mon, 24 Oct 2016 22:28:16 +00002.2Managed Beans36<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Please note the importance of specifying client window timeouts and/or a maximum number of client windows per http session to provide an upper limit of the memory requirements of this feature. Faces Flows currently do not have such a limit either (<a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1398" class="external-link" rel="nofollow">https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1398</a>), but could get it as well by storing them in the client window scope.</p><p>A corresponding CDI scope would be great. But, how can we ensure that a user does not transfer a client window id from one tab to the other by copy and pasting the URL? </p><p>There is no perfect solution for that one. For historical purposes about the browser tab problem see <a href="https://struberg.wordpress.com/2011/11/13/solving-the-browser-tab-problem/" class="external-link" rel="nofollow">https://struberg.wordpress.com/2011/11/13/solving-the-browser-tab-problem/</a> . Right now @FlowScoped relies on client window id. MyFaces has a client window mode different from the default that uses the url called "client", extracted from MyFaces CODI.</p>Rank0|i005e7:Rank (Obsolete)875[JAVASERVERFACES_SPEC_PUBLIC-1077] HTML5 Form Associated Elementshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1077
javaserverfaces-spec-public<p>See: <a href="http://dev.w3.org/html5/spec/Overview.html#form-associated-element" class="external-link" rel="nofollow">http://dev.w3.org/html5/spec/Overview.html#form-associated-element</a></p>
<p>The following elements, some of which already are rendered by JSF, have been updated or added for HTML5.</p>
<p>button<br/>
fieldset<br/>
input<br/>
keygen<br/>
label<br/>
meter<br/>
object<br/>
output<br/>
progress<br/>
select<br/>
textarea</p>
<p>Proper provision must be made for these in JSF 2.2</p>JAVASERVERFACES_SPEC_PUBLIC-1077HTML5 Form Associated ElementsSub-taskJAVASERVERFACES_SPEC_PUBLIC-1090MajorOpenUnresolvedUnassignedEd BurnsWed, 22 Feb 2012 21:49:35 +0000Fri, 1 Aug 2014 17:56:01 +0000Components/Renderers02<p>It would be nice, if h:commandButton would render the button tag. Maybe we should have an optional attribute called "element" or "tag" which's value would be "button" to tell the renderer to render the children.<br/>
If we do so, we could simply render the value of the value attribute as a text child if no children are present, because the developer is used to use the value attribute for the button's text with classic buttons.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major. Verify what needs to be done here.</p>DuplicateJAVASERVERFACES_SPEC_PUBLIC-990Rank0|i004y7:Rank (Obsolete)803[JAVASERVERFACES_SPEC_PUBLIC-1120] UIData (and related classes) doesn't respect contract for UIComponent process{Decodes, Validators, Updates}https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1120
javaserverfaces-spec-public<p>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.</p>
<p>Clearly, the problem is in the javadoc for UIComponent, which is much too restrictive.</p>
<p>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.</p>
<p>Having a complete and accurate description of the responsibilities of the methods would, on the other hand, help understanding.</p><p>N/A</p>JAVASERVERFACES_SPEC_PUBLIC-1120UIData (and related classes) doesn't respect contract for UIComponent process{Decodes, Validators, Updates}BugMajorOpenUnresolvedUnassignedjontylMon, 9 Jul 2012 19:45:41 +0000Wed, 13 Aug 2014 19:04:35 +00002.2Components/Renderers02<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i0057j:Rank (Obsolete)845[JAVASERVERFACES_SPEC_PUBLIC-1116] Add the possibility to change "rel" and "type" on <h:outputStylesheet>https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1116
javaserverfaces-spec-public<p>Currently, when using a <tt>&lt;h:outputStylesheet&gt;</tt>, it will always generate a <tt>&lt;link href="..." rel="stylesheet" type="text/css"&gt;</tt>, there is no way to change the value of the "rel" and "type" attributes on the generated HTML tag.</p>
<p>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.</p><p>All</p>JAVASERVERFACES_SPEC_PUBLIC-1116Add the possibility to change "rel" and "type" on <h:outputStylesheet>ImprovementMajorOpenUnresolvedUnassignedpaul_dijouFri, 15 Jun 2012 17:58:28 +0000Thu, 11 Sep 2014 15:08:30 +00002.1 Rev aComponents/Renderers02<p>To see the fact that "type" and "rel" are hard-coded, just check that source code: <a href="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" class="external-link" rel="nofollow">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</a> (it's near the end).</p>
<p>Not sure even the new passthru attributes can change them...</p><p>Also, consider the same problem with script resources. New types like Coffeescript are now possible. As we can see at the beginning of <a href="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" class="external-link" rel="nofollow">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</a> , also here the type is hard-coded.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>I confirmed that this doesn't work, even with passthrough elements:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;h:outputStylesheet library=<span class="code-quote">"alibrary"</span> name=<span class="code-quote">"favicon.ico"</span> pt:rel=<span class="code-quote">"icon"</span> pt:type=<span class="code-quote">"image/x-icon"</span> /&gt;
</pre>
</div></div>
<p>Just outputs:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;link type=<span class="code-quote">"text/css"</span> rel=<span class="code-quote">"stylesheet"</span> href=<span class="code-quote">"/test-agnostic-renderKit-basic/faces/javax.faces.resource/favicon.ico?ln=alibrary"</span> /&gt;
</pre>
</div></div>
<p>This clearly is not what is intended. </p>Rank0|i0056n:Rank (Obsolete)841TagscssoutputStylesheet[JAVASERVERFACES_SPEC_PUBLIC-1112] Security bug with FacesContext in application startuphttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1112
javaserverfaces-spec-public<p>Regarding the FacesContext that is available during application initialization, we need some language in the spec about how it is cleaned up. Otherwise, it can leak into the initialization thread of another application and allow one WAR to see the context of another WAR.</p>
<p>Also, we need some language saying that FacesContext.getCurrentInstance() should always return null except when:<br/>
A) We are in the context of a servlet request, or<br/>
B) We are receiving a PostConstructApplicationEvent</p>
<p>See <a href="http://java.net/jira/browse/JAVASERVERFACES-2436" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES-2436</a> for full details and an application that recreates the issues.</p>JAVASERVERFACES_SPEC_PUBLIC-1112Security bug with FacesContext in application startupBugMajorOpenUnresolvedUnassignedssilvertFri, 1 Jun 2012 20:34:11 +0000Wed, 13 Aug 2014 18:31:56 +0000Configuration/BootstrappingSecurity12<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i0055r:Rank (Obsolete)837[JAVASERVERFACES_SPEC_PUBLIC-1093] The id attribute of javax.faces.ViewState is not uniquehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1093
javaserverfaces-spec-public<p>As per the work done for this spec change, <a href="http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-220" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-220</a>, the id of each hidden ViewState element is supposed to be unique on the page. This should hold true for multiple forms in a single view as well as multiple views on the page (e.g. portlets). The documentation in ResponseStateManager indicates that this should be done by setting the id to be:</p>
<p>namingContainerId:javax.faces.ViewState:counterUniqueToView</p>
<p>I have attached a test case which has two forms on it. The resulting ViewState elements both have identical ids:</p>
<p>ViewState for form1: j_id1:javax.faces.ViewState:0<br/>
ViewState for form2: j_id1:javax.faces.ViewState:0</p>
<p>The counter is not incremented and the id of the form (which should be the naming container in this case) is not used.</p>
<p>Also, I noticed that the method for getting the ViewState id is com.sun.faces.util.Util.getViewStateId(FacesContext fc). For those of us working on extending the framework who might need access to the information in their own renderers, will there be a way to get at the information in a more public way?</p><p>Any</p>JAVASERVERFACES_SPEC_PUBLIC-1093The id attribute of javax.faces.ViewState is not uniqueBugMajorOpenUnresolvedUnassigneddmsinotteTue, 1 May 2012 15:58:28 +0000Fri, 1 Aug 2014 17:57:50 +00002.2 Sprint 12Lifecycle25<p>(First of all, javax.faces.ViewState should not be modified for Ajax updates using server-side state-saving, but this simple approach does not appear to be the current direction.)</p>
<p>We are a bit unclear on how the current implementation is intended to work, but expect that something like the following is necessary:</p>
<p>When the request is submitted, call getElementsByName('javax.faces.ViewState') and store the list of IDs for all with equal value to that of the javax.faces.ViewState in the submitting form. In the case of future JSP inclusion or current Portlets, there will be javax.faces.ViewState fields not associated with the current view. They will have different values and are not included in the list.</p>
<p>When the partial response is generated, it may contain rendered hidden inputs with name javax.faces.ViewState and unique IDs, but also contains the special case &lt;update id="javax.faces.ViewState"&gt;&lt;![CDATA<span class="error">&#91;...&#93;</span>]&gt;&lt;/update&gt;. The previously stored list of IDs are now all updated to use the new value. Any javax.faces.ViewState hidden fields that have been modified by the page update itself (potentially now having different IDs) have the correct value anyway because they were just updated.</p><p>TG&gt; (First of all, javax.faces.ViewState should not be modified for Ajax<br/>
TG&gt; updates using server-side state-saving, but this simple approach<br/>
TG&gt; does not appear to be the current direction.)</p>
<p>Can you please elaborate more on what you mean by this? The issue<br/>
doesn't mention anything about Ajax specifically. Is this a separate<br/>
concern you are raising, Ted?</p>
<p>TG&gt; We are a bit unclear on how the current implementation is intended<br/>
TG&gt; to work, but expect that something like the following is necessary:</p>
<p>TG&gt; When the request is submitted, call<br/>
TG&gt; getElementsByName('javax.faces.ViewState') and store the list of IDs<br/>
TG&gt; for all with equal value to that of the javax.faces.ViewState in the<br/>
TG&gt; submitting form. In the case of future JSP inclusion or current<br/>
TG&gt; Portlets, there will be javax.faces.ViewState fields not associated<br/>
TG&gt; with the current view. They will have different values and are not<br/>
TG&gt; included in the list.</p>
<p>TG&gt; When the partial response is generated, it may contain rendered<br/>
TG&gt; hidden inputs with name javax.faces.ViewState and unique IDs, but<br/>
TG&gt; also contains the special case &lt;update<br/>
TG&gt; id="javax.faces.ViewState"&gt;&lt;![CDATA<span class="error">&#91;...&#93;</span>]&gt;&lt;/update&gt;. The previously<br/>
TG&gt; stored list of IDs are now all updated to use the new value. Any<br/>
TG&gt; javax.faces.ViewState hidden fields that have been modified by the<br/>
TG&gt; page update itself (potentially now having different IDs) have the<br/>
TG&gt; correct value anyway because they were just updated.</p>
<p>These two comments are better suited to <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790" title="javax.faces.ViewState + PPR does not work out for cross form ppr cases" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-790">JAVASERVERFACES_SPEC_PUBLIC-790</a>,<br/>
so I'll copy them there. Ted, can you please take a look at 790 and see<br/>
if you agree that your comments pertain more to that issue than this<br/>
one?</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major. Verify if we are already doing the right thing.</p>RelatedJAVASERVERFACES_SPEC_PUBLIC-790Rank0|i0051r:Rank (Obsolete)819[JAVASERVERFACES_SPEC_PUBLIC-951] Unable to map composite component facet to new namehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-951
javaserverfaces-spec-public<p>If you need to map map the public name exposed by a composite component to a different name as required by the consuming component, it is not possible with cc:insertFacet. Here's an example:</p>
<p>Page:<br/>
&lt;my:component&gt;<br/>
&lt;f:facet name="fooHeader"&gt;<br/>
&lt;h:outputText value="foo" /&gt;<br/>
&lt;/f:facet&gt;<br/>
&lt;f:facet name="barHeader"&gt;<br/>
&lt;h:outputText value="bar" /&gt;<br/>
&lt;/f:facet&gt;<br/>
&lt;/my:component&gt;</p>
<p>Component:<br/>
&lt;cc:implementation&gt;<br/>
...<br/>
&lt;h:dataTable ...&gt;<br/>
&lt;cc:insertFacet name="fooHeader" /&gt;<br/>
...<br/>
&lt;/h:dataTable&gt;<br/>
&lt;h:dataTable ...&gt;<br/>
&lt;cc:insertFacet name="barHeader" /&gt;<br/>
&lt;/h:dataTable&gt;</p>
<p>In the example component code above "header" is the required name for h:dataTable. However, to retrieve the outer name, you must use the correct name exposed by the component, "fooHeader" or "barHeader" in this example. The above code will obviously fail to render the headers.</p>
<p>To solve this, I propose adding "localName" (or something similar) to the insertFacet tag:</p>
<p> &lt;cc:insertFacet name="barHeader" localName="header" /&gt;</p>
<p>Thanks!</p>
<p>-Ken</p><p>All</p>JAVASERVERFACES_SPEC_PUBLIC-951Unable to map composite component facet to new nameBugMajorOpenUnresolvedUnassignedkenpaulsenWed, 23 Mar 2011 12:28:27 +0000Fri, 1 Aug 2014 17:25:44 +00002.02.1Components/Renderers451 day1 day<p>I have problem to create composite components using cc:renderFacet inside a p:datatable</p>
<p>Page:<br/>
&#8211;<br/>
&lt;sds:crud&gt;<br/>
&lt;f:facet name="listColumns" &gt;<br/>
&lt;p:column &gt;<br/>
&lt;f:facet name="header"&gt; <br/>
My column<br/>
&lt;/f:facet&gt; <br/>
&lt;h:outputText value="#</p>
{s}
<p>" /&gt; <br/>
&lt;/p:column&gt;<br/>
&lt;/f:facet&gt;<br/>
&lt;/sds:crud&gt;<br/>
&#8211;</p>
<p>My Component (crud):<br/>
&#8211;<br/>
&lt;cc:interface &gt;<br/>
&lt;cc:facet name="listColumns" required="true" /&gt;<br/>
&lt;/cc:interface&gt;</p>
<p> &lt;cc:implementation&gt;<br/>
&lt;p:dataTable value="#</p>
{teste.list()}
<p>" var="s"&gt;<br/>
&lt;cc:renderFacet name="listColumns" /&gt;<br/>
&lt;/p:dataTable&gt;<br/>
&lt;/cc:implementation&gt;<br/>
&#8211;</p>
<p>If I use cc:insertChildren it works, however I need to use facets.</p><p>Ken,</p>
<p>Have you tried doing the following?</p>
<p>&lt;cc:implementation&gt;<br/>
&lt;h:dataTable&gt;<br/>
&lt;f:facet name="header"&gt;<br/>
&lt;cc:renderFacet name="fooHeader"/&gt;<br/>
&lt;/f:facet&gt;<br/>
&lt;/h:dataTable&gt;<br/>
&lt;/cc:implementation&gt;</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i0043z:Rank (Obsolete)667Status Whiteboard<p>size_small importance_large</p>[JAVASERVERFACES_SPEC_PUBLIC-935] UIData needs review on a couple of frontshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-935
javaserverfaces-spec-public<p>Note that the following will most likely apply to 1.2 as well</p>
<p>From Martin Marinschek:<br/>
-----------------------------</p>
<p>a) if invokeOnComponent returns successfully for any of the facets,<br/>
invokeOnComponent should return with true - currently it doesn't (maybe there is<br/>
a reason for this I fail to see?)</p>
<p>b) I think that the NumberConversionException thrown from the current version of<br/>
this method is dangerous in the sense that if the client-id is not actually<br/>
valid (the component is not yet anymore in the table) but was a sub-component of<br/>
a naming-container in a facet (client-id<br/>
tableClientId:namContainerId:subCompId), the long client-id will trigger the<br/>
code to check if the component is in one of the rows and you will suddenly get a<br/>
number conversion exception popping up from the table. This is not the case with<br/>
other components and invokeOnComponent, and so should be done differently.<br/>
Instead, this NumberConversion exception has to be silently ignored - or a<br/>
better solution for this algorithm has to be found (I didn't find one in a<br/>
decent time-frame, however, and just ignored the NumberConversion exception in<br/>
my version).</p>
<p>As a side-note: could it be that you guys keep track of the state of children of<br/>
transient nodes? I seem to be running into this from time to time. Leonardo<br/>
mentioned this as an implementation difference to MyFaces to me, so maybe you<br/>
could check if this is the case (I don't think this would make sense - a<br/>
transient component would certainly mean every sub-component has to be transient<br/>
as well).</p>JAVASERVERFACES_SPEC_PUBLIC-935UIData needs review on a couple of frontsBugMajorOpenUnresolvedUnassignedrogerkMon, 31 Jan 2011 08:21:03 +0000Fri, 1 Aug 2014 17:17:00 +0000Components/Renderers443 days, 23 hours, 30 minutes1 hour, 16 minutes<p>The most important problem I see with UIData current implementation is the clientId append the rowIndex and it could be better if we can just create some property called rowKey or a converter or whatever that allow us to generate this part of the id in a clean way. Right now, there is a solution for this one committed on tomahawk code if you want to take a look. I'm willing to write the solution for mojarra too.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>JAVASERVERFACES_SPEC_PUBLIC-322JAVASERVERFACES_SPEC_PUBLIC-479JAVASERVERFACES_SPEC_PUBLIC-963JAVASERVERFACES_SPEC_PUBLIC-965Rank0|i0041z:Rank (Obsolete)658Status Whiteboard<p>size_medium importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-925] Helper methods for FacesContexthttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-925
javaserverfaces-spec-public<p>There are a number of fairly common tasks for web applications that require a<br/>
fairly long method string to capture. A set of helper methods would be handy...</p>
<p>For instance getting a parameter, or getting an EL value, both require chained<br/>
method calls that are 5 levels or so deep. There are probably others - I'll<br/>
think about it and see if I can come up with a list.</p>JAVASERVERFACES_SPEC_PUBLIC-925Helper methods for FacesContextNew FeatureMajorOpenUnresolvedUnassignedEd BurnsMon, 31 Jan 2011 07:19:13 +0000Fri, 1 Aug 2014 17:13:55 +0000Lifecycle652 days2 days<p>Bulk assign all of Sheetal's spec issues to me.</p><p>This would be really handy. The FacesContext not only requires deep chaining, but since especially ExternalContext doesn't make too many assumptions about its environment (basically a Good Thing) a lot of casting is typically done in web applications.</p>
<p>Since Servlet based web applications seem to be the most common use case for JSF, a (additional) utility class could be created that already assumed this environment. Many JSF applications that I've seen already create such utility classes anyway. Besides the mentioned helper methods, the following might be useful:</p>
<ul>
<li>HttpServletRequest getRequest()</li>
<li>HttpServletResponse getResponse()</li>
<li>HttpSession getSession()</li>
<li>Map&lt;String, String&gt; getRequestParameterMap()</li>
<li>ServletContext getServletContext()</li>
<li>Locale getLocale()</li>
<li>UIComponent findComponent(String expression)</li>
<li>addPhaseListener(PhaseListener phaseListener)</li>
<li>&lt;T&gt; T evaluateExpression(String expression)</li>
</ul>
<p>And finally two (perhaps) more exotic helper methods:</p>
<ul>
<li>void addBeforePhaseListener(PhaseId phaseId, final Runnable runnable)</li>
<li>void addAfterPhaseListener(PhaseId phaseId, final Runnable runnable)</li>
</ul>
<p>The last two not only flatten the FacesContext chain, but allow a single interface type (SAM type) to be a PhaseListener, which is already more convenient to implement but will ever further reduce complexity when/if Java 8 closures are introduced. It can be implemented by simply adding some DefaultPhaseListener that calls the provided Runnable:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> <span class="code-keyword">static</span> void addAfterPhaseListener(PhaseId phaseId, <span class="code-keyword">final</span> <span class="code-object">Runnable</span> runnable) {
FacesContext.getCurrentInstance().getViewRoot().addPhaseListener(<span class="code-keyword">new</span> DefaultPhaseListener(phaseId) {
@Override
<span class="code-keyword">public</span> void afterPhase(PhaseEvent event) {
runnable.run();
}
});
}
</pre>
</div></div>
<p>Not sure if it's in scope for this issue, but some helper methods for components would also be nice. Some tasks that you'd think would be simple, still require some amount of code. E.g.:</p>
<ul>
<li>boolean hasValue(UIInput input) // without firing validators</li>
<li>&lt;T&gt; T getValue(UIInput input) // validated value, without need to know if validation already happened before call</li>
<li>String getComponentLabel(UIComponent component)</li>
</ul>
<p>I've added this issue to the JSF_2_2_WORKING_SET JIRA filter.</p><p>Another simplification that could be caught in a single method is adding faces messages.</p>
<p>Currently, idiomatic code to adding such a message (globally) is this:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
FacesContext context = FacesContext.getCurrentInstance();
FacesMessage message = <span class="code-keyword">new</span> FacesMessage(<span class="code-quote">"Error message here"</span>);
message.setSeverity(FacesMessage.SEVERITY_ERROR);
context.addMessage(<span class="code-keyword">null</span>, message);
</pre>
</div></div>
<p>It gets more verbose when i18n is involved:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
FacesContext context = FacesContext.getCurrentInstance();
Locale locale = context.getViewRoot().getLocale();
<span class="code-object">String</span> bundleName = context.getApplication().getMessageBundle();
ResourceBundle bundle = ResourceBundle.getBundle(bundleName, locale);
<span class="code-object">String</span> text = <span class="code-keyword">null</span>;
<span class="code-keyword">try</span> {
text = MessageFormat.format(bundle.getString(key), param1, param2);
} <span class="code-keyword">catch</span> (MissingResourceException e) {
text = <span class="code-quote">"Missing key: "</span> + key;
}
FacesMessage message = <span class="code-keyword">new</span> FacesMessage(text);
message.setSeverity(SEVERITY_ERROR);
context.addMessage(<span class="code-keyword">null</span>, message);
</pre>
</div></div>
<p>Every JSF project in practice that I've seen thus abstracts this code away in some utility method. For instance, the following captures a great chunk of practical usage:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
FacesMessages.addMessageFromBundle(SEVERITY_ERROR, key, param1, param2);
</pre>
</div></div>
<p>(incidentally, this was one of the original gripes Matt Raible had with JSF: <a href="http://raibledesigns.com/rd/entry/the_joy_of_developing_with" class="external-link" rel="nofollow">http://raibledesigns.com/rd/entry/the_joy_of_developing_with</a>)</p>
<p>Several variants are possible (but to keep it simple, not too many variants should be introduced, else the user is better of using the existing API).</p>
<p>Don't look up in bundle, but use text provided by user:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
FacesMessages.addMessage(SEVERITY_ERROR, text, param1, param2);
</pre>
</div></div>
<p>Overloaded to add message to specific component:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
FacesMessages.addMessage(componentId, SEVERITY_ERROR, text, param1, param2);
</pre>
</div></div>
<p>One more request for a helper method, although it's more related to components so I'm not sure it's in scope for this ticket, but it's a method to get hold of all select items for a given component.</p>
<p>Currently almost everybody seems to be creating their own version of this (e.g. Mojarra's com.sun.faces.renderkit.SelectItemsIterator, MyFaces' org.apache.myfaces.shared_impl.util.SelectItemsIterator and PrimeFaces' org.primefaces.util.ComponentUtils#createSelectItems).</p><p>Implementation for a given helper method is likely straightforward, but some may be controversial. For instance, getRequest() (as above) is only valid in a Servlet environment. Not all application code requires Servlet/Portlet portability, so potentially a helper with a type-safe API could be instantiated and used:</p>
<p>helper = new FacesServletHelper(facesContext)</p>
<p>but perhaps a better question is why direct access to the HttpServletRequest is required. Once this is understood, type-safe portable methods could potentially be added to FacesContext or ExternalContext.</p><blockquote>
<p>Not all application code requires Servlet/Portlet portability, so potentially a helper with a type-safe API could be instantiated and used:</p></blockquote>
<p>That was indeed exactly what I meant with "Since Servlet based web applications seem to be the most common use case for JSF, a (additional) utility class could be created that already assumed this environment." <img class="emoticon" src="https://java.net/jira/images/icons/emoticons/wink.gif" height="16" width="16" align="absmiddle" alt="" border="0"/></p>
<blockquote>
<p>but perhaps a better question is why direct access to the HttpServletRequest is required</p></blockquote>
<p>A quick scan in the JSF application I build with my team reveals that among others this is used to access the request attributes, to get a specific request header, interaction with legacy/non-jsf code that requires the HttpServletRequest as input, getting the userPrincipal or doing the isUserInRole check.</p>
<p>Clearly, a lot on that on that list is also available on the type-safe ExternalContext.</p><p>@tedgoddard what about HttpServletRequest#login, logout, authenticate etc?</p><p>The OmniFaces FacesLocal class is a good reference for this: <a href="http://showcase.omnifaces.org/utils/FacesLocal" class="external-link" rel="nofollow">http://showcase.omnifaces.org/utils/FacesLocal</a>;</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i004cn:Rank (Obsolete)706Status Whiteboard<p>size_small importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-1002] Order of isRendered and pushComponentToEL prevents rendered="#{}" based on component implicit objecthttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
javaserverfaces-spec-public<p>Current specification for lifecycles methods:<br/>
1) processDecodes<br/>
2) processValidators<br/>
3) processUpdates<br/>
4) encodeAll<br/>
4) encodeBegin</p>
<p>explicitly says that:</p>
<p>1) If the rendered property of this UIComponent is false, skip further processing.<br/>
2) call pushComponentToEL</p>
<p>But in that order of invocations it is impossible to achieve rendered like this:</p>
<p>&lt;h:outputText rendered="#</p>
{component.id eq 'outputTextId'}
<p>" id="outputTextId" /&gt;</p>
<p>i.e. any rendered ValueEpression based on component itself.</p>
JAVASERVERFACES_SPEC_PUBLIC-1002Order of isRendered and pushComponentToEL prevents rendered="#{}" based on component implicit objectBugMajorOpenUnresolvedUnassignedMartin KočíTue, 17 May 2011 10:27:20 +0000Tue, 12 Aug 2014 20:10:16 +00002.1Components/Renderers01<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i0046v:Rank (Obsolete)680[JAVASERVERFACES_SPEC_PUBLIC-988] Dynamic include problemhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-988
javaserverfaces-spec-public<p>JB&gt; 2) the "dynamic UI include" problem - This is a scenario where you<br/>
JB&gt; have several different types of include files and need to show a<br/>
JB&gt; list of items (each "item" being the include template) where the<br/>
JB&gt; list is only know at runtime. Let's make up a specific example here<br/>
JB&gt; to illustrate:</p>
<p>JB&gt; You have an event registration system that sells tickets online:</p>
<p>JB&gt; - A user can buy multiple tickets (and different types of tickets)<br/>
JB&gt; as part of the purchase process</p>
<p>JB&gt; - Each ticket purchased has to have totally different information<br/>
JB&gt; filled out</p>
<p>JB&gt; - There are many different types of tickets (e.g.: attendee,<br/>
JB&gt; sponsor, exhibitor, etc)</p>
<p>JB&gt; - every time they "add a ticket" (it considers what kind of ticket<br/>
JB&gt; they selected and adds that type of form to the list of forms that<br/>
JB&gt; will need to be completed before proceeding with the purchase)</p>
<p>JB&gt; Now obviously in this example you could build a "dynamic" template<br/>
JB&gt; that based on an input variable renders itself differently and put<br/>
JB&gt; this inside a &lt;ui:repeat/&gt; - or for that matter you could<br/>
JB&gt; programmatically insert the elements comprising each type of form<br/>
JB&gt; into the control tree. The problems with these approaches is that<br/>
JB&gt; you're back to server programming for every little UI change (not to<br/>
JB&gt; mention you've got one big component with potentially hundreds of<br/>
JB&gt; pieces of logic in it). ASP.NET solves this by allowing you to<br/>
JB&gt; define a .ascx file (much like a facelet include) and then<br/>
JB&gt; programmatically include them into something akin to a JSF<br/>
JB&gt; panelGroup. Then on postback you simply get an enumeration of the<br/>
JB&gt; items and loop through them to retrieve the values of the class<br/>
JB&gt; that's bound to the child components. Now with a lot of trickery and<br/>
JB&gt; a ton of time for each implementation you can get something close<br/>
JB&gt; with JSF but it's not at all intuitive or easy.</p>JAVASERVERFACES_SPEC_PUBLIC-988Dynamic include problemImprovementMajorOpenUnresolvedUnassignedEd BurnsMon, 25 Apr 2011 09:31:07 +0000Tue, 12 Aug 2014 20:08:21 +00001.22.02.1Facelets/VDL11<ul class="alternate" type="square">
<li>The JSF framework is a set of abstractions for building different types of web applications.</li>
<li>A business application is a set of polymorphic systems.</li>
<li>Different types of Customers</li>
<li>Different types of Contracts</li>
<li>Different types of Y</li>
</ul>
<p>which leads to this recurrent design</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> <span class="code-keyword">abstract</span> class Y {
}
<span class="code-keyword">public</span> class XY <span class="code-keyword">extends</span> Y{
}
</pre>
</div></div>
<p>which once applied in an event registration system brings something like this</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> <span class="code-keyword">abstract</span> class Ticket {
}
<span class="code-keyword">public</span> class SponsorTicket <span class="code-keyword">extends</span> Ticket {
}
<span class="code-keyword">public</span> class AttendeeTicket <span class="code-keyword">extends</span> Ticket {
}
<span class="code-keyword">public</span> class Reservation {
<span class="code-keyword">public</span> void addTicket(Ticket ticket) {
}
<span class="code-keyword">public</span> void removeTicket(Ticket ticket) {
}
<span class="code-keyword">public</span> Collection&lt;Ticket&gt; getTickets() {
}
}
</pre>
</div></div>
<p>Let's make something interesting now and let's override the toString() method to return the type of a ticket.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> class SponsorTicket <span class="code-keyword">extends</span> Ticket {
<span class="code-keyword">public</span> <span class="code-object">String</span> toString() {
<span class="code-keyword">return</span> <span class="code-quote">"SponsorTicket"</span>;
}
}
<span class="code-keyword">public</span> class AttendeeTicket <span class="code-keyword">extends</span> Ticket {
<span class="code-keyword">public</span> <span class="code-object">String</span> toString() {
<span class="code-keyword">return</span> <span class="code-quote">"AttendeeTicket"</span>;
}
}
</pre>
</div></div>
<p>This technique is powerful in a polymorphic system once coupled with the power of a template engine to generate dynamic content following a pattern like this one :</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
return-value${dynamic-value}
</pre>
</div></div>
<ul class="alternate" type="square">
<li>Let's design now our form web pages using the Velocity Template Engine</li>
</ul>
<ul class="alternate" type="square">
<li>Reservation page</li>
</ul>
<p>dynamic include of the derivate forms based on the toString() return value.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
#foreach($ticket in $reservation.tickets)
#set($template=<span class="code-quote">"form"</span> + $ticket + <span class="code-quote">".vm"</span>)
#include($template)
#end
</pre>
</div></div>
<ul class="alternate" type="square">
<li>formSponsorTicket.vm</li>
</ul>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
label 1 : <span class="code-tag">&lt;input type=<span class="code-quote">"text"</span> value=<span class="code-quote">".."</span>/&gt;</span>
label 2 : <span class="code-tag">&lt;input type=<span class="code-quote">"text"</span> value=<span class="code-quote">".."</span>/&gt;</span>
label 3 : <span class="code-tag">&lt;input type=<span class="code-quote">"text"</span> value=<span class="code-quote">".."</span>/&gt;</span>
label 4 : <span class="code-tag">&lt;input type=<span class="code-quote">"text"</span> value=<span class="code-quote">".."</span>/&gt;</span>
label 5 : <span class="code-tag">&lt;input type=<span class="code-quote">"text"</span> value=<span class="code-quote">".."</span>/&gt;</span>
</pre>
</div></div>
<p>Because we have a polymorphic system, the forms will have some fields in common. Thus to avoid the duplication, it is better to create a common page (formTicket.vm) like we did for the abstract class Ticket.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
#foreach($ticket in $reservation.tickets)
#include(<span class="code-quote">"formTicket.vm"</span>)
#set($template=<span class="code-quote">"form"</span> + $ticket + <span class="code-quote">".vm"</span>)
#include($template)
#end
</pre>
</div></div>
<p>..............................................................................</p>
<ul class="alternate" type="square">
<li>Let's design now our form web pages using the Facelets Template Engine</li>
</ul>
<ul class="alternate" type="square">
<li>Reservation Page</li>
</ul>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;ui:repeat value=<span class="code-quote">"#{reservation.tickets}"</span> var=<span class="code-quote">"ticket"</span>&gt;</span>
<span class="code-tag">&lt;ui:include src=<span class="code-quote">"formTicket.xhtml"</span>/&gt;</span>
<span class="code-tag">&lt;ui:include src=<span class="code-quote">"form${ticket}.xhtml"</span>/&gt;</span>
<span class="code-tag">&lt;/ui:repeat&gt;</span>
</pre>
</div></div>
<p>Common Page : formTicket.xhtml</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
label 1 : <span class="code-tag">&lt;h:inputText value=<span class="code-quote">".."</span>/&gt;</span>
label 2 : <span class="code-tag">&lt;h:inputText value=<span class="code-quote">".."</span>/&gt;</span>
</pre>
</div></div>
<p>Page : formSponsorTicket.xhtml</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
label 3 : <span class="code-tag">&lt;h:inputText value=<span class="code-quote">".."</span>/&gt;</span>
label 4 : <span class="code-tag">&lt;h:inputText value=<span class="code-quote">".."</span>/&gt;</span>
label 5 : <span class="code-tag">&lt;h:inputText value=<span class="code-quote">".."</span>/&gt;</span>
</pre>
</div></div>
<p>-------------------------------------------------------------------------</p>
<p>Comparison of the solutions</p>
<p>The two solutions are the same even if I'm using two different template engines and what is quite amazing is that none of them works. Why? Because when you include a file in a iteration, you still get the whole context as model. No way to use the current object being iterated as model thus making you unable to do something like this</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;ui:repeat value=<span class="code-quote">"#{reservation.tickets}"</span> var=<span class="code-quote">"ticket"</span>&gt;</span>
<span class="code-tag">&lt;ui:include src=<span class="code-quote">"formTicket.xhtml"</span>/&gt;</span> (var=<span class="code-quote">"ticket"</span> not used)
....................................................
<span class="code-tag">&lt;/ui:repeat&gt;</span>
</pre>
</div></div>
<p>Velocity :</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;input type=<span class="code-quote">"text"</span> value=<span class="code-quote">"${ticket.property1}"</span>/&gt;</span>
</pre>
</div></div>
<p>Facelets :</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;h:inputText value=<span class="code-quote">"#{ticket.property1}"</span>/&gt;</span>
</pre>
</div></div>
<p>Jason, You are doing a binding in your managed beans because you want to have a way to get this reference and as you may know, binding means coupling, maintenance nightmare, a change here and a change there.</p>
<p>To overcome this problem without using the problematic programmatic approach, we should have a way to set the model to use for the template to be included, something like this </p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;ui:include src=<span class="code-quote">"formTicket.xhtml"</span> model=<span class="code-quote">"${ticket}"</span>/&gt;</span>
</pre>
</div></div>
<p>Reservation Page</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;ui:repeat value=<span class="code-quote">"#{reservation.tickets}"</span> var=<span class="code-quote">"ticket"</span>&gt;</span>
<span class="code-tag">&lt;ui:include src=<span class="code-quote">"formTicket.xhtml"</span> model=<span class="code-quote">"#{ticket}"</span>/&gt;</span>
<span class="code-tag">&lt;ui:include src=<span class="code-quote">"form#{ticket}.xhtml"</span> model=<span class="code-quote">"#{ticket}"</span>/&gt;</span>
<span class="code-tag">&lt;/ui:repeat&gt;</span>
</pre>
</div></div>
<p>Another alternative would be to use the JSF composite components feature which is the opposite side of the dynamic include approach<br/>
and one possible solution to leverage if the JSF runtime was able to generate dynamically the xml tags by following a pattern like this</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;namespace:#{tag-value}&gt;</span>
</pre>
</div></div>
<p>So instead of creating a facelets view for each type of ticket, we will create a composite component for each type of ticket and write something like this in the reservation page</p>
<p>Reservation Page</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;ui:repeat value=<span class="code-quote">"#{reservation.tickets}"</span> var=<span class="code-quote">"ticket"</span>&gt;</span>
<span class="code-tag">&lt;ez:formTicket model=<span class="code-quote">"#{ticket}"</span>/&gt;</span> (formTicket.xhtml)
<span class="code-tag">&lt;ez:form#{ticket} model=<span class="code-quote">"#{ticket}"</span>/&gt;</span> (formSponsorTicket.xhtml...)
<span class="code-tag">&lt;/ui:repeat&gt;</span>
</pre>
</div></div>
<p>Composite component (formSponsorTicket.xhtml)</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;composite:interface&gt;</span>
<span class="code-tag">&lt;composite:attribute name=<span class="code-quote">"model"</span> required=<span class="code-quote">"true"</span>/&gt;</span>
<span class="code-tag">&lt;/composite:interface&gt;</span>
<span class="code-tag">&lt;composite:implementation&gt;</span>
label 3 : <span class="code-tag">&lt;h:inputText value=<span class="code-quote">" #{cc.attrs.model.property1}"</span>/&gt;</span>
label 4 : <span class="code-tag">&lt;inputText value=<span class="code-quote">"#{cc.attrs.model.property2}"</span>/&gt;</span>
label 5 : <span class="code-tag">&lt;inputText value=<span class="code-quote">"#{cc.attrs.model.property3}"</span>/&gt;</span>
<span class="code-tag">&lt;/composite:implementation&gt;</span>
</pre>
</div></div>
<p>If the dynamic tags generation is impossible for JSF, we can still make some if.........</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;ui:repeat value=<span class="code-quote">"#{reservation.tickets}"</span> var=<span class="code-quote">"ticket"</span>&gt;</span>
<span class="code-tag">&lt;c:if test=<span class="code-quote">"#{ticket == 'SponsorTicket'}"</span>&gt;</span>
<span class="code-tag">&lt;ez:formSponsorTicket model=<span class="code-quote">"#{ticket}"</span>/&gt;</span>.
<span class="code-tag">&lt;/c:if&gt;</span>
......
<span class="code-tag">&lt;/ui:repeat&gt;</span>
</pre>
</div></div>
<p> we have two solutions and two possible new issues.</p>
<p>1) Facelets inclusion improvement<br/>
2) EL support for generating dynamic xml tags</p>
<p>These solutions have been realized from a page author perspective.</p><p>JB&gt; Proposed solutions certainly appear valid – but this may actually be a little easier. If item 989 (<a href="http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-989" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-989</a>) is implemented you could quite simply use that function to programmatically add the dynamic include to the control tree. This of course assumes that you can read, compile and include a facelet file programmatically (which I believe I’ve seen somewhere?)</p>
<p>MLB&gt; Again Jason, thus you can programmatically create an UI representation for your object and attach this representation to its UI container<br/>
But this time the UI representation is not created directly from your java code. You take it from a resource, from a facelets file written maybe by a web designer. And the algorithm of your handleRepeatItem(Object currentObjectFromCollection, UIComponent currentContainerHoldingChildComponents) method will look something like that: </p>
<p>1)for the currentObjectFromCollection, find its UI resource file (facelets file)<br/>
2) load the resource file, compile it and create an UI representation from it<br/>
3) Attach the UI representation to its UI container : currentContainerHoldingChildComponents.add(representation)</p>
<p>But at this point, If I were you, I would say " Hey I don't see anymore what JSF did for me and the abstraction it brings to ease the job. Why do I have my hands dirty? Why things shouldn't be simpler as to give the resource name to the JSF runtime which will manage the details for me and create an UI representation (UIComponent) from my resource ".</p>
<h4><a name="javax.faces.Applicationclass"></a>javax.faces.Application class</h4>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> <span class="code-keyword">abstract</span> class Application {
<span class="code-keyword">public</span> UIComponent createComponent(FacesContext context,
Resource componentResource) {
}
<span class="code-keyword">public</span> UIComponent createComponent(Resource resource) {
<span class="code-comment">// a simplification of the first method which use the current context
</span>
}
<span class="code-keyword">public</span> UIComponent createComponent(<span class="code-object">String</span> resourceName) {
<span class="code-comment">// unification, componentType and resourceName must be supported
</span>
}
}
</pre>
</div></div>
<p>To move further Take a look at these issues below because they are related </p>
<p>Where to find the resources : <a href="http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-809" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-809</a></p>
<p>Jason, you are managing 40 developers to develop business applications? Are these applications modular? How do you divide the work among your developers? How do you do the integration of the pieces (modules)? How do you reuse your past work when developing a new application? Do you always start from scratch?</p>
<p>Support for modular, reusable fragments of web applications : <a href="http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532</a><br/>
Plugin System : <a href="http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-970" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-970</a></p>
<p>Have you a web designer in your team?</p>
<p>Multi-templating : <a href="http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971</a></p>
<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i003jj:Rank (Obsolete)575Status Whiteboard<p>size_large importance_large</p>[JAVASERVERFACES_SPEC_PUBLIC-963] Alignment/extending of iterating ui componentshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-963
javaserverfaces-spec-public<p>UIRepeat and UIData do pretty much the same: iterate over a collection of items. There should be a common base class for this, encapsulating the complicated logic for saving/restoring and iterating the state of the "rows". Something like "UIIterate". </p>
<p>Writing iterating components is very complicated at the moment. This base class should be easy to extend and also support any kind of data structures, not only "lists". Using an integer for the "row" iterating index is insufficient for creating "tree" components. A string or kind of indexing object would be much more flexible.</p>
<p>UIRepeat and UIData could extend this class and provide the existing interface on top of it.</p>JAVASERVERFACES_SPEC_PUBLIC-963Alignment/extending of iterating ui componentsSub-taskJAVASERVERFACES_SPEC_PUBLIC-935MajorOpenUnresolvedUnassignedMathias WerlitzFri, 1 Apr 2011 10:32:36 +0000Fri, 1 Aug 2014 17:29:48 +00002.243<p>Well the essential difference between UIData(&lt;h:dataTable&gt;) and UIRepeat is how the iteration is done during render response.<br/>
UIRepeat iterates in the component and HtmlDataTable iterates in the renderer. This flexibility should be possible. Iterating in the renderer can be easier for "tree" components.</p>
<p>I could imagine a structure like this:</p>
<p>UINamingContainer<br/>
&#124;<br/>
UIIterate<br/>
&#124;<br/>
&#124;- UISequentialIterate<br/>
&#124; &#124;<br/>
&#124; &#124;- UIData<br/>
&#124; &#124;- UIRepeat<br/>
&#124;<br/>
&#124;- UITree?</p>
<p>At least there should be an marking interface for such components because state saving seems to be different when nesting of iterating components is possible. For example UIRepeat already checks for UIData or UIRepeat parents. UIData does only look for itself as a parent. </p><p>I thought we had an issue for this, but yes, it's a good idea.</p><p>I think is a very important issue. In general <tt>UIData</tt> seems to be more robust than <tt>UIRepeat</tt>, but they indeed do pretty much the same thing and when inspecting the code it also looks like they had similar implementations at one time and/or borrowed from each other.</p>
<p>If there was a common implementation bugs such as <a href="https://java.net/jira/browse/JAVASERVERFACES-3215" title="UIRepeat needlessly evaluates EL for EditableValueHolders when saving state which can cause exceptions" class="issue-link" data-issue-key="JAVASERVERFACES-3215"><del>JAVASERVERFACES-3215</del></a> would probably not have been there.</p>
<p>It would also prevent issues like <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1103" title="UIRepeat and UIData supports Iterable" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1103"><del>JAVASERVERFACES_SPEC_PUBLIC-1103</del></a>. In that case <tt>UIData</tt> got a new feature that <tt>UIRepeat</tt> would have needed just as well, but because of the time between JSF releases now has to wait for this for a rather long time.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i0042n:Rank (Obsolete)661Status Whiteboard<p>size_medium importance_small</p>[JAVASERVERFACES_SPEC_PUBLIC-961] Limited layout of SelectManyCheckbox and SelectOneRadiohttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-961
javaserverfaces-spec-public<p>&lt;h:selectManyCheckbox&gt; and &lt;h:selectOneRadio&gt; are very limited regarding the output and layout of the individual items. For example is not possible to output any further description for the items. Furthermore rendering tables for layout is quite old fashioned. </p>
<p>Sine these are base components and used very often they should be improved to support user defined output like MyFaces tomahawk eliminating the need for additional component libraries.</p>JAVASERVERFACES_SPEC_PUBLIC-961Limited layout of SelectManyCheckbox and SelectOneRadioImprovementMajorOpenUnresolvedUnassignedMathias WerlitzFri, 1 Apr 2011 10:13:03 +0000Fri, 1 Aug 2014 17:29:14 +00002.2Components/Renderers54<p>It would be very nice to be able to make design like this with use of &lt;h:selectManyCheckbox&gt;</p>
<p>&lt;h:selectManyCheckbox&gt; use of tables make it impossible.</p>
<p>I think this issue should have a higher priority. </p>
<p>I have meet limiteations of the &lt;h:selectManyCheckbox&gt; and &lt;h:selectOneRadio&gt; several times.</p>
<p>And made work around using &lt;h:inputHidden&gt;, &lt;input type="checkbox"&gt; and JavaScript to transfer values from checkboxes and radio buttons to the &lt;h:inputHidden&gt; to use them in JSF.</p><p>+1</p>
<p>I wonder if this is related to <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-329" title="Add new single HTML radio button component that isn&#39;t bound to a list" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-329"><del>JAVASERVERFACES_SPEC_PUBLIC-329</del></a></p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i004fb:Rank (Obsolete)718Status Whiteboard<p>size_large importance_small</p>[JAVASERVERFACES_SPEC_PUBLIC-810] Access to component ancestor chain during Facelets handler processinghttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-810
javaserverfaces-spec-public<p>We have various JSP tag implementations that walk up the component ancestor chain during tag execution <br/>
for one reason or another. While porting these tags to Facelets, we have been forced to work around the <br/>
fact that Facelets does not connect the ancestor chain until after children have been processed.</p>
<p>While it may be too late to change Facelets behavior now, it would be helpful to provide access to the <br/>
ancestor chain through some API so that Facelets handlers can interact with parent/ancestor components.</p><p>Operating System: All<br/>
Platform: Macintosh</p>JAVASERVERFACES_SPEC_PUBLIC-810Access to component ancestor chain during Facelets handler processingImprovementMajorOpenUnresolvedUnassignedaschwartTue, 25 May 2010 15:03:48 +0000Tue, 12 Aug 2014 19:38:50 +00002.0Facelets/VDL51<p>2.1.</p><p>Add adf keyword</p><p>triage</p><p>edburns</p><p>Change target milestone.</p><p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Issuezilla Id810.0Rank0|i003a7:Rank (Obsolete)533Status Whiteboard<p>size_large importance_medium</p>Tagsadf[JAVASERVERFACES_SPEC_PUBLIC-795] UIViewParameter state saving algorithmhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-795
javaserverfaces-spec-public<p>From the mail "State saving of UIViewParameter" on jsr-314-open:</p>
<p>UIViewParameter uses the submittedValue to store its value in the state for the<br/>
next postback, because obviously the view parameter won't be in the request<br/>
parameter map of the next request (which is the postback). But because its<br/>
submittedValue is null after the conversions and validations, it has to be set<br/>
again before the state is generated. To accomplish that, the spec currently<br/>
states to override encodeAll() and make the call to setSubmittedValue() there.<br/>
In addition, encodeAll() has to be called in UIViewRoot.encodeEnd() for every<br/>
UIViewParameter in the view. This works perfectly for normal requests, but when<br/>
you are using an AJAX request the state is generated before<br/>
UIViewRoot.encodeEnd() is called an thus the submittedValue for every<br/>
UIViewParameter is null in the state. This means that the value of every<br/>
UIViewParameter will be null in the following request.</p>
<p>Now the easiest solution to this problem, which I also already committed to<br/>
MyFaces trunk (again see <span class="error">&#91;1&#93;</span> for details), is to do mostly the same as in<br/>
UIViewRoot.encodeEnd() just also in PartialViewContext.<br/>
processPartial() when the PhaseId is RENDER_RESPONSE before the state is<br/>
generated to make it work for AJAX-requests.</p>
<p>However I don't really like this solution, because we have to think of handling<br/>
UIViewParameters in a special way every time we change something on any render<br/>
mechanism. Why don't we just override saveState() on UIViewParameter and set the<br/>
submittedValue there before the state is saved. This will have the same result,<br/>
but without the code in UIViewRoot, PartialViewContext and<br/>
UIViewParameter.encodeAll() and without future headaches. I also already<br/>
uploaded a patch for this to the MyFaces issue at <span class="error">&#91;1&#93;</span>.</p>
<p>Answer to this from Martin Marinschek: "This is just a so much better solution<br/>
<img class="emoticon" src="https://java.net/jira/images/icons/emoticons/wink.gif" height="16" width="16" align="absmiddle" alt="" border="0"/>. We should spec this one."</p>
<p><span class="error">&#91;1&#93;</span> <a href="https://issues.apache.org/jira/browse/MYFACES-2645" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MYFACES-2645</a></p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-795UIViewParameter state saving algorithmBugMajorOpenUnresolvedUnassignedJakob KorherrWed, 12 May 2010 09:05:56 +0000Fri, 1 Aug 2014 16:42:57 +00002.0Components/Renderers64<p>Move to 2.1.</p>
<p>I agree with this approach.</p><p>triage</p><p>rogerk</p><p>triage</p><p>triage</p><p>Was anything ever done for this one?</p><p>Myfaces team took 3 days to review and accept the fix, and Mojarra team could not do the same thing for more than 33 months, and still saw no light.</p>
<p>Is that really amazing or the team is sleeping on its way?</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Set priority to Major</p>Issuezilla Id795.0Rank0|i0038v:Rank (Obsolete)527Status Whiteboard<p>size_small importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-723] add partial parameterhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-723
javaserverfaces-spec-public<p>add attribute partialSubmit="true/false" to f:ajax and<br/>
parameter partialSubmit:'true/false' to jsf.ajax.request options</p>
<p>Only the components named in the "execute" parameter are processed in phase 2-4,<br/>
but the spec insists on submitting all elements included in a form. If<br/>
partialSubmit is set to true submission is reduced to the form params named in<br/>
execute. This is a performance feature that can boost speed on large pages.</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-723add partial parameterImprovementMajorOpenUnresolvedUnassignedganeshpuriTue, 19 Jan 2010 02:46:31 +0000Fri, 1 Aug 2014 16:22:28 +00002.0Ajax/JavaScript75<p>Set target milestone to 2.1</p><p>triage</p><p>rogerk</p><p>status whiteboard</p><p>target milestone</p><p>Former name: "partialSubmit", but "partial" is more compact.<br/>
Would be great to get this into JSF 2.1</p><p>unfortunately this will go into 2.2</p><p>triage</p><p>This is a very good feature provided that there is also a "whitelist" of additional parameters that must be submitted with every Ajax post. Alternatively, a JavaScript callback could be registered to allow frameworks to add required parameters to the POST before submission.</p><p>Regarding the whitelist, we do have that already as documented in the JSDoc. </p>
<p>I strongly favor the callback option. We already have a function jsf.getViewState(formElement). We could specify that a user provided function is called before returning from getViewState() that takes the associative array and the function can modify the associative array however they like.</p>
<p>MyFaces seems to have implemented this and calls it Partial Page Submit (PPS). Werner Punz recently blogged about this great feature here: <a href="http://werpublogs.blogspot.com/2011/07/apache-myfaces-jsfjs-queue-control.html" class="external-link" rel="nofollow">http://werpublogs.blogspot.com/2011/07/apache-myfaces-jsfjs-queue-control.html</a></p>
<p>Incidentally, JavaServer Faces 2.0 The Complete Reference already spoke about a "Partial Submit" (page 343 "... only the value of the userid field is submitted" and Figure 12-2, page 345).</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Issuezilla Id723.0Rank0|i0026n:Rank (Obsolete)355Status Whiteboard<p>size_small importance_large</p>[JAVASERVERFACES_SPEC_PUBLIC-715] missing <f:behavior> (convenience) taghttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-715
javaserverfaces-spec-public<p>For converters/validators there is a convenience tag to integrate (simple)<br/>
custom implementations of these.</p>
<p>For behaviors that is not the case. A &lt;f:behavior&gt; tag would nice; It should<br/>
"act" similar to its cousins, f:converter/validator</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-715missing <f:behavior> (convenience) tagBugMajorOpenUnresolvedUnassignedmwessendorfTue, 5 Jan 2010 22:37:50 +0000Fri, 1 Aug 2014 16:14:01 +00002.1Facelets/VDL02<p>cat1</p><p>vdl</p><p>These are targeted at 2.1.</p><p>edburns</p><p>triage</p><p>GlassFish 3.1 M6 at the latest.</p><p>Move these to 2.2</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Set priority to Major</p>Issuezilla Id715.0Rank0|i00333:Rank (Obsolete)501Status Whiteboard<p>cat2 javadoc size_medium importance_large draft</p>[JAVASERVERFACES_SPEC_PUBLIC-704] UIRepeat et al are not specifiedhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-704
javaserverfaces-spec-public<p>with JSF 2.0, thanks to Facelets, there is a &lt;ui:repeat&gt;. While I understand<br/>
that tags/rendering behavior is part of the internals of an implementation, I am<br/>
not really sure if the underlying/related components should be "hidden" by the<br/>
spec as well.</p>
<p>For instance: I noticed that in MyFaces the UIRepeat extends UIComponentBase and<br/>
implements NamingContainer, while with the JSF RI / Mojarra, the UIRepeat "just"<br/>
extends the UINamingContainer... </p>
<p>... and oh yes... I know that UINamingContainer extends UIComponentBase and<br/>
implements NamingContainer....</p>
<p>but instanceof UINamingContainer doesn't say TRUE for the MyFaces UIRepeat </p>
<p>See a community related discussion here:<br/>
<a href="http://markmail.org/message/wllfudu4ge7n5gxa" class="external-link" rel="nofollow">http://markmail.org/message/wllfudu4ge7n5gxa</a></p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-704UIRepeat et al are not specifiedBugMajorOpenUnresolvedUnassignedmwessendorfWed, 16 Dec 2009 23:59:19 +0000Tue, 12 Aug 2014 19:12:55 +00002.0Components/Renderers12<p>cat2</p><p>javadoc</p><p>These are targeted at 2.1.</p><p>rogerk</p><p>triage</p><p><a href="https://glassfish.dev.java.net/issues/show_bug.cgi?id=11785" class="external-link" rel="nofollow">https://glassfish.dev.java.net/issues/show_bug.cgi?id=11785</a></p>
<p>On Mon Apr 12 15:57:00 +0000 2010, mohammadalavi MA wrote</p>
<p>MA&gt; I've found 2 bugs in jsf 1.2 here's the list<br/>
MA&gt; <br/>
MA&gt; <br/>
MA&gt; 1.when h:dataTable's parent is ui:repeat from facelet duplicated ids<br/>
MA&gt; are generated for child component because UIData's<br/>
MA&gt; isNestedWithinUIData method reports true<br/>
MA&gt; only when the parent is an instance of UIData and UIRepeat is not.<br/>
MA&gt; of course the problem happens because the UIData's getClientId method<br/>
MA&gt; caches the parent client id when isNestedWithinUIData returns false<br/>
MA&gt; if it never cache parent client id this problem wont happen.<br/>
MA&gt; <br/>
MA&gt; public String getClientId(FacesContext context) {<br/>
MA&gt; if (context == null) </p>
{
MA&gt; throw new NullPointerException();
MA&gt; }
<p>MA&gt; if (rowIndex &gt;= 0) </p>
{
MA&gt; String cidBuilder = new StringBuilder();
MA&gt; return cidBuilder.append(super.getClientId(context))
MA&gt; .append(NamingContainer.SEPARATOR_CHAR).append(rowIndex)
MA&gt; .toString();
MA&gt; }
<p> else </p>
{
MA&gt; return super.getClientId(context);
MA&gt; }
<p>MA&gt; }<br/>
MA&gt; 2.TableMetaInfo a static inner class in BaseTableRenderer is used for<br/>
MA&gt; managing style for columns and rows, the getCurrentColumnClass method<br/>
MA&gt; doesn't work as expected it doesn't repeat the styles when number of<br/>
MA&gt; columns is grater than column classes it should be implemented as<br/>
MA&gt; follows:<br/>
MA&gt; <br/>
MA&gt; public String getCurrentColumnClass() {<br/>
MA&gt; <br/>
MA&gt; String style = null;<br/>
MA&gt; if (columnStyleCounter &lt; columnClasses.length &amp;&amp;<br/>
MA&gt; columnStyleCounter &lt; columnCount) </p>
{
MA&gt; style = columnClasses[columnStyleCounter++];
MA&gt; }
<p>MA&gt; if(columnStyleCounter &gt;= columnClasses.length) </p>
{
MA&gt; columnStyleCounter = 0;
MA&gt; }
<p>MA&gt; return ((style != null &amp;&amp; style.length() &gt; 0) ? style : null);</p><p>triage</p><p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Issuezilla Id704.0Rank0|i0032n:Rank (Obsolete)499Status Whiteboard<p>cat2 javadoc size_medium importance_large draft</p>[JAVASERVERFACES_SPEC_PUBLIC-682] Add support for XHR timeouthttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-682
javaserverfaces-spec-public<p>Add support for XHR timeout.</p>
<p>This is marked as a P1 spec defect - it was felt during the EG Ajax meeting that<br/>
this lack of support for timeout was a critical failure.</p>
<p>A request that is unexpectedly long running, or a network timeout, can<br/>
completely freeze the client. Hence, the P1 status.</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-682Add support for XHR timeoutBugMajorOpenUnresolvedUnassigneddriscollWed, 2 Dec 2009 08:07:47 +0000Tue, 12 Aug 2014 18:57:51 +00002.0Ajax/JavaScript11<p>corrected target</p><p>rogerk</p><p>triage</p><p>target 2.1_gf31_m5</p><p>starting</p><p>I am looking to introduce a "timeout" attribute (property) on the ajax.request<br/>
(and also f:ajax tag) where u can specify a time in milliseconds. For example:</p>
<p>onclick="jsf.ajax.request(this, event, </p>
{execute: this.id, render: 'out1',
timeout: '5000'}
<p>);....</p>
<p>and also</p>
<p>f:ajax timeout="5000"...</p>
<p>target MS6</p><p>Out of time for this for 2.1.</p><p>MyFaces has timeout already in with a custom parameter.<br/>
You cam pass a myfaces</p>
{timeout:&lt;value&gt;}
<p> in the options list.</p>
<p>The timeout should be an option like execute and render.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Issuezilla Id682.0Rank0|i0026f:Rank (Obsolete)354Status Whiteboard<p>size_large importance_large</p>[JAVASERVERFACES_SPEC_PUBLIC-674] Allow ajax response short-circuit/overridehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-674
javaserverfaces-spec-public<p>Currently, JSF handles an ajax response, including the re-rendering of the<br/>
specified components, every time, even if onevent is specified. There are times<br/>
when the ajax response requires custom handling. For example, the HTML returned<br/>
after rerendering a large data table might need to be passed to a Javascript<br/>
widget so it can update its state in a widget-specific manner. There is<br/>
currently no way to do this. </p>
<p>I would like to see the ajax portion of the spec modified to allow client code<br/>
to override the response handling, thus assuming the full burden of updating the<br/>
client.</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-674Allow ajax response short-circuit/overrideImprovementMajorOpenUnresolvedUnassignedJason LeeFri, 20 Nov 2009 10:10:43 +0000Tue, 12 Aug 2014 18:56:24 +00002.0Ajax/JavaScript01<p>Prepare to delete "spec" subcomponent.</p><p>cat2</p><p>frame</p><p>These are targeted at 2.1.</p><p>triage</p><p>rogerk</p><p>triage</p><p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Issuezilla Id674.0Rank0|i002yv:Rank (Obsolete)482Status Whiteboard<p>cat2 frame size_medium importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-658] PartialViewContext interoperabilityhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-658
javaserverfaces-spec-public<p>Contract of PartialViewContext doesn't give enough freedom for JSF components libraries to override it <br/>
partially. Example: simple addition of "extension" element (or any other that RI's implementation doesn't <br/>
do, but component libraries may need) requires full re-implementation of PartialViewContext class, thus <br/>
making co-existence of different libraries almost impossible. If some AJAX-updated component outputs <br/>
"extension" element, then it appears inside "update" element causing malformed XML error on the client, <br/>
so this approach doesn't work.</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-658PartialViewContext interoperabilityBugMajorOpenUnresolvedUnassignednick_belaevskiMon, 2 Nov 2009 12:19:54 +0000Tue, 12 Aug 2014 18:51:59 +00002.0Ajax/JavaScript92<p>Prepare to delete api subcomponent</p><p>2.0 rev a</p><p>frame</p><p>Just to be clear...<br/>
Are you proposing an API change on PartialViewContext?<br/>
Can you please provide a more concrete example and use case?</p><p>Ownership</p><p>These are valid 2.0 Rev a issues</p><p>Target 2.1</p><p>More concrete example can be update/insertion/deletion of component part. Let's <br/>
take filterable data table component. When user types something in filter field, <br/>
live update of table content should be happening, but we aren't going to update <br/>
the whole table, because this will cause loss of user's input focus. So, <br/>
component assigns id="#</p>
{clientId}:tbody" to &lt;tbody&gt; element with the intention <br/>
to update it later by special event.<br/>
<br/>
Looking at the API of PartialViewContext, how would component be doing this? <br/>
There's processPartial(PhaseId phaseId) that does the complete processing and in <br/>
Mojarra it is implemented via visiting components tree using either <br/>
PartialVisitContext or FullVisitContext. So, if we add component clientId into <br/>
renderIds, implementation will call component's encodeAll(...) method wrapping <br/>
it into &lt;update id="#{clientId}
<p>"&gt;...&lt;/update&gt; element. If we don't add component <br/>
clientId, then control won't be passed to component at all. If we call <br/>
startUpdate()/endUpdate() for our &lt;tbody&gt; from encodeAll(...), then &lt;update&gt; <br/>
elements are nested and XML is not correct, causing update to fail (this has <br/>
been already discussed in jsr-314 mailing list). The same problem with any <br/>
insert/delete/extension element. Solution: do complete re-write of <br/>
PartialViewContext, but this affects interoperability in a poor way.</p>
<p>Proposed API change: two methods that will allow users to override creation of <br/>
VisitContext &amp; VisitCallback for the particular phase.</p><p>triage</p><p>target</p><p>Nick - I need to push this to 2.2 unless you can supply the spec changes.</p><p>Created an attachment (id=318)<br/>
Proposed patch</p><p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Issuezilla Id658.0Rank0|i002xr:Rank (Obsolete)477Status Whiteboard<p>cat1 frame size_large importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-636] Clarification of Facelets-only (non-JSP) functionalityhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-636
javaserverfaces-spec-public<p>I would like to see the spec provide more explicit documentation of exactly which new features are not <br/>
available in JSP. I sent the following two proposals to the EG list:</p>
<p>1. Let's update the spec to state specifically what functionality (down to the tag/tag library level) is not <br/>
supported in JSP.</p>
<p>It is possible that this information is already present, but if not, I would like to see a section that <br/>
contains a list of all of the new tags that were added in JSF 2 that are specific to Facelets (ie. not <br/>
available in JSP).</p>
<p>2. Let's update the Facelets PDL docs to identify tags that are not present in JSP.</p>
<p>For example, the PDL doc for f:ajax should state that it is not available in JSP.</p>
<p>Regarding #1... I think it is important to have this information available in a centralized location, where <br/>
it can be easily found/understood by JSP users. #2 should also help to avoid confusion.</p><p>Operating System: All<br/>
Platform: Macintosh</p>JAVASERVERFACES_SPEC_PUBLIC-636Clarification of Facelets-only (non-JSP) functionalityImprovementMajorOpenUnresolvedUnassignedaschwartThu, 24 Sep 2009 08:53:33 +0000Tue, 12 Aug 2014 18:49:32 +00002.0Facelets/VDL11<p>Move to unscheduled target milestone</p><p>Prepare to delete api subcomponent</p><p>Target 2.0 Rev A</p><p>cat1</p><p>facelets</p><p>These are valid 2.0 Rev a issues</p><p>take ownership.</p><p>Please make sure to see issue 1402.</p><p>This is not a technically difficult issue, but it is a time consuming one. </p>
<p>I think the best way to do it is empirically. I'm writing an HtmlUnit test suite that exercises the jsp <br/>
accessible supported/unsupported status of the big ticket new features in JSF2.</p>
<p>So far it's looking like this:</p>
<p> public void testUnsupportedFeaturesAreUnsupported() throws Exception </p>
{
// These features are not implemented in JSP
assert500Response("/faces/jsf2jsp/head-gives-500.jspx");
assert500Response("/faces/jsf2jsp/body-gives-500.jspx");
assert500Response("/faces/jsf2jsp/outputScript-gives-500.jspx");
assert500Response("/faces/jsf2jsp/outputStylesheet-gives-500.jspx");
assert500Response("/faces/jsf2jsp/button-gives-500.jspx");
assert500Response("/faces/jsf2jsp/link-gives-500.jspx");
assert500Response("/faces/jsf2jsp/resource-ELResolver-gives-500.jspx");
assert500Response("/faces/jsf2jsp/ajax-gives-500.jspx");
assert500Response("/faces/jsf2jsp/event-gives-500.jspx");
assert500Response("/faces/jsf2jsp/metadata-gives-500.jspx");
}
<p> public void testSupportedFeaturesAreSupported() throws Exception </p>
{
// These features are implemented in JSP
HtmlPage page = getPage("/faces/jsf2jsp/commandButton-parameter-children-gives-hidden-
fields.jspx");
HtmlSubmitInput button = (HtmlSubmitInput) page.getElementById("reload");
page = button.click();
String text = page.asText();
assertTrue(text.contains("name01=value01"));
assertTrue(text.contains("name02=value02"));
page = getPage("/faces/jsf2jsp/resources.jspx");
text = page.asXml();
assertTrue(text.contains("duke.gif"));
assertTrue(text.contains("vLibrary"));
assertTrue(text.contains("2_01_1"));
assert200Response("/faces/jsf2jsp/selectManyJsf2Features.jspx");
Test validatorTest = ValidatorTestCase.suite();
TestResult validatorResult = new TestResult();
validatorTest.run(validatorResult);
assertTrue(validatorResult.failureCount() == 0);
}
<p>Because this issue is labor intensive, I'm wondering if we should push it to 2.1?</p><p>Move to 2.1.</p><p>Copy this from Neil Griffin's google doc linked from issue 714.</p>
<p>Availability of f:validateBean and f:validateRequired in JSP</p>
<p>Section 10.4 outlines the f: namespaced tags that are only applicable to Facelets (and not JSP). In that <br/>
section, f:validateBean, and f:validateRequired are listed. However, they are both listed as working with <br/>
JSP as well (kind of like f:validateRegex), as can be seen from the JSP TLDDocs <span class="error">&#91;1&#93;</span>.</p>
<p>According to Dan Allen: "those tags only work partially in JSP. Yes, they work as single field validators. <br/>
But the branch validator capability does not work (wrapping the validator tag around a branch). The <br/>
later feature is Facelets only. So the validators do have their feet in both ponds, but only Facelets has full <br/>
support. I suppose we could mention this tidbit in the JSP section."</p>
<p>I agree with Dan that it should be mentoned in the JSP section, but also, that f:validateBean and <br/>
f:validateRequired belong in both Section 10.4 and 9.4, with the limits of their functionality described in <br/>
each section.</p>
<p><span class="error">&#91;1&#93;</span> <a href="https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/jsp/index.html" class="external-link" rel="nofollow">https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/jsp/index.html</a></p><p>triage</p><p>GlassFish 3.1 M6 at the latest.</p><p>ADF issues targeted at GlassFish 3.1 M5</p><p>Created an attachment (id=248)<br/>
jsf-ri/systest/web/validator06.jspx</p><p>I discovered that f:viewParam exists in the JSP jsf_core.tld. Does it really work?</p><p>Move to m6</p><p>Must be done by September 30th.</p><p>Move these to 2.2</p><p>changelog</p><p>remove changelog_2_1 keyword.</p><p>The specification of StateManagementStrategy is too tight and needs to be loosened to allow greater flexibility of implementation.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Issuezilla Id636.0Rank0|i002vj:Rank (Obsolete)467Status Whiteboard<p>cat1 frame size_large importance_large</p>Tagsadf[JAVASERVERFACES_SPEC_PUBLIC-634] Add an escape attribute to h:messages and h:message like in h:outputTexthttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-634
javaserverfaces-spec-public<p>I want to output an HTML link as part of my error message, but can't because the<br/>
HTML is escaped by h:messages. I searched Google for a workaround and found<br/>
many people have the same problem. There have even been tickets created against<br/>
JSF RI and MyFaces years ago. </p>
<p><a href="https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=746" class="external-link" rel="nofollow">https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=746</a><br/>
<a href="http://issues.apache.org/jira/browse/MYFACES-155" class="external-link" rel="nofollow">http://issues.apache.org/jira/browse/MYFACES-155</a></p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-634Add an escape attribute to h:messages and h:message like in h:outputTextImprovementMajorOpenUnresolvedUnassignedrdelaplanteTue, 22 Sep 2009 07:37:16 +0000Tue, 12 Aug 2014 18:49:17 +00002.0Components/Renderers24<p>Move to unscheduled target milestone</p><p>Prepare to delete api subcomponent</p><p>Target 2.0 Rev A</p><p>cat2</p><p>rk</p><p>These are targeted at 2.1.</p><p>triage</p><p>rogerk</p><p>triage</p><p>triage</p><p>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 &amp; emphasis.</p><p>RichFaces supports this attribute with it's rich:message component (see: <a href="http://docs.jboss.org/richfaces/latest_4_X/vdldoc/rich/message.html" class="external-link" rel="nofollow">http://docs.jboss.org/richfaces/latest_4_X/vdldoc/rich/message.html</a>)</p>
<p>Primefaces also supports this attirbute in it's message tag:<br/>
<a href="http://blog.primefaces.org/?p=1894" class="external-link" rel="nofollow">http://blog.primefaces.org/?p=1894</a></p>
<p>It seems to me it's something the community is asking for, and should be rolled into the spec.</p><p>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.</p><p>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.</p><p>This feature is implemented in OmniFaces:</p>
<p><a href="http://showcase.omnifaces.org/components/messages" class="external-link" rel="nofollow">http://showcase.omnifaces.org/components/messages</a></p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Issuezilla Id634.0Rank0|i002vb:Rank (Obsolete)466Status Whiteboard<p>cat2 renderkitdoc size_small importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-631] Specify target facet name when inserting into composite componenthttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-631
javaserverfaces-spec-public<p>As discussed on jsr-314-open...</p>
<p>As currently specified, composite:insertFacet's "name" attribute serves two purposes:</p>
<p>1. It identifies the name of the facet on the containing composite component to insert.<br/>
2. It identifies the name of the facet on the target component into which the facet is being inserted.</p>
<p>As a result, the name of the facet exposed by the composite component must match the name of the <br/>
facet on the implementation component into which the facet is being inserted. So, for example, if I <br/>
have a composite component as follows:</p>
<p>&lt;composite:interface&gt;<br/>
&lt;composite:facet name="caption"/&gt;<br/>
&lt;/composite:interface&gt;</p>
<p>&lt;composite:implementation&gt;<br/>
&lt;h:panelGrid&gt;<br/>
&lt;composite:insertFacet name="caption"/&gt;<br/>
&lt;/h:panelGrid&gt;<br/>
&lt;/composite:implementation&gt;</p>
<p>Everything is happy, since both the composite component and the h:panelGrid expose a "caption" facet.</p>
<p>However, if I want to define a composite component with two h:panelGrid components and two <br/>
captions:</p>
<p>&lt;composite:interface&gt;<br/>
&lt;composite:facet name="caption"/&gt;<br/>
&lt;composite:facet name="backupCaption"/&gt;<br/>
&lt;/composite:interface&gt;</p>
<p>&lt;composite:implementation&gt;<br/>
&lt;h:panelGrid&gt;<br/>
&lt;composite:insertFacet name="caption"/&gt;<br/>
&lt;/h:panelGrid&gt;</p>
<p> &lt;h:panelGrid&gt;<br/>
&lt;!-- Uh oh. --&gt;<br/>
&lt;composite:insertFacet name="backupCaption"/&gt;<br/>
&lt;/h:panelGrid&gt;<br/>
&lt;/composite:implementation&gt;</p>
<p>I am out of luck, since I now have a mismatch between the composite component facet name and the <br/>
h:panelGrid facet name.</p>
<p>I think that we could/should solve this in one of two ways:</p>
<p>1. Add an attribute to composite:insertFacet that allows a target facet name to be specified:</p>
<p> &lt;h:panelGrid&gt;<br/>
&lt;composite:insertFacet name="backupCaption" targetName="caption"/&gt;<br/>
&lt;/h:panelGrid&gt;</p>
<p>2. Specify that the target facet name can be picked up from a wrapping &lt;f:facet&gt; tag:</p>
<p> &lt;h:panelGrid&gt;<br/>
&lt;f:facet name="caption"&gt;<br/>
&lt;composite:insertFacet name="backupCaption"/&gt;<br/>
&lt;/f:facet&gt;<br/>
&lt;/h:panelGrid&gt;</p><p>Operating System: All<br/>
Platform: Macintosh</p>JAVASERVERFACES_SPEC_PUBLIC-631Specify target facet name when inserting into composite componentImprovementMajorOpenUnresolvedUnassignedaschwartFri, 18 Sep 2009 13:25:36 +0000Fri, 1 Aug 2014 15:41:10 +00002.0Uncategorized13<p>Move to unscheduled target milestone</p><p>Prepare to delete api subcomponent</p><p>Because we now have renderFacet <b>and</b> insertFacet, I'm wondering if this is still valid? Can you re-<br/>
open if so?</p><p>I find the insertFacet tag to be useless without this fix. I think that we should address this, perhaps for <br/>
2.2.</p><p>Don't know how this ended up being assigned to javaserverfowner. I thought we<br/>
re-assigned all of those.</p><p>Created an attachment (id=322)<br/>
Patch with solution involving add "targetName" attribute</p><p>Created an attachment (id=323)<br/>
WAR file from test project</p><p>Created an attachment (id=324)<br/>
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run</p><p>triage</p><p>IMHO it should be targeted for 2.1</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Issuezilla Id631.0Rank0|i002v3:Rank (Obsolete)465Status Whiteboard<p>size_medium importance_medium</p>Tagsadf[JAVASERVERFACES_SPEC_PUBLIC-609] ui:repeat varStatus incompletely specified.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-609
javaserverfaces-spec-public<p>The varStatus attribute on ui:repeat supports some of the concepts present in JSTL's LoopTagStatus <span class="error">&#91;1&#93;</span>, <br/>
including the "begin" and "end" concept. However, the corresponding attributes from c:forEach are not <br/>
exposed on ui:repeat. This issue would like to fix that.</p>
<p><span class="error">&#91;1&#93;</span> <a href="http://java.sun.com/javaee/6/docs/api/javax/servlet/jsp/jstl/core/LoopTagStatus.html" class="external-link" rel="nofollow">http://java.sun.com/javaee/6/docs/api/javax/servlet/jsp/jstl/core/LoopTagStatus.html</a></p><p>Operating System: All<br/>
Platform: Macintosh</p>JAVASERVERFACES_SPEC_PUBLIC-609ui:repeat varStatus incompletely specified.BugMajorOpenUnresolvedUnassignedEd BurnsWed, 12 Aug 2009 09:19:39 +0000Fri, 1 Aug 2014 15:31:59 +00002.0Facelets/VDL33<p>Taking the documentatation from c:forEach <span class="error">&#91;1&#93;</span></p>
<p>begin If items specified: Iteration begins at the item located at the specified index. First item of the <br/>
collection has index 0. If items not specified: Iteration begins with index set at the value specified.</p>
<p>end </p>
<p>If items specified: Iteration ends at the item located at the specified index (inclusive). If items not <br/>
specified: Iteration ends when index reaches the value specified.</p>
<p><span class="error">&#91;1&#93;</span> <a href="http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/c/forEach.html" class="external-link" rel="nofollow">http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/c/forEach.html</a></p><p>Target to 2.1</p><p>Prepare to delete "spec" subcomponent.</p><p>Move these to unscheduled because we need to target them correctly. 2.next isn't <br/>
specific enough.</p><p>cat2</p><p>vdl</p><p>These are targeted at 2.1.</p><p>triage</p><p>Change target milestone.</p><p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Issuezilla Id609.0Rank0|i0025j:Rank (Obsolete)350Status Whiteboard<p>cat2 vdldoc size_small importance_small</p>[JAVASERVERFACES_SPEC_PUBLIC-543] @Valid and JSFhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-543
javaserverfaces-spec-public<p>Consider this using page</p>
<p>&lt;h:form&gt;<br/>
&lt;h:inputText value="#{person.name" /&gt;<br/>
&lt;h:inputText value="#{person.email" /&gt;</p>
<p> &lt;ez:address person="#</p>
{person"}
<p>&gt;<br/>
&lt;f:validateBean /&gt;<br/>
&lt;/ez:address&gt;</p>
<p>&lt;/h:form&gt;</p>
<p>and this composite component </p>
<p>&lt;comp:interface&gt;<br/>
&lt;comp:attribute name="person" /&gt;<br/>
&lt;comp:editableValueHolder target="street" /&gt;<br/>
&lt;comp:editableValueHolder target="city" /&gt;<br/>
&lt;/comp:interface&gt;</p>
<p>&lt;comp:implementation&gt;<br/>
&lt;h:inputText value="#</p>
{cc.attrs.person.address.street}
<p>" /&gt;<br/>
&lt;h:inputText value="#</p>
{cc.attrs.person.address.city}
<p>" /&gt;<br/>
&lt;/comp:implementation&gt;</p>
<p>I'd like to be able to simply put the JSR-303 @Valid annotation on the entire Person bean and know that <br/>
the fields will be validated appropriately according to the rules for that annotation. Currently I don't <br/>
think this is possible.</p><p>Operating System: All<br/>
Platform: Macintosh</p>JAVASERVERFACES_SPEC_PUBLIC-543@Valid and JSFSub-taskJAVASERVERFACES_SPEC_PUBLIC-972MajorOpenUnresolvedUnassignedEd BurnsFri, 17 Apr 2009 07:16:24 +0000Fri, 1 Aug 2014 15:14:43 +00002.2 Sprint 8Validation/Conversion13<p>Move to unscheduled target milestone</p><p>Prepare to delete "spec" subcomponent.</p><p>cat2</p><p>frame</p><p>These are targeted at 2.1.</p><p>triage</p><p>sheetalv</p><p>triage</p><p>BV v1 doesn't allow @Valid at the class level - see:<br/>
@Target(</p>
{ METHOD, FIELD, CONSTRUCTOR, PARAMETER }
<p>)<br/>
@Retention(RUNTIME)<br/>
public @interface Valid {}</p>
<p>What we should support is something similar - see <a href="http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-972" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-972</a></p><p>Bulk assign all of Sheetal's spec issues to me.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting to priority Major. Please check latest iteration of BeanValidator to see if this is already working.</p>Issuezilla Id543.0Rank0|i0045j:Rank (Obsolete)674Status Whiteboard<p>cat2 frame size_medium importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-457] Use EL in message bundleshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-457
javaserverfaces-spec-public<p>Motivation<br/>
------</p>
<p>EL is pervasive in JSF, except in one obvious place, message bundles. Adding<br/>
this support would be natural for the developer, and in some respects increase<br/>
DRY (by not requiring parameters to specified in each place the message is used).</p>
<p>Proposal<br/>
------</p>
<p>Support the use of EL in the values of the key-value pairs present in any bundle<br/>
that is loaded via &lt;f:loadBundle /&gt; or via the &lt;message-bundle&gt; element in<br/>
faces-config.xml. The EL expression should be parsed out of the value String,<br/>
and evaluated as a value expression.</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-457Use EL in message bundlesImprovementMajorOpenUnresolvedUnassignedpmuirSun, 31 Aug 2008 14:46:21 +0000Fri, 1 Aug 2014 14:51:15 +00002.2 Sprint 8Platform Integration (except for Bean Validator)14<p>A JBoss top priority issue issue</p><p>Change target milestone to 2.0</p><p>move to 2.1</p><p>Prepare to delete api subcomponent</p><p>Move these to unscheduled because we need to target them correctly. 2.next isn't <br/>
specific enough.</p><p>Changed to platform integration (may not be the right subcomponent). Changed<br/>
milestone to 2.0 Rev A.</p><p>cat1</p><p>frame</p><p>New functionality, move to 2.1</p><p>New functionality, move to 2.1</p><p>cat2</p><p>These are targeted at 2.1.</p><p>triage</p><p>edburns</p><p>GlassFish 3.1 M6 at the latest.</p><p>Move these to M5</p><p>Move these to 2.2</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Issuezilla Id457.0Rank0|i002hz:Rank (Obsolete)406Status Whiteboard<p>EGTop5 cat2 frame size_medium importance_large draft</p>[JAVASERVERFACES_SPEC_PUBLIC-353] Only halt component processing on disabled not readOnlyhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-353
javaserverfaces-spec-public<p>Currently the renderkit docs for input specify that in decode no further<br/>
processing of a component should take place if it is readOnly or disabled.</p>
<p>I'd like to propose that this get modified to only apply to "disabled". <br/>
According to (<a href="http://www.w3.org/TR/html401/interact/forms.html#adef-readonly" class="external-link" rel="nofollow">http://www.w3.org/TR/html401/interact/forms.html#adef-readonly</a>)<br/>
readonly input elements cannot be modified by the user. However, they can be<br/>
modified by a script and it IS submitted with the form.</p>
<p>For example. You might have a standard "datepicker" JS component. I may attach<br/>
a javascript datepicker to an inputText component. If I want only the<br/>
datePicker JS to modify the inputtext then I would set it to "readOnly". This<br/>
will restrict user modification of the field but allow Script modification. <br/>
When this form is submitted I would expect JSF to process the date entered using<br/>
the date picker JS just like it would a non "readonly" input element.</p>
<p>The big difference between disabled and readonly is disabled elements are not<br/>
submitted with the form.</p>
<p>I would expect JSF to process 'readOnly" elements but not "disabled" elements.</p>
<p>Mike</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-353Only halt component processing on disabled not readOnlyBugMajorOpenUnresolvedUnassignedyoungmTue, 8 Apr 2008 11:01:47 +0000Fri, 1 Aug 2014 14:45:17 +00001.2Components/Renderers13<p>Updated target milestone.</p><p>Status Whiteboard</p><p>effort_moderate</p><p>change target_milestone to 2.0</p><p>Push to 2.1</p><p>Prepare to delete "spec" subcomponent.</p><p>Move these to unscheduled because we need to target them correctly. 2.next isn't <br/>
specific enough.</p><p>Changed subcomponent to Components/Renderers.</p><p>cat2</p><p>These are targeted at 2.1.</p><p>triage</p><p>rogerk</p><p>target</p><p>re-target</p><p>For now re-target for 2.2.<br/>
If time permits may revisit for 2.1.</p><p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting to Major</p>Issuezilla Id353.0Rank0|i002fz:Rank (Obsolete)397Status Whiteboard<p>EGTop5 effort_moderate cat2 size_medium importance_large draft</p>[JAVASERVERFACES_SPEC_PUBLIC-322] Add interfaces to javax.faces.component packagehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-322
javaserverfaces-spec-public<p>There are currently nice interfaces, like ValueHolder and EditableValueHolder.<br/>
But this isn't enough.</p>
<p>The minimal contract of creating a (custom) JSF component is UIComponent.<br/>
It is not necessary to extend something like UIComponentBase or even UIInput,<br/>
which is good.</p>
<p>For instance for checking if a component is able to be validated, some do a<br/>
instanceof UIInput, which would fail in some cases (as in Trinidad). Luckily<br/>
enough, we have the EditableValueHolder interfaces, so checking against that is<br/>
fine.</p>
<p>I noticed a lot of issues in the past with UIForm, since there is not "Form"<br/>
interface for that. One of the issues, when making Tomahawk working with<br/>
Trinidad/ADF Faces was that the Trinidad/ADF Faces form isn't extending UIForm<br/>
(which isn't wrong). We ended up, using a String-based identifier (component<br/>
family) for ensuring the component (from Trinidad) is a form. With an interface<br/>
for Form (like for EditableValueHolder) there weren't a need for "checking Strings".</p>
<p>This is true for "table components" as well. A "table interface" would be nice.</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-322Add interfaces to javax.faces.component packageSub-taskJAVASERVERFACES_SPEC_PUBLIC-935MajorOpenUnresolvedUnassignedmwessendorfWed, 21 Nov 2007 01:37:40 +0000Mon, 4 Aug 2014 16:26:08 +00002.0Components/Renderers82<p>On an interface for "Form", I can think about things like:<br/>
-autoComplete<br/>
-usesUpload (bool, when TRUE =&gt; set enctype="multipart/form-data")<br/>
(and/or enctype)<br/>
-prependId<br/>
-defaultCommand (executed when hitting ENTER inside the form)</p>
<p>On an interfaces for Tables (call it structuredData or so, since it could be<br/>
implemented in a custom Tree, for instance) I can think of these:<br/>
-var ?<br/>
See Trinidad's UIXCollection CLASS, which is the base for all structured Data<br/>
(in Trinidad):<br/>
<a href="http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/component/UIXCollection.html" class="external-link" rel="nofollow">http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/component/UIXCollection.html</a></p>
<p>Again such a "generic" interfaces could be useful when creating tree's (instead<br/>
of extending UIData (like Tomahawk or the Hans Bergsten book).</p>
<p>But... it is really important to have STRONG types, instead of messing around<br/>
with Strings (component family)</p><p>Add status whiteboard: EGTop5</p><p>effort_moderate</p><p>change target_milestone to 2.0</p><p>As discussed at JSFOne, I think we need a behavioral interface for components that manage collections of <br/>
children, such as trees, tables, and such.</p><ul>
<li>
<ul>
<li>
<ul>
<li>Issue 189 has been marked as a duplicate of this issue. ***</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>It'd make sense to expose a isPostBack() method (which I think is on<br/>
FacesContext in 2.0) through the Form interface, as well.</p><ul>
<li>
<ul>
<li>
<ul>
<li>Issue 245 has been marked as a duplicate of this issue. ***</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>We just didn't get to this one. Sorry Matzew.</p><p>Prepare to delete "spec" subcomponent.</p><p>Move these to unscheduled because we need to target them correctly. 2.next isn't <br/>
specific enough.</p><p>I really don't think this is a P1 also.</p><p>Matthias, aren't your example form properties more renderer-specific?</p><p>cat2</p><p>javadoc</p><p>components</p><p>These are targeted at 2.1.</p><p>triage</p><p>rogerk</p><p>triage</p><p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Target for 2.3</p>DependencyJAVASERVERFACES_SPEC_PUBLIC-236Issuezilla Id322.0Rank0|i00427:Rank (Obsolete)659Status Whiteboard<p>EGTop5 effort_moderate cat2 javadoc size_medium importance_medium draft</p>[JAVASERVERFACES_SPEC_PUBLIC-307] Ajax Push (Reverse/Comet)https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-307
javaserverfaces-spec-public<p>The specification must define the APIs/SPIs for pushing server side state<br/>
changes to the client (a.ka. comet, reverse ajax,...).<br/>
-------------------------------<br/>
Norbert Truchsess wrote:<br/>
&gt; For real asynchronous comet-style communication there is an api to<br/>
&gt; access the component-tree asynchronously on the server not in response<br/>
&gt; to an HttpRequest (e.g. from a message-driven bean). Any change to the<br/>
&gt; tree- and component state would be send to the client with the next<br/>
&gt; response. In case of client-site statesaving the 'non httprequest based'<br/>
&gt; call would be queued until the next HttpRequest comes in, then the state<br/>
&gt; would be restored, the queued 'non-httprequests' would be processed in<br/>
&gt; the same order they arrived and after that the regular processing of the<br/>
&gt; HttpRequest would continue. In case of client-side statesaving where a<br/>
&gt; communication-channel to the client is allready open (e.g. by means of a<br/>
&gt; 'delayed' request that does not nessesarely contain the state) the<br/>
&gt; delayed request would be released first, if it contains the state<br/>
&gt; processing could continue as in the 'serverside statesaving' case. If no<br/>
&gt; state is included in the request there would be an immediate response to<br/>
&gt; the client containing a message that forces the client to send the state<br/>
&gt; in a new request and processing may continue as described before.<br/>
-------------------------------<br/>
Roger Kitain wrote:<br/>
Sounds interesting. But how does this tie in with the inclusion of "Comet" in<br/>
the Servlet specification (JSR 315)? Does that simplify what you describe here?<br/>
-------------------------------<br/>
Norbert Truchsess wrote:<br/>
&gt; The JSR 315 proposal talkes about non-blocking<br/>
&gt; input/output, delayed request-handling, delayed response-close and<br/>
&gt; Blocking/nonblocking notification (channel concept with the ability to<br/>
&gt; subscribe to and get asynchronous events from that channel). The first 3<br/>
&gt; items are just nessesary to do the client/server-part of the<br/>
&gt; communication. If the last item (blocking/nonblocking notification) is<br/>
&gt; describing a server-side feature (it sounds like the description of an<br/>
&gt; existing feature in Grizzly), then it might/will help a lot to implement<br/>
&gt; what I described above. <br/>
-------------------------------<br/>
Ted Goddard wrote:<br/>
&gt; The approach taken by ICEfaces is essentially to allow the<br/>
&gt; application to retain a reference to the FacesContext outside<br/>
&gt; of the servlet request/response (we call it a PersistentFacesState).<br/>
&gt; Then, the application can invoke render() on the associated<br/>
&gt; component tree at any time, causing any page updates to be pushed<br/>
&gt; to the client. Only one simultaneous render of the component tree<br/>
&gt; is allowed, so client-initiated updates and server-initiated updates<br/>
&gt; are applied coherently.<br/>
&gt;<br/>
&gt; We did not support client-side state saving with Ajax Push because<br/>
&gt; a server-initiated update is only meaningful when the server has<br/>
&gt; full knowledge of what it is updating ... but perhaps there is<br/>
&gt; a use case where it can be applied.<br/>
-------------------------------<br/>
Norbert Truchsess wrote:<br/>
&gt; Shure there's no gain in doing<br/>
&gt; server-initiated updates without having access to the state on the<br/>
&gt; serverside. But 'having' to retain the complete state on server (as it's<br/>
&gt; done by ICEFaces results in quite limited scalability due to memory<br/>
&gt; consumption. It would be beneficial to mark which parts of the<br/>
&gt; component-tree-state are required during a server-initiated update so<br/>
&gt; either only this part would be stored on the server or only this part<br/>
&gt; would have to be 'requested' from the client before a server-initiated<br/>
&gt; update could take place. </p>
<p>&gt; My opinion here: let's target best of breed support for ajax in the<br/>
&gt; framework itself. And that is support for 'real' comet-style push<br/>
&gt; updates that can be used without any vendor-extensions 'out of the box'.<br/>
&gt; We all know that the jcp is turning much slower than the techniques<br/>
&gt; being used in the real world are evolving. At the time JSF 2.0 will be<br/>
&gt; ready to ship the ajax-techniques being used out there world will be way<br/>
&gt; more advanced then they are now and I bet support for<br/>
&gt; comet-communication will be commodity in most 'non java based'<br/>
&gt; web-application frameworks. If we don't have support for this 'build<br/>
&gt; into the bases', jsf 2.0 will not be as attractive as it could be.<br/>
&gt;<br/>
&gt; Shure, not everyone needs it. Most enterprise-applications will do<br/>
&gt; without it. So it should be optional to use - best would be to be able<br/>
&gt; to switch in on/off at runtime for precisely that single page that e.g.<br/>
&gt; contains a 'chat-component'. But wouldn't it be <em>really</em> cool, if you<br/>
&gt; could use a chat-component by just placing it on the page and set<br/>
&gt; 'communicationStyle="comet" in the view-tag? I'm more than convinced<br/>
&gt; that <em>this</em> feature would rise the recognition of JSF as a modern<br/>
&gt; technologie way more than most other things on our roadmap will do.<br/>
&gt;<br/>
&gt; This particular issue should <em>not</em> be priorized low just because a lack<br/>
&gt; of resources in this EG. I hereby volunteer to write this chapter, the<br/>
&gt; code and the tck even single-handet if no one else is willing to do <img class="emoticon" src="https://java.net/jira/images/icons/emoticons/wink.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> <br/>
-------------------------------<br/>
Ted Goddard wrote:<br/>
&gt; Ajax Push (also known as "comet", although that tends to<br/>
&gt; refer to the Dojo implementation) is the main distinguishing<br/>
&gt; feature of ICEfaces. ICEfaces is open source, so there is<br/>
&gt; no barrier in principle to incorporating any desired<br/>
&gt; parts of it into JSF 2.0.<br/>
&gt;<br/>
&gt; In terms of the technology, should it be part of JSF 2.0?<br/>
&gt; - the server infrastructure really requires changes to the<br/>
&gt; Servlet API (although asynchronous I/O is a goal of JSR-315) <br/>
-------------------------------<br/>
Norbert Truchsess wrote:<br/>
&gt; I did invest quite some time to dig through ICEFaces<br/>
&gt; implementation details, and from an architectural point of view I like<br/>
&gt; it a lot. So if there would be no memory-contrains in reall-world<br/>
&gt; scenarios I'd love to just take and transfer it into JSF 2.0. And in the<br/>
&gt; reall world developers will not want to be constrained in using<br/>
&gt; client-side widgets that do dom-manipulations on the client. (which also<br/>
&gt; would be in conflict with our first assumtion 'Ajax.A01') <br/>
-------------------------------<br/>
Ted Goddard wrote:<br/>
&gt; It's the JavaScript aspect that makes me hesitant to advocate<br/>
&gt; Ajax Push for JSF 2.0 (since the Servlet changes are on the<br/>
&gt; horizon), but I could certainly be persuaded otherwise. <br/>
-------------------------------<br/>
Roger Kitain wrote:<br/>
If would like to focus more on what's required on the server to facilitate this<br/>
feature, and ** not ** standardize lots of javascript (if that's possible).<br/>
-------------------------------<br/>
Norbert Truchsess wrote:<br/>
&gt; 100% agree - Not<br/>
&gt; that I think we could go without JS on the client here, but the the<br/>
&gt; server-side requirenments are the prerequisite that has to be done first.</p><p>Operating System: All<br/>
Platform: Macintosh</p>JAVASERVERFACES_SPEC_PUBLIC-307Ajax Push (Reverse/Comet)BugMajorOpenUnresolvedUnassignedrogerkTue, 18 Sep 2007 13:19:57 +0000Fri, 1 Aug 2014 14:41:08 +00002.0Ajax/JavaScript53<p>Set target milestone 2.0</p><p>Push to 2.1</p><p>Prepare to delete "spec" subcomponent.</p><p>Move these to unscheduled because we need to target them correctly. 2.next isn't <br/>
specific enough.</p><p>Target 2.1</p><p>status</p><p>frame</p><p>ajax</p><p>These are targeted at 2.1.</p><p>triage</p><p>triage</p><p>triage</p><p>Now that WebSockets have been standardized in Java EE 7 (JSR 356), it might be the right time to reconsider standardizing push for JSF.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>DependencyJAVASERVERFACES_SPEC_PUBLIC-293Issuezilla Id307.0Rank0|i002ef:Rank (Obsolete)390Status Whiteboard<p>cat2 frame size_large importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-205] Custom by-class converters not considered in UISelect{One,Many}.validateValue()https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-205
javaserverfaces-spec-public<p>al80 on ##jsf on freenode found this one, and it appears to be a good candidate<br/>
for the upcoming MR.</p>
<p>Look at the javadocs for UISelect</p>
{One,Many}
<p>.validateValue():</p>
<ul>
<li>Before comparing each option, coerce the</li>
<li>option value type to the type of this component's value following</li>
<li>the Expression Language coercion rules.</li>
</ul>
<p>If you have a custom converter installed as a by-type converter, then it will<br/>
have been used to convert the value before calling into validateValue(). <br/>
However, when the EL coercion rules are used, this by-type converter is not<br/>
consulted.</p><p>Operating System: All<br/>
Platform: Macintosh</p>JAVASERVERFACES_SPEC_PUBLIC-205Custom by-class converters not considered in UISelect{One,Many}.validateValue()BugMajorOpenUnresolvedUnassignedEd BurnsThu, 10 Aug 2006 11:36:55 +0000Fri, 1 Aug 2014 14:27:05 +00001.1Validation/Conversion13<p>Created an attachment (id=101)<br/>
al80's test war</p><p>Created an attachment (id=102)<br/>
java sources for war</p><p>Add jan to CC.</p><p>EL Spec section 1.18.7 has this to say about custom coercion.</p>
<p>Coerce <br/>
AtoAnyOtherTypeT <br/>
â– IfAisnull, returnnull <br/>
â– IfAisassignabletoT, coercequietly <br/>
â– IfAisaString, andThasnoPropertyEditor: <br/>
â– IfAis"", returnnull <br/>
â– Otherwiseerror <br/>
â– IfAisaStringandT'sPropertyEditorthrowsanexception: <br/>
â– IfAis"", returnnull <br/>
â– Otherwise, error <br/>
â– Otherwise, applyT'sPropertyEditor <br/>
â– Otherwise, error </p><p>Created an attachment (id=103)<br/>
fix for this bug, first iteration</p><p>Created an attachment (id=104)<br/>
tarball of modified and new files for first iteration bugfix.</p><p>Attachment 103 is a JSF Impl based fix for this issue, but I do think something<br/>
should be done at the spec level. There is no sense in requiring someone to<br/>
write a converter twice: once as a JSF Converter and once as a PropertyEditor.</p><p>After thinking about this some more, I have to wonder, why don't we just use<br/>
UIInput.getConvertedValue() rather than the EL's coerceToType() in the<br/>
UISelect</p>
{One,Many}
<p>.matchValue() implementation?</p>
<p>take ownership</p><p>Let's defer this to 2.0. At least we have a by-type solution in the Sun Impl.</p><p>57 is an umbrella issue for this one.</p><p>Move to unscheduled target milestone</p><p>Prepare to delete "spec" subcomponent.</p><p>cat2</p><p>javadoc</p><p>These are targeted at 2.1.</p><p>triage</p><p>GlassFish 3.1 M6 at the latest.</p><p>Move these to M5</p><p>Move these to 2.2</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Set priority to Major</p>DependencyJAVASERVERFACES_SPEC_PUBLIC-57Issuezilla Id205.0Rank0|i0022n:Rank (Obsolete)337Status Whiteboard<p>cat2 frame javadoc size_small importance_large</p>[JAVASERVERFACES_SPEC_PUBLIC-201] Locale handling in f:convertDateTime and f:convertNumberhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-201
javaserverfaces-spec-public<p>The handling of the "locale" attribute in the JSF core taglib tags <br/>
&lt;f:convertDateTime&gt; and &lt;f:convertNumber&gt; is inconsistent with each other and <br/>
with the handling of the "locale" attribute in the &lt;f:view&gt; view-root tag.</p>
<p>For &lt;f:convertDateTime&gt;, the description mandates that the implementation must <br/>
pass any string value as the first arg to the two-arg Locale constructor, and <br/>
pass the empty string as the second arg.</p>
<p>For &lt;f:convertNumber&gt;, the tld docs imply that string values are not supported <br/>
at all, but the sun javaserverfaces api implementation does allow literal <br/>
strings that are treated the same way as for &lt;f:convertDateTime&gt;.</p>
<p>In both cases, it would be more useful and consistent if String values were <br/>
treated as references to locale "names" using the same syntax as for the <br/>
&lt;f:view&gt; locale attribute (ie, allow language-country-variant type strings).</p>
<p>Placing support for a standard "locale" attribute in the &lt;f:converter&gt; tag may <br/>
be a good way to provide consistent behaviour for both &lt;f:convertDateTime&gt;, <br/>
&lt;f:convertNumber&gt;, and any user supplied custom converters.</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-201Locale handling in f:convertDateTime and f:convertNumberBugMajorOpenUnresolvedUnassignedtony_robertsonSun, 6 Aug 2006 16:19:04 +0000Fri, 1 Aug 2014 14:25:50 +00002.2 Sprint 8Validation/Conversion02<p>Status Whiteboard</p><p>take ownership</p><p>target 2.0</p><p>We didn't get to this one. Sorry.</p><p>Prepare to delete api subcomponent</p><p>Move these to unscheduled because we need to target them correctly. 2.next isn't <br/>
specific enough.</p><p>cat2</p><p>frame</p><p>These are targeted at 2.1.</p><p>triage</p><p>Change target milestone.</p><p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major because it involves multiple tags</p>Issuezilla Id201.0Rank0|i002br:Rank (Obsolete)378Status Whiteboard<p>EGEasy5 cat2 frame size_small importance_medium</p>[JAVASERVERFACES_SPEC_PUBLIC-1285] f:selectItems ignore itemDescription within h:selectOneListbox and related componentshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1285
javaserverfaces-spec-public<p>Facelets tag lib documentation shows the following properties as valid for f:selectItems:</p>
<p>itemValue<br/>
itemLabel<br/>
itemDescription<br/>
itemDisabled<br/>
itemLabelEscaped<br/>
...</p>
<p>But in both Mojarra and MyFaces the attribute itemDescription, itemDisabled, itemLabel are ignored.</p>
<p>But taking a look at the renderkit spec javadoc of javax.faces.SelectMany/javax.faces.Listbox in the section "Rendering the "option" elements" it says this:</p>
<p>"... If the current child is a UISelectItem create a SelectIteminstance from its itemValue, itemLabel, itemEscaped, and itemDescription properties, add it to the list. If the current child is a UISelectItems instance, call its getValue() method. If the result is a SelectItem bean, add it to the list. If the result is an array of SelectItem beans, add each one to the list. If the result is a Collection of SelectItem beans, add each one to the list. If the result is a Map, create a SelectItem bean for each entry in the Map using the key as the label, the value as the value, and null as the description. ..."</p>
<p>So, these properties are supposed to be used with f:selectItem, not with f:selectItems. But the user perceive this as a bug, which is something logic. See:</p>
<p><a href="https://issues.apache.org/jira/browse/MYFACES-3901" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MYFACES-3901</a></p>
<p>In JSF 2.2 with HTML5 friendly markup, it is supposed that f:selectItems can have passthrough attributes. See:</p>
<p><a href="https://issues.apache.org/jira/browse/MYFACES-3879" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MYFACES-3879</a></p>
<p>But in MyFaces we found that it doesn't work for h:selectOneRadio or h:selectManyCheckbox. </p>
<p>The thing is the fix for this issue is pretty similar for the one that needs to be done for HTML5 friendly markup.</p>JAVASERVERFACES_SPEC_PUBLIC-1285f:selectItems ignore itemDescription within h:selectOneListbox and related componentsBugMajorOpenUnresolvedUnassignedlu4242Thu, 19 Jun 2014 20:08:18 +0000Fri, 1 Aug 2014 20:14:03 +00002.02.12.2Components/Renderers02<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i0066v:Rank (Obsolete)1004[JAVASERVERFACES_SPEC_PUBLIC-1296] Clarify when it is valid to instantiate and use a PartialResponseWriterhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1296
javaserverfaces-spec-public<p>The spec makes an implicit assumption about when it is valid to instantiate a PartialViewContext(). This assumption is: the current execution context must have FacesServlet.service() above on the callstack, which implies the existence of a FacesContext.</p>JAVASERVERFACES_SPEC_PUBLIC-1296Clarify when it is valid to instantiate and use a PartialResponseWriterBugMajorOpenUnresolvedUnassignedEd BurnsWed, 30 Jul 2014 17:53:43 +0000Wed, 13 Aug 2014 20:30:31 +000001<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>RelatedJAVASERVERFACES-3358Rank0|i0d7jj:Rank (Obsolete)77039[JAVASERVERFACES_SPEC_PUBLIC-1295] Add default implementation for UIComponent#getFamily()https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1295
javaserverfaces-spec-public<p>Custom components inheriting from <tt>UIComponentBase</tt> are currently required to provide an implementation for <tt>UIComponent#getFamily()</tt> as it's an abstract method.</p>
<p>This is a small nuisance for simple custom components (e.g. ones used internally by some application), which rarely have any need for distinguishing components based on family.</p>
<p>Typically those components just return the empty string or null (<a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1267" title="Clarify meaning of null return from UIComponent.getFamily()" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1267"><del>JAVASERVERFACES_SPEC_PUBLIC-1267</del></a>) or some nonsense string like "whatshouldido.with.this".</p>
<p>If developers are not providing any meaningful return value for this method, I guess JSF might just as well provide a default implementation in <tt>UIComponentBase</tt> (e.g. a method just returning null), thereby making custom components yet again a tiny bit easier to create.</p>JAVASERVERFACES_SPEC_PUBLIC-1295Add default implementation for UIComponent#getFamily()ImprovementMajorOpenUnresolvedUnassignedarjan tijmsSun, 20 Jul 2014 13:56:16 +0000Fri, 1 Aug 2014 20:11:23 +0000Components/Renderers13<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i0bpm7:Rank (Obsolete)68303Tagsease-of-useease_of_development[JAVASERVERFACES_SPEC_PUBLIC-1291] RFE: Ability for h:messages to display a single custom message whenever the component has received any faces message.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1291
javaserverfaces-spec-public<p>In OmniFaces you can use h:messages to display a single message at the top of the screen such as "There are validation errors. Please fix them.", and then display component specific messages beside the components. They have added a "for" attribute to h:messages that points to the form component, and a "message" for the message to display. I will attach a screenshot.</p>
<p><a href="http://showcase.omnifaces.org/components/messages" class="external-link" rel="nofollow">http://showcase.omnifaces.org/components/messages</a></p>
<p>I've had customers ask me to do this very thing in our production applications.</p>JAVASERVERFACES_SPEC_PUBLIC-1291RFE: Ability for h:messages to display a single custom message whenever the component has received any faces message.ImprovementMajorOpenUnresolvedUnassignedrdelaplanteFri, 11 Jul 2014 03:45:52 +0000Fri, 1 Aug 2014 20:12:26 +0000Components/Renderers03<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i09t6n:Rank (Obsolete)57217[JAVASERVERFACES_SPEC_PUBLIC-1290] RFE: Add a var attribute to h:messages that enables the developer to fully control output stylinghttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1290
javaserverfaces-spec-public<p>Please see the OmniFaces messages component:</p>
<p><a href="http://showcase.omnifaces.org/components/messages" class="external-link" rel="nofollow">http://showcase.omnifaces.org/components/messages</a></p>
<p>"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."</p>
<p>&lt;o:messages var="message"&gt;<br/>
&lt;li class="#</p>
{fn:toLowerCase(message.severity)}
<p>"&gt;#</p>
{message.summary}
<p>&lt;/li&gt;<br/>
&lt;/o:messages&gt;</p>JAVASERVERFACES_SPEC_PUBLIC-1290RFE: Add a var attribute to h:messages that enables the developer to fully control output stylingImprovementMajorOpenUnresolvedUnassignedrdelaplanteFri, 11 Jul 2014 03:37:58 +0000Wed, 13 Aug 2014 20:29:53 +0000Components/Renderers12<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i09t0v:Rank (Obsolete)57191[JAVASERVERFACES_SPEC_PUBLIC-1289] RFE: When the required attribute of a checkbox is set to true, a validation error should occur when the form is submitted and the checkbox is not checkedhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1289
javaserverfaces-spec-public<p>See the RequiredCheckboxValidator in OmniFaces for a discussion of the issue:</p>
<p><a href="http://showcase.omnifaces.org/validators/RequiredCheckboxValidator" class="external-link" rel="nofollow">http://showcase.omnifaces.org/validators/RequiredCheckboxValidator</a></p>
<p>The default behavior in JSF is non-intuitive and causes seemingly unnecessary work to be required in the action method.</p>JAVASERVERFACES_SPEC_PUBLIC-1289RFE: When the required attribute of a checkbox is set to true, a validation error should occur when the form is submitted and the checkbox is not checkedImprovementMajorOpenUnresolvedUnassignedrdelaplanteFri, 11 Jul 2014 03:24:06 +0000Fri, 1 Aug 2014 20:12:53 +0000Components/Renderers13<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i09swn:Rank (Obsolete)57172[JAVASERVERFACES_SPEC_PUBLIC-1288] Clarify that default locale is implicitly a supported localehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1288
javaserverfaces-spec-public<p>Section "2.5.2.1 Determining the active Locale"</p>
<p>gives an example of locale configuration:</p>
<blockquote>
<p>This application’s default locale is en, but it also supports de, fr, and es locales. These elements cause the Application instance to be populated with Locale data. Please see the javadocs for details.</p></blockquote>
<p>This seems to imply that the default locale is implicitly a supported locale. I think we should state this explicitly.</p>JAVASERVERFACES_SPEC_PUBLIC-1288Clarify that default locale is implicitly a supported localeImprovementMajorOpenUnresolvedUnassignedEd BurnsThu, 10 Jul 2014 17:07:56 +0000Wed, 13 Aug 2014 20:29:39 +000001<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i09nlb:Rank (Obsolete)56311[JAVASERVERFACES_SPEC_PUBLIC-1299] jsf.ajax.response should not send 'success' events in case of an errorhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1299
javaserverfaces-spec-public<p>This is a followup of <a href="https://java.net/jira/browse/JAVASERVERFACES-3103" title="jsf.ajax.response sends success events in case of an error" class="issue-link" data-issue-key="JAVASERVERFACES-3103"><del>JAVASERVERFACES-3103</del></a>.</p>
<p>If the ajax response contains an error the clientside JS (jsf.ajax.response) sends an "serverError" event to the registered listeners AND just after this an "success" event to registered listeners. This leads to malfunctions if the application depends on both of these events. The "success" event is unexpected in the server side error (e.g. Exception in the triggered ajax listener) case here.</p>
<p>jsf.js<br/>
line 2255: sendError(request, context, "serverError", null, errorName, errorMessage);<br/>
line 2256: sendEvent(request, context, "success");</p>
<p>At the moment this behavior is by design but it does not make sense:<br/>
Two concerns are mixed up here: processing the response on the client side and processing the request on the server side.</p>
<p>The response is indeed successfully processed on the client side. But the client side does not need to be notified by this explicitly in that case. The processed result is already available in the onerror event handler.<br/>
There is no more information available in the "success" event and this behaviour makes it complicated to handle server side errors on the client.</p>
<p>For the enduser the result of a failed processed request or a successfully proccessed server side error is the same: there is an error not a successfully performed action.</p>
<p>So how can one dedect a "success" event in a server error case at the moment:</p>
<ul class="alternate" type="square">
<li>explicitly analyse the data transmitted</li>
<li>remember there was already an error event before</li>
</ul>
<p>Both options are not necessary if the spec would not require to send the "success" event in a server error case.</p>
<p>Manfred Riem agrees with me.</p>JAVASERVERFACES_SPEC_PUBLIC-1299jsf.ajax.response should not send 'success' events in case of an errorBugMajorOpenUnresolvedUnassignedMathias WerlitzThu, 14 Aug 2014 09:44:07 +0000Thu, 14 Aug 2014 09:44:07 +00002.2Ajax/JavaScript01Rank0|i0e78n:Rank (Obsolete)82822[JAVASERVERFACES_SPEC_PUBLIC-1281] Extend vdl.createComponent with support of ui:includes and user tagshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1281
javaserverfaces-spec-public<p>Myfaces implementation extends their vdl.createComponent with support of ui:include and custom or composite tags. This great solution completely replace a set of strange workarounds from network or OpenFaces.</p>
<p>Mojarra in vdl.createComponent and DefaultFaceletFactory._createComponent supports only standard UIComponents and tags from api. There is no reason to support only tags from api.<br/>
Problem was registered as <a href="https://java.net/jira/browse/JAVASERVERFACES-3281" class="external-link" rel="nofollow">https://java.net/jira/browse/JAVASERVERFACES-3281</a> but unfortunately closed.</p>
<p>Test examples<br/>
-mojarra-2.2.6\test\agnostic\component\programmaticComponentCreation\src\main\java\com\sun\faces\test\agnostic\component\programmaticComponentCreation\CreateComponentBean.java<br/>
-<a href="http://svn.apache.org/repos/asf/myfaces/core/trunkimplsrctestjavaorgapachemyfacesviewfaceletspool" class="external-link" rel="nofollow">http://svn.apache.org/repos/asf/myfaces/core/trunk\impl\src\test\java\org\apache\myfaces\view\facelets\pool\</a><br/>
-<a href="http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/test/java/org/apache/myfaces/view/facelets/pss/acid" class="external-link" rel="nofollow">http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/test/java/org/apache/myfaces/view/facelets/pss/acid</a></p>
JAVASERVERFACES_SPEC_PUBLIC-1281Extend vdl.createComponent with support of ui:includes and user tagsImprovementMajorOpenUnresolvedUnassignedkrokodylowy3Sat, 31 May 2014 09:13:51 +0000Thu, 21 Aug 2014 20:17:11 +00002.203<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p><p>This extension is also performance improvement. We no longer need use a set of permanent includes and tags for temporary visible popups and views which was a old headache of jsf framework. Code can be truly dynamic and well separated.</p>Rank0|i0065z:Rank (Obsolete)1000[JAVASERVERFACES_SPEC_PUBLIC-1271] Simplify overriding a component's rendererhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1271
javaserverfaces-spec-public<p>A component in JSF can be customized by overriding its renderer and creating a new tag for it, e.g as demonstrated here: <a href="https://weblogs.java.net/blog/mriem/archive/2013/11/07/jsf-tip-34-override-jsf-renderer-and-create-new-tag-it" class="external-link" rel="nofollow">https://weblogs.java.net/blog/mriem/archive/2013/11/07/jsf-tip-34-override-jsf-renderer-and-create-new-tag-it</a></p>
<p>This however requires a small but tedious amount of XML. As an analogy to the <tt>createTag</tt> attribute of <tt>FacesComponent</tt> a similar attribute on <tt>@FacesRenderer</tt> could simplify this task and provide a greater ease of use. E.g. the XML in the above referenced example could be replaced by the following:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">@FacesRenderer(forComponentType=<span class="code-quote">"javax.faces.HtmlOutputText"</span> tagName=<span class="code-quote">"myOutputText"</span>)
<span class="code-keyword">public</span> class MyTextRenderer <span class="code-keyword">extends</span> Renderer {
<span class="code-comment">// ...
</span>}
</pre>
</div></div>
<p>Overriding the render of a component and keeping its existing tag requires roughly the same amount of XML, but less straightforward. It requires the user to find out what the render-kit-id, component-family and renderer-type is of the component for which they want to override. This is demonstrated e.g. here: <a href="https://weblogs.java.net/blog/mriem/archive/2013/11/05/jsf-tip-32-override-jsf-renderer" class="external-link" rel="nofollow">https://weblogs.java.net/blog/mriem/archive/2013/11/05/jsf-tip-32-override-jsf-renderer</a></p>
<p>It would be great if this could be simplified to just this:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">@FacesRenderer(forComponentType=<span class="code-quote">"javax.faces.HtmlOutputText"</span>)
<span class="code-keyword">public</span> class MyTextRenderer <span class="code-keyword">extends</span> Renderer {
<span class="code-comment">// ...
</span>}
</pre>
</div></div>
<p>As a user often primarily knows a component by its namespace and tag name, it might be worthwhile to let the user alternatively reference the component via this kind of naming. E.g.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">@FacesRenderer(forComponentTag=<span class="code-quote">"http:<span class="code-comment">//java.sun.com/jsf/html:outputText"</span>)
</span><span class="code-keyword">public</span> class MyTextRenderer <span class="code-keyword">extends</span> Renderer {
<span class="code-comment">// ...
</span>}
</pre>
</div></div>
JAVASERVERFACES_SPEC_PUBLIC-1271Simplify overriding a component's rendererNew FeatureMajorOpenUnresolvedUnassignedarjan tijmsThu, 27 Mar 2014 23:01:13 +0000Fri, 1 Aug 2014 20:17:49 +0000Components/Renderers13<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i00647:Rank (Obsolete)992[JAVASERVERFACES_SPEC_PUBLIC-1276] FacesEvent not serializable with PhaseIdhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1276
javaserverfaces-spec-public<p>FacesEvent (and its derivative objects) are marked as serializable, yet they are not if a phaseId is provided. The following test class:</p>
<p>public class Test<br/>
{<br/>
public static void main(String[] argv)<br/>
{<br/>
ActionEvent event = new ActionEvent(new UIOutput());<br/>
event.setPhaseId(PhaseId.APPLY_REQUEST_VALUES);</p>
<p> ByteArrayOutputStream out = new ByteArrayOutputStream();<br/>
ObjectOutputStream oout;<br/>
try</p>
{
oout = new ObjectOutputStream(out);
oout.writeObject(event);
}
<p> catch (IOException e)</p>
{
e.printStackTrace();
}
<p> }<br/>
}</p>
<p>Yields the following error:</p>
<p>java.io.NotSerializableException: javax.faces.event.PhaseId<br/>
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1165)<br/>
at<br/>
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1535)<br/>
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)<br/>
at<br/>
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1413)<br/>
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1159)<br/>
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:329)<br/>
at test.Test.main(Test.java:31)</p>
<p>This is because PhaseId is not serializable. Regardless of PhaseId's ability to be serialized, FacesEvent must honor the serializable contract and be able to be serializable.</p>JAVASERVERFACES_SPEC_PUBLIC-1276FacesEvent not serializable with PhaseIdBugMajorOpenUnresolvedUnassigneddarkarenaThu, 1 May 2014 18:19:36 +0000Wed, 13 Aug 2014 20:28:27 +00001.11.22.02.101<p>Unfortunately, because PhaseId is a javax.faces class, we cannot change its signature without revising the JSF specification. We will tackle this in 2.3. </p><p>I may be able to come up with a workaround to make this work in the meantime.</p><p>Would below change affect signature as well?<br/>
As workaround this would use the PhaseId ordinal as serialized value in FacesEvent:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
Index: jsf-api/src/main/java/javax/faces/event/FacesEvent.java
===================================================================
--- jsf-api/src/main/java/javax/faces/event/FacesEvent.java (revision 13233)
+++ jsf-api/src/main/java/javax/faces/event/FacesEvent.java (working copy)
@@ -86,7 +86,9 @@
}
- <span class="code-keyword">private</span> PhaseId phaseId = PhaseId.ANY_PHASE;
+ <span class="code-keyword">private</span> <span class="code-object">int</span> phaseOrdinal = PhaseId.ANY_PHASE.getOrdinal();
+
+ <span class="code-keyword">private</span> <span class="code-keyword">transient</span> PhaseId phaseId = PhaseId.VALUES.get(phaseOrdinal);
/**
* &lt;p&gt;Return the identifier of the request processing phase during
@@ -112,6 +114,7 @@
<span class="code-keyword">throw</span> <span class="code-keyword">new</span> IllegalArgumentException();
}
<span class="code-keyword">this</span>.phaseId = phaseId;
+ <span class="code-keyword">this</span>.phaseOrdinal = phaseId.getOrdinal();
}
</pre>
</div></div><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i00653:Rank (Obsolete)996[JAVASERVERFACES_SPEC_PUBLIC-1398] Cleanup for unused Flowshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1398
javaserverfaces-spec-public<p>One thing missing from the faces flow spec that exists with @ConversationScoped are access timeouts after which the current scope is invalidated and destroyed.</p>
<p>Consider the case where a flow is not exited through the flow return, but instead simply abandoned by the user (via the back button, bookmarks or after closing a window). In this case the flow scoped beans will stay in the session, until the session is destroyed. In a web application with flows that is used intensively by its users for a long time it's easily possible that 100s of flow instances stay in the session before they are cleaned up and thus wasting a lot of memory.</p>
<p>To solve this problem either </p>
<ul class="alternate" type="square">
<li>a timeout could be introduced - similar to Conversations. This timeout could be specified for all flow as a web context param or on a flow level in the flow definition.</li>
<li>or alternatively a maximum of client window instances per flow could be set globally (implemented like ViewMaps by a LRU Map).</li>
</ul>
JAVASERVERFACES_SPEC_PUBLIC-1398Cleanup for unused FlowsImprovementMajorOpenUnresolvedUnassignedfrederickkaempferSun, 16 Aug 2015 12:28:42 +0000Tue, 1 Sep 2015 04:23:21 +00002.22.3Flow02<p>Implemented in MyFaces. See: <a href="https://issues.apache.org/jira/browse/MYFACES-3938" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MYFACES-3938</a></p>Rank0|i0ha9z:Rank (Obsolete)100810[JAVASERVERFACES_SPEC_PUBLIC-1397] Provide documentation and tuning options for activeViewMapshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1397
javaserverfaces-spec-public<p>We are using JSF 2.2.12 with server side state saving and plenty of ViewScoped ManagedBeans. After investigating our load tests it turned out that the data in our ViewScoped Beans is kept in session memory for quite some time. We were debugging Mojarra and found that the ViewScopeManager holds all ViewScoped beans of the last 25 used views. Even when you set <em>numberOfLogicalViews</em> to 1, it will still keep the last 25.</p>
<p>Now there is also an undocumented parameter <em>com.sun.faces.application.view.activeViewMapsSize</em>. When tuning JSF applications it would be very interesting to know why 25 and which impact this parameter has in conjunction with <em>numberOfLogicalViews</em> and <em>numberOfViewsInSession</em>.</p>
<p>I created also a stackoverflow post about this: <a href="http://stackoverflow.com/questions/31959982/jsf-2-2-memory-consumption-why-does-mojarra-keep-the-viewscoped-beans-of-the-la" class="external-link" rel="nofollow">http://stackoverflow.com/questions/31959982/jsf-2-2-memory-consumption-why-does-mojarra-keep-the-viewscoped-beans-of-the-la</a></p>JAVASERVERFACES_SPEC_PUBLIC-1397Provide documentation and tuning options for activeViewMapsImprovementMajorOpenUnresolvedUnassignedfischermatteThu, 13 Aug 2015 20:04:32 +0000Thu, 13 Aug 2015 20:10:44 +00002.2Documentation: Javadoc, TLDDoc, RenderkitDoc, PDFManaged Beans01<p>sorry, this issue belongs to mojarra not to spec. unfortunately i am not allowed to delete or move this issue here. I created the same here for mojarra now: <a href="https://java.net/jira/browse/JAVASERVERFACES-4015" class="external-link" rel="nofollow">https://java.net/jira/browse/JAVASERVERFACES-4015</a></p>Rank0|i0ha33:Rank (Obsolete)100779[JAVASERVERFACES_SPEC_PUBLIC-1381] Specify forbidding of use of EL expressions in query paramshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1381
javaserverfaces-spec-public<p>The resolution of Mojarra issue <a href="https://java.net/jira/browse/JAVASERVERFACES-3832" title="Re-evaluation on EL expressions in JSF RI 2.2.5" class="issue-link" data-issue-key="JAVASERVERFACES-3832"><del>JAVASERVERFACES-3832</del></a> is to sanitize rhs of query params to not have EL expressions. If an EL expression is encountered, the whole rhs is replaced with the empty string and an INFO message is logged.</p>
<p>This needs to be included in the specification of 7.4.2 Default NavigationHandler Algorithm.</p>JAVASERVERFACES_SPEC_PUBLIC-1381Specify forbidding of use of EL expressions in query paramsBugMajorOpenUnresolvedUnassignedEd BurnsFri, 24 Jul 2015 18:13:08 +0000Fri, 24 Jul 2015 20:38:18 +0000Navigation02<p>Section 7.4.2 Default NavigationHandler algorithm must also be fixed to replace &lt;view-param&gt; within &lt;redirect&gt; with &lt;redirect-param&gt;.</p>
<p>Also, EL expressions as the &lt;value&gt; of a &lt;redirect-param&gt; should be permitted since these are safe because they can never come from user input, whereas query params can come from user input.</p>RelatedJAVASERVERFACES-3832JAVASERVERFACES-3997Rank0|i0h8r3:Rank (Obsolete)100563[JAVASERVERFACES_SPEC_PUBLIC-1407] Options for @ViewScoped to specify where associated state is savedhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1407
javaserverfaces-spec-public<p>The current implementation of <tt>@ViewScoped</tt> in JSF 2.2 is tied to the session scope, which is a server side storage.</p>
<p>I'd like to propose to have several options for <tt>@ViewScoped</tt> to specify where the state associated with it is saved.</p>
<p>The options can be as follows:</p>
<ul>
<li>Follow the state saving setting applicable for that view (<em>this is approximately the JSF 2.1 and earlier behavior</em>)</li>
<li>Always session (<em>this is the JSF 2.2 behavior</em>)</li>
<li>Always client (<em>new option</em>)</li>
</ul>
JAVASERVERFACES_SPEC_PUBLIC-1407Options for @ViewScoped to specify where associated state is savedNew FeatureMajorOpenUnresolvedEd Burnsarjan tijmsThu, 10 Sep 2015 14:31:58 +0000Thu, 10 Sep 2015 14:31:58 +000001Rank0|i0jfyf:Rank (Obsolete)9223372036854775807Tagsstatestate_savingstate_saving_method[JAVASERVERFACES_SPEC_PUBLIC-1406] Unify pseudo state save method "none" (stateless) with modes "server" and "client"https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1406
javaserverfaces-spec-public<p>In JSF the user can choose to save state on the server or the client via the <tt>javax.faces.STATE_SAVING_METHOD</tt> context parameter. This is a global setting that applies to all views (URLs) in the application.</p>
<p>At the same time there's effectively a "none" setting, which is what happens when a view root (e.g. via the <tt>f:view</tt> tag) is set to <tt>transient</tt>. This is also called "stateless".</p>
<p>I'd like to propose that in addition to the current mechanism used to set a single view to stateless, the range of values for <tt>javax.faces.STATE_SAVING_METHOD</tt> context parameter is extended with a "none" option. </p>
<p>The intended purpose of this option is to globally set all views in the application to stateless.</p>
JAVASERVERFACES_SPEC_PUBLIC-1406Unify pseudo state save method "none" (stateless) with modes "server" and "client"New FeatureMajorOpenUnresolvedEd Burnsarjan tijmsThu, 10 Sep 2015 14:21:20 +0000Thu, 10 Sep 2015 14:21:20 +000001Rank0|i0jfy7:Rank (Obsolete)9223372036854775807Tagsstatestate_savingstate_saving_methodstateless[JAVASERVERFACES_SPEC_PUBLIC-1405] Set state save method per patternhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1405
javaserverfaces-spec-public<p>In JSF the user can choose to save state on the server or the client via the <tt>javax.faces.STATE_SAVING_METHOD</tt> context parameter. This is a global setting that applies to all views (URLs) in the application.</p>
<p>I would like to propose to additionally make it possible to set this per URL pattern (using the pattern syntax as used by Servlet to map and/or protect URLs).</p>
<p>Setting the state saving method per URL pattern then overrides the global setting. If a given URL is not covered by the URL pattern, the global setting comes into effect.</p>JAVASERVERFACES_SPEC_PUBLIC-1405Set state save method per patternNew FeatureMajorOpenUnresolvedEd Burnsarjan tijmsThu, 10 Sep 2015 14:08:52 +0000Thu, 10 Sep 2015 14:08:52 +000001Rank0|i0jfxz:Rank (Obsolete)9223372036854775807Tagsstatestate_savingstate_saving_method[JAVASERVERFACES_SPEC_PUBLIC-1374] Disable client window through parameterhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1374
javaserverfaces-spec-public<p>When exiting a flow, I sometimes need to redirect the user to some page where the client window id is not relevant anymore. It would be nice if the jfwid parameter could be dropped by simply adding "disable-client-window=true" in the url.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
flowBuilder.returnNode(<span class="code-quote">"returnFromFlow"</span>).fromOutcome(<span class="code-quote">"/index.xhtml?faces-redirect=<span class="code-keyword">true</span>&amp;disable-client-window=<span class="code-keyword">true</span>"</span>);
</pre>
</div></div>JAVASERVERFACES_SPEC_PUBLIC-1374Disable client window through parameterImprovementMajorOpenUnresolvedUnassignedXavier DuryMon, 18 May 2015 07:52:56 +0000Mon, 18 May 2015 07:52:56 +0000Flow01Rank0|i0h0m7:Rank (Obsolete)99245[JAVASERVERFACES_SPEC_PUBLIC-1373] @FlowScoped should be allowed on method and annotationhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1373
javaserverfaces-spec-public<p>Currently, <tt>@FlowScoped</tt> annotation can only target types. This makes it impossible to create flowscoped beans through <tt>@Produces</tt> methods or use <tt>@FlowScoped</tt> on a <tt>@Stereotype</tt> annotation.</p>JAVASERVERFACES_SPEC_PUBLIC-1373@FlowScoped should be allowed on method and annotationImprovementMajorOpenUnresolvedUnassignedXavier DuryThu, 14 May 2015 14:13:48 +0000Thu, 14 May 2015 14:13:48 +00002.2Flow01Rank0|i0h067:Rank (Obsolete)99173[JAVASERVERFACES_SPEC_PUBLIC-1376] Missing StateHolder in Behaviour API for usage in dataTable and alikehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1376
javaserverfaces-spec-public<p>Recently I came across the fact that the Behaviour API is not using the StateHolder.</p>
<p>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.</p>
<p>As a consequence, the EL can't reference a var defined in the dataTable.</p>JAVASERVERFACES_SPEC_PUBLIC-1376Missing StateHolder in Behaviour API for usage in dataTable and alikeImprovementMajorOpenUnresolvedUnassignedrdebusscherFri, 22 May 2015 14:38:45 +0000Fri, 22 May 2015 14:38:45 +00002.3Components/Renderers02Rank0|i0h2gv:Rank (Obsolete)99545[JAVASERVERFACES_SPEC_PUBLIC-1375] Faces Flows CDI Bean Defining Annotations Clarificationhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1375
javaserverfaces-spec-public<p>The Faces Flow annotation @FlowScoped is clearly defined as a CDI scope. In the CDI spec, however, it's not defined as a "bean defining annotation" <a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations" class="external-link" rel="nofollow">http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_defining_annotations</a></p>
<p>The default bean discovery mode is "annotated", so it seems that with the default CDI configuration @FlowScope beans aren't discovered. The beans are discovered correctly with a bean-discovery-mode="all", which is set via beans.xml</p>
<p>Is it desirable to require this kind of explicit configuration, which can possibly lead to confusion?</p>JAVASERVERFACES_SPEC_PUBLIC-1375Faces Flows CDI Bean Defining Annotations ClarificationBugMajorOpenUnresolvedUnassignedwtlucyTue, 19 May 2015 20:35:39 +0000Thu, 2 Jul 2015 18:19:24 +00002.2Flow01<p>I've misunderstood the issue here. @FlowScoped is, in fact, a "bean defining annotation" as per the mentioned CDI spec: it falls under the "all other normal scope types" category. From the FlowScoped annotation documentation <a href="http://docs.oracle.com/javaee/7/api/javax/faces/flow/FlowScoped.html" class="external-link" rel="nofollow">http://docs.oracle.com/javaee/7/api/javax/faces/flow/FlowScoped.html</a> : </p>
<p> @NormalScope<br/>
@Inherited<br/>
@Documented<br/>
@Target(value=TYPE)<br/>
@Retention(value=RUNTIME)<br/>
public @interface FlowScoped</p>
<p>So, explicit configuration of the CDI bean-discovery-mode should not be required. </p>Rank0|i0h17z:Rank (Obsolete)99343[JAVASERVERFACES_SPEC_PUBLIC-1371] 11.4.3.3 (Packaging Flows in Directories) ambiguityhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1371
javaserverfaces-spec-public<p>SH&gt; The relevant spec is JSF 2.2 11.4.3.3 (Packaging Flows in Directories): there it says "The following conventions apply to<br/>
SH&gt; flows defined in this manner. Any flow definition in the<br/>
SH&gt; corresponding -flow.xml<br/>
SH&gt; file will override any of the conventions in the case of a conflict.<br/>
SH&gt; Every vdl file in that directory is a view node of that flow.<br/>
SH&gt; The start node of the flow is the view whose name is the same as the name of the flow.<br/>
SH&gt; ..."<br/>
SH&gt; (note the ambiguity - "Every vdl file in that directory" ... which directory?)</p>
<p>EB&gt; "that directory" is the directory containing the corresponding<br/>
EB&gt; -flow.xml file. For example, in the case of the following<br/>
EB&gt; convention match, "bounded-task-flow/bounded-task-flow-flow.xml",<br/>
EB&gt; "that directory" is "bounded-task-flow/".</p>JAVASERVERFACES_SPEC_PUBLIC-137111.4.3.3 (Packaging Flows in Directories) ambiguityBugMajorOpenUnresolvedUnassignedEd BurnsMon, 4 May 2015 18:17:31 +0000Wed, 2 Sep 2015 02:11:31 +00002.2Flow02<p>Ok, I looked at the built multipagewebinf WAR and see the following<br/>
files:</p>
<p>Archive: ./dist/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/jsf_flows_multipagewebinf_web.war<br/>
testing: META-INF/ OK<br/>
testing: META-INF/MANIFEST.MF OK<br/>
testing: WEB-INF/ OK<br/>
testing: WEB-INF/classes/ OK<br/>
testing: WEB-INF/classes/com/ OK<br/>
testing: WEB-INF/classes/com/sun/ OK<br/>
testing: WEB-INF/classes/com/sun/ts/ OK<br/>
testing: WEB-INF/classes/com/sun/ts/tests/ OK<br/>
testing: WEB-INF/classes/com/sun/ts/tests/jsf/ OK<br/>
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/ OK<br/>
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/ OK<br/>
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/ OK<br/>
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/beans/ OK<br/>
testing: WEB-INF/classes/com/sun/ts/tests/jsf/spec/flows/multipagewebinf/beans/FlowBean.class OK<br/>
testing: WEB-INF/bounded-task-flow/ OK<br/>
testing: WEB-INF/bounded-task-flow/bounded-task-flow-flow.xml OK<br/>
testing: WEB-INF/beans.xml OK<br/>
testing: bounded-task-flow/ OK<br/>
testing: bounded-task-flow/bounded-task-flow.xhtml OK<br/>
testing: bounded-task-flow/next_a.xhtml OK<br/>
testing: bounded-task-flow/next_b.xhtml OK<br/>
testing: index.xhtml OK<br/>
testing: nonFlow.xhtml OK<br/>
testing: return1.xhtml OK<br/>
testing: WEB-INF/web.xml OK</p>
<p>This is indeed strange that there is <b>both</b> a</p>
<p> testing: WEB-INF/bounded-task-flow/ OK</p>
<p><b>and</b> a</p>
<p> testing: bounded-task-flow/ OK</p>
<p>directory. The spec doesn't say what to do in that case, but it is<br/>
clear that in this specific case MyFaces is behaving correctly while<br/>
Mojarra is not. </p><p>Hi Ed,</p>
<p>Can you make this more clear to me? you mean the work flow can be defined both under webapp / directory and WEB-INF/ and that defined in the webapp / should take higher priority, right? what's the current behavior of Mojarra?</p>
<p>BR,<br/>
Zhijun</p>RelatedJAVASERVERFACES-3883Rank0|i0gyr3:Rank (Obsolete)98943[JAVASERVERFACES_SPEC_PUBLIC-1341] Default value for viewParamhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1341
javaserverfaces-spec-public<p>What about allowing the definition of a default value for a view-parameter?</p>
<p><b>Example</b></p>
<p>Defining number of displayed items (pagination feature) as a view-parameter but still keeping default value within xhtml and not java bean.</p>
<p>Following example is a very clean approach provinding a default value.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;f:viewParam name=<span class="code-quote">"pageSize"</span> value=<span class="code-quote">"#{bean.pageSize}"</span> <span class="code-keyword">default</span>=<span class="code-quote">"10"</span>/&gt;
&lt;p:dataTable rows=<span class="code-quote">"#{bean.pageSize}"</span>/&gt;
</pre>
</div></div>
<p>Currently there are two workarounds which have no clean separation between markup and java code:</p>
<p><b>Workaround 1</b></p>
<p>Passing the default value to bean.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xhtml">
<span class="code-tag">&lt;f:viewParam name=<span class="code-quote">"pageSize"</span> value=<span class="code-quote">"#{bean.pageSize}"</span>/&gt;</span>
<span class="code-tag">&lt;f:event type=<span class="code-quote">"preRenderView"</span> listener=<span class="code-quote">"#{bean.initPreRenderView(10)"</span>/&gt;</span>
<span class="code-tag">&lt;p:dataTable rows=<span class="code-quote">"#{bean.pageSize}"</span>/&gt;</span>
</pre>
</div></div>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">private</span> <span class="code-object">int</span> pageSize;
<span class="code-keyword">public</span> void initPreRenderView(<span class="code-object">int</span> pageSize)
{
<span class="code-keyword">if</span> (<span class="code-keyword">this</span>.pageSize == 0)
<span class="code-keyword">this</span>.pageSize == pageSize;
}
</pre>
</div></div>
<p><b>Workaround 2</b></p>
<p>Hardcoding the default value in bean. But markup should be responsible and not bean.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xhtml">
<span class="code-tag">&lt;f:viewParam name=<span class="code-quote">"pageSize"</span> value=<span class="code-quote">"#{bean.pageSize}"</span>/&gt;</span>
<span class="code-tag">&lt;p:dataTable rows=<span class="code-quote">"#{bean.pageSize}"</span>/&gt;</span>
</pre>
</div></div>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">private</span> <span class="code-object">int</span> pageSize = 10;
</pre>
</div></div>JAVASERVERFACES_SPEC_PUBLIC-1341Default value for viewParamImprovementMajorOpenUnresolvedUnassigneddjmjWed, 10 Dec 2014 02:02:04 +0000Fri, 19 Jun 2015 01:28:34 +0000Components/Renderers01<p>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.</p>
<p>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`</p>
<p>A `&lt;h:link&gt;` with `&lt;f:param name="pageSize" value="10"&gt;` can be ignored in the final URL.</p>Rank0|i0g6nj:Rank (Obsolete)94391[JAVASERVERFACES_SPEC_PUBLIC-1340] Allow ViewHandler to be injectablehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1340
javaserverfaces-spec-publicJAVASERVERFACES_SPEC_PUBLIC-1340Allow ViewHandler to be injectableBugMajorOpenUnresolvedUnassignedManfred RiemThu, 4 Dec 2014 19:20:17 +0000Wed, 26 Aug 2015 15:26:48 +000001Rank0|i0g5yv:Rank (Obsolete)94280[JAVASERVERFACES_SPEC_PUBLIC-1363] Add cols attribute to selectManyCheckboxhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1363
javaserverfaces-spec-public<p>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.</p>
<p>add attribute "cols" of type int to selectManyCheckBox. If omitted, assume a default of 1.</p>
<p>If layout="pagedirection" (vertical) than cols &gt; 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.</p>
<p>If layout="linedirection", than cols is ignored. Optionally, an attribute lines is used for this layout. Now n/lines cols will be created.</p>JAVASERVERFACES_SPEC_PUBLIC-1363Add cols attribute to selectManyCheckboxImprovementMajorOpenUnresolvedUnassignedmuellermiThu, 12 Feb 2015 21:14:21 +0000Thu, 12 Feb 2015 21:49:07 +00002.3Components/Renderers01<p>example:</p>
<p>layout="pagedirection"<br/>
[] item1<br/>
[] item2<br/>
[] item3<br/>
[] item4<br/>
[] item5</p>
<p>layout="pagedirection" cols="2"<br/>
[] item1 [] item2<br/>
[] item3 [] item4<br/>
[] item5</p>
<p>ayout="linedirection" lines="2"<br/>
[] item1 [] item2 [] item3<br/>
[] item4 [] item5</p>Rank0|i0giuf:Rank (Obsolete)96366[JAVASERVERFACES_SPEC_PUBLIC-1358] Enhance conversation handlinghttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1358
javaserverfaces-spec-public<p>During a process flow, using @ConversationScoped beans, sometime it is useful to start a new (second, third, ...) conversation. <br/>
Using the standard postback navigation, JSF always injects the same conversation instance. <br/>
One approach to force a fresh conversation is to use &lt;h:link ...&gt; instead of &lt;h:commandLink...&gt;<br/>
Since the outcome of link is computed whilst rendering the page, navigation is static.<br/>
commandLink on the other hand allows to compute the navigation on click.<br/>
I propose these enhancements:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;h:commandLink createConversation=<span class="code-quote">"true"</span> ...&gt;</span>
</pre>
</div></div>
<p>With this optional argument JSF does not inject the existing instance of a session but a fresh one.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;h:link output=<span class="code-quote">"#{...}"</span> lazyCalculation=<span class="code-quote">"true"</span> ...&gt;</span>
</pre>
</div></div>
<p>This renders a link without target &lt;a href="" onclick="#{bean.navigationFunction}"&gt;...&lt;/a&gt; and an onclick handler.<br/>
The handler's duty is to perform a partial request, retrieve the result of bean.navigationFunction (return value is String) and then perform a get navigation, e.g. by window.location.href = navOutcome;</p>JAVASERVERFACES_SPEC_PUBLIC-1358Enhance conversation handlingImprovementMajorOpenUnresolvedUnassignedmuellermiMon, 2 Feb 2015 22:17:41 +0000Tue, 3 Feb 2015 13:10:10 +00002.3Navigation01Rank0|i0ggov:Rank (Obsolete)96017[JAVASERVERFACES_SPEC_PUBLIC-1354] Allow specify node-on-return in flow call nodehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1354
javaserverfaces-spec-public<p>Nested flow has to know where to go (name of node in calling flow) when returning back to calling flow.<br/>
To encapsulate nested flow we should allow to specify node where to go after return from nested flow in the flow-call-node.</p>
<p>Conversation from another Jira issue:<br/>
Ed&gt;You mean you'd like the "where to go after return" to be specified in<br/>
Ed&gt;the flow-call node? That's not a bad idea. I can see adding that,<br/>
Ed&gt;making it trump whatever value is returned from the called flow. Would<br/>
Ed&gt;that satisfy?</p>
<p>Yes, that would be great. The nested flow would be encapsulated and it wouldn't have to know anything about calling flow's node names. It would be like when calling nested flow - you specify nested flow name, but not node name in nested flow.</p>JAVASERVERFACES_SPEC_PUBLIC-1354Allow specify node-on-return in flow call nodeBugMajorOpenUnresolvedUnassignedMartin_SvihlikFri, 23 Jan 2015 06:53:44 +0000Fri, 23 Jan 2015 06:53:44 +0000Flow01Rank0|i0ge1b:Rank (Obsolete)95587[JAVASERVERFACES_SPEC_PUBLIC-1352] More clearly define requirements for one request cycle especially with respect to concurrencyhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1352
javaserverfaces-spec-publicJAVASERVERFACES_SPEC_PUBLIC-1352More clearly define requirements for one request cycle especially with respect to concurrencyImprovementMajorOpenUnresolvedUnassignedManfred RiemWed, 21 Jan 2015 14:07:26 +0000Wed, 26 Aug 2015 15:14:55 +000001RelatedJAVASERVERFACES-3690Rank0|i0gdpj:Rank (Obsolete)95534[JAVASERVERFACES_SPEC_PUBLIC-1357] Make enum constants accessible from EL.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1357
javaserverfaces-spec-public<p>Enum constants shall be accessible </p>
<p>Let me explain this by an example. Given an enum</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> <span class="code-keyword">enum</span> Page {
Welcome(<span class="code-quote">"/welcome"</span>),
<span class="code-comment">// many more...
</span> AdminWelcome(<span class="code-quote">"/admin/welcome"</span>);
<span class="code-keyword">private</span> Page(<span class="code-object">String</span> url) {
_url = url;
}
<span class="code-keyword">private</span> <span class="code-keyword">final</span> <span class="code-object">String</span> _url;
<span class="code-keyword">public</span> <span class="code-object">String</span> getUrl() {
<span class="code-keyword">return</span> _url + <span class="code-quote">".xhtml"</span>;
}
<span class="code-keyword">public</span> <span class="code-object">String</span> getRedirectUrl() {
<span class="code-keyword">return</span> _url + <span class="code-quote">".xhtml?faces-redirect=<span class="code-keyword">true</span>"</span>;
}
}
</pre>
</div></div>
<p>The goal is to access an URL of a specific member of that enum from an EL.</p>
<p>Declaring the enum as a named CDI bean (@Named) grants access to the methods, but the constants.</p>
<p>By now, there is an ugly workaround by mapping all entries and delegating from another bean to this</p>
<p>{enum Page)</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">private</span> <span class="code-keyword">static</span> Map&lt;<span class="code-object">String</span>, <span class="code-object">String</span>&gt; _pages;
<span class="code-keyword">public</span> <span class="code-keyword">static</span> Map&lt;<span class="code-object">String</span>, <span class="code-object">String</span>&gt; getPages() {
<span class="code-keyword">if</span> (_pages == <span class="code-keyword">null</span>) {
_pages = <span class="code-keyword">new</span> HashMap&lt;&gt;();
<span class="code-keyword">for</span> (Page page : Page.values()) {
_pages.put(page.name(), page.getUrl());
}
}
<span class="code-keyword">return</span> _pages;
}
</pre>
</div></div>
<p>(otherBean)</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> Map&lt;<span class="code-object">String</span>, <span class="code-object">String</span>&gt; getPages() {
<span class="code-keyword">return</span> Page.getPages();
}
</pre>
</div></div>
<p>Now access within EL is possible:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
#{otherBean.pages.AdminCategoryEditor}}
</pre>
</div></div>
<p>--&gt; The goal is to directly access the enum</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
#{page.AdminCategoryEditor.url}
</pre>
</div></div>
<p>The enum is used in a method</p>
<p>(otherBean)</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> <span class="code-object">String</span> navigate(<span class="code-object">String</span> topic) {
<span class="code-comment">// perform some useful stuff
</span> <span class="code-keyword">return</span> topic;
}
</pre>
</div></div>
<p>This can be used from EL</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
#{otherBean.navigate(otherBean.pages.AdminWelcome)}
</pre>
</div></div>
<p>It would be preferred to use an enum in the navigation method:</p>
<p>(otherBean)</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> <span class="code-object">String</span> navigate(Page page) {
<span class="code-comment">// perform some useful stuff
</span> <span class="code-keyword">return</span> page.getUrl();
}
</pre>
</div></div>
<p>--&gt; The goal is to directly access the enum</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
#{otherBean.navigate(page.AdminWelcome)}
</pre>
</div></div>
JAVASERVERFACES_SPEC_PUBLIC-1357Make enum constants accessible from EL.New FeatureMajorOpenUnresolvedUnassignedmuellermiSun, 1 Feb 2015 21:09:39 +0000Sun, 1 Feb 2015 21:36:37 +00002.3EL01{otherBean.navigate(AdminWelcome)}
<p>should be</p>
{otherBean.navigate(page.AdminWelcome)} Rank0|i0gg5b:Rank (Obsolete)95929[JAVASERVERFACES_SPEC_PUBLIC-1253] Consider enabling abandoning a flow directly for another flowhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1253
javaserverfaces-spec-public<p>Consider an app with this arrangement.</p>
<blockquote>
<p>src/main/webapp/WEB-INF/faces-config.xml<br/>
src/main/webapp/flowA/flowA-flow.xml<br/>
src/main/webapp/flowA/flowA.xhtml<br/>
src/main/webapp/flowB/flowB-flow.xml<br/>
src/main/webapp/flowB/flowB.xhtml<br/>
src/main/webapp/flowC/flowC-flow.xml<br/>
src/main/webapp/flowC/flowC.xhtml<br/>
src/main/webapp/index.xhtml<br/>
src/main/webapp/site-template.xhtml</p></blockquote>
<p>All .xhtml pages in this app are template clients of<br/>
site-template.xhtml. The site-template.xhtml has a row of buttons along<br/>
the top that allow immediate navigation to all of the flows. The intent<br/>
is that whatever flow you're in, you want to abandon it and enter the<br/>
new flow when the corresponding button is clicked. This is not a flow<br/>
call, but rather should be treated as an atomic "abandon/enter".</p>
<p>The current specification does not support this cleanly. </p>JAVASERVERFACES_SPEC_PUBLIC-1253Consider enabling abandoning a flow directly for another flowImprovementMajorOpenUnresolvedUnassignedEd BurnsFri, 17 Jan 2014 20:04:01 +0000Fri, 1 Aug 2014 20:22:24 +00002.2Flow45<p>Diff of reproducer.</p><p>zip of reproducer.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i00607:Rank (Obsolete)974[JAVASERVERFACES_SPEC_PUBLIC-1248] Allow EL in ResourceBundles used by JSF.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1248
javaserverfaces-spec-public<p>It would be nice if we could allow the use of EL expressions in ResourceBundles used by JSF.</p>JAVASERVERFACES_SPEC_PUBLIC-1248Allow EL in ResourceBundles used by JSF.ImprovementMajorOpenUnresolvedUnassignedEd BurnsFri, 27 Dec 2013 19:17:38 +0000Wed, 13 Aug 2014 20:25:20 +0000Platform Integration (except for Bean Validator)11<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Bean Validation 1.1 added this, so it's high time we do the same.</p>Rank0|i005z3:Rank (Obsolete)969[JAVASERVERFACES_SPEC_PUBLIC-1246] Prevent jumping into a flow without going through the front door.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1246
javaserverfaces-spec-public<p>RS&gt; One observation is with regards to access to flow scoped data. When<br/>
RS&gt; using the provided buttons, everything works as it should, i.e. flow<br/>
RS&gt; scoped data is created at the point of entering the flow and<br/>
RS&gt; destroyed when the flow is exited. However, it is easy to bypass the<br/>
RS&gt; entry and exit points. For example I can go directly to a page<br/>
RS&gt; associated with a flow without entering the flow, and if the page<br/>
RS&gt; tries to access flow data, the result would be<br/>
RS&gt; ContextNotActiveException.</p>
<p>One could argue that such an exception is the right response. The<br/>
context is indeed not active. However, if you are not using any flow<br/>
scoped data, such an exception would not be thrown, and it would give<br/>
the impression that the navigation is supported.</p>
<p>I think we can add some language to the spec to detect these "jump in"<br/>
cases.</p>JAVASERVERFACES_SPEC_PUBLIC-1246Prevent jumping into a flow without going through the front door.New FeatureMajorOpenUnresolvedUnassignedEd BurnsFri, 27 Dec 2013 17:09:03 +0000Wed, 13 Aug 2014 20:24:45 +00002.2Flow01<p>Rossen wrote:</p>
<blockquote>
<p>When flows are defined under the web application's root, I can easily access <br/>
their source from a browser which is a security concern. I can see there is <br/>
an example that puts the flow definition under WEB-INF but the pages are <br/>
still under the web application root and hence the flow is in two different <br/>
places. It would be useful to be able to keep a flow with all its files in a <br/>
folder under WEB-INF.</p></blockquote><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i005yn:Rank (Obsolete)967[JAVASERVERFACES_SPEC_PUBLIC-1247] Disable implicit navigation within flows on a per-flow basis.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1247
javaserverfaces-spec-public<p>The ease of use of implicit navigation can be a boon for quick development, but it can also make it difficult to reason about flows when they get more complex. Consider adding a configuration element that disables implicit navigation in a flow. </p>JAVASERVERFACES_SPEC_PUBLIC-1247Disable implicit navigation within flows on a per-flow basis.ImprovementMajorOpenUnresolvedUnassignedEd BurnsFri, 27 Dec 2013 17:21:30 +0000Fri, 1 Aug 2014 20:23:19 +00002.2Flow02<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i005yv:Rank (Obsolete)968[JAVASERVERFACES_SPEC_PUBLIC-1263] Add rowStatePreserved property to com.sun.faces.facelets.component.UIRepeat, exactly the same as javax.faces.component.UIDatahttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1263
javaserverfaces-spec-public<p>This is the implementation work for <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1230" title="VDLDoc for &lt;ui:repeat&gt; does not have concept of rowStatePreserved which &lt;h:dataTable&gt; does have." class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1230"><del>JAVASERVERFACES_SPEC_PUBLIC-1230</del></a>, but it can be done outside of the spec because properties can be added to Facelet backed components without having to change the TLD.</p>JAVASERVERFACES_SPEC_PUBLIC-1263Add rowStatePreserved property to com.sun.faces.facelets.component.UIRepeat, exactly the same as javax.faces.component.UIDataNew FeatureMajorOpenUnresolvedUnassignedEd BurnsMon, 14 Oct 2013 18:58:25 +0000Fri, 1 Aug 2014 20:19:45 +0000223 days3 days<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>DependencyJAVASERVERFACES-2633RelatedJAVASERVERFACES_SPEC_PUBLIC-1230Rank0|i0062f:Rank (Obsolete)984[JAVASERVERFACES_SPEC_PUBLIC-1223] Facelet ui:param doesn't work in composite components (action)https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1223
javaserverfaces-spec-public<p>If i have a facelet file which includes a composite component and I want to pass ui:params for the action it doesn't work</p>
<p>File a.xhtml includes my template myTemplate.xhtml. I want to pass parameters for an action</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>&lt;ui:include src="/pages/templates/myTemplate.xhtml"&gt;
&lt;ui:param name="resetAction" value="reset" /&gt;
&lt;ui:param name="bean" value="#{myBean}" /&gt;
&lt;/ui:include&gt;
</pre>
</div></div>
<p>Following works / works not in myTemplate.xhtml:</p>
<p><img class="emoticon" src="https://java.net/jira/images/icons/emoticons/check.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> value is displayed</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>&lt;h:outputText value="Bean: #{bean}" /&gt;
</pre>
</div></div>
<p><img class="emoticon" src="https://java.net/jira/images/icons/emoticons/check.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> value is displayed</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>&lt;h:outputText value="resetAction: #{resetAction}" /&gt;
</pre>
</div></div>
<p><img class="emoticon" src="https://java.net/jira/images/icons/emoticons/error.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> Action doesn't work if i pass it into a compositeComponent</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>&lt;myCom:reset resetAction="#{bean[resetAction]}" /&gt;
</pre>
</div></div>
<p><img class="emoticon" src="https://java.net/jira/images/icons/emoticons/check.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> for a commandButton it works.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>&lt;p:commandButton value="test reset" action="#{bean[resetAction]}" /&gt;
</pre>
</div></div>
<p><img class="emoticon" src="https://java.net/jira/images/icons/emoticons/check.gif" height="16" width="16" align="absmiddle" alt="" border="0"/> If I don't add my composite component to a facelet tempalte the action also works:</p>
<p>&lt;myCom:reset resetAction="#</p>
{myBean.reset}
<p>" /&gt;</p>JAVASERVERFACES_SPEC_PUBLIC-1223Facelet ui:param doesn't work in composite components (action)BugMajorOpenUnresolvedUnassigneddasagoTue, 26 Mar 2013 10:39:01 +0000Fri, 1 Aug 2014 20:29:47 +000049<p>Can you send the entire reproducer (including all the sources) to issues@javaserverfaces.java.net?</p><p>I send you an example project.. (maven based, JBoss 6.0 Final, Mojarra 2.1.17, PrimeFaces 3.5, Omnifaces 1.4.1)</p>
<p>First example in reset page works - pass values directly to composite component</p>
<p>Second example in reset page doesn't work - pass values via facelet file to composite component</p>
<p>Third example in reset page works - pass values via facelet file to composite component with a workaround of omnifaces</p><p>You have hit upon an area with respect to composite components and ui:include that has not been ironed out as much as needed. The problem is that the context of the ui:param is not available within a retargetted expression that the action needs to actually work.</p>
<p>I am moving this to the spec issue tracker as the real issue still exists.</p><p>This is probably a better description of the <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1222" title="ValueChange method in POJO doesn&#39;t resolve correctly when POJO is a ui:param" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1222">JAVASERVERFACES_SPEC_PUBLIC-1222</a> issue I filed. Being a POJO or a managed bean is unrelated if I recall correctly.</p>
<p>I've been working around this by placing the ui:param in the view outside of the ui:include so that evaluations can find the ui:param correctly.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;ui:param name=<span class="code-quote">"pojoOrManagedBean"</span> value=<span class="code-quote">"#{bean}"</span>/&gt;
&lt;ui:include src=<span class="code-quote">"innerPageWithCompositeComponentWithTarget"</span>/&gt;
</pre>
</div></div><p>Manfred, do you think we can close 1222 as a duplicate of this one?</p>
<p>Ed</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>RelatedJAVASERVERFACES_SPEC_PUBLIC-1222Rank0|i005tj:Rank (Obsolete)944[JAVASERVERFACES_SPEC_PUBLIC-1160] Clarify intended workings of includeViewParamshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1160
javaserverfaces-spec-public<p>The workings of includeViewParams need to be clarified. See also <a href="http://java.net/jira/browse/JAVASERVERFACES-2260" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES-2260</a> </p>JAVASERVERFACES_SPEC_PUBLIC-1160Clarify intended workings of includeViewParamsBugMajorOpenUnresolvedUnassignedManfred RiemTue, 29 Jan 2013 18:52:25 +0000Wed, 13 Aug 2014 19:17:34 +000001<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>RelatedJAVASERVERFACES-2260Rank0|i005gf:Rank (Obsolete)885[JAVASERVERFACES_SPEC_PUBLIC-1172] ClientWindow: deal gracefully with multiple client windows having the same idhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1172
javaserverfaces-spec-public<p>AS&gt; + * &lt;p&gt;In addition to the hidden field already described. The runtime<br/>
AS&gt; + * must ensure that any component that renders a hyperlink that causes<br/>
AS&gt; + * the user agent to send a GET request to the Faces server when it is<br/>
AS&gt; + * clicked has a query parameter with a name and value specified in<br/>
AS&gt; + * </p>
{@link ResponseStateManager#CLIENT_WINDOW_URL_PARAM}
<p>. This<br/>
AS&gt; + * requirement is met by several of the "encode" methods on </p>
{@link
AS&gt; + * javax.faces.context.ExternalContext}
<p>. See </p>
{@link
AS&gt; + * javax.faces.context.ExternalContext#encodeActionURL(java.lang.String)
AS&gt; + * }
<p> for details.&lt;/p&gt;</p>
<p>AS&gt; What is the expected behavior when the end user creates a second browser <br/>
AS&gt; tab/window with an existing window id? For example, this can happen by:</p>
<p>AS&gt; - Bookmarking an url with a window id and opening that URL in multiple tabs.<br/>
AS&gt; - Copying and pasting an url from one tab into a second tab.<br/>
AS&gt; - (On some browsers) Using the browser's "New Window" action.</p>
<p>AS&gt; For each of the above cases, each window/tab should be assigned its own <br/>
AS&gt; unique id, even though it would require additional work to determine <br/>
AS&gt; when a client window id has been copied across windows/tabs</p>JAVASERVERFACES_SPEC_PUBLIC-1172ClientWindow: deal gracefully with multiple client windows having the same idBugMajorOpenUnresolvedUnassignedEd BurnsWed, 13 Mar 2013 20:44:41 +0000Wed, 13 Aug 2014 19:19:17 +0000Lifecycle11<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i005j3:Rank (Obsolete)897[JAVASERVERFACES_SPEC_PUBLIC-1171] Specify interaction of Stateless and CSRF protectionhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1171
javaserverfaces-spec-public<p>LU&gt; 2. Stateless views that needs to be protected against CSRF attack, must<br/>
LU&gt; include its token in javax.faces.ViewState field as if it was the view<br/>
LU&gt; state, but only contains the info related to the secret stored in session<br/>
LU&gt; or encoded/encrypted when client side state saving is used. In few words<br/>
LU&gt; if the view is protected, javax.faces.ViewState generation may requires<br/>
LU&gt; additional steps.</p>JAVASERVERFACES_SPEC_PUBLIC-1171Specify interaction of Stateless and CSRF protectionBugMajorOpenUnresolvedUnassignedEd BurnsWed, 13 Mar 2013 16:24:58 +0000Fri, 1 Aug 2014 20:00:04 +0000Lifecycle23<p>Don't stateless views also loose the implicit CSRF protection offerd by the required view state Id that stateful views have?</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i005iv:Rank (Obsolete)896[JAVASERVERFACES_SPEC_PUBLIC-1162] Dynamically created ClientBehaviors do not call addComponentResourcehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1162
javaserverfaces-spec-public<ul>
<li>If I dynamically create UIComponents using the new Application.createComponent( context, componentType, rendererType ), I find they automatically add any dependent resources (JS/CSS) to the h:head. This is fantastic.</li>
</ul>
<ul>
<li>If I dynamically create ClientBehaviours using Application.createBehavior( id ), no dependent resources get added.</li>
</ul>
<p>Am I supposed to add such resources manually? For example:</p>
<p> UIOutput js = new UIOutput();<br/>
js.setRendererType("javax.faces.resource.Script");<br/>
js.getAttributes().put("library", "mylibrary");<br/>
js.getAttributes().put("name", "bar.js");</p>
<p> FacesContext context = FacesContext.getCurrentInstance();<br/>
context.getViewRoot().addComponentResource(context, js, "head");</p>
<p>If so, how am I supposed to know what they are? For example, if I am dynamically adding an AjaxBehavior the exact name of the JavaScript file depends on which JSF implementation I am using.</p>
<p>Also logged as <a href="https://issues.apache.org/jira/browse/MYFACES-3610" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MYFACES-3610</a> (but got no response, so I'm trying it as a spec issue)</p><p>Both Mojarra and MyFaces 2.1.x implementations behave the same</p>JAVASERVERFACES_SPEC_PUBLIC-1162Dynamically created ClientBehaviors do not call addComponentResourceBugMajorOpenUnresolvedUnassignedkennardconsultingThu, 7 Feb 2013 00:45:37 +0000Wed, 13 Aug 2014 19:18:11 +00002.1Ajax/JavaScript02<p>The MyFaces team have indicated this may be a bug in the spec:</p>
<p>"the reason it does not work is because javax.faces.component.behavior.AjaxBehavior does not have @ResourceDependency attached"<br/>
<a href="https://issues.apache.org/jira/browse/MYFACES-3610" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MYFACES-3610</a></p>
<p>Could you please discuss?</p><p>I checked javax.faces.component.behavior.AjaxBehaviour.java in the latest 2.2 snapshot...</p>
<p><a href="https://maven.java.net/content/repositories/snapshots/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20130207.091549-141-sources.jar" class="external-link" rel="nofollow">https://maven.java.net/content/repositories/snapshots/javax/faces/javax.faces-api/2.2-SNAPSHOT/javax.faces-api-2.2-20130207.091549-141-sources.jar</a></p>
<p>...and it doesn't appear to be annotated there either?</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i005gv:Rank (Obsolete)887[JAVASERVERFACES_SPEC_PUBLIC-1178] Remove references to old XML schema and tag library URIhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1178
javaserverfaces-spec-public<p>Arun P. Gupta reported numerous instances of the old namespaces in the PDF. These should be fixed.</p>JAVASERVERFACES_SPEC_PUBLIC-1178Remove references to old XML schema and tag library URITaskMajorOpenUnresolvedUnassignedEd BurnsMon, 1 Apr 2013 23:33:55 +0000Wed, 13 Aug 2014 19:22:04 +0000Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF01<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i005kf:Rank (Obsolete)903[JAVASERVERFACES_SPEC_PUBLIC-1236] For Ajax File Uploads: Investigate the use of XMLHttpRequest2 (If available).https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1236
javaserverfaces-spec-public<p>Investigate the use of XMLHttpRequest (Level2) for file uploads (if available) and fall back to iframe if it is not available.</p>JAVASERVERFACES_SPEC_PUBLIC-1236For Ajax File Uploads: Investigate the use of XMLHttpRequest2 (If available).ImprovementMajorOpenUnresolvedUnassignedrogerkWed, 31 Jul 2013 18:49:36 +0000Wed, 13 Aug 2014 19:49:58 +0000Ajax/JavaScript13<p>Reminder that ICEsoft has submitted a patch for this, would be nice if the JIRA reflected this, etc.</p>
<p>Also note that MyFaces has preliminary support for this already, see <a href="https://issues.apache.org/jira/browse/MYFACES-2852" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MYFACES-2852</a>.</p>
<p>Contribution From IceSoft</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i005wf:Rank (Obsolete)957[JAVASERVERFACES_SPEC_PUBLIC-1211] UIOutput.resetValue() and UIInput.resetValue() produce unwanted state that is equal to the default values of the property accessor methodshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1211
javaserverfaces-spec-public<p>UIOutput/UIInput resetState() call set methods that cause StateHelper to add state that actually is the same as the default values that would be returned by the respective get-methods.</p>
<p>Proposed state neutral solution is be to remove the state from StateHelper using getStatehelper().remove(PropertyKey.xxx).</p>
JAVASERVERFACES_SPEC_PUBLIC-1211UIOutput.resetValue() and UIInput.resetValue() produce unwanted state that is equal to the default values of the property accessor methodsBugMajorOpenUnresolvedUnassignedHanspeter DuennenbergerTue, 30 Jul 2013 12:36:19 +0000Fri, 1 Aug 2014 20:32:41 +00002.2Components/Renderers02<p>if resetValue() would remove the state UIData could make use of UIInput.resetValue() while restoring descendant state iterating the rows.</p><p>Added changebundle containing the proposed changes.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>DependencyJAVASERVERFACES-2965Rank0|i005qv:Rank (Obsolete)932[JAVASERVERFACES_SPEC_PUBLIC-1183] selectMany components swallow/forgets preselected disabled SeletItemshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1183
javaserverfaces-spec-public<p>Consider this situation: you have a number of options and some options are already selected but must not be unselected. SelectItem allows to pass a disable item state and the item will be correctly rendered as checked but disabled. If some other options/checkboxes are enabled during decode only the submitted options will survive - the preselected disabled option will be lost since the disabled items checked state is not submitted.</p>
<p>I have a fix ready for that and also a test application - what's currently missing is the unit test for it, but I hope Manfred could help me out with that.</p>
<p>The change works like this: during rendering selected &amp; disabled itemValues will be added to a Set that is maintained on the component attributes map with name "selectedDisabledItems". This Set, if existing, will be merged to the newValues[] array with the submitted values. </p>
<p>See attached changebundle.txt and the sources of the test bean and page.</p>JAVASERVERFACES_SPEC_PUBLIC-1183selectMany components swallow/forgets preselected disabled SeletItemsImprovementMajorOpenUnresolvedUnassignedHanspeter DuennenbergerThu, 18 Apr 2013 14:24:19 +0000Fri, 1 Aug 2014 20:37:21 +000002<p>Please see associated issue for attachments</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>RelatedJAVASERVERFACES-2555Rank0|i005lb:Rank (Obsolete)907[JAVASERVERFACES_SPEC_PUBLIC-1191] SelectMany with generic collection results in ClassCastExceptionhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1191
javaserverfaces-spec-public<p>Using a generic wrapper class similar to java.util.Map.Entry with a collection as generic value argument within a selectmany-component will result in following ClassCastException on submit:</p>
<div class="code panel" style="border-style: solid;border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><b>Bean.java</b></div><div class="codeContent panelContent">
<pre class="code-java"><span class="code-keyword">private</span> List&lt;<span class="code-object">String</span>&gt; values;
<span class="code-keyword">private</span> Entry&lt;TestType, List&lt;<span class="code-object">String</span>&gt;&gt; entry;
</pre>
</div></div>
<div class="code panel" style="border-style: solid;border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;border-bottom-style: solid;"><b>site.xhtml</b></div><div class="codeContent panelContent">
<pre class="code-java">&lt;h:selectManyMenu value=<span class="code-quote">"#{bean.entry.value}"</span>&gt;
&lt;f:selectItems value=<span class="code-quote">"#{bean.values}"</span>
<span class="code-keyword">var</span>=<span class="code-quote">"<span class="code-keyword">var</span>"</span> itemLabel=<span class="code-quote">"#{<span class="code-keyword">var</span>}"</span> itemValue=<span class="code-quote">"#{<span class="code-keyword">var</span>}"</span>/&gt;
&lt;/h:selectManyMenu&gt;
</pre>
</div></div>
<p>"java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to java.util.Collection"</p>
<p>(the Entry class does not works since it does not follows bean conventions, but its just for understanding of the generic problem)</p><p>Glassfish 3.12</p>JAVASERVERFACES_SPEC_PUBLIC-1191SelectMany with generic collection results in ClassCastExceptionBugMajorOpenUnresolvedUnassigneddjmjTue, 7 May 2013 22:12:04 +0000Fri, 1 Aug 2014 20:35:49 +00002.102<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i005n3:Rank (Obsolete)915Tagscollectiongenericselectmanycheckboxselectmanylistbox[JAVASERVERFACES_SPEC_PUBLIC-1189] Flow identifier in @FlowDefinitionhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1189
javaserverfaces-spec-public<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
@Produces @FlowDefinition
<span class="code-keyword">public</span> Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {
<span class="code-object">String</span> flowId = <span class="code-quote">"flow1"</span>;
flowBuilder.id(<span class="code-quote">"unique"</span>, flowId);
flowBuilder.viewNode(flowId, <span class="code-quote">"/"</span> + flowId + <span class="code-quote">"/"</span> + flowId + <span class="code-quote">".xhtml"</span>).markAsStartNode();
<span class="code-keyword">return</span> flowBuilder.getFlow();
}
</pre>
</div></div>
<p>can be simplified to:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
@Produces @FlowDefinition(<span class="code-quote">"flow1"</span>)
<span class="code-keyword">public</span> Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {
...
}
</pre>
</div></div>JAVASERVERFACES_SPEC_PUBLIC-1189Flow identifier in @FlowDefinitionImprovementMajorOpenUnresolvedUnassignedarunguptaMon, 29 Apr 2013 20:28:46 +0000Tue, 11 Aug 2015 10:59:42 +0000Flow24<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>Rank0|i005mn:Rank (Obsolete)913Tagsfishcat[JAVASERVERFACES_SPEC_PUBLIC-1219] Specify behavior in case of abandoned flow.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1219
javaserverfaces-spec-public<p>Currently trying to navigate away from a flow by any means other than a flow-return or flow-call node will cause the navigation to silently fail. This approach has the nice property in that it prevents abandoned flows. Unfortunately, as <a href="https://java.net/jira/browse/JAVASERVERFACES-2997" title="None flow command actions navigation failed when entered a flow" class="issue-link" data-issue-key="JAVASERVERFACES-2997"><del>JAVASERVERFACES-2997</del></a> shows, this approach is overly restrictive. </p>
<p>This issue calls for the spec to say what should happen when the flow is abandoned.</p>JAVASERVERFACES_SPEC_PUBLIC-1219Specify behavior in case of abandoned flow.BugMajorOpenUnresolvedUnassignedEd BurnsMon, 26 Aug 2013 17:09:56 +0000Fri, 1 Aug 2014 20:30:53 +00002.2Flow026 hours6 hours<p>The fix for <a href="https://java.net/jira/browse/JAVASERVERFACES-2997" title="None flow command actions navigation failed when entered a flow" class="issue-link" data-issue-key="JAVASERVERFACES-2997"><del>JAVASERVERFACES-2997</del></a> did the following.</p>
<p>When looking for a navigation match in the midst of the flow, if no other way of finding a match is found, look for an implicit match outside of the flow. If that's not found, look in the root navigation map using the same three step process in normal JSF navigation.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>DependencyJAVASERVERFACES-2997Rank0|i005sn:Rank (Obsolete)940[JAVASERVERFACES_SPEC_PUBLIC-1206] required attribute is not enforced for inputFilehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1206
javaserverfaces-spec-public<p>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.</p>
<p>glassfish 4.0, Firefox</p>JAVASERVERFACES_SPEC_PUBLIC-1206required attribute is not enforced for inputFileBugMajorOpenUnresolvedUnassignedjasonzhang2002gmailcomMon, 8 Jul 2013 05:28:42 +0000Wed, 13 Aug 2014 19:29:54 +00002.2Components/Renderers01<p>Can you please supply an example that reproduces the problem?</p><p>This can be reproduced easily.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
@RequestScoped
@Named
<span class="code-keyword">public</span> class Test
{
Part file;
<span class="code-object">String</span> str;
<span class="code-keyword">public</span> <span class="code-object">String</span> getStr()
{
<span class="code-keyword">return</span> str;
}
<span class="code-keyword">public</span> void setStr(<span class="code-object">String</span> str)
{
<span class="code-keyword">this</span>.str = str;
}
<span class="code-keyword">public</span> Part getFile()
{
<span class="code-keyword">return</span> file;
}
<span class="code-keyword">public</span> void setFile(Part file)
{
<span class="code-keyword">this</span>.file = file;
}
<span class="code-keyword">public</span> <span class="code-object">String</span> save()
{
<span class="code-object">System</span>.out.println(<span class="code-quote">"save is called"</span>);
<span class="code-keyword">return</span> <span class="code-keyword">null</span>;
}
}
</pre>
</div></div>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;!DOCTYPE html PUBLIC <span class="code-quote">"-<span class="code-comment">//W3C//DTD XHTML 1.0 Transitional//EN"</span>
</span><span class="code-quote">"http:<span class="code-comment">//www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"</span>&gt;
</span>&lt;html xmlns=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/1999/xhtml"</span>
</span> xmlns:h=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/jsf/html"</span>
</span> xmlns:f=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/jsf/core"</span>
</span> xmlns:c=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/jsp/jstl/core"</span>
</span> xmlns:ui=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/jsf/facelets"</span>&gt;
</span>
&lt;h:body&gt;
&lt;h:messages&gt;
&lt;/h:messages&gt;
&lt;h:form enctype=<span class="code-quote">"multipart/form-data"</span>&gt;
&lt;h:inputFile value=<span class="code-quote">"#{test.file}"</span> id=<span class="code-quote">"file"</span> required=<span class="code-quote">"<span class="code-keyword">true</span>"</span>&gt;&lt;/h:inputFile&gt;
&lt;h:inputText value=<span class="code-quote">"#{test.str}"</span> id=<span class="code-quote">"string"</span> required=<span class="code-quote">"<span class="code-keyword">true</span>"</span>&gt;&lt;/h:inputText&gt;
&lt;h:commandButton value=<span class="code-quote">"submit"</span> action=<span class="code-quote">"#{test.save}"</span>&gt;
&lt;/h:commandButton&gt;
&lt;/h:form&gt;
&lt;/h:body&gt;
&lt;/html&gt;
</pre>
</div></div><p>Manfred and I investigated this and determined that UIInput.isEmpty() doesn't correctly handle this case when there is a Part that is empty.</p>
<p>UIInput.isEmpty() was added in support of <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-426" title="Bean Validator support." class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-426"><del>JAVASERVERFACES_SPEC_PUBLIC-426</del></a>.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>RelatedJAVASERVERFACES-2923Rank0|i005q7:Rank (Obsolete)929Tagsfilefile_uploadrequire[JAVASERVERFACES_SPEC_PUBLIC-1201] Require that the cookie used to store the Flash key is setHttpOnly(true)https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1201
javaserverfaces-spec-public<p>Require that the cookie used to store the Flash key is setHttpOnly(true)</p>JAVASERVERFACES_SPEC_PUBLIC-1201Require that the cookie used to store the Flash key is setHttpOnly(true)New FeatureMajorOpenUnresolvedUnassignedEd BurnsTue, 2 Jul 2013 17:35:26 +0000Fri, 1 Aug 2014 20:33:40 +00002.2Lifecycle021 hour1 hour<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>DependencyJAVASERVERFACES-2911Rank0|i005pb:Rank (Obsolete)925[JAVASERVERFACES_SPEC_PUBLIC-1197] Support multiple attribute on h:inputFilehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1197
javaserverfaces-spec-public<p>HTML 5 has a new attribute on input file: multiple.</p>
<p>When present, the user agent must allow the file chooser to select multiple files.</p>
<p>While the pass through attributes feature allows this to render correctly:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">&lt;html xmlns=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/1999/xhtml"</span>
</span> xmlns:ui=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/jsf/facelets"</span>
</span> xmlns:f=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/jsf/core"</span>
</span> xmlns:h=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/jsf/html"</span>
</span> xmlns:p=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/jsf/passthrough"</span>&gt;
</span> &lt;h:head&gt;&lt;/h:head&gt;
&lt;h:form id=<span class="code-quote">"form"</span> enctype=<span class="code-quote">"multipart/form-data"</span> prependId=<span class="code-quote">"<span class="code-keyword">false</span>"</span>&gt;
&lt;p&gt;&lt;h:inputFile id=<span class="code-quote">"file"</span> value=<span class="code-quote">"#{fileUploadBean.uploadedFile}"</span> p:multiple=<span class="code-quote">"multiple"</span>&gt;
&lt;f:validator validatorId=<span class="code-quote">"FileValidator"</span> /&gt;
&lt;/h:inputFile&gt;
&lt;/p&gt;
...
</pre>
</div></div>
<p>The renderer for javax.faces.Input javax.faces.File doesn't handle this case correctly.</p>
<p>Instead, as it iterates through the parts, it just overwrites the preceding part with each file in the uploaded collection.</p>
<p>I think a better strategy is to always have the value of the component be a List&lt;Part&gt; instead of just Part. </p>JAVASERVERFACES_SPEC_PUBLIC-1197Support multiple attribute on h:inputFileNew FeatureMajorOpenUnresolvedUnassignedEd BurnsMon, 10 Jun 2013 22:02:36 +0000Fri, 1 Aug 2014 20:34:22 +00002.2Components/Renderers243 days3 days<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>RelatedJAVASERVERFACES_SPEC_PUBLIC-802Rank0|i005of:Rank (Obsolete)921[JAVASERVERFACES_SPEC_PUBLIC-1194] Make it so web-facelettaglibrary and web-facesconfig XSD files are canonically stored in javaee schemas workspace.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1194
javaserverfaces-spec-public<p>This is the current workflow for updating the web-facelettaglibrary and web-facesconfig files in the javaee schemas workspace.</p>
<p>1. Use the NetBeans XML validator on the corresponding .xsd file<br/>
committed to the Mojarra workspace.</p>
<p>2. In the schema workspace, apply the instructions in doc/HOWTO to add<br/>
test content for new elements, and change test content for modified<br/>
elements, ensuring the tests are all wired up to execute in the<br/>
normal build process.</p>
<p>3. Copy the .xsd from the Mojarra workspace to the .xsds in the schema<br/>
workspace.</p>
<p>4. Ensure the tests all run cleanly.</p>
<p>5. Commit the changes in the schema workspace.</p>
<p>Instead, the workflow should be that the output from step 4. is taken to be the source of truth for the corresponding files in the JSF workspace. </p>JAVASERVERFACES_SPEC_PUBLIC-1194Make it so web-facelettaglibrary and web-facesconfig XSD files are canonically stored in javaee schemas workspace.TaskMajorOpenUnresolvedUnassignedEd BurnsWed, 22 May 2013 19:48:26 +0000Wed, 13 Aug 2014 19:24:52 +0000Documentation: Javadoc, TLDDoc, RenderkitDoc, PDF12<p>The crux of this task is to modify the .xsds files so that what they produce is identical to what is in glassfish-4.0-b89.zip for the web-facelettaglibrary and web-facesconfig XSD files.</p><p>web-partialresponse also must be fixed.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i005nr:Rank (Obsolete)918[JAVASERVERFACES_SPEC_PUBLIC-755] passing through of actionListener, action,.. not possible between composite componentshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-755
javaserverfaces-spec-public<p>I already talked to Ed Burns about this at the JSFDays, but I thought opening a<br/>
spec issue won't be bad!</p>
<p>There are 4 special attributes on composite components (action, actionListener,<br/>
validator, valueChangeListener) which are not populated on #</p>
{cc.attrs}
<p> as<br/>
MethodExpressions, but added to their related components (defined via the<br/>
targets attribute of cc:attribute) directly via setAction(), addActionListener(),...</p>
<p>This works fine for all standard components. However if you nest another<br/>
composite component inside the implementation of our composite component, you<br/>
are not able to pass any of those 4 attributes through to the nested composite<br/>
component, because it (normally) is a UINamingContainer which does not implement<br/>
any of the needed interfaces.</p>
<p>To make this more clear imagine you have a composite component which is a<br/>
special commandButton (AJAX-commandButton or whatever) and you're creating e.g.<br/>
a LoginPanel composite component. This LoginPanel composite component has an<br/>
actionListener attribute to determine the actionListener for the login button<br/>
(which in our implementation is our composite component commandButton). Now we<br/>
are not able to pass the actionListener through to "our" commandButton, because<br/>
it is no ActionSource2 an the MethodExpression is not stored in<br/>
#</p>
{cc.attrs.actionListener}
<p>. The same applies to the 3 other attributes.</p>
<p>&lt;cc:interface name="loginPanel"&gt;<br/>
&lt;cc:attribute name="actionListener" targets="???" /&gt;<br/>
&lt;/cc:interface&gt;<br/>
&lt;cc:implementation&gt;<br/>
&lt;!-- other components --&gt;<br/>
&lt;ez:customCommandButton actionListener="???" /&gt;<br/>
&lt;/cc:implementation&gt;</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-755passing through of actionListener, action,.. not possible between composite componentsSub-taskJAVASERVERFACES_SPEC_PUBLIC-901MajorOpenUnresolvedUnassignedJakob KorherrSat, 27 Feb 2010 03:22:41 +0000Fri, 1 Aug 2014 16:34:50 +00002.0Facelets/VDL96<p>cat2</p><p>frame</p><p>These are targeted at 2.1.</p><p>triage</p><p>GlassFish 3.1 M6 at the latest.</p><p>Move these to 2.2</p><p>I ran into this with my first large scale JSF 2.0 customer within a few days and<br/>
I think it should be urgently fixed, because usage of action, actionListener,<br/>
validator and valueChangeListener is essential to composite components and<br/>
nesting them will happen as soon a they are used in non trivial projects.</p><p>I am delighted to report that now taking the time to look at this more<br/>
closely, I observe that it appears to work.</p>
<p>In fact, we have an automated test and I'm about to attach the war.</p>
<p>Deploy the war and visit </p>
<p><a href="http://localhost:8080/jsf-systest/faces/composite/nesting03.xhtml" class="external-link" rel="nofollow">http://localhost:8080/jsf-systest/faces/composite/nesting03.xhtml</a></p>
<p>Click the button. It works if you are navigated to a page with<br/>
&lt;title&gt;Navigation Result&lt;/title&gt;.</p>
<p>The key enabler is you must declare the cc-relative client-id in the<br/>
targets.</p>
<p>SECTION: Using Page nesting03.xhtml</p>
<p>&lt;html xmlns="http://www.w3.org/1999/xhtml"<br/>
xmlns:h="http://java.sun.com/jsf/html"<br/>
xmlns:f="http://java.sun.com/jsf/core"<br/>
xmlns:ui="http://java.sun.com/jsf/facelets"<br/>
xmlns:ez="http://java.sun.com/jsf/composite/composite"&gt;<br/>
&lt;head&gt;<br/>
&lt;title&gt;Nesting 03&lt;/title&gt;<br/>
&lt;/head&gt;<br/>
&lt;body&gt;<br/>
&lt;h:form&gt;<br/>
&lt;ez:nesting3 action="#</p>
{compositeBean.doNav}
<p>" /&gt;<br/>
&lt;/h:form&gt;<br/>
&lt;/body&gt;<br/>
&lt;/html&gt;</p>
<p>SECTION: Defining Page nesting3.xhtml</p>
<p>&lt;html xmlns="http://www.w3.org/1999/xhtml"<br/>
xmlns:h="http://java.sun.com/jsf/html"<br/>
xmlns:f="http://java.sun.com/jsf/core"<br/>
xmlns:ui="http://java.sun.com/jsf/facelets"<br/>
xmlns:composite="http://java.sun.com/jsf/composite"<br/>
xmlns:ez="http://java.sun.com/jsf/composite/composite"&gt;<br/>
&lt;head&gt;<br/>
&lt;title&gt;Should Not Be Displayed&lt;/title&gt;<br/>
&lt;/head&gt;<br/>
&lt;body&gt;<br/>
&lt;composite:interface&gt;<br/>
&lt;composite:attribute name="action" required="true" method-signature="String method()" <br/>
targets="wrapper:commandButton"/&gt;<br/>
&lt;/composite:interface&gt;<br/>
&lt;composite:implementation&gt;<br/>
&lt;ez:wrapper id="wrapper"&gt;<br/>
&lt;h:commandButton id="commandButton" value="Click Me" /&gt;<br/>
&lt;/ez:wrapper&gt;<br/>
&lt;/composite:implementation&gt;<br/>
&lt;/body&gt;<br/>
&lt;/html&gt;</p>
<p>SECTION: Managed Bean CompositeBean.java</p>
<p> public String doNav() </p>
{
return "nestingNav";
}<p>Created an attachment (id=304)<br/>
mojarra systest.war</p><p>REOPENING</p>
<p>Thanks for looking into this, Ed, but unfortunately you got our scenario wrong.<br/>
Your scenario works, but imagine the following implementation section of nesting3:</p>
<p>&lt;composite:implementation&gt;<br/>
&lt;ez:someOtherNestingComponent action="????" /&gt;<br/>
&lt;/composite:implementation&gt;</p>
<p>and the page for someOtherNestingComponent:</p>
<p>&lt;composite:interface&gt;<br/>
&lt;composite:attribute name="action" required="true"<br/>
method-signature="String method()" targets="commandButton"/&gt;<br/>
&lt;/composite:interface&gt;<br/>
&lt;composite:implementation&gt;<br/>
&lt;h:commandButton id="commandButton" value="Click Me" /&gt;<br/>
&lt;/composite:implementation&gt;</p>
<p>Thus you have a composite component with an action attribute that itself uses a<br/>
composite component with and action attribute that itself uses a<br/>
h:commandButton. How can you accomplish that?</p>
<p>Or to be more specific: what do you use for the action attribute of the inner<br/>
composite component since action is not published as #</p>
{cc.attrs.action}
<p> and how<br/>
do you prevent the ClassCastException for ActionSource2 for the inner composite<br/>
component (since the first composite component tries to retarget the action<br/>
listener to it)?</p>
<p>Is this enough documentation or should I provide a sample webapp?</p><p>Ahh, thanks for reopening this. </p>
<p>I have modified the systest and will attach a patch and a new version of it.</p>
<p>Deploy it and you can reproduce the problem by visiting<br/>
<a href="http://localhost:8080/jsf-systest/faces/composite/nesting09.xhtml" class="external-link" rel="nofollow">http://localhost:8080/jsf-systest/faces/composite/nesting09.xhtml</a></p>
<p>Created an attachment (id=305)<br/>
patch to systest that shows off the bug.</p><p>Created an attachment (id=306)<br/>
systest with patch applied.</p><p>I'm really sorry to do this, but we simply don't have time to make this into 2.1.</p>
<p>If someone wants to submit a patch, maybe we can get it in under the wire. If so, I suggest they start by <br/>
taking a look at FaceletViewHandlingStrategy.java, line 1408:</p>
<p> ((ActionSource2) target)<br/>
.setActionExpression(<br/>
new ContextualCompositeMethodExpression(((sourceValue instanceof ValueExpression)<br/>
? (ValueExpression) sourceValue<br/>
: null),<br/>
me));</p>
<p> }</p>
<p>This is where the ClassCastException mentioned by Jakob originates. </p>
<p>I'd approach a first approximation of this feature by introducing some isCompositeComponent() test <br/>
there and take action accordingly.</p><p>On Friday 22 October at 18:33 EDT, Martin Marinschek wrote:</p>
<p>MM&gt; Hi guys,</p>
<p>MM&gt; my strong believe is that the target attribute should be immediately<br/>
MM&gt; deprecated.</p>
<p>MM&gt; It is wrongly placed where it is right now - an interface definition<br/>
MM&gt; should never provide hooks into the implementation. It should only<br/>
MM&gt; provide a meaningful context to which the implementation can refer.</p>
<p>The targets attribute is central to the entire concept of composite<br/>
components. I assert that it does not constitute a violation of the<br/>
abstraction because the targets attribute is not intended for<br/>
consumption by the page author. In fact, it is an implementation detail<br/>
that happens to reside within the &lt;cc:interface&gt; section.</p>
<p>MM&gt; I am sorry I haven't voiced this objection before - but at the time<br/>
MM&gt; this was discussed I was not very active on the EG, and then it was<br/>
MM&gt; too late to talk about this.</p>
<p>Yes, I'll say! I recall that we talked about this in December 2007. I<br/>
know because we had the EG meeting while I was in the hotel at<br/>
JavaPolis and I remember such a unique venue.</p>
<p>&gt;&gt;&gt;&gt;&gt; On Tue, 19 Oct 2010 14:30:17 -0500, Leonardo Uribe &lt;lu4242@gmail.com&gt; said:</p>
<p>LU&gt; I like the way it works now. For example, tomahawk t:inputHtml<br/>
LU&gt; component was rewritten into a composite component, and it is a good<br/>
LU&gt; example about when it could be useful that the only requerimiento<br/>
LU&gt; for a component to be composite is implement NamingContainer:</p>
<p>For what it's worth, Leonardo is happy with this way it works, provided<br/>
we address his other issues.</p>
<p>On Sat Oct 23 03:46:13 EDT 2010 Ganesh wrote:</p>
<p>G&gt; Martin, I like your proposal on deprecating "targets". But how would<br/>
G&gt; you then handle this case: Using a cc I nest &lt;f:actionListener<br/>
G&gt; "for=a" ... /&gt; and inside the cc there is a &lt;cc:actionSource name="a"<br/>
G&gt; targets="b, c" /&gt; where b and c are buttons? The logic of the "for"<br/>
G&gt; attributes only includes this: "If present, this attribute refers to<br/>
G&gt; the value of <b>one</b> of the exposed attached objects within the<br/>
G&gt; composite component inside of which this tag is nested." IMO<br/>
G&gt; deprecating "targets" would require opening "for" to refer to<br/>
G&gt; <b>multiple</b> exposed attached objects within the composite component<br/>
G&gt; inside of which this tag is nested just the way targets is doing this<br/>
G&gt; right now. "targets" kind of bundles them right now.</p>
<p>Yes, exactly. There was a lot of back and forth between David Geary,<br/>
Ken Paulsen, Kito Mann, Andy Schwartz, and myself on this. </p>
<p>G&gt; To make this more convenient omitting "for" could simply be a synonym<br/>
G&gt; representing a "for" for <b>all</b> nested actionSources, actionSource2s<br/>
G&gt; and CCs.</p>
<p>I prefer to be explicit here.</p>
<p>G&gt; Please follow Jakob's proposal on adding action, actionListener,<br/>
G&gt; valueChangeListener and validator the attributes map<br/>
G&gt; (#</p>
{cc.attrs.action}, #{cc.attrs.actionListener},<br/>
G&gt; #{cc.attrs.valueChangeListener}, #{cc.attrs.validator}). This is what<br/>
G&gt; a developer would expect to happen (at least I did so) and one could<br/>
G&gt; easily pass them on to nested components.<br/>
<br/>
JK&gt; I think we should do this a little differently:<br/>
<br/>
JK&gt; 1) try to add the e.g. ActionListener to the component specified in<br/>
JK&gt; the targets attribute, if possible. If it is not possible, log a<br/>
JK&gt; warning.<br/>
<br/>
JK&gt; 2) also expose the "well-known" attributes ("action",<br/>
JK&gt; "actionListener", ...) on the composite component attribute map, this<br/>
JK&gt; means being able to access the action attribute via #{cc.attrs.action}
<p>JK&gt; (currently not possible, because those attributes are not put on the<br/>
JK&gt; attribute map).</p>
<p>JK&gt; Thus the user can use the targets attribute if he/she wants to (and of<br/>
JK&gt; course, if it is possible) and also use #</p>
{cc.attrs.action} to refer to<br/>
JK&gt; the action attribute (like to any other attribute).<br/>
<br/>
JK&gt; Frankly I really don't understand why this was separated in the first<br/>
JK&gt; place. Of course, the targets attribute is neat, but IMHO it is also<br/>
JK&gt; kinda confusing. I find it a lot easier to access <em>every</em> attribute<br/>
JK&gt; (regardless if well-known or custom) via #{cc.attrs.attributeName}.<br/>
JK&gt; Furthermore using this approach you can support nesting normal<br/>
JK&gt; components and also nesting composite components.<br/>
<br/>
JK&gt; In addition the targets attribute can't solve a scenario in which the<br/>
JK&gt; action attribute of the inner component is required (most likely the<br/>
JK&gt; attribute from a composite component), because you need to enter a<br/>
JK&gt; value for the attribute, but you currently can't use<br/>
JK&gt; #{cc.attrs.action}
<p>, because this one points "nowhere".</p>
<p>Created an attachment (id=319)<br/>
Patch to use cc.attrs.action EL</p><p>Created an attachment (id=320)<br/>
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run</p><p>Created an attachment (id=321)<br/>
WAR file from test project</p><p>Thanks for the patch. I'm evaluating it now.</p><p>I applied the patch and re-ran a test page I had previously authored (on 13 October) and still see the <br/>
ClassCastException.</p>
<p>Can you please rework the patch to fix that?</p>
<p>Thanks,</p>
<p>Ed</p>
<p>This time I'll attach a zip of the simple xhtml files.</p><p>Created an attachment (id=325)<br/>
zip of composite component files</p><p>Created an attachment (id=330)<br/>
Patch solving problem cc:attribute targets to nested composite components</p><p>Created an attachment (id=331)<br/>
WAR file from test project</p><p>Created an attachment (id=332)<br/>
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run</p><p>Created an attachment (id=335)<br/>
Full solution merging two previous patches</p><p>Snapshot of reproducer, in progress.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p>RelatedJAVASERVERFACES_SPEC_PUBLIC-901Issuezilla Id755.0Rank0|i003t3:Rank (Obsolete)618Status Whiteboard<p>cat2 frame size_medium importance_large</p>[JAVASERVERFACES_SPEC_PUBLIC-1409] CDI @ViewScoped storage size context-paramhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1409
javaserverfaces-spec-public<p>This maximum number of active views in the CDI @ViewScoped storage should be configurable via a context-param setting, because they have a high impact on memory usage.</p>
<p>See discussion in: <a href="https://java.net/jira/browse/JAVASERVERFACES-3869" class="external-link" rel="nofollow">https://java.net/jira/browse/JAVASERVERFACES-3869</a></p>JAVASERVERFACES_SPEC_PUBLIC-1409CDI @ViewScoped storage size context-paramBugMajorOpenUnresolvedEd BurnsfrederickkaempferMon, 5 Oct 2015 08:55:59 +0000Mon, 5 Oct 2015 08:55:59 +000001Rank0|i0jh27:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-1410] Define the result when the same namespace is used in annotation defined and tag library defined components.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1410
javaserverfaces-spec-public<p>I cannot see anywhere in the specification that defines what should happen when the same namespace is used to define components using both the javax.faces.component.FacesComponent annotation and also in a tag library *.taglib.xml file. </p>
<p>For example:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
@FacesComponent(value=<span class="code-quote">"xforms.input"</span>, createTag=<span class="code-keyword">true</span>, namespace=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2002/xforms"</span>, tagName=<span class="code-quote">"input"</span>)
</span><span class="code-keyword">public</span> class Input ...
</pre>
</div></div>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;facelet-taglib version=<span class="code-quote">"2.2"</span>
xmlns=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/xml/ns/javaee"</span>
</span> xmlns:xsi=<span class="code-quote">"http:<span class="code-comment">//www.w3.org/2001/XMLSchema-instance"</span>
</span> xsi:schemaLocation=<span class="code-quote">"http:<span class="code-comment">//xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facelettaglibrary_2_2.xsd"</span>&gt;
</span>
&lt;namespace&gt;http:<span class="code-comment">//www.w3.org/2002/xforms&lt;/namespace&gt;
</span>
&lt;tag&gt;
&lt;tag-name&gt;model&lt;/tag-name&gt;
&lt;handler-class&gt;my.custom.xforms.ModelTagHandler&lt;/handler-class&gt;
&lt;/tag&gt;
&lt;/facelet-taglib&gt;
</pre>
</div></div>
<p>See <a href="https://stackoverflow.com/questions/28650232/creating-a-taglib-xml-with-a-taghandler-makes-annotated-custom-components-fail-t" class="external-link" rel="nofollow">this Stack Overflow question</a> for the full example.</p>
<p>The observed behaviour in Mojarra 2.2.12 is that the tag library defined components are available but the annotation defined ones are not. Reading the comments on the SO issue, the MyFaces implementation appears to make both components avaiable.</p>
<p>I think the specification should clearly define what should happen in this case.</p>
<p>From there, I'd suggest that the MyFaces behaviour of making both components available is more intuitive. If there is a conflict then the taglib version should probably win.</p>JAVASERVERFACES_SPEC_PUBLIC-1410Define the result when the same namespace is used in annotation defined and tag library defined components.ImprovementMajorOpenUnresolvedUnassignedBaarneyWed, 4 Nov 2015 03:38:37 +0000Wed, 4 Nov 2015 03:38:37 +00002.2Facelets/VDL01Rank0|i0jicn:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-1366] Within Resource Identifier, allow resourceName to have path separatorhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1366
javaserverfaces-spec-public<p>The expert group discussion for <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1141" title="Specify that all parts of a resource identifier must not have &quot;/&quot;." class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1141"><del>JAVASERVERFACES_SPEC_PUBLIC-1141</del></a> concluded that resourceName should be allowed to contain path separators.</p>
<p>An insufficient response to this conclusion was the following change to ResourceHandler.createResource()</p>
<blockquote>
<ul class="alternate" type="square">
<li>Added this text to createResource(string)</li>
</ul>
<p> For historical reasons, this method operate correctly when the<br/>
argument resourceName is of the form libraryName/resourceName, even<br/>
when resourceName contains '/' characters.</p></blockquote>
<p>The following additional spec actions must be taken.</p>
<p>1. Fix the wording of the text of createResource() to be:</p>
<blockquote>
<p>For historical reasons, this method <b>must</b> operate correctly when the argument resourceName is of the form libraryName/resourceName, even when resourceName contains '/' characters.</p></blockquote>
<p>2. In section 2.6.1.3 modify the sentence starting with "The set of characters..." to be:</p>
<blockquote>
<p>The set of characters that are valid for use in the localePrefix, libraryName, libraryVerison, resourceName and resourceVersion segments of the resource identifier is specififed as XML NameChar excluding the path separator and ‘:’ characters, <b>with the exception of resourceName, which may contain the path separator character</b>.</p></blockquote>JAVASERVERFACES_SPEC_PUBLIC-1366Within Resource Identifier, allow resourceName to have path separatorBugMajorOpenUnresolvedUnassignedEd BurnsThu, 5 Mar 2015 20:47:28 +0000Wed, 3 Feb 2016 08:07:23 +00002.2Lifecycle12<p>If resourceName may contain path separators, could that not create ambiguity with libraryVersion or resourceVersion?</p>
<p>For example the resourceIdentifier "libName/1_0/resName/2_0" might mean<br/>
libraryName=libName, libraryVersion=1_0, resourceName=resName, resourceVersion=2_0<br/>
or<br/>
libraryName=libName, libraryVersion=&lt;empty&gt;, resourceName=1_0/resName/2_0, resourceVersion=&lt;empty&gt;</p>
<p>libraryName is restricted to prevent ambiguity with libraryVersion (JSF 2.2 Spec, page 78). Maybe resourceName should have a similar restriction?</p>
<p>Or maybe this ambiguity is already dealt with elsewhere? For instance I didn't read through the whole algorithm in 2.6.1.4.</p><p>Other possible problems:</p>
<ul class="alternate" type="square">
<li>path separator charactar at the beginning or end "/resName/"</li>
<li>multiple path separators "res//Name"</li>
</ul>
<p>Not addressed by JSF 2.3 Early Draft Review.</p>RelatedJAVASERVERFACES_SPEC_PUBLIC-1141Rank0|i0gm7z:Rank (Obsolete)96913[JAVASERVERFACES_SPEC_PUBLIC-1378] Clear the view map on session destroy or when the ACTIVE_VIEW_MAPS_SIZE is reached and a view map is thrown awayhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1378
javaserverfaces-spec-public<p>The full discussion is at <a href="https://java.net/jira/browse/JAVASERVERFACES-3947" title="ViewScopeManager should better clear the view map (or publish a PreDestroyViewMapEvent) on session destroy" class="issue-link" data-issue-key="JAVASERVERFACES-3947"><del>JAVASERVERFACES-3947</del></a>.<br/>
In brief: when the session is destroyed, the beans of all the active view maps are destroyed, however the view maps themselves are not cleared (hence, no <tt>PreDestroyViewMapEvent</tt> is fired).<br/>
The same happens when the eldest view map is thrown away because the ACTIVE_VIEW_MAPS_SIZE is reached.</p>
<p>However, when JSF is integrated with other CDI-like frameworks, like the Spring Framework, for instance through an appropriate EL resolver (<tt>org.springframework.web.jsf.el.SpringBeanFacesELResolver</tt> in this case) and appropriate hooks on the <tt>PostConstructViewMapEvent}}s and {{PreDestroyViewMapEvent}}s, view-scoped beans created by the external framework won't be cleared on the above cases because no {{PreDestroyViewMapEvent</tt> is fired (the Mojarra <tt>ViewScopeManager</tt> takes care of just destroying view-scoped beans managed by JSF BeanManager itself).</p>
<p>Manfred Riem says this is a specification problem, because no strict requirement is stated on this.</p>JAVASERVERFACES_SPEC_PUBLIC-1378Clear the view map on session destroy or when the ACTIVE_VIEW_MAPS_SIZE is reached and a view map is thrown awayBugMajorOpenUnresolvedUnassignedmauromolThu, 4 Jun 2015 08:13:50 +0000Thu, 4 Jun 2015 08:13:50 +00002.2ELLifecycleManaged Beans14Rank0|i0h4l3:Rank (Obsolete)99888[JAVASERVERFACES_SPEC_PUBLIC-1235] better integration of bv-groupshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1235
javaserverfaces-spec-public<p>in several cases different bv-groups should get used (in the validation-phase) depending on the triggered action.<br/>
(if there are e.g. multiple buttons in the same form which should lead to different bv-constraints.)</p>
<p>also see: <a href="https://issues.apache.org/jira/browse/EXTVAL-141" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/EXTVAL-141</a></p>JAVASERVERFACES_SPEC_PUBLIC-1235better integration of bv-groupsImprovementMajorOpenUnresolvedUnassignedgerhard_petracekThu, 31 Oct 2013 20:07:08 +0000Mon, 8 Feb 2016 16:08:12 +00002.2Validation/Conversion14<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p><ul class="alternate" type="square">
<li>add an attribute validateGroup="someGroup" to the f:validateBean tag,<br/>
e.g.<br/>
&lt;f:validateBean validationGroups="javax.validation.groups.Default,de.muellerbruehl.jsf23.Email" validateGroup="de.muellerbruehl.jsf23.Email"/&gt;</li>
</ul>
<p>At the time, the validator is executed (on submit, immediate if ajaxified), do not validate according to the default group, which is default if validateGroup is missing, but according to the given group. If this group performs a multi field validation, create a copy of the model, apply new values (if applicable) and perform the validation.</p><p>Maybe a "validate" attribute for the f:ajax would be a good place to trigger (multi field) group validation.</p>
<p>&lt;h:message for="ageValidator"/&gt;<br/>
&lt;h:inputText id="ageDays" value="#</p>
{grouper.ageDays}
<p>"&gt;<br/>
&lt;f:validateBean id="ageValidator" validationGroups="javax.validation.groups.Default,de.muellerbruehl.jsf23.Age"/&gt;<br/>
&lt;f:ajax render="msgAgeDays ageValidator" validate="de.muellerbruehl.jsf23.Age"/&gt;<br/>
&lt;/h:inputText&gt;<br/>
&lt;h:message id="msgAgeDays" for="ageDays"/&gt;</p>
<p>&lt;h:inputText id="ageYears" value="#</p>
{grouper.ageYears}
<p>"&gt;<br/>
&lt;f:validateBean validationGroups="javax.validation.groups.Default,de.muellerbruehl.jsf23.Age"/&gt;<br/>
&lt;f:ajax render="msgAgeYears ageValidator" validate="de.muellerbruehl.jsf23.Age"/&gt;<br/>
&lt;/h:inputText&gt;<br/>
&lt;h:message id="msgAgeYears" for="ageYears"/&gt;</p>
Rank0|i005w7:Rank (Obsolete)956[JAVASERVERFACES_SPEC_PUBLIC-1227] Add <f:protectClientWindowOpenInNewTab> JavaScript behavior taghttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1227
javaserverfaces-spec-public<p>With the introduction of ClientWindow in JSF 2.2, it's possible to protect against multiple tabs being open on the same view. However, components that render links allow the user to do "open in new tab" or "open in new window". This can cause a situation where there are multiple tabs that still have the same ClientWindow, which is incorrect. </p>
<p>This feature proposal asks for the creation of a ClientBehavior tag that, when nested inside of a component that renders as a link, will make it so a new client window is created when the link is clicked.</p>JAVASERVERFACES_SPEC_PUBLIC-1227Add <f:protectClientWindowOpenInNewTab> JavaScript behavior tagNew FeatureMajorOpenUnresolvedUnassignedEd BurnsMon, 7 Oct 2013 22:38:51 +0000Thu, 17 Sep 2015 14:49:29 +00002.2Ajax/JavaScript664 days4 days<p>Here's a sketch for how this could work.</p>
<p>Here's how you'd use it.</p>
<p>&lt;h:link outcome="callB" value="Call B via GET"&gt;<br/>
&lt;f:protectClientWindowOpenInNewTab /&gt;<br/>
&lt;/h:link&gt;</p>
<p>This would cause the link to be rendered with some javascript that listens for an onclick on the link. In the handler, check if the right mouse button was pressed and take appropriate action.</p><p>I am afraid that this feature would force unintuitive behavior and also advocates a rather patronizing development style. </p>
<p>How about creating a client behavior that creates a window id on demand? <br/>
So instead of blocking the contextmenu we could use the oncontextmenu handler to create a new id and append it as a parameter to the link.</p>
<p>Thanks for the feedback, Thomas. We can certainly change the name to be less patronizing. </p>
<p>Please note that the ClientWindow <b>will</b> be created on demand when the request comes in without having one already. This is why it is sufficient for the context menu handler to simply strip it off. </p>
<p>The client behavior for this tag does two things.</p>
<p>1. If the link is clicked without the context menu, no action is taken. The already-existing ClientWindow is allowed to remain on the link, causing the correct ClientWindow to be carried forward.</p>
<p>2. If the link is clicked with the context menu (new tab or new window), the ClientWindow is removed before the browser issues the GET. This will cause a new ClientWindow to be created for the new tab (or window), this is the correct action in this case.</p>
<p>@Ed<br/>
is it really possible to listen on "onclick" when the link will be openend in new tab via context menu?<br/>
I'm sure onclick won't be called.</p>
<p>Maybe we should never render the windowId to a link und just add via onclick.<br/>
We could store the windowId globally in a JS varable in in the listener, we could add it to the href.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major</p><p>The idea behind this issue only protects the browser to open a new tab or window using the same client id. </p>
<p>Sadly the user still is able to copy the url and paste it into a manually opened new tab. What we really need is some information to determine the "right" window.</p><p>Maybe window.name (JavaScript) would be helpful to perform this task.</p><p>window.name is also used in DeltaSpike.<br/>
Please have a look at it: <a href="http://deltaspike.apache.org/documentation/jsf.html#AvailableModes" class="external-link" rel="nofollow">http://deltaspike.apache.org/documentation/jsf.html#AvailableModes</a><br/>
CLIENT_WINDOW is the most complete and 100% working mode.</p>
<p>I will complete the docu these days, LAZY mode is described much more detailed.</p>Rank0|i005uf:Rank (Obsolete)948[JAVASERVERFACES_SPEC_PUBLIC-1098] f:ajax exeucte always sends all the fields of the wrapping formhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1098
javaserverfaces-spec-public<p>f:ajax doesn't obey the 'execute' attribute but always sends all the fields in a form. Mojarra does, however, only process the listed fields as supposed. However, excess fields shouldn't be sent because it increases request size.</p>
<p>Recplicate with:</p>
<p>&lt;h:form id="form1"&gt;<br/>
&lt;h:commandButton&gt;<br/>
&lt;h:inputText id="field1" /&gt;<br/>
&lt;h:inputText id="field1x" /&gt;<br/>
&lt;f:ajax execute="field1" /&gt;<br/>
&lt;/h:commandButton&gt;<br/>
&lt;/h:form&gt;</p>
<p>On button click, both fields are sent (but only field1 would be processed).</p>
<p>See for further info: <a href="http://stackoverflow.com/questions/3889894/jsf-2-0-why-does-fajax-send-all-the-form-fields-and-not-only-those-marked-with" class="external-link" rel="nofollow">http://stackoverflow.com/questions/3889894/jsf-2-0-why-does-fajax-send-all-the-form-fields-and-not-only-those-marked-with</a></p>
<p>See: <a href="http://java.net/jira/browse/JAVASERVERFACES-1908" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES-1908</a></p>JAVASERVERFACES_SPEC_PUBLIC-1098f:ajax exeucte always sends all the fields of the wrapping formBugMajorOpenUnresolvedUnassignedrogerkTue, 8 May 2012 20:09:02 +0000Wed, 13 Aug 2014 18:28:57 +00002.1Ajax/JavaScript118<p>PrimeFaces has recently implemented this, would be great to have this in the spec.</p><p>Must have feature for JSF 2.3. This really shouldn't be that hard, should it?</p><p>An implementation duplicate: <a href="https://java.net/jira/browse/JAVASERVERFACES-1841" title="Ajax request submit all input fields although &quot;execute&quot; attribute is used to submit a few fields" class="issue-link" data-issue-key="JAVASERVERFACES-1841"><del>JAVASERVERFACES-1841</del></a></p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i0052v:Rank (Obsolete)824[JAVASERVERFACES_SPEC_PUBLIC-1147] Dynamical switching of state saving mechanismhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1147
javaserverfaces-spec-public<p>It should be possible to switch state saving dynamically per request via StateManager#isSavingStateInClient.<br/>
e.g. Therefore it would be possible to use server side state for view A and client side for view B.</p>JAVASERVERFACES_SPEC_PUBLIC-1147Dynamical switching of state saving mechanismImprovementMajorOpenUnresolvedUnassignedtandraschkoWed, 28 Nov 2012 19:16:03 +0000Fri, 1 Aug 2014 19:53:08 +0000Components/RenderersFacelets/VDL03<p>I think this is a direct duplicate of <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1056" title="More flexible state saving" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1056"><del>JAVASERVERFACES_SPEC_PUBLIC-1056</del></a></p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting to priority Major (because of its related issue).</p>RelatedJAVASERVERFACES-1959JAVASERVERFACES-2616Rank0|i005dj:Rank (Obsolete)872[JAVASERVERFACES_SPEC_PUBLIC-1417] Deprecate types in javax.faces.bean packagehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1417
javaserverfaces-spec-public<p>JSF has for some time been emphasising to use CDI instead of its own native bean facility. Specifically, newer features such as <tt>@FlowScoped</tt> that were introduced in JSF 2.2 require CDI and won't work with the native bean facility.</p>
<p>Having the old native managed bean facility available is not rarely confusing to users. E.g. it's common to accidentally import <tt>javax.faces.bean.RequestScoped</tt> instead of <tt>javax.enterprise.context.RequestScoped</tt>.</p>
<p>Because of this I'd like to propose deprecating all the types in the <tt>javax.faces.bean</tt> package as well as the package itself via the @Deprecated annotation and/or javadoc, and mention what the alternatives are.</p>JAVASERVERFACES_SPEC_PUBLIC-1417Deprecate types in javax.faces.bean packageTaskMajorOpenUnresolvedarjan tijmsarjan tijmsWed, 18 May 2016 20:40:08 +0000Thu, 26 May 2016 15:54:54 +00002.32.3Managed Beans01RelatedJAVASERVERFACES-4145Rank0|i0jnsf:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-1420] Provide portable way to attach behaviors to a composite / base implementation for behaviorshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1420
javaserverfaces-spec-public<p>Implementing behaviors in a component library is currently not as easy as implementing components.</p>
<p>1) There is no abstract behavior base available<br/>
2) No common way to handle state saving like the StateHelper<br/>
3) No common way to attach a behavior to a component<br/>
4) No common, portable and easy way to attach a behavior to a composite</p>
<p>It would be a great goal to create a abstract base for behaviors, which fixes the common problems.<br/>
In PrimeFaces, i developed it via:</p>
<ul class="alternate" type="square">
<li>AbstractBehavior; base class which handles the attributes and state saving - similar to getStateHelper and PropertyKeys</li>
</ul>
<p><a href="https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java" class="external-link" rel="nofollow">https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java</a></p>
<ul class="alternate" type="square">
<li>AbstractBehaviorHandler; attach the behavior to the target component or composite; currently with a hack for Mojarra and MyFaces</li>
</ul>
<p><a href="https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/base/AbstractBehaviorHandler.java" class="external-link" rel="nofollow">https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/base/AbstractBehaviorHandler.java</a></p>
<p>Example implemtation of p:ajax:<br/>
<a href="https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/ajax/AjaxBehavior.java" class="external-link" rel="nofollow">https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/ajax/AjaxBehavior.java</a><br/>
<a href="https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/ajax/AjaxBehaviorHandler.java" class="external-link" rel="nofollow">https://github.com/primefaces/primefaces/blob/6_0/src/main/java/org/primefaces/behavior/ajax/AjaxBehaviorHandler.java</a></p>
JAVASERVERFACES_SPEC_PUBLIC-1420Provide portable way to attach behaviors to a composite / base implementation for behaviorsNew FeatureMajorOpenUnresolvedUnassignedtandraschkoTue, 7 Jun 2016 10:26:55 +0000Tue, 7 Jun 2016 10:26:55 +00002.2Ajax/JavaScriptComponents/RenderersFacelets/VDL11Rank0|i0jocn:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-1336] ViewScope and client side state saving is brokenhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1336
javaserverfaces-spec-public<p>Easy to reproduce: use CS state saving... store something in view scope... stop your server (ensure it doesn't restore sessions)... start server and observe viewScope data is lost.</p>JAVASERVERFACES_SPEC_PUBLIC-1336ViewScope and client side state saving is brokenBugMajorOpenUnresolvedUnassignedEd BurnsTue, 4 Nov 2014 00:25:10 +0000Tue, 4 Nov 2014 20:16:40 +000012<p>JSF 2.2 javadoc of UIViewRoot.getViewMap(boolean create) says this:</p>
<p>"... For reasons made clear in ViewScoped, this map must ultimately be stored in the session. For this reason, a true value for the create argument will force the session to be created with a call to ExternalContext.getSession(boolean). ..."</p>
<p>Before JSF 2.2, view scope was stored with the view state on client side state saving.</p>Rank0|i0fwnz:Rank (Obsolete)92773[JAVASERVERFACES_SPEC_PUBLIC-1421] Modify the requirements of the jsf.ajax.response JavaScript documentation to enable portlet compatibilityhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1421
javaserverfaces-spec-public<p>The <a href="https://javaserverfaces.java.net/nonav/docs/2.2/jsdocs/symbols/jsf.ajax.html#.response" class="external-link" rel="nofollow">jsf.ajax.response JavaScript documentation</a> contains requirements that are not compatible with portlet environments.</p>
<p><b>Portlet Incompatibility #1</b></p>
<blockquote>
<p>If an <tt>&lt;update&gt;</tt> element is found in the response with the identifier javax.faces.ViewRoot:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;update id=<span class="code-quote">"javax.faces.ViewRoot"</span>&gt;</span>
<span class="code-tag">&lt;![CDATA[...]]&gt;</span>
<span class="code-tag">&lt;/update&gt;</span>
</pre>
</div></div>
<p>Update the entire DOM replacing the appropriate head and/or body sections with the content from the response</p></blockquote>
<p><b>Portlet Incompatibility #2</b></p>
<blockquote>
<p>If an <tt>&lt;update&gt;</tt> element is found in the response with the identifier javax.faces.ViewBody:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;update id=<span class="code-quote">"javax.faces.ViewBody"</span>&gt;</span>
<span class="code-tag">&lt;![CDATA[...]]&gt;</span>
<span class="code-tag">&lt;/update&gt;</span>
</pre>
</div></div>
<p>update the document's body section with the CDATA contents from the response.</p></blockquote>
<p>These requirements assume that the RENDER_RESPONSE phase of the JSF lifecycle was responsible for generating the <b>entire HTML document</b> including the following tags:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;html&gt;</span>
<span class="code-tag">&lt;head&gt;</span>
...
<span class="code-tag">&lt;/head&gt;</span>
<span class="code-tag">&lt;body&gt;</span>
...
<span class="code-tag">&lt;/body&gt;</span>
<span class="code-tag">&lt;/html&gt;</span>
</pre>
</div></div>
<p>The requirements further assume that the renderer associated with the h:body component tag renders the <tt>&lt;body&gt;</tt> starting tag and <tt>&lt;/body&gt;</tt> end tag, and that the <tt>&lt;f:view&gt;</tt> (UIViewRoot) corresponds to the body section of the document.</p>
<p>In a portlet environment, the JSF Portlet Bridge ensures that object returned by FacesContext.getCurrentInstance().getViewRoot() to be an instance of <a href="http://myfaces.apache.org/portlet-bridge/2.0/api/apidocs/javax/portlet/faces/component/PortletNamingContainerUIViewRoot.html" class="external-link" rel="nofollow">javax.portlet.faces.component.PortletNamingContainerUIViewRoot</a>. Since it extends <a href="https://javaserverfaces.java.net/nonav/docs/2.2/javadocs/javax/faces/component/NamingContainer.html" class="external-link" rel="nofollow">javax.faces.component.NamingContainer</a>, the UIViewRoot becomes "namespaced" with the portlet namespace.</p>
<p>The JSF Portlet Bridge also overrides the renderer associated with the h:body component and renders a <tt>&lt;div&gt;...&lt;/div&gt;</tt> section instead of a <tt>&lt;body&gt;...&lt;/body&gt;</tt> section. In addition, the div has an <tt>id</tt> attribute with the <em>namespaced</em> clientId of the view root.</p>
<p>The JSF Portlet Bridge also overrides the renderer associated with the h:head component so that it can inform the portlet container of required JSF resources. The renderer does <b>not</b> render a <tt>&lt;head&gt;...&lt;/head&gt;</tt> section in a portlet environment.</p>
<p>For example, given the following JSF view:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;f:view&gt;</span>
<span class="code-tag">&lt;h:head /&gt;</span>
<span class="code-tag">&lt;h:body&gt;</span>
<span class="code-tag">&lt;h:form id=<span class="code-quote">"f1"</span>&gt;</span>
<span class="code-tag">&lt;h:inputText id=<span class="code-quote">"foo"</span> value=<span class="code-quote">"#{backingBean.foo}"</span> /&gt;</span>
<span class="code-tag">&lt;h:commandButton /&gt;</span>
<span class="code-tag">&lt;/h:form&gt;</span>
<span class="code-tag">&lt;/h:body&gt;</span>
<span class="code-tag">&lt;/f:view&gt;</span>
</pre>
</div></div>
<p>On Apache Pluto the portlet div section might look something like this:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;div id=<span class="code-quote">"Pluto_myPortlet_1__24955534_0_"</span>&gt;</span>
...
<span class="code-tag">&lt;form id=<span class="code-quote">"Pluto_myPortlet_1__24955534_0_:f1"</span>&gt;</span>
<span class="code-tag">&lt;input type=<span class="code-quote">"hidden"</span> name=<span class="code-quote">"Pluto_myPortlet_1__24955534_0_:f1"</span> value=<span class="code-quote">"Pluto_myPortlet_1__24955534_0_:f1"</span>&gt;</span>
<span class="code-tag">&lt;input id=<span class="code-quote">"Pluto_myPortlet_1__24955534_0_:f1:foo"</span> type=<span class="code-quote">"text"</span> name=<span class="code-quote">"Pluto_myPortlet_1__24955534_0_:f1:foo"</span>&gt;</span>
<span class="code-tag">&lt;input type=<span class="code-quote">"submit"</span>&gt;</span>
<span class="code-tag">&lt;input type=<span class="code-quote">"hidden"</span> name=<span class="code-quote">"Pluto_myPortlet_1__24955534_0_javax.faces.ViewState"</span> id=<span class="code-quote">"Pluto_myPortlet_1__24955534_0_:javax.faces.ViewState:0"</span> value=<span class="code-quote">"-7034168008597714894:-3199096175767081201"</span> autocomplete=<span class="code-quote">"off"</span>&gt;</span>
<span class="code-tag">&lt;/form&gt;</span>
<span class="code-tag">&lt;/div&gt;</span>
</pre>
</div></div>
<p>The requirements need to be updated so that they enable portlet compatibility by replacing the <tt>&lt;div&gt;...&lt;/div&gt;</tt> section associated with the UIViewRoot rather than the <tt>&lt;body&gt;...&lt;/body&gt;</tt> section of the document when running in a portlet environment.</p><p>Portlets</p>JAVASERVERFACES_SPEC_PUBLIC-1421Modify the requirements of the jsf.ajax.response JavaScript documentation to enable portlet compatibilityImprovementMajorOpenUnresolvedUnassignedNeil GriffinFri, 10 Jun 2016 22:43:43 +0000Tue, 14 Jun 2016 19:02:48 +00002.22.3Ajax/JavaScript02<p>This seems to be <a href="http://grepcode.com/file/repo1.maven.org/maven2/org.glassfish/javax.faces/2.2.0/com/sun/faces/context/PartialViewContextImpl.java#PartialViewContextImpl.renderAll%28javax.faces.context.FacesContext%2Cjavax.faces.component.UIViewRoot%29" class="external-link" rel="nofollow">already implemented</a> since Mojarra 2.2.0. It only uses <tt>getClientId()</tt> instead of <tt>getContainerClientId()</tt>, but it shouldn't make any difference on the root component.</p>
<p>In other words, when <tt>render="@all"</tt> is used, it will already not anymore write out <tt>&lt;update id="javax.faces.ViewRoot"&gt;</tt>. It's only left unspecified in the spec. All in all, when also considering issue 790, I think it makes sense to propose the following change to be as transparent as possible (i.e. do not mention Portlet specifics and do not change JavaScript):</p>
<blockquote>
<p>Update <a href="http://docs.oracle.com/javaee/7/api/javax/faces/context/PartialViewContext.html#processPartial-javax.faces.event.PhaseId-" class="external-link" rel="nofollow"><tt>PartialViewContext#processPartial()</tt></a> to specify that during render response phase, when the <tt>&lt;update&gt;</tt> for <tt>javax.faces.ViewRoot</tt> will be written, and the <tt>UIViewRoot</tt> is an instance of <tt>UINamingContainer</tt>, then write <tt>id</tt> attribute with value of <tt>UIViewRoot#getContainerClientId()</tt>, else write value of <a href="http://docs.oracle.com/javaee/7/api/javax/faces/context/PartialResponseWriter.html#RENDER_ALL_MARKER" class="external-link" rel="nofollow"><tt>PartialResponseWriter#RENDER_ALL_MARKER</tt></a>.</p></blockquote>
<p>This way, we can also remove the <tt>Util.isPortletRequest()</tt> check from the current implementation.</p>
<p>The <tt>javax.faces.ViewBody</tt> is nowhere considered in JSF API nor in Mojarra impl, it's only mentioned in JS API. It's internally treated exactly the same way as <tt>javax.faces.ViewRoot</tt>. I guess it's a leftover, so we can ignore it for now. Perhaps it should better be removed from JS API, but that's a different issue.</p><p>@balusc: Please forgive, but I simply didn't remember that I had created <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1069" title="Portlet incompatibilities with jsf.js" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1069"><del>JAVASERVERFACES_SPEC_PUBLIC-1069</del></a> back in 2012. This resulted in the following paragraph being modified in section 2.2.6.1 of the Spec titled "Render Response Partial Processing":</p>
<blockquote><p>If isRenderAll() returns true and this is not a portlet request, call startUpdate(PartialResponseWriter.RENDER_ALL_MARKER) on the PartialResponseWriter. For each child of the UIViewRoot, call encodeAll(). Call endUpdate() on the PartialResponseWriter. Render the state using the algorithm described below in Section “Partial State Rendering”, call endDocument() on the PartialResponseWriter and return. If isRenderAll() returns true and this <b>is</b> a portlet request, treat this as a case where isRenderAll() returned false, but use the UIViewRoot itself as the one and only component from which the tree visit must start.</p></blockquote>
<p>Thanks for pointing out the code in com.sun.faces.context.PartialViewContextImpl &#8211; This functionality was introduced into Mojarra 2.2 by Manfred via commit <a href="https://github.com/javaserverfaces/mojarra/commit/e25abcae751d4684040d49039bb62488ff7208ef" class="external-link" rel="nofollow">e25abcae</a> and <a href="https://github.com/javaserverfaces/mojarra/commit/0e42795e69e107b7062b69fa8516034b0c95e801" class="external-link" rel="nofollow">0e42795e</a>.</p>
<p>I did some research and the reason why <a href="https://github.com/liferay/liferay-faces-bridge-impl/blob/master/bridge-impl/src/main/java/com/liferay/faces/bridge/renderkit/bridge/internal/ResponseWriterBridgeImpl.java#L222" class="external-link" rel="nofollow">ResponseWriterBridgeImpl.java</a> still contains a workaround is because the <a href="https://svn.apache.org/repos/asf/myfaces/core/tags/myfaces-core-module-2.2.9/impl/src/main/java/org/apache/myfaces/context/servlet/PartialViewContextImpl.java" class="external-link" rel="nofollow">MyFaces PartialViewContextImpl. processRenderAll(UIViewRoot,PartialResponseWriter) method</a> does not yet implement the requirements outlined in section 2.2.6.1 of the Spec. I just created <a href="https://issues.apache.org/jira/browse/MYFACES-4053" class="external-link" rel="nofollow">MYFACES-4053</a> and will try to contribute a fix soon.</p>
<p><b>I really like your idea</b> of using language like "if UIViewRoot is an instance of UINamingContainer" rather than "if this is a portlet request" and would recommend that section 2.2.6.1 of the Spec be updated.</p>
<p>Finally, I agree with your assessment regarding <tt>javax.faces.ViewBody</tt>. After studying the JavaScript documentation more today, I also noticed <tt>javax.faces.ViewHead</tt>. I think that the Bridge Spec can simply state that bridge implementations should ignore these features since they are inherently incompatible with portlet environments.</p>Rank0|i0joen:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-1238] Enhance component referencing / findComponenthttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1238
javaserverfaces-spec-public<p>Currently component referencing with the JSF API is very limited.<br/>
Keywords can currently only be used with f:ajax and not for e.g. outputLabel "for" attribute.<br/>
Also keywords cant be combined and we dont even have many keywords.</p>
<p>For PrimeFaces, i created a small modular API to enhance the search alogorithm as you can read here:<br/>
<a href="http://blog.primefaces.org/?p=2740" class="external-link" rel="nofollow">http://blog.primefaces.org/?p=2740</a></p>
<p>Noteable features are:</p>
<ul class="alternate" type="square">
<li>keywords can be used for all components</li>
<li>combinable keywords like @composite:@parent or @form:myId</li>
<li>currently a (limited) pluggable framework to allow new keywords for endusers</li>
</ul>
<p>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.<br/>
Maybe something like "ComponentExpressionResolver".</p>
<p>If its somehow possible, i would like to help to create and finalyze the API.</p>
<p>Sorry for Issue 1237 - please close it.</p>JAVASERVERFACES_SPEC_PUBLIC-1238Enhance component referencing / findComponentNew FeatureMajorOpenUnresolvedUnassignedtandraschkoFri, 15 Nov 2013 18:11:30 +0000Mon, 20 Jun 2016 12:05:51 +0000Ajax/JavaScriptComponents/Renderers67<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>This area is very sensitive to performance problems.</p><p>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 "@".<br/>
Some expressions are faster, some are slower but the overall performance is very good and i did a lot of optimization for it.</p>
<p>Would great to see it in the next API release. BootsFaces implemented a similiar API.<br/>
As i said, i would take care of it and would contribute my ideas to the JSF API.</p><p>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.</p><p>This is one of the things I'd like to see in JSF 2.3 as well. Community contribution is very welcome.</p>Rank0|i005wv:Rank (Obsolete)959[JAVASERVERFACES_SPEC_PUBLIC-1426] @NaviationMode on the action methodhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1426
javaserverfaces-spec-public<p>If you handle navigation via a action-method return value, there are actually 2 possible navigation modes:</p>
<p>Forward:<br/>
return "index.xhtml"</p>
<p>Redirect:<br/>
return "index.xhtml?faces-redirect=true"</p>
<p>As "faces-redirect=true" is not a modern way to handle the mode, i would introduce something like this:</p>
<p>@NavigationMode(NavigationMode.Mode.REDIRECT)<br/>
public String login() </p>
{
return "index.xhtml";
}JAVASERVERFACES_SPEC_PUBLIC-1426@NaviationMode on the action methodImprovementMajorOpenUnresolvedUnassignedtandraschkoWed, 29 Jun 2016 11:39:15 +0000Wed, 29 Jun 2016 11:39:15 +00002.2Navigation01Rank0|i0jopr:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-1369] <protected-views><url-pattern> does not work as per Servlet 12.1 and is compared against JSF view ID instead of request URLhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1369
javaserverfaces-spec-public<p>Trigger: <a href="http://stackoverflow.com/q/29104597/157882" class="external-link" rel="nofollow">http://stackoverflow.com/q/29104597/157882</a></p>
<p>Problem 1: &lt;protected-views&gt;&lt;url-pattern&gt; does not work as per Servlet 12.1. It does merely an exact match and wildcards are not supported. It's also nowhere in JSF 2.2 specification documented how exactly this should be used in faces-config.xml.</p>
<p>Problem 2: During generating action URL, &lt;protected-views&gt;&lt;url-pattern&gt; is not compared against final action URL, but against JSF view ID, causing failures when there's a virtual URL based mapping like &#42;.faces or /faces/*.</p>
<p>Another non-related problem 3: the current approach is inefficient. It's for every single view checked on a per-request basis while it could easily be (lazily) checked and stored in view/facelet metadata on an application wide basis.</p>JAVASERVERFACES_SPEC_PUBLIC-1369<protected-views><url-pattern> does not work as per Servlet 12.1 and is compared against JSF view ID instead of request URLBugMajorOpenUnresolvedUnassignedbaluscWed, 18 Mar 2015 08:57:01 +0000Wed, 26 Aug 2015 15:10:24 +00002.212Rank0|i0gn9z:Rank (Obsolete)97084[JAVASERVERFACES_SPEC_PUBLIC-1416] Introduce annotation/class based configurationhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1416
javaserverfaces-spec-public<p>In JSF 2.2 the way to automatically enable JSF in a project is having either a class on the class path annotated with one of the JSF native annotations, or having a <tt>/WEB-INF/faces-config.xml</tt> file present.</p>
<p>With the world moving to CDI, the JSF native annotations (specifically <tt>@MangedBean</tt>) are not so much used anymore. This way to enable JSF is therefor not longer practical.</p>
<p>A <tt>faces-config.xml</tt> file is still a simple way, if it wasn't for the fact that officially it can't be just an empty file like CDI's <tt>bean.xml</tt>. Looking up the right schema for trivial applications is a bit of a hassle.</p>
<p>Therefor it might be worth looking into a JSF annotation that is specifically intended to enable JSF.</p>
<p>E.g.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
@FacesConfig
<span class="code-keyword">public</span> class JustAClass {
}
</pre>
</div></div>
<p>In the simplest version this will just activate JSF like <tt>@ManagedBean</tt> does, but without the side effect of also creating a (potentially unused) managed bean.</p>
<p>One step further may be to add some configuration options, potentially the annotation variant of the various web.xml settings.</p>
<p>E.g.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
@FacesConfig(
stateSavingMethod = <span class="code-quote">"server"</span>
)
</pre>
</div></div>
<p>Or a new option, to indicate the JSF version:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
@FacesConfig(
version = <span class="code-quote">"2.3"</span> <span class="code-comment">// enables all JSF 2.3 features
</span>)
</pre>
</div></div>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
@FacesConfig(
version = <span class="code-quote">"2.2"</span> <span class="code-comment">// behaves as much as possible as 2.2 did
</span>)
</pre>
</div></div>
<p>This mechanism can also be used for simple configuration sets. Namely, if the class on which <tt>@FacesConfig</tt> appears is a CDI bean, CDI alternatives can be used to switch configuration.</p>
<p>Going another step further the class could (optionally) implement methods that return config programmatically.</p>
<p>E.g.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
@FacesConfig
<span class="code-keyword">public</span> class MyConfig {
<span class="code-keyword">public</span> <span class="code-object">String</span> getStateSavingMethod() {
<span class="code-keyword">return</span> ... ? <span class="code-quote">"server"</span> : <span class="code-quote">"client"</span>;
}
}
</pre>
</div></div>
<p>But that really is an optional proposal. The main proposal is just having the annotation.</p>
<p>Note that the class on which the annotation is put doesn't matter that much; it only has to be on the class path such that the runtime code (e.g. via a CDI extension) can pick it up.</p>JAVASERVERFACES_SPEC_PUBLIC-1416Introduce annotation/class based configurationNew FeatureMajorOpenUnresolvedarjan tijmsarjan tijmsFri, 15 Apr 2016 09:03:05 +0000Fri, 15 Apr 2016 09:03:05 +00002.32.3Configuration/Bootstrapping11Rank0|i0jmvr:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-1400] ui:repeat does not resolve (nested structures of) map.valueshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1400
javaserverfaces-spec-public<p>Given a class containing a map</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
Map&lt;<span class="code-object">Integer</span>, AccountNode&gt; _children = <span class="code-keyword">new</span> LinkedHashMap&lt;&gt;();
</pre>
</div></div>
<p><tt>AccountNode</tt> wraps an object <tt>Account</tt> inside, which can be obtained by a getter.</p>
<p>The values of this map might be accessed by this getter</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> Collection&lt;AccountNode&gt; getChildren() {
<span class="code-keyword">return</span> _children.values();
}
</pre>
</div></div>
<p>This should be used from facelets like in following code</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;c:forEach items =<span class="code-quote">"#{treeController.rootNode.children}"</span> var=<span class="code-quote">"child"</span>&gt;</span>
<span class="code-tag">&lt;p&gt;</span>#{child.account.name}<span class="code-tag">&lt;/p&gt;</span>
<span class="code-tag">&lt;/c:forEach&gt;</span>
</pre>
</div></div>
<p>Using the tag handler "forEach", everything is fine. <br/>
But moving on to the component "repeat", the app fails.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;ui:repeat value =<span class="code-quote">"#{treeController.rootNode.children}"</span> var=<span class="code-quote">"child"</span>&gt;</span>
<span class="code-tag">&lt;p&gt;</span>#{child.account.name}<span class="code-tag">&lt;/p&gt;</span>
<span class="code-tag">&lt;/ui:repeat&gt;</span>
</pre>
</div></div>
<p>"/index.xhtml: The class 'java.util.LinkedHashMap$LinkedValues' does not have the property 'account'."</p>
<p>Workaround: If the values get copied into another list, "repeat" works fine too.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-keyword">public</span> Collection&lt;AccountNode&gt; getChildren() {
<span class="code-keyword">return</span> <span class="code-keyword">new</span> ArrayList&lt;AccountNode&gt;(_children.values());
}
</pre>
</div></div><p>Checked with Windows 6.1 "7" and 6.3 "8.1"<br/>
and Java 1.8 "8"</p>JAVASERVERFACES_SPEC_PUBLIC-1400ui:repeat does not resolve (nested structures of) map.valuesBugMajorOpenUnresolvedUnassignedmuellermiWed, 19 Aug 2015 20:44:36 +0000Sun, 23 Oct 2016 15:48:50 +00002.2Components/Renderers01<p>Will this become obsolete due to the extended collection / map handling?</p>Rank0|i0jewv:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-1184] Support using JSON for component updates instead of XMLhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1184
javaserverfaces-spec-public<p>One of the primary complaints about JSF is speed. We have paid a lot<br/>
of attention to optimizing server-side state over the past few years,<br/>
but we can also optimize the processing on the client. When a<br/>
component is updated via Ajax, currently we render the entire<br/>
component, even if only one property has changed. It would be much<br/>
more efficient if we sent only the changed properties via JSON and let<br/>
the client-side representation of the component update itself<br/>
accordingly. I have implemented a limited version of this for one of<br/>
my clients, and Ajax updates are noticeably faster. Updating the spec<br/>
to support this would not be a major change (because components would<br/>
opt-in to this feature), but it would have a dramatic affect on<br/>
client-side Ajax updates.</p>
<p>Initial EG thread: <a href="https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/105" class="external-link" rel="nofollow">https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/105</a></p>
<p>I will post a more formal proposal later.</p>JAVASERVERFACES_SPEC_PUBLIC-1184Support using JSON for component updates instead of XMLImprovementMajorOpenUnresolvedUnassignedkito75Mon, 22 Apr 2013 13:05:11 +0000Wed, 13 Aug 2014 19:23:27 +0000Ajax/JavaScriptComponents/Renderers43<p>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?</p><p>Arjun, you're exactly right.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i005lj:Rank (Obsolete)908[JAVASERVERFACES_SPEC_PUBLIC-1368] Static EL Resolution Doesn't Workhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1368
javaserverfaces-spec-public<p>EL 3.0 static field resolution on imported classes does not currently work in any JSF implementation, and it seems to come down to a spec issue. For example, the expression </p>
<p>&lt;h:outputText value="# </p>
{Boolean.TRUE}
<p>" /&gt;</p>
<p>Prints out nothing, while it should print "true". Since ScopedAttributeELResolver must be the last resolver in the chain, modifying that resolver to resolve classes (via the importhandler, for example) allows these expressions to be resolved properly.</p>
<p>That fix was implemented by the Tomcat project here: <a href="https://bz.apache.org/bugzilla/show_bug.cgi?id=57141" class="external-link" rel="nofollow">https://bz.apache.org/bugzilla/show_bug.cgi?id=57141</a><br/>
Related Mojarra issue: <a href="https://java.net/jira/browse/JAVASERVERFACES-3362" class="external-link" rel="nofollow">https://java.net/jira/browse/JAVASERVERFACES-3362</a><br/>
Related UEL issue: <a href="https://java.net/jira/browse/UEL-40" class="external-link" rel="nofollow">https://java.net/jira/browse/UEL-40</a></p>JAVASERVERFACES_SPEC_PUBLIC-1368Static EL Resolution Doesn't WorkBugMajorOpenUnresolvedUnassignedwtlucyTue, 28 Apr 2015 14:28:48 +0000Tue, 28 Apr 2015 14:28:48 +00002.2EL11Rank0|i0gwqn:Rank (Obsolete)98617[JAVASERVERFACES_SPEC_PUBLIC-638] Ajax Back Button Supporthttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-638
javaserverfaces-spec-public<p>Many modern Ajax frameworks support back button actions.</p>
<p>JSF should as well.</p>
<p>This probably means both browser history manipulation and state restoration. <br/>
Could be pretty hard to do, but really important for being seen as a real Ajax<br/>
solution.</p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-638Ajax Back Button SupportNew FeatureMajorOpenUnresolvedUnassigneddriscollThu, 24 Sep 2009 12:14:12 +0000Tue, 12 Aug 2014 18:49:44 +00002.0Ajax/JavaScript63<p>Also, see here for a newly proposed standard by Google:</p>
<p><a href="http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html" class="external-link" rel="nofollow">http://googlewebmastercentral.blogspot.com/2009/10/proposal-for-making-ajax-crawlable.html</a></p><p>Prepare to delete api subcomponent</p><p>unscheduled</p><p>frame</p><p>These are targeted at 2.1.</p><p>triage</p><p>On 5 May 2010, at the JAX conference, this feature was requested, but in a slightly different guise. The <br/>
requestor wanted something like</p>
<p>&lt;h:backButton ...&gt; with an optional "number of views to go back" attribute.</p><p>rogerk</p><p>triage</p><p>triage</p><p>Ok Ajax back button support is tricky at best. I will investigate the following days into this issue. I know html5 will provide an official api and there are hacks which enable it via hashtags on the url. (the hashtag hacks also enable bookmarking for ajax)</p>
<p>I personally think in step 1 we should aim for the standardized html5 way of doing things and then aim lower with the hasthags which open another can of worms.</p><p><a href="https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history" class="external-link" rel="nofollow">https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history</a></p>
<p>is interesting information regarding this.</p><p>Ok I was able to enable back button support with some html 5 see following link<br/>
<a href="https://gist.github.com/1993051" class="external-link" rel="nofollow">https://gist.github.com/1993051</a></p>
<p>A detailed blog will follow. The problem i see is, that there are several approaches.<br/>
a) The simplest is to go for the pure html5 way. Then you have to snapshot the page and restore it upon a proper back button event.</p>
<p>b) The probably easiest one is, to enable the same by adding a html5 storage simulation and back button simulation to the page (and use hashtash for the back button simulation). This should be doable, or by simply storing the page shots in a javascript map.</p>
<p>c) The third one would be to enable something else via hashes in the url, that would need some server side patching additionally.</p>
<p>I will try to prototype approach b) tomorrow.</p>
<p><a href="https://gist.github.com/2000091" class="external-link" rel="nofollow">https://gist.github.com/2000091</a> here is the same prototype for html4 browsers.</p>
<p>The problem i see here with both methods is, they are purely clientside, and rely on the state history to recover the correct state.<br/>
So they </p>
<p>a) need some kind of notification how deep the state history is to prevent states which result in an error.</p>
<p>b) it is still unclear on how to deal with embedded scripts in the page and onload handlers which rely on component initialisation.</p>
<p>We probably have to add a callback event which the component systems can hook in to reintialize their stuff, or we simply execute all embedded scripts even with the danger of getting sideffects.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>DependencyJAVASERVERFACES_SPEC_PUBLIC-718JAVASERVERFACES_SPEC_PUBLIC-542Issuezilla Id638.0Rank0|i002vz:Rank (Obsolete)469Status Whiteboard<p>cat2 frame size_large importance_large draft</p>[JAVASERVERFACES_SPEC_PUBLIC-1419] Support new Html5 events like oninputhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1419
javaserverfaces-spec-public<p>e.g. HtmlInputText#EVENT_NAMES should contain oninput</p>
<p>We should actually check the list, all JSF components and add missing events:<br/>
<a href="http://www.tutorialspoint.com/html5/html5_events.htm" class="external-link" rel="nofollow">http://www.tutorialspoint.com/html5/html5_events.htm</a></p>
<p>IMO it's important for 2.3 to be more compliant with HTML5.</p>JAVASERVERFACES_SPEC_PUBLIC-1419Support new Html5 events like oninputNew FeatureMajorOpenUnresolvedUnassignedtandraschkoTue, 7 Jun 2016 10:12:53 +0000Sat, 30 Jul 2016 15:18:07 +00002.2Components/Renderers44<p>I"d suggest this one <a href="http://www.w3schools.com/tags/ref_eventattributes.asp" class="external-link" rel="nofollow">http://www.w3schools.com/tags/ref_eventattributes.asp</a></p>Rank0|i0jocf:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-217] Add a styleClass attribute to h:columnhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-217
javaserverfaces-spec-public<p>Add a styleClass attribute to h:column and relegate the columnClasses attribute<br/>
from h:dataTable to a purpose similar to what rowClasses does: cycle through<br/>
each item in the list repeatedly (the use case being the ability to apply<br/>
alternating styles, like differently-colored even and odd columns, without<br/>
requiring knowledge of the number of columns).</p>
<p>There should be nothing in the &lt;h:dataTable&gt; attribute list that is dependant<br/>
upon the actual number of columns appearing inside of the table. All<br/>
information related to specific columns should be associated with each column's<br/>
corresponding &lt;h:column&gt; entity. Indeed, this is already the case with the sole<br/>
exception of the columnClasses attribute.</p>
<p>This is related to: <a href="https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=426" class="external-link" rel="nofollow">https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=426</a></p><p>Operating System: All<br/>
Platform: All</p>JAVASERVERFACES_SPEC_PUBLIC-217Add a styleClass attribute to h:columnImprovementMajorOpenUnresolvedUnassigneddmlloydThu, 12 Oct 2006 15:33:45 +0000Fri, 4 Nov 2016 22:18:29 +00001.2Components/Renderers104<p>Incidentally, adding a styleClass attribute to the &lt;h:column&gt; tag can be done<br/>
without breaking backwards compatibility. Changing the behavior of<br/>
columnClasses will be somewhat more difficult. You may want to create a new<br/>
attribute called columnCycleClasses or something - or maybe not, given that the<br/>
1.2 JSF implementation implemented the columnClasses attribute incorrectly<br/>
(until just now), and said implementation happens to concur with my proposed<br/>
behavior.</p><p>Created an attachment (id=110)<br/>
Implement a styleClass property on &lt;h:column&gt;</p><p>I've asked the Mojarra team if they think this is ok to do.</p><p>Move to unscheduled target milestone</p><p>Prepare to delete api subcomponent</p><p>Update milestone and component.</p><p>In addition to the styleClass attribute, the style attribute should be added as <br/>
well. Assigning a style to a column is something that simply cannot be done with <br/>
the current &lt;h:dataTable&gt;/&lt;h:column&gt; component pair.</p><p>cat2</p><p>renderkit</p><p>These are targeted at 2.1.</p><p>triage</p><p>rogerk</p><p>triage</p><p>triage</p><p>hi! </p>
<p>just like to push this up since I already came across this issue a few times.<br/>
Today a colleague of mine had this again: he looked at &lt;h:column&gt; where he found the footerClass and headerClass attributes, but no styleClass for h:column. The columnClasses attribute in &lt;h:dataTable&gt; is not a full replacement since you cannot do data based css assignment.</p>
<p>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.<br/>
Of course you can do this with &lt;span&gt; but it is not really intuitive why there is no styleClass on the &lt;td&gt; at all.</p><p>+1 (also for Dan's style-attribute)</p>
<p>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.<br/>
so:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;h:dataTable <span class="code-keyword">var</span>=<span class="code-quote">"item"</span> value=<span class="code-quote">"..."</span>
rowStyle=<span class="code-quote">"#{item.important ? 'font-weight: bold' : ''}"</span>
rowStyleClass='trilternate#{component.rowIndex%3}'&gt;
</pre>
</div></div>
<p>Not so important: Introduce varstatus as for ui:repeat / c:forEach, even if you can calculate index/last/first/etc. from #</p>
{component}
<p>, I think most template authors will not know that + it gets ugly.</p>
<p>Eventually!!! document, that 'global'-column-styling should be done with &lt;f:facet name="colgroups"&gt;, if possible (less to render).</p><p>+1 </p>
<p>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 <a href="http://docs.jboss.org/richfaces/4.3.X/4.3.0.Final/vdldoc/" class="external-link" rel="nofollow">http://docs.jboss.org/richfaces/4.3.X/4.3.0.Final/vdldoc/</a></p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Major, because of higher vote count</p><p>With Richfaces sun-setting in June 2016 it would be very nice to pick this feature up in 2.3</p>
<p>This is really the only feature that keeps me from using the native JSF datatable</p><p>I've gone ahead and implemented styleClass on column and rowClass on datatable.</p>
<p>This aligns with now Richfaces named the properties.</p>
<p><a href="https://github.com/codylerum/mojarra/tree/JAVASERVERFACES_SPEC_PUBLIC-217" class="external-link" rel="nofollow">https://github.com/codylerum/mojarra/tree/JAVASERVERFACES_SPEC_PUBLIC-217</a></p>
<p>I'm going to need some review and pointers to know if I've updated the docs correctly.</p>DependencyJAVASERVERFACES_SPEC_PUBLIC-627Issuezilla Id217.0Rank0|i002cf:Rank (Obsolete)381Status Whiteboard<p>cat2 renderkitdoc size_small importance_small</p>[JAVASERVERFACES_SPEC_PUBLIC-1348] Better define usage of Flash, specifically with respect to response buffer sizehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1348
javaserverfaces-spec-publicJAVASERVERFACES_SPEC_PUBLIC-1348Better define usage of Flash, specifically with respect to response buffer sizeImprovementMajorOpenUnresolvedUnassignedManfred RiemMon, 12 Jan 2015 20:15:37 +0000Wed, 30 Nov 2016 15:13:23 +000001<p>As this is not adding any value beyond clarification I am lowering its priority to Major</p>DependencyJAVASERVERFACES_SPEC_PUBLIC-1320Rank0|i0gca7:Rank (Obsolete)95303[JAVASERVERFACES_SPEC_PUBLIC-1433] Add Option to expand meaning of required="true" for UIInputhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1433
javaserverfaces-spec-public<p> When you say required="true" on a UIInput component, the validation<br/>
must always take place, even when there is no entry in the request<br/>
corresponding to that component.</p>
<p>Background:</p>
<p>Consider this login page:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;h:inputText id=“userName” required=“<span class="code-keyword">true</span>”
value=“#{backingBean.userName}” /&gt;
&lt;h:inputSecret id=“password” required=“<span class="code-keyword">true</span>”
validator=“#{backingBean.validatePassword}”
value=“#{backingBean.password}” /&gt;
&lt;h:commandButton action=“/views/authenticatedUser.xhtml” /&gt;
</pre>
</div></div>
<p>If the postback is hacked such that the userName is present as a request<br/>
parameter, but the password is not, the password validator would be<br/>
bypassed. If the password validator is used as the entry point to<br/>
perform authentication, this could cause problems.</p>
<p>Now, it must be said that using a validator on a password field as the<br/>
entry point to perform authentication is a particular design choice.<br/>
This design choice runs a bit counter to the stated purpose of the<br/>
validation system, which is to ensure syntactic and some level of<br/>
semantic validity of fields. There are other ways to perform<br/>
authentication that do not rely on the validation system for this<br/>
purpose.</p>
<p>Nonetheless, we would like to accomodate this use case. </p>
<p>Proposal:</p>
<p>For JSF 2.3, I propose the following.</p>
<p>Modify PDF section 3.5.4 to read:</p>
<blockquote>
<p>Spec&gt; *The render-independent property required is a shorthand for the<br/>
Spec&gt; function of a required validator. If the value of this property is<br/>
Spec&gt; true, **there is an entry in the request payload corresponding to<br/>
Spec&gt; this component**, and the component has no value, the component is<br/>
Spec&gt; marked invalid and a message is added to the FacesContext<br/>
Spec&gt; instance.*</p></blockquote>
<p>Modify the JavaDoc for UIInput.validate(). Modify the first bullet<br/>
point to read:</p>
<blockquote>
<p>Spec&gt; Retrieve the submitted value with getSubmittedValue(). If this<br/>
Spec&gt; returns null, and the<br/>
Spec&gt; javax.faces.component.UIInput.ALWAYS_PERFORM_VALIDATION_WHEN_REQUIRED_IS_TRUE<br/>
Spec&gt; context-parameter is set to true (ignoring case), examine the<br/>
Spec&gt; value of the "required" property. If the value of "required" is<br/>
Spec&gt; true, continue as below. If the value of "required" is false, the<br/>
Spec&gt; "required" attribute is not set, exit without further<br/>
Spec&gt; processing. If the context-paramater is not set, or is set to<br/>
Spec&gt; false (ignoring case) exit without further processing. (This<br/>
Spec&gt; indicates that no value was submitted for this component.)</p></blockquote>
<p>With these changes, the javadoc for UIInput.validateValue() can remain<br/>
unchanged.</p>
JAVASERVERFACES_SPEC_PUBLIC-1433Add Option to expand meaning of required="true" for UIInputNew FeatureMajorOpenUnresolvedEd BurnsEd BurnsTue, 29 Nov 2016 17:08:43 +0000Wed, 7 Dec 2016 04:15:37 +00002.3Components/Renderers01Rank0|i0jrif:Rank (Obsolete)9223372036854775807[JAVASERVERFACES_SPEC_PUBLIC-916] Support for generic types in Composite Component's attribute @type and @method-signaturehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-916
javaserverfaces-spec-public<p>Currently there is no way to infer type of cc:attribute's type, since you can only use fully qualified name of class like:</p>
<p>&lt;composite:interface&gt;<br/>
&lt;composite:attribute name="value" type="java.util.List"/&gt;<br/>
&lt;/composite:interface&gt;</p>
<p>This is not sufficient for tools to implement features like validation and code completion of EL expressions inside &lt;cc:implementation&gt;</p>
<p>Allow definition of generic types in @type and @method-signature to improve composite component's usability:</p>
<p>&lt;composite:interface&gt;<br/>
&lt;composite:attribute name="value" type="java.util.List&lt;my.package.Person&gt;"/&gt;<br/>
&lt;/composite:interface&gt;</p>JAVASERVERFACES_SPEC_PUBLIC-916Support for generic types in Composite Component's attribute @type and @method-signatureImprovementMinorOpenUnresolvedUnassignedlfrycThu, 9 Dec 2010 12:58:23 +0000Tue, 12 Aug 2014 19:53:47 +0000Facelets/VDL76<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i00413:Rank (Obsolete)654Status Whiteboard<p>size_large importance_medium</p>Tags3_1-exclude[JAVASERVERFACES_SPEC_PUBLIC-919] Allow inheritance for TagException and TagAttributeExceptionhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-919
javaserverfaces-spec-public<p>javax.faces.view.facelets.TagAttributeException and javax.faces.view.facelets.TagException are final classes. If JSF implementation want provide "smarter" version of those classes, it is not possible now.</p>
<ul class="alternate" type="square">
<li>remove final modifier</li>
<li>add getTag() and getTagAttribute() methods</li>
<li>modify spec: change sentences like " rethrow the exception as a TagException" to "rethrow the exception as a INSTANCE OF TagException"</li>
</ul>
JAVASERVERFACES_SPEC_PUBLIC-919Allow inheritance for TagException and TagAttributeExceptionImprovementMinorOpenUnresolvedUnassignedMartin KočíMon, 17 Jan 2011 03:36:18 +0000Fri, 1 Aug 2014 17:09:41 +0000Facelets/VDL02<p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting to priority Minor</p>Rank0|i004br:Rank (Obsolete)702Status Whiteboard<p>size_small importance_small</p>Tags3_1-exclude[JAVASERVERFACES_SPEC_PUBLIC-918] InitialStateEvent is not fired from the ComponentHandlerhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-918
javaserverfaces-spec-public<p>Hi</p>
<p>I'm working on Mojarra 2.0.3 and no InitialStateEvent is fired.</p>
<p>In the spec it says:</p>
<blockquote>
<p>The specification defines the following ComponentSystemEvent classes, all in package javax.faces.event.</p>
<ul>
<li>InitialStateEvent must be published with a direct call to UIComponent.processEvent(), during the<br/>
apply() method of the class javax.faces.webapp.vdl.ComponentHandler. Please see the javadocs for<br/>
the normative specification.</li>
</ul>
</blockquote>
<p>I'm looking for a clean way (listener over extending the component handler) to interact with the initial state of the created component. I would like to have access to the Tag attributes specified on the tag on that event as well.</p>
<p>I want to use this event to validate required attributes and inject additional properties on the component like:</p>
<ul>
<li>injecting a semantic id based on the value or action attribute</li>
<li>injecting the value attribute by using a specified id a the key in a resource bundle</li>
<li>etc.</li>
</ul>
JAVASERVERFACES_SPEC_PUBLIC-918InitialStateEvent is not fired from the ComponentHandlerNew FeatureMinorOpenUnresolvedUnassignedciliusWed, 5 Jan 2011 07:20:18 +0000Tue, 12 Aug 2014 19:54:02 +00002.0Facelets/VDL01<p>triage</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i004bj:Rank (Obsolete)701Status Whiteboard<p>size_medium importance_large</p>Tags3_1-exclude[JAVASERVERFACES_SPEC_PUBLIC-1045] Flash created in ExceptionHandler not workhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1045
javaserverfaces-spec-public<p>Original issue created on</p>
<p><a href="https://issues.apache.org/jira/browse/MYFACES-3358" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MYFACES-3358</a></p>
<p>by Keith Wong:</p>
<p>------------------------------------------------</p>
<p>I have a custom ExceptionHandler for handling ViewExpiredException as occurred in session timeout or application restart. I have to tell the user in the redirected page the reason for being redirected. Here is the handler:</p>
<p> public void handle() throws FacesException {<br/>
for (Iterator&lt;ExceptionQueuedEvent&gt; i=getUnhandledExceptionQueuedEvents().iterator(); i.hasNext(); ) {<br/>
ExceptionQueuedEventContext context = i.next().getContext();<br/>
Throwable t = context.getException();<br/>
if (t instanceof ViewExpiredException) {<br/>
FacesContext ctx = FacesContext.getCurrentInstance();<br/>
ViewExpiredException vee = (ViewExpiredException)t;<br/>
try </p>
{
ctx.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_ERROR, vee.getClass().getName(), vee.getMessage()));
Flash flash = ctx.getExternalContext().getFlash();
flash.put("expiredViewId", vee.getViewId());
flash.setKeepMessages(true);
ctx.getApplication().getNavigationHandler().handleNavigation(ctx, null, "/login?faces-redirect=true");
ctx.renderResponse();
}
<p> finally </p>
{
i.remove();
}
<p> }<br/>
}<br/>
super.handle();<br/>
}</p>
<p>In the login.xhtml, it has #</p>
{flash.expiredViewId}
<p> and &lt;f:messages&gt; but both are empty when displayed. </p>
<p>------------------------------------------------</p>
<p>Unfortunately the code proposed does not work by spec. See JSF 2.0 section 12.3. In few words, the problem is handle() is called after the current phase is processed, so flash scope has been already processed. Maybe in this case it is possible to call Flash.doPostPhaseActions(FacesContext) and doPrePhaseActions(FacesContext) to wrap flash operations inside handle() method, but we can't do anything from MyFaces point of view. Maybe it should be possible to do something on the spec, because it sounds like a common use case. </p>
<p>Really it is curious people trying to create custom ExceptionHandler implementations using JSF usually finds problems like this one and others, for example if you try to create a jsf page to handle jsf errors. It is worth to take a look to this API, to see if in practice requires some fixes to make it more practical. </p>JAVASERVERFACES_SPEC_PUBLIC-1045Flash created in ExceptionHandler not workBugMinorOpenUnresolvedUnassignedlu4242Thu, 27 Oct 2011 19:36:24 +0000Fri, 1 Aug 2014 17:49:13 +00002.02.1Lifecycle13<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Minor</p>Rank0|i004qv:Rank (Obsolete)770[JAVASERVERFACES_SPEC_PUBLIC-1040] Outstanding PhaseListener.afterPhase() calls for the current phase should be made before any requested redirect actually takes placehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1040
javaserverfaces-spec-public<p>See email thread beginning at <a href="http://java.net/projects/javaserverfaces/lists/dev/archive/2011-10/message/5" class="external-link" rel="nofollow">http://java.net/projects/javaserverfaces/lists/dev/archive/2011-10/message/5</a> .</p>JAVASERVERFACES_SPEC_PUBLIC-1040Outstanding PhaseListener.afterPhase() calls for the current phase should be made before any requested redirect actually takes placeImprovementMinorOpenUnresolvedUnassignedMatt BensonWed, 19 Oct 2011 21:54:43 +0000Tue, 12 Aug 2014 20:12:43 +00002.1LifecycleNavigation01<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i004bb:Rank (Obsolete)700[JAVASERVERFACES_SPEC_PUBLIC-1048] Provide mechanism for component to declare scoped variableshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1048
javaserverfaces-spec-public<p>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.</p>
<p>E.g.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml"><span class="code-tag">&lt;ui:repeat value=<span class="code-quote">"#{someBean.items}"</span> var=<span class="code-quote">"item"</span>&gt;</span>
<span class="code-tag">&lt;h:outputText value=<span class="code-quote">"#{item.name}"</span> /&gt;</span>
<span class="code-tag">&lt;/ui:repeat&gt;</span>
</pre>
</div></div>
<p>In this example the <tt>ui:repeat</tt> component selects a value from <tt>someBean.items</tt> and makes that available under the name <tt>item</tt>.</p>
<p>In order for tools to validate the correctness of the <tt>item.name</tt> 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.</p>
<p>I would like to propose adding a mechanism to JSF for components to declare they make (scoped) variables available.</p>
<p>E.g.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">@FacesComponent(<span class="code-quote">"components.CustomComponent"</span>)
<span class="code-keyword">public</span> class CustomComponent <span class="code-keyword">extends</span> UIComponentBase {
@Attribute
@VariableName(type=<span class="code-quote">"#{attributes.value[0]}"</span> scope=<span class="code-quote">"component"</span>)
<span class="code-keyword">private</span> <span class="code-object">String</span> <span class="code-keyword">var</span>;
@Attribute
@VariableSource
<span class="code-keyword">private</span> List&lt;Item&gt; value;
</pre>
</div></div>
<p>In this example, the component declares that the <tt>var</tt> 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 <tt>value</tt> attribute.</p>
<p>Additionally, it should also be possible that a fixed type is specified, e.g:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">@FacesComponent(<span class="code-quote">"components.CustomComponent"</span>)
<span class="code-keyword">public</span> class CustomComponent <span class="code-keyword">extends</span> UIComponentBase {
@Attribute
@VariableName(type=<span class="code-quote">"com.example.SomeType"</span> scope=<span class="code-quote">"component"</span>)
<span class="code-keyword">private</span> <span class="code-object">String</span> <span class="code-keyword">var</span>;
</pre>
</div></div>
<p>Of course the given syntax is just a quick sketch of the idea. Maybe <tt>@VariableExportName</tt> is a better name, <tt>@VariableSource</tt> might not be needed, etc.</p>
<p>This issue is somewhat related to <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-594" title="Add tagName attribute to @FacesComponent annotation" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-594"><del>JAVASERVERFACES_SPEC_PUBLIC-594</del></a></p>
JAVASERVERFACES_SPEC_PUBLIC-1048Provide mechanism for component to declare scoped variablesNew FeatureMinorOpenUnresolvedUnassignedarjan tijmsTue, 1 Nov 2011 22:16:05 +0000Tue, 12 Aug 2014 20:13:40 +0000Components/Renderers22<p>Issue <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-984" title="Component context management" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-984"><del>JAVASERVERFACES_SPEC_PUBLIC-984</del></a> might also be somewhat related to this. </p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i004rj:Rank (Obsolete)773[JAVASERVERFACES_SPEC_PUBLIC-1024] Allow parents of forms as render targets of ajax requestshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1024
javaserverfaces-spec-public<p>Currently it is not possible to use parents of forms as render targets in &lt;f:ajax/&gt; 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.</p>
<p>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.</p>
<p>However the JSDoc for jsf.ajax.response states the following for ViewState updates:</p>
<blockquote>
<p>If an update element is found in the response with the identifier javax.faces.ViewState:</p>
<p>&lt;update id="javax.faces.ViewState"&gt;<br/>
&lt;![CDATA<span class="error">&#91;...&#93;</span>]&gt;<br/>
&lt;/update&gt;</p>
<p>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.</p></blockquote>
<p>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.</p>
<p>For more information see the corresponding Mojarra bug report:</p>
<p><a href="http://java.net/jira/browse/JAVASERVERFACES-1718" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES-1718</a></p>JAVASERVERFACES_SPEC_PUBLIC-1024Allow parents of forms as render targets of ajax requestsBugMinorOpenUnresolvedUnassignedfrederickkaempferMon, 11 Jul 2011 16:00:33 +0000Tue, 12 Aug 2014 20:12:01 +00002.1Ajax/JavaScriptComponents/Renderers1075 hours5 hours<p>"Judging from the JSDoc the request method's execute parameter "</p>
<p>This was meant to be the render parameter.</p><p>This issue is related to (or even included in) <a href="http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790</a>. 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.</p><p>Simple test case from duplicate issue <a href="https://java.net/jira/browse/JAVASERVERFACES-1788" title="View state input disappears when form is rendered by AJAX" class="issue-link" data-issue-key="JAVASERVERFACES-1788"><del>JAVASERVERFACES-1788</del></a>:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
<span class="code-tag">&lt;h:panelGroup layout=<span class="code-quote">"block"</span> id=<span class="code-quote">"group"</span>&gt;</span>
<span class="code-tag">&lt;h:form&gt;</span>
<span class="code-tag">&lt;h:commandLink value=<span class="code-quote">"Link A"</span>&gt;</span>
<span class="code-tag">&lt;f:ajax /&gt;</span>
<span class="code-tag">&lt;/h:commandLink&gt;</span>
<span class="code-tag">&lt;/h:form&gt;</span>
<span class="code-tag">&lt;/h:panelGroup&gt;</span>
<span class="code-tag">&lt;h:form&gt;</span>
<span class="code-tag">&lt;h:commandLink value=<span class="code-quote">"Link B"</span>&gt;</span>
<span class="code-tag">&lt;f:ajax render=<span class="code-quote">":group"</span> /&gt;</span>
<span class="code-tag">&lt;/h:commandLink&gt;</span>
<span class="code-tag">&lt;/h:form&gt;</span>
</pre>
</div></div>
<ol>
<li>Press <tt>Link A</tt> - view state is submitted</li>
<li>Press <tt>Link B</tt>, then <tt>Link A</tt> - view state is not submitted anymore</li>
</ol>
<p>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).<br/>
I am trying to retrieve the javax.faces.ViewState using the id attribute in a Javascript which works.</p>
<p>But i still don't see the id attribute in the loaded page <br/>
&lt;input type="hidden" name="javax.faces.ViewState" value="!-14uywjgjai"&gt;</p>
<p>Could you please tell me if this is an issue with JSF 1.2 version as well? <br/>
Or once the page is rendered the id attribute associated with "javax.faces.ViewState" is not seen anymore.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i004af:Rank (Obsolete)696Tagsajaxfaceletsjavascript[JAVASERVERFACES_SPEC_PUBLIC-1033] BeanValidator "wrapping" functionality should be extended to any (e.g. custom) validator handled using the default ValidatorHandler (+ delegate)https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1033
javaserverfaces-spec-public<p>As an apparently incidental side-effect of the implementation of Bean Validation support, this functionality is available in Mojarra. It is not, however, explicitly required per the specification. Having the ability to wrap custom validator tags around multiple EditableValueHolders as is possible with f:validateBean will improve the consistency of validator handling in facelets.</p>JAVASERVERFACES_SPEC_PUBLIC-1033BeanValidator "wrapping" functionality should be extended to any (e.g. custom) validator handled using the default ValidatorHandler (+ delegate)ImprovementMinorOpenUnresolvedUnassignedMatt BensonTue, 16 Aug 2011 19:45:14 +0000Fri, 1 Aug 2014 17:46:16 +00002.1 Rev aFacelets/VDLValidation/Conversion03<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Minor</p>Rank0|i004av:Rank (Obsolete)698[JAVASERVERFACES_SPEC_PUBLIC-1034] disentangle ViewScope state handling from UIViewRoot.saveState()/restoreState() methods to better control ViewScope state handlinghttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1034
javaserverfaces-spec-public<p>With <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-787" title="Restore ViewScope before templates are processed with buildView" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-787"><del>JAVASERVERFACES_SPEC_PUBLIC-787</del></a> a new method restoreViewScopeState was added to UIViewRoot to allow restore ViewScope before buildView is called. But there is no matching saveViewScopeState method.</p>
<p>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[] </p>
{ null, stateMap }
<p>; I see element<span class="error">&#91;0&#93;</span> 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().</p>
<p>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. </p>JAVASERVERFACES_SPEC_PUBLIC-1034disentangle ViewScope state handling from UIViewRoot.saveState()/restoreState() methods to better control ViewScope state handlingSub-taskJAVASERVERFACES_SPEC_PUBLIC-787MinorOpenUnresolvedUnassignedHanspeter DuennenbergerTue, 16 Aug 2011 22:57:24 +0000Tue, 12 Aug 2014 20:12:29 +00002.2Components/Renderers33<p>Would this also help the much needed CDI implementation of @ViewScoped?</p><p>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.</p><p>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.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>DependencyJAVASERVERFACES_SPEC_PUBLIC-1087RelatedJAVASERVERFACES_SPEC_PUBLIC-787Rank0|i003qf:Rank (Obsolete)606[JAVASERVERFACES_SPEC_PUBLIC-1031] Support registration of ExceptionHandlerWrappers directly from faces-config.xml or @ExceptionHandlerWrapperhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1031
javaserverfaces-spec-public<p>It is currently painful to register exception handlers in JSF: see reference ( <a href="http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2?force=148" class="external-link" rel="nofollow">http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2?force=148</a> )</p>
<p>I think it should be possible to register ExceptionHandlerWrappers directly from faces-config.xml</p>
<p>&lt;exception-handler-wrapper&gt;com.example.ExceptionHandlerWrapperImpl&lt;/exception-handler-wrapper&gt;</p>
<p>This would eliminate the painful 2-class registration process we have now.</p>JAVASERVERFACES_SPEC_PUBLIC-1031Support registration of ExceptionHandlerWrappers directly from faces-config.xml or @ExceptionHandlerWrapperImprovementMinorOpenUnresolvedUnassignedlincolnbaxterTue, 9 Aug 2011 20:55:38 +0000Fri, 1 Aug 2014 17:45:00 +00002.1 Rev aConfiguration/Bootstrapping133 days3 days<p>I like this idea but I must state that a concrete proposal, attached to this issue, would increase the chance of this making it into the spec from &lt; 10% to &gt; 80%. </p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Minor</p>Rank0|i004hb:Rank (Obsolete)727[JAVASERVERFACES_SPEC_PUBLIC-1074] Add ViewDeclarationLanguageWrapper to JSF APIhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1074
javaserverfaces-spec-public<p>While developing a portlet bridge, I found it necessary to have a ViewDeclarationLanguageWrapper. I've attached it do this issue with the hopes that it will be included JSF 2.2. Thanks!</p>JAVASERVERFACES_SPEC_PUBLIC-1074Add ViewDeclarationLanguageWrapper to JSF APIImprovementMinorOpenUnresolvedUnassignedNeil GriffinTue, 21 Feb 2012 21:38:38 +0000Tue, 12 Aug 2014 20:14:52 +00002.02.112<p>The javax.faces.view. ViewDeclarationLanguageWrapper class is present in the latest JSF 2.2 jsf-api artifact, so I think that this issue can be closed.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i004xj:Rank (Obsolete)800[JAVASERVERFACES_SPEC_PUBLIC-1073] Add file upload specific attributes to h:inputFile component taghttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1073
javaserverfaces-spec-public<p>This issue serves as a proposal for enhancing the new h:inputFile component tag with additional attributes.</p>
<p>The three attributes that I would like to propose are:</p>
<ul class="alternate" type="square">
<li>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.</li>
<li>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.</li>
<li>mimeTypes: Comma-delimited list of uploaded file mime types that are valid. If not specified, then all mime types are assumed to be valid.</li>
</ul>
JAVASERVERFACES_SPEC_PUBLIC-1073Add file upload specific attributes to h:inputFile component tagNew FeatureMinorOpenUnresolvedUnassignedNeil GriffinTue, 14 Feb 2012 20:53:44 +0000Fri, 29 Aug 2014 21:00:17 +00002.02.1Components/Renderers03<p>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:</p>
<p>&lt;h:inputFile&gt;<br/>
&lt;f:validateFile maxFileSize="1048576" mimeTypes="png,gif,jpg" /&gt;<br/>
&lt;/h:inputFile&gt;</p><p>I like that idea. Would definitly makes sense!</p><p>What will happen if a file of same name exists in upload location?<br/>
The web developer may hook into.</p>
<p>I propose to add an additional attribute as hint to create a default behavior if not hooked in.</p>
<p>overwrite=allow|deny|rename</p>
<p>rename will append some chars to the filename (e.g. a simple count) to make it unique</p><p>I <b>think</b> it is the case with every implementation of file upload that I have seen, that the file would be overwritten.</p><p>Hm, better to be a follower or on the cutting edge? Innovation lives from new ideas.<br/>
BTW, most file explorers, FTP uploads etc. offers options to prevent or allow overwrite or to keep both versions (rename).</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Minor</p><p>I recently implemented my idea with the new alloy:inputFile and alloy:validateFile tags in Liferay Faces. For more info, see the <a href="https://github.com/liferay/liferay-faces/blob/master/demos/showcase/showcase-webapp/src/main/webapp/component/alloy/inputfile/validation/inputFile.xhtml#L12" class="external-link" rel="nofollow">Showcase demo</a>.</p>Rank0|i004xb:Rank (Obsolete)799[JAVASERVERFACES_SPEC_PUBLIC-1070] Add ExternalContext#setFlash(Flash) methodhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1070
javaserverfaces-spec-public<p>Due to an incongruity between the JSF and Portlet lifecycles, I would like to propose adding the ExternalContext#setFlash(Flash) method to ExternalContext.</p>
<p>There is precedent for a method like this, for example ExternalContext#setRequest(Object) and ExternalContext#setResponse(Object):<br/>
<a href="http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#setRequest(java.lang.Object" class="external-link" rel="nofollow">http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#setRequest(java.lang.Object</a>)<br/>
<a href="http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#setResponse(java.lang.Object" class="external-link" rel="nofollow">http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/ExternalContext.html#setResponse(java.lang.Object</a>)</p>
<p>For more information and justification, please refer to these issues:<br/>
<a href="https://issues.apache.org/jira/browse/PORTLETBRIDGE-201" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/PORTLETBRIDGE-201</a><br/>
<a href="https://issues.apache.org/jira/browse/PORTLETBRIDGE-207" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/PORTLETBRIDGE-207</a></p>JAVASERVERFACES_SPEC_PUBLIC-1070Add ExternalContext#setFlash(Flash) methodImprovementMinorOpenUnresolvedUnassignedNeil GriffinMon, 13 Feb 2012 20:26:00 +0000Tue, 12 Aug 2014 20:14:41 +00002.02.101<p>Set fixVersion to 2.3.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>RelatedJAVASERVERFACES_SPEC_PUBLIC-1071Rank0|i004wn:Rank (Obsolete)796[JAVASERVERFACES_SPEC_PUBLIC-1086] h:outputLabel doesn't determine ID of inputs for components which wraps inputhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1086
javaserverfaces-spec-public<p><b>Sample:</b></p>
<p>The code in first snippet results in HTML markup below which is not valid. The <tt>for</tt> attribute of the label element must refer to a input element.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>xhtml</b></div><div class="codeContent panelContent">
<pre class="code-xml"><span class="code-tag">&lt;h:outputLabel value=<span class="code-quote">"Date"</span> for=<span class="code-quote">"date"</span> /&gt;</span>
<span class="code-tag">&lt;rich:calendar id=<span class="code-quote">"date"</span> .../&gt;</span>
</pre>
</div></div>
<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>html</b></div><div class="codeContent panelContent">
<pre class="code-xml"><span class="code-tag">&lt;label for=<span class="code-quote">"form:date"</span>&gt;</span>Date<span class="code-tag">&lt;/label&gt;</span>
<span class="code-tag">&lt;span id=<span class="code-quote">"form:date"</span>&gt;</span>
<span class="code-tag">&lt;span id=<span class="code-quote">"form:datePopup"</span>&gt;</span>
<span class="code-tag">&lt;input id=<span class="code-quote">"form:dateInputDate"</span> name=<span class="code-quote">"form:dateInputDate"</span> /&gt;</span>
...
</pre>
</div></div>
<hr />
<p><b>Issue description:</b></p>
<p>Some input components (like <tt>rich:calendar</tt> in the sample bellow) generates a HTML markup which does not have <tt>input</tt> element in the root of the component, but the input is wrapped instead.</p>
<p>On the other side, <tt>h:outputLabel</tt> expects that the input has ID=<tt>component.getClientId()</tt>, which refers to the root of the component (it is <tt>span</tt> element in case of <tt>rich:calendar</tt>).</p>
<p>If we would change the ID of the <tt>span</tt> and use the <tt>component.getClientId()</tt> for the input, the it would break AJAX mechanism, which expects that the root of the component (here it is the <tt>span</tt>) bears ID=<tt>component.getClientId()</tt>.</p>
<hr />
<p><b>Proposal:</b></p>
<p>This issue could be fixed by specifying new method <tt>component.getInputClientId()</tt> for all input components - it could default to <tt>clientId</tt>, but each component could define how to address its input when overridden.</p>JAVASERVERFACES_SPEC_PUBLIC-1086h:outputLabel doesn't determine ID of inputs for components which wraps inputImprovementMinorOpenUnresolvedUnassignedlfrycFri, 30 Mar 2012 13:55:12 +0000Wed, 13 Aug 2014 18:28:19 +00002.1Components/Renderers02<div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>JSF RI 2.1.5, LabelRenderer:85</b></div><div class="codeContent panelContent">
<pre class="code-java">
<span class="code-object">String</span> forClientId = <span class="code-keyword">null</span>;
<span class="code-object">String</span> forValue = (<span class="code-object">String</span>) component.getAttributes().get(<span class="code-quote">"<span class="code-keyword">for</span>"</span>);
<span class="code-keyword">if</span> (forValue != <span class="code-keyword">null</span>) {
forValue = augmentIdReference(forValue, component);
UIComponent forComponent = getForComponent(context, forValue, component);
<span class="code-keyword">if</span> (forComponent == <span class="code-keyword">null</span>) {
<span class="code-comment">// it could that the component hasn't been created yet. So
</span> <span class="code-comment">// construct the clientId <span class="code-keyword">for</span> component.
</span> forClientId = getForComponentClientId(component, context,
forValue);
} <span class="code-keyword">else</span> {
forClientId = forComponent.getClientId(context);
}
}
</pre>
</div></div><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i00507:Rank (Obsolete)812[JAVASERVERFACES_SPEC_PUBLIC-1128] All form controls sent as request params when @none specified for execute.https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1128
javaserverfaces-spec-public<p>A clarification is needed to state that no form controls should be sent if the 'execute' option is @none.<br/>
Currently, all form controls are encoded and sent regardless.</p>JAVASERVERFACES_SPEC_PUBLIC-1128All form controls sent as request params when @none specified for execute.BugMinorOpenUnresolvedUnassignedrogerkWed, 1 Aug 2012 14:31:48 +0000Wed, 13 Aug 2014 19:05:48 +00002.1Ajax/JavaScript12<p>See: <a href="http://java.net/jira/browse/JAVASERVERFACES-2480" class="external-link" rel="nofollow">http://java.net/jira/browse/JAVASERVERFACES-2480</a></p><p>In ajax call, all render parameters (@this, ids, @none) should be respected. The current implementation sends the whole form. All input controlls are evaluated(validated, and model are updated). </p><p>Isn't this perhaps a special case of <a href="https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1098" title="f:ajax exeucte always sends all the fields of the wrapping form" class="issue-link" data-issue-key="JAVASERVERFACES_SPEC_PUBLIC-1098">JAVASERVERFACES_SPEC_PUBLIC-1098</a>?</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i0059b:Rank (Obsolete)853[JAVASERVERFACES_SPEC_PUBLIC-1117] "value" attribute for "h:command*" components should be marked as "required"https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1117
javaserverfaces-spec-public<p>Take a look at &lt;<a href="https://maven.java.net/service/local/repositories/releases/archive/javax/faces/javax.faces-api/2.0/javax.faces-api-2.0-javadoc.jar/!/vdldocs/facelets/h/commandButton.html" class="external-link" rel="nofollow">https://maven.java.net/service/local/repositories/releases/archive/javax/faces/javax.faces-api/2.0/javax.faces-api-2.0-javadoc.jar/!/vdldocs/facelets/h/commandButton.html</a>&gt;, and also the same page for commandLink. In both cases, the "value" attribute is listed as not required. The spec must be modified to show that it <b>is</b> required.</p>JAVASERVERFACES_SPEC_PUBLIC-1117"value" attribute for "h:command*" components should be marked as "required"BugMinorOpenUnresolvedUnassignedEd BurnsMon, 18 Jun 2012 21:54:32 +0000Fri, 1 Aug 2014 18:04:56 +00001.11.22.02.12.2Components/Renderers021 hour1 hour<p>I can understand for commandButton (since it's always generate a &lt;input&gt; tag and not a &lt;button&gt; tag, which is sad btw), but why also for commandLink? You should be authorize to nest an outputText (or several of them), or graphicImage, or any combo of those, inside a commandLink. No need for "value" in that case since those components would be the value inside the &lt;a&gt; tag generated.</p><p>Also, the browsers will render a default text, dependent on the browser and language of the user, if the value attribute is left out. This is most likely not the desired result, but there is already a fallback in case this attribute is left out.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Minor</p>Rank0|i0056v:Rank (Obsolete)842[JAVASERVERFACES_SPEC_PUBLIC-1123] Add an ability to specify charset of the properties file while using ResourceBundlehttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1123
javaserverfaces-spec-publicJAVASERVERFACES_SPEC_PUBLIC-1123Add an ability to specify charset of the properties file while using ResourceBundleImprovementMinorOpenUnresolvedUnassignedManfred RiemTue, 17 Jul 2012 17:18:06 +0000Fri, 1 Aug 2014 19:45:38 +000002<p>As mentioned in #<a href="https://java.net/jira/browse/JAVASERVERFACES-2462" title="Add an ability to specify charset of the properties file while using ResourceBundle" class="issue-link" data-issue-key="JAVASERVERFACES-2462"><del>JAVASERVERFACES-2462</del></a> I think you can do the following:</p>
<ol>
<li>Add an extra Control constructor with the charset parameter.</li>
<li>This constructor would set the charset property of Control class/object.</li>
<li>The default constructor of Control would set charset to "ISO-8859-1".</li>
<li>The charset would be used in ResourceBundle.Control#newBundle (as mentioned in #<a href="https://java.net/jira/browse/JAVASERVERFACES-2462" title="Add an ability to specify charset of the properties file while using ResourceBundle" class="issue-link" data-issue-key="JAVASERVERFACES-2462"><del>JAVASERVERFACES-2462</del></a>).</li>
</ol>
<p>This I belive would make it as backward compatible as possible.</p><p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Minor</p>RelatedJAVASERVERFACES-2462Rank0|i00587:Rank (Obsolete)848[JAVASERVERFACES_SPEC_PUBLIC-1122] RFE: make HtmlInputHidden a ClientBehaviorHolder so that it can be used as the target for AJAX change events in composite componentshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1122
javaserverfaces-spec-public<p>I created a JSF 2 composite component that is rendered almost entirely using JavaScript. When the user makes a selection, it sets the value of a hidden input field. I am able to use an HtmlInputHidden as the cc:valueHolder of my composite component and it works as designed.</p>
<p>When I try to add an AJAX change listener, I get the following error:</p>
<p>&lt;cc:clientBehavior name="change" event="change" targets="#</p>
{cc.clientId}
<p>:selectedRoom"/&gt;</p>
<p>"Unable to attach behavior to non-ClientBehaviorHolder parent:javax.faces.component.html.HtmlInputHidden@150ef67"</p>
<p>When I change the h:inputHidden to an h:inputText, then the AJAX functionality works as designed. Please update JSF so that an inputHidden can be used in this way as well.</p>JAVASERVERFACES_SPEC_PUBLIC-1122RFE: make HtmlInputHidden a ClientBehaviorHolder so that it can be used as the target for AJAX change events in composite componentsImprovementMinorOpenUnresolvedUnassignedrdelaplanteThu, 12 Jul 2012 15:58:38 +0000Wed, 13 Aug 2014 19:04:48 +0000Ajax/JavaScript02<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>Rank0|i0057z:Rank (Obsolete)847[JAVASERVERFACES_SPEC_PUBLIC-1121] FaceletCache: some caching is incorrectly done in DefaultFaceletFactoryhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1121
javaserverfaces-spec-public<p>LU&gt; I realized the FaceletCache API has a flaw.</p>
<p>LU&gt; The original code from facelets 1.1.x has logic to cache the<br/>
LU&gt; "conversion" between logical identifiers to find a specific facelet and<br/>
LU&gt; its related URL.</p>
<p>LU&gt; So inside DefaultFaceletFactory there is a map like this:</p>
<p>LU&gt; private Map&lt;String, URL&gt; _relativeLocations;</p>
<p>LU&gt; Checking the code deeper, I notice this cache store also the values<br/>
LU&gt; returned by the ResourceResolver.</p>
<p>LU&gt; Now suppose a scenario where you have a custom FaceletCache<br/>
LU&gt; implementation, and by some coincidence there is some mechanism to load/<br/>
LU&gt; unload some facelets in some way. Once a facelet is called,<br/>
LU&gt; relativeLocations will hold the same key/value pair, so if a facelet is<br/>
LU&gt; unloaded and then another one is loaded and it has the same association,<br/>
LU&gt; it will fail to find the new one.</p>
<p>LU&gt; A realistic scenario that will be part of JSF 2.2 spec is if you have<br/>
LU&gt; a jar with some composite components and facelet files. For two<br/>
LU&gt; different skins, there will be facelets with the same "logical<br/>
LU&gt; identifiers", but with different URL. This issue prevents change the<br/>
LU&gt; skins on the fly, because you can't clean that map.</p>
<p>LU&gt; Who should hold that map? It should be hold by FaceletCache, not by<br/>
LU&gt; FaceletFactory, because FaceletCache is the responsible to load/unload<br/>
LU&gt; and hold facelets into memory.</p>
JAVASERVERFACES_SPEC_PUBLIC-1121FaceletCache: some caching is incorrectly done in DefaultFaceletFactoryBugMinorOpenUnresolvedUnassignedEd BurnsThu, 12 Jul 2012 14:32:57 +0000Fri, 1 Aug 2014 19:44:53 +00002.2 Sprint 13Facelets/VDL021 day1 day<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Set priority to Minor</p>DependencyJAVASERVERFACES_SPEC_PUBLIC-777Rank0|i0057r:Rank (Obsolete)846[JAVASERVERFACES_SPEC_PUBLIC-1133] <h:outputStylesheet/> Rendering Should Occur Last in the Rendering Processhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1133
javaserverfaces-spec-public<p>The problem here is the ordering of the CSS files. A &lt;h:outputStyleSheet/&gt; tag in the &lt;h:head&gt; tag is rendered first. Subsequent inclusion of a component on the page then renders it's required CSS resources, after your CSS link. As such you are not overriding the values.</p>
<p>The fix/workaround here is to include your custom &lt;h:outputStyleSheet&gt; CSS reference at the end of the page, after you've referenced all other components. This way your style sheet will be included last, and CSS values will cascade as you expect. You are merely influencing the order in which they are included by the JSF component. renderers.</p>
<p>The ordering here is the important part. I understand that CSS resource links will still be rendered into the html &lt;head&gt;, but the behavior is not what you would expect. I am expecting that the local stylesheet will override the default skinning on the components. This behavior would be modified by any local attributes such as style and styleClass on the component.</p>JAVASERVERFACES_SPEC_PUBLIC-1133<h:outputStylesheet/> Rendering Should Occur Last in the Rendering ProcessImprovementMinorOpenUnresolvedUnassignedjyearyWed, 5 Sep 2012 14:51:43 +0000Fri, 1 Aug 2014 19:47:54 +00002.02.1Components/Renderers13<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Minor</p>Rank0|i005af:Rank (Obsolete)858[JAVASERVERFACES_SPEC_PUBLIC-1106] Content of ui.taglib.xml https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1106
javaserverfaces-spec-public<p>In one project I tried to display content of facelet-taglib descriptions from the file <tt>ui.taglib.xml</tt> as HTML.<br/>
In a browser (Mozilla) the content of </p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">
&lt;div class=<span class="code-quote">"syntax"</span>&gt;&lt;div class=<span class="code-quote">"html4strict"</span>
style=<span class="code-quote">"font-family: monospace;"</span>&gt;&lt;ol&gt;&lt;li class=<span class="code-quote">"li1"</span>&gt;&lt;div
class=<span class="code-quote">"de1"</span>&gt;&lt;span class=<span class="code-quote">"sc0"</span>&gt;&amp;amp;lt;!DOCTYPE html PUBLIC
&amp;amp;quot;-<span class="code-comment">//W3C//DTD XHTML 1.0 Transitional//EN&amp;amp;quot;&lt;/div&gt;&lt;/li&gt;</span>
</pre>
</div></div>
<p>is not displayed correctly.</p>
<p>I do not know why </p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">&amp;amp</pre>
</div></div>
<p> is used before every HTML entity. I think that this can be replaced by </p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-java">&amp;</pre>
</div></div>
<p> to display it correctly.</p>JAVASERVERFACES_SPEC_PUBLIC-1106Content of ui.taglib.xml TaskMinorOpenUnresolvedUnassignedpetrpodzimekWed, 30 May 2012 16:11:37 +0000Sun, 24 May 2015 14:12:20 +00002.02.102<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>DependencyJAVASERVERFACES_SPEC_PUBLIC-1107Rank0|i0054n:Rank (Obsolete)832[JAVASERVERFACES_SPEC_PUBLIC-1105] f:convertDateTime within h:dataTable/h:colum is not resolving EL expression referencing dataTable varhttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1105
javaserverfaces-spec-public<p>I have a scenario where every row in a data table has a date and also a different timeZone spec.<br/>
I wanted to use f:convertDateTime and set the timeZone parameter from the var element to format it. But this is not working as expected. Instead of the per-row timezone it is allways using the default timeZone to format the output since the EL expression for timeZone resolvs to null for all rows.</p>
<p>Attached is a minimal sample class and jsf file to demonstrate the issue. The expected output would be the time for 3 different timezones. But instead all 3 rows are rendered in the default TZ.</p>
<p>There are several workarounds for this but handling it like this would be the preffered one.</p>
<p>Thanks</p><p>JBoss AS 7<br/>
Tomcat 7</p>JAVASERVERFACES_SPEC_PUBLIC-1105f:convertDateTime within h:dataTable/h:colum is not resolving EL expression referencing dataTable varBugMinorOpenUnresolvedUnassignedsunf1reTue, 29 May 2012 13:42:20 +0000Fri, 1 Aug 2014 18:01:29 +000013<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Minor</p>RelatedJAVASERVERFACES-2430Rank0|i0054f:Rank (Obsolete)831TagscolumconvertDateTimedataTableexpression[JAVASERVERFACES_SPEC_PUBLIC-1104] Can't use expression for validator attributeshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1104
javaserverfaces-spec-public<p>Attaching a test case that shows a problem when using an expression for an attribute in a validator. We have markup that looks like this:</p>
<p> &lt;h:inputText id="ajaxMy"<br/>
value="#</p>
{testBean.myNumber}
<p>"&gt;<br/>
&lt;f:validateLongRange minimum="1"<br/>
maximum="#</p>
{testBean.maxValue}
<p>"/&gt;<br/>
&lt;f:ajax execute="@this"<br/>
render="@form"/&gt;<br/>
&lt;/h:inputText&gt;</p>
<p>When the value of the maximum attribute is modified via Ajax from another input field, the value of the bean is properly set but the validator doesn't resolve appear to resolve the expression at the right time and the result is that validation occurs against the "old" values.</p>JAVASERVERFACES_SPEC_PUBLIC-1104Can't use expression for validator attributesBugMinorOpenUnresolvedUnassigneddmsinotteThu, 24 May 2012 20:01:25 +0000Wed, 13 Aug 2014 18:29:54 +000013<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p>RelatedJAVASERVERFACES-2417Rank0|i00547:Rank (Obsolete)830Tagsajaxelvalidator[JAVASERVERFACES_SPEC_PUBLIC-1115] How does JSF handle children when they are not JSF components?https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1115
javaserverfaces-spec-public<p>I've tryed to find in the spec how a JSF component should handle its children if those are HTML tags or plain text instead of JSF components but I couldn't really find anything. So please, if I've miss it, just indicate me the chapter number.</p>
<p>So I've make some tests and it appears that Mojarra is always wrapping those kind of child inside a UIInstructions (which is implementation specific). Shouldn't a standard way should be specify to let people know how to handle with non JSF content inside a JSF component? So every JSF implementation use the same mechanism.</p>
<p>In the same topic, I'm fine when plain text is nested inside a UIInstructions, but a bit sad when several HTML tags are nested inside only one UIInstructions. Why? Because I can no longer easily use both JSF components and HTML tags at the same time. For example, let's say I have a dropdown menu that will wrap each of its child inside a &lt;li&gt; tag when rendered.</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml"><span class="code-tag">&lt;x:dropdownMenu&gt;</span>
<span class="code-tag">&lt;h:link outcome=<span class="code-quote">"/index"</span> value=<span class="code-quote">"Home"</span>/&gt;</span>
<span class="code-tag">&lt;h:link outcome=<span class="code-quote">"/admin"</span> value=<span class="code-quote">"Admin"</span>/&gt;</span>
<span class="code-tag">&lt;/x:dropdownMenu&gt;</span>
</pre>
</div></div>
<p>Should generated, by iterating over the children, something like:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml"><span class="code-tag">&lt;ul class=<span class="code-quote">"dropdown"</span>&gt;</span>
<span class="code-tag">&lt;li&gt;</span><span class="code-tag">&lt;a href=<span class="code-quote">"you.context.path/index.jsf"</span>&gt;</span>Home<span class="code-tag">&lt;/a&gt;</span><span class="code-tag">&lt;/li&gt;</span>
<span class="code-tag">&lt;li&gt;</span><span class="code-tag">&lt;a href=<span class="code-quote">"you.context.path/admin.jsf"</span>&gt;</span>Home<span class="code-tag">&lt;/a&gt;</span><span class="code-tag">&lt;/li&gt;</span>
<span class="code-tag">&lt;/ul&gt;</span>
</pre>
</div></div>
<p>But what if I use HTML tags directly now?</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml"><span class="code-tag">&lt;x:dropdownMenu&gt;</span>
<span class="code-tag">&lt;h:link outcome=<span class="code-quote">"/index"</span> value=<span class="code-quote">"Home"</span>/&gt;</span>
<span class="code-tag">&lt;h:link outcome=<span class="code-quote">"/admin"</span> value=<span class="code-quote">"Admin"</span>/&gt;</span>
<span class="code-tag">&lt;a href=<span class="code-quote">"help.externatsite.com"</span>&gt;</span>Help<span class="code-tag">&lt;/a&gt;</span>
<span class="code-tag">&lt;a href=<span class="code-quote">"partner.com"</span>&gt;</span>Our partner<span class="code-tag">&lt;/a&gt;</span>
<span class="code-tag">&lt;/x:dropdownMenu&gt;</span>
</pre>
</div></div>
<p>The generated code will be:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml"><span class="code-tag">&lt;ul class=<span class="code-quote">"dropdown"</span>&gt;</span>
<span class="code-tag">&lt;li&gt;</span><span class="code-tag">&lt;a href=<span class="code-quote">"you.context.path/index.jsf"</span>&gt;</span>Home<span class="code-tag">&lt;/a&gt;</span><span class="code-tag">&lt;/li&gt;</span>
<span class="code-tag">&lt;li&gt;</span><span class="code-tag">&lt;a href=<span class="code-quote">"you.context.path/admin.jsf"</span>&gt;</span>Home<span class="code-tag">&lt;/a&gt;</span><span class="code-tag">&lt;/li&gt;</span>
<span class="code-tag">&lt;li&gt;</span><span class="code-tag">&lt;a href=<span class="code-quote">"help.externatsite.com"</span>&gt;</span>Help<span class="code-tag">&lt;/a&gt;</span><span class="code-tag">&lt;a href=<span class="code-quote">"partner.com"</span>&gt;</span>Our partner<span class="code-tag">&lt;/a&gt;</span><span class="code-tag">&lt;/li&gt;</span>
<span class="code-tag">&lt;/ul&gt;</span>
</pre>
</div></div>
<p>Why is that? Because the two HTML tags are wrapped inside only one UIInstructions, so for the parent JSF component, both of them are only one child, and so they are both nested inside only one &lt;li&gt; tag.</p>
<p>You could say that I could have used &lt;h:outputLink&gt; but that's not the point here. There is lots of HTML tags that just don't have a JSF equivalent, even more since HTML5, and those tags are not greatly handle when it comes to tree hierarchy IMO. Since the goal of JSF is to generate HTML, it should be able to plug with HTML natively.</p>
<p>What about creating a JSF component like "UIHtmlTag" that would wrap any HTML tag found? So, in the previous example, instead of having only one UIInstructions, you would have two UIHtmlTag, far better for child rendering purpose. UIInstructions would be use for plain text only. What do you think?</p><p>Mojarra 2.1</p>JAVASERVERFACES_SPEC_PUBLIC-1115How does JSF handle children when they are not JSF components?New FeatureMinorOpenUnresolvedUnassignedpaul_dijouWed, 13 Jun 2012 10:52:45 +0000Fri, 1 Aug 2014 18:04:03 +000024<p>Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.</p><p>Setting priority to Minor</p>Rank0|i0056f:Rank (Obsolete)840Tagschildjsf2[JAVASERVERFACES_SPEC_PUBLIC-1022] Support base classes as source class for SystemEventshttps://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1022
javaserverfaces-spec-public<p>Originally created on <a href="https://issues.apache.org/jira/browse/MYFACES-3185" class="external-link" rel="nofollow">https://issues.apache.org/jira/browse/MYFACES-3185</a> by Carsten Dimmek:</p>
<p>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.</p>
<p>&lt;system-event-listener&gt;<br/>
&lt;system-event-listener-class&gt;view.RequiredValidationListener&lt;/system-event-listener-class&gt;<br/>
&lt;system-event-class&gt;javax.faces.event.PostValidateEvent&lt;/system-event-class&gt;<br/>
&lt;source-class&gt;javax.faces.component.html.HtmlInputText&lt;/source-class&gt;<br/>
&lt;/system-event-listener&gt;</p>
<p>&lt;system-event-listener&gt;<br/>
&lt;system-event-listener-class&gt;view.RequiredValidationListener&lt;/system-event-listener-class&gt;<br/>
&lt;system-event-class&gt;javax.faces.event.PostValidateEvent&lt;/system-event-class&gt;<br/>
&lt;source-class&gt;javax.faces.component.html.HtmlInputSecret&lt;/source-class&gt;<br/>
&lt;/system-event-listener&gt;</p>
<p>etc.</p>
<p>Supporting base classes would be great:</p>
<p>&lt;system-event-listener&gt;<br/>
&lt;system-event-listener-class&gt;view.RequiredValidationListener&lt;/system-event-listener-class&gt;<br/>
&lt;system-event-class&gt;javax.faces.event.PostValidateEvent&lt;/system-event-class&gt;<br/>
&lt;source-class&gt;javax.faces.component.UIInput&lt;/source-class&gt;<br/>
&lt;/system-event-listener&gt;</p>
<p>a fine-grained configuration would be still possible through SystemEventListener.isListenerForSource(Object source) </p>JAVASERVERFACES_SPEC_PUBLIC-1022Support base classes as source class for SystemEventsImprovementMinor