Currently the spec only mentions about using method binding expressions for the
"action" property. Even the tag library documentation lacks this additional
information. From the EG archives:

Date: Tue, 22 Jun 2004 13:04:00 -0700
Reply-To: Java Community Process JSR #127 Expert List [email protected]
Sender: Java Community Process JSR #127 Expert List [email protected]
From: Hans Bergsten [email protected]
Subject: [JSFv1.1 or 1.2] literal "action" attribute value
Comments: To: Java Community Process JSR #127 Expert List [email protected]
Content-Type: text/plain; charset=us-ascii; format=flowed

I think we all agree that it should be possible to specify a literal string
value, as an alternative to a method binding expression, for the "action"
attribute of <h:commandButton> and <h:commandButton> elements. Apparently, this
doesn't work in the 1.1 RI, but it's acknowledged as a bug by Ed in this thread:
<http://forum.java.sun.com/thread.jsp?forum=427&thread=528921> However, I can't
find any place where the spec PDF, JavaDocs, tag library docs or the renderer
docs explicitly define this requirement. In the 1.0 source, it was handled by
the tag handlers by creating a MethodBinding that simply returns the static
outcome value from its invoke() method, but the TLD for the <h:commandButton>
and <h:commandButton> actions doesn't describe this behavior. I'm also not sure
that it's the right place for this behavior. Shouldn't this behavior apply to
any ActionSource, and therefore be represented by an ActionSource property
(e.g., "staticOutcome") and used by the default ActionListener? Either way, we
need to clarify this behavior. Hans

Environment

Operating System: All
Platform: All

Affected Versions

[1.2]

On Thu, 18 Sep 2003 15:21:17 +0200, Stephane Bastian
[email protected] said:

SB> I developed a custom tag which represents a TreeNode. The tag is
SB> processed by JSF on each request. However, the TreeNode must be
SB> added to the list of child nodes of the parent TreeNode only the
SB> first time the page is requested. On subsequent requests, the
SB> TreeNode is already in the list of child nodes, so there is no need
SB> to add it again. Right now, the TreeNodeTag search for the node in
SB> the parent child nodes collection. If it's not already there, I add
SB> it to the list.

SB> Obviously, this works fine, but the logic really should be: "if it's
SB> not a postback, add it otherwise skip it". I know that it doesn't
SB> make much difference but I truly believe that JSF should provide
SB> this flag and not require developers to figure out if it's a
SB> postback or not. Furthermore, in my case, searching for each node
SB> in an expensive operation, especially when the only thing I need to
SB> know is .... "is it a postback"

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

The specification is silent on whether ValueBinding and MethodBinding should
implement equals() and hashCode() or not, and the current RI implementation does
not implement them, defaulting to the underlying logic in java.lang.Object. It
would be very useful for equals() to return true if the reference expressions
for two instances are the same (and hashCode() would have to be implemented as
well to maintain the contracts defined in java.lang.Object). These methods
could be implemented in the API classes (javax.faces.el.

{Method,Value}

Binding)
quite easily, so that all implementations could benefit from them.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

getClientId() is used for two purposes in JSF 1.0:

(1) For defining the client ID of a component.
(2) For defining the prefix used in building up a composite client ID.

This in turn causes two problems:

(1) When you're in the middle of iterating through rows in
a UIData, there is no good way to request the client ID of
the table itself.

(2) If anyone implemented Renderer.convertClientId() as anything
other than the identity function, they'd note that it gets
called more than it should; for instance, with;
<h:form id="foo">
<h:outputText id="bar"/>
</h:form>

... then when building up "foo:bar", convertClientId() gets
called on both "foo" and "foo:bar", so if convertClientId()
reversed the string, you'd get "rab:foo", not "rab:oof". I
think that's wrong - convertClientId() should get called once
on the fully assembled composite ID.

We should add a second method on UIComponent that is used
strictly for NamingContainer prefixing. This would also
enable us to turn off prefixing for specific instances of
UIForms. I don't think we can add the method to NamingContainer
itself, as its an interface, and we're stuck with it, right?

Environment

Operating System: All
Platform: All

Affected Versions

[1.2]

It's hard to spread the radio button into multiple cell in GridPanel. It would
be nice to have each radio button in the h:selectOneRadio to occupy 1 cell, and
set them in a way that they horrizontally expanding in a row, or vertically
expanding in a column.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Section 9.4 (The JSF Core Tag Library) defines a series of constraints for each
of these tags, however, the current spec has no language as to what the expected
behavior of the implemenation will be if any of the constraints are violated.

I believe this should be clarified for 1.2.

Environment

Operating System: All
Platform: All

Affected Versions

[1.2]

There is no support for colspan and rowspan in the GridPanel. This is very
important for layout of components. Currently, you can use the HTML table tag
to do so, but it lacks JSF capability such as you cannot have something like
"rendered = false".

Also, more control over row and column attributes. For example, adding
capability to set arbitrary attributes to any element of the generated HTML.

For example, I want to dyamically hide/show a Table's row. I need to set an ID
for this row, so that I can call a javascript to toggle this row's display CSS
properly on or off. There's no way of doing this right now with the GridPanel.

With the suggestion for attribute above, it should apply to all HTML components.
This is like a catch all thing so that JSF won't limit power users from doing
their things when the JSF spec does not address them.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Szenario:
A table is displayed with some entries. By selecting an entry you can edit the
values. To pass the selected bean to the form, the selected entry is stored in
the sessionMap. The form page contains a "Cancel-Button" which was using
"immidiate=true" to avoid calling beans setter-methods. After pressing "Cancel"
you will be navigated back to the table page. After selecting another entry the
old values will be displayed within the form.

Sorry for the complex szenario but I was not able to find a simple sample for
this issue.

The following testcase can be used for demonstration:

------- The table page (users.jsp) ----------
<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

http://java.sun.com/jsf/html" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

{selectedUser}

)

Press Cancel then select another entry!
</f:verbatim>
<h:form>
<h:panelGrid columns="2" cellpadding="5">
<h:outputText value="Login Name" />
<h:inputText value="#

{selectedUser.loginName}

"/>

<h:outputText value="First Name" />
<h:inputText value="#

{selectedUser.firstName}

"/>

<h:outputText value="Last Name" />
<h:inputText value="#

{selectedUser.lastName}

"/>

<h:outputText value=" " />
<h:panelGroup>
<h:commandButton action="#

{selectedUser.cancel}

" value="Cancel"
immediate="true"/>
<h:outputText value=" " />
<h:commandButton action="#

{selectedUser.update}

" value="OK"/>
</h:panelGroup>
</h:panelGrid>
</h:form>
</f:view>

------- The bean used for the form (User.java) ----------
package jsf.test;

import javax.faces.context.FacesContext;
import javax.faces.component.UIViewRoot;

public class User
{
private String loginName;
private String firstName;
private String lastName;

public User(String loginName, String firstName, String lastName)

{ System.out.println("User Bean created " + loginName); this.loginName = loginName; this.firstName = firstName; this.lastName = lastName; }

public String getLoginName()

{ System.out.println("get loginName " + loginName); return loginName; }

public void setLoginName(String loginName)

{ System.out.println("set loginName"); this.loginName = loginName; }

public String getFirstName()

{ System.out.println("get firstName " + firstName); return firstName; }

public void setFirstName(String firstName)

{ System.out.println("set firstName"); this.firstName = firstName; }

public String getLastName()

{ System.out.println("get lastName " + lastName); return lastName; }

public void setLastName(String lastName)

{ System.out.println("set lastName"); this.lastName = lastName; }

public String update()

{ System.out.println("user update: " + this); return "navToUsers"; }

public String cancel()

{ System.out.println("user cancel: " + this); return "navToUsers"; }

public String toString()

{ return firstName + " " + lastName; }

}

----- additional jsf-config entries ----------------------


Bean for TEST users.

users
jsf.test.Users
session

–
Wolfgang

Environment

Operating System: All
Platform: All

Affected Versions

[2.2 Sprint 8]

From forum:
http://forum.java.sun.com/thread.jsp?forum=427&thread=521863&tstart=0&trange=15

1. The commandLink's target attribute does not get rendered into the appropriate
javascript (according to the source of the RI 1.0, it seems to be forgotten).
[email protected] 2004-05-17
[email protected] 2004-05-17

Justification last updated 2004-06-12 00:16:14.0

This is crucial to having JSF work with Framesets.

Public Summary last updated 2004-06-10 21:16:40.0

1. The commandLink's target attribute does not get rendered into the appropriate
javascript (according to the source of the RI 1.0, it seems to be forgotten).
[email protected] 2004-05-17

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

Html Standard Renderkit Docs specify that layout="list" should render the
messages as an HTML list. MessageRenderer does not do this.

Environment

Operating System: All
Platform: All

Affected Versions

[1.2]

Currently, UISelectMany is defined to require that its value be an object array,
or a VB expression pointing at an object array. It would be a nice usability
addition to have this component treat a non-array object value as if it were a
single-element array. That way, for example, you could still use a literal
value attribute in the <h:selectManyXxx> tag to set the initially selected item
value (although you could only set one in this way).

[email protected] 2004-06-07
[email protected] 2004-06-07

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

On Thu, 29 Jul 2004 00:26:39 +0900, HANAI Shisei [email protected] said:

HS> Hi,
HS> required attribute seems no use for following HTML standard tags. I
HS> suggest to drop required attribute from them to prevent confusion.

HS> h:selectManyListbox
HS> h:selectManyMenu
HS> h:selectManyCheckbox
HS> h:selectBooleanCheckbox
HS> h:selectOneMenu
HS> h:selectBooleanCheckbox

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

The isReadOnly() method is not well specified for ValueBinding and
PropertyResolvers. In particular, what is its behavior for properties when the
base object is null? I'm certain that the correct behavior for
ValueBinding.isReadOnly() is to return "true". For PropertyResolver, I suspect
the best behavior is throwing a NullPointerException?

In either case, the RI currently throws a PropertyNotFoundException; I've
filed an issue against the RI for that problem.

This needs to be fed back into the EL alignment effort.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

JSF.3.2.2 talks about the client id generation system, but doesn't specify the
exact algorithm. We need to exactly specify this algorithm to ensure
inter-implementation interoperability in apps that have JavaScript that
references JSF components.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

The JSF 1.1 specification (Section 3.3.3) lists the by-type converter
registrations that a JSF implementation must support. This list does not
include the converters for BigDecimal and BigInteger, but the RI actually does
register these two converters. This behavior is very useful, so please update
the spec to include the requirement for these registrations, rather than
removing this functionality from the RI.

Environment

Operating System: All
Platform: All

Affected Versions

[1.2]

The <h:outputText> component does not include "dir" and "lang" attributes for
internationalization. These should be added (by including i18n-props.xml in the
concrete component, and i18n-attrs.xml in the renderer, and should be passed
through to the element that is created around the text (including forcing
creation of the span if necessary).

[email protected] 2004-05-28

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

This is a subset of the content from the email. The "easy stuff" has been done
without filing a bug.

On Fri, 21 Nov 2003 16:40:37 -0800, "HB" == Hans Bergsten
[email protected] wrote:

HB> At a minimum, we must state which sections are normative and which ones
HB> aren't. It seems as if only the Javadocs are normative at this point,
HB> while the rest of the spec serves more as an overview to put things in
HB> perspective. I think more parts of the spec need to be formal, normative
HB> descriptions of the behavior, for instance the interaction between all
HB> classes involved with state saving and rendering, the interaction
HB> between JSP tag handlers and components, etc. Maybe sequence diagrams
HB> would help?

HB> I also think it's important to use formal language in the text. Today,
HB> many descriptions say that this and that "will" or "is" happening. It
HB> would be better to follow the W3C conventions of using "MUST", "SHALL",
HB> "MAY" etc., described in RFC 2119, or at least a subset of these rules:

HB> <ftp://ftp.isi.edu/in-notes/rfc2119.txt>

HB> 2.2 Standard Request Processing Lifecycle Phases
HB> ------------------------------------------------
HB> All subsections say something along the lines of "the JSF implementation
HB> must perform these tasks". This must be clarified and instead say which
HB> class does what, for instance what the Lifecycle is responsible for vs.
HB> UIViewRoot and other classes. I think sequence diagrams may be useful
HB> here.

HB> 2.2.4 Update Model Values
HB> -------------------------
HB> "The actual model update for a particular component is done in
HB> the updateModel() method for that component."

HB> Shouldn't each phase have a similar clarification about what method
HB> the processXXX() method calls?

HB> 2.2.6 Render Response
HB> ---------------------
HB> Some of the general requirements don't give any guidance or guarantee
HB> to component writers. I suggest we cut the list and only describe the
HB> general requirements for the "rendered" (missing today) and the
HB> "rendersChildren" properties, and describe in detail what the JSP layer
HB> must do instead.

HB> The part about forward to a resource path equal to the view identifier
HB> is incorrect; the view ID paths needs to be adjusted first (e.g.,
HB> replace the extension).

[email protected] 2003-11-26
[email protected] 2003-11-26

HB> 2.3 Common Event Processing
HB> ---------------------------
HB> Clearly mark that this may change, e.g., the boolean return type
HB> may not be needed if we get rid of getPhaseId() on the listeners.
HB> Add this note to the Javadocs as well.

I plan on adding a section in the preface listing all the stuff that we
know will change.

HB> 2.4.2.2 Configure the Desired RenderKit
HB> ---------------------------------------
HB> "The UIViewRoot instance [...] will automatically be configured to
HB> utilize the default RenderKit [...]"

HB> Which class is responsible for this? The ViewHandler?

Currently it's the UIViewRoot ctor. I've put this in the bug.

[email protected] 2003-11-26

Evaluation last updated 2004-06-11 15:43:03.0

These make sense.
[email protected] 2003-11-26

Justification last updated 2004-06-12 00:16:14.0

absence will impede uptake

Justification By: ed.burns on 2004-01-09 Priority from 3 to 5
I agree we need to do this, but it has to be post 1.0. I sent mail to Mimi and
Craig about it last night.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

On Tue, 05 Aug 2003 10:47:26 +0200, Stephane Bastian
[email protected] said:

SB> For instance, in the case of a tree control, our component will
SB> generate the first level of nodes and fetch subsequent levels only
SB> "on-demand" (which means when the user clicks on the plus
SB> sign). Note that only part of the webpage will be refreshed to
SB> dynamically add the new item(s) to the tree control. We have pretty
SB> much everything in place to do that, excepted that right now, as you
SB> know, JSF processes every component in the tree. In our case, we
SB> simply need a way to tell JSF "don't process the whole tree, simply
SB> process this particular component". This way the response will only
SB> render one component, which is exactly what we need since we don't
SB> need to refresh the whole page.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

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

UIData use int data type. There is very long lists of items. F.g. very big
database table with billions or records. Of course, for such kind of data I
should use special datamodel which can get just shown items from DB. But all
methods of UIData return int values. Even getRowCount() can't return value
larger than int.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Consider adding to the spec what the Sun RI does when a ResourceBundle lookup
fails: return ?KEY? instead of throwing a MissingResourceException.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

Without writing custom components or using other technolog (such as JSTL), it's
hard to write raw data back to the web browser. For example, I want to populate
some java script arrays, or send back some javascript with different content
depending on the current state of the session.

Another example would be to pass data into javascript in the onclick event.
Currently, onclick event is supported (along with other javascript event).
However, you either have to enter static javascript, or populate the javascript
through variable/method binding, but no way to call a static javascript with
some dynamic data passing in such as: onclick="doit('')";

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

From the forum:
We did a test run today with JSF RI weekly build from 18 August 2004.
The results were better than with JSF RI 1.1, but although to worse for a
productive use.
Instead of 4 use cases per seconds we got 8 use cases per seconds (to be more
precise with 4 concurrent clients -> 7 use cases, for 10, 20, 30, 40,50 clients
the value sticks
to 8 use cases).
I took a thread dump and think there is potentially a deadlock problem. Here is
an extract from this thread dump:

Thread-4" daemon prio=5 tid=0x1502e8 nid=0x14 waiting for monitor entry
[b2c7f000..b2c819bc]
at java.lang.ref.ReferenceQueue.poll(ReferenceQueue.java:76)

• waiting to lock (a java.lang.ref.ReferenceQueue$Lock)
  at java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:263)
  at java.util.WeakHashMap.getTable(WeakHashMap.java:292)
  at java.util.WeakHashMap.get(WeakHashMap.java:336)
  at
  javax.faces.component.UIComponentBase.getPropertyDescriptor(UIComponentBase.java:114)
  at javax.faces.component.UIComponentBase.access$300(UIComponentBase.java:56)
  at
  javax.faces.component.UIComponentBase$AttributesMap.get(UIComponentBase.java:1353)
  at com.sun.faces.util.Util.hasPassThruAttributes(Util.java:719)
  at
  com.sun.faces.renderkit.html_basic.TextRenderer.getEndTextToRender(TextRenderer.java:120)
  at
  com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeEnd(HtmlBasicRenderer.java:173)
  at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:720)
  at
  com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:443)
  at
  com.sun.faces.renderkit.html_basic.TableRenderer.encodeChildren(TableRenderer.java:257)
  at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:701)
  at javax.faces.webapp.UIComponentTag.encodeChildren(UIComponentTag.java:607)
  at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:544)
  at com.sun.faces.taglib.html_basic.DataTableTag.doEndTag(DataTableTag.java:491)
  at register_jsp._jspx_meth_h_dataTable_0(register_jsp.java:1148)
  at register_jsp._jspx_meth_h_form_2(register_jsp.java:1103)
  at register_jsp._jspx_meth_f_view_0(register_jsp.java:185)
  at register_jsp._jspService(register_jsp.java:124)
  at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:1

For additional comments and follow, plese refer to the URL in the URL field,
which has a link to issue on the javaserverfaces project

Environment

Operating System: All
Platform: All
URL: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=49

Affected Versions

[1.1]

On client side, if the drop down menu is populated by javascript, any selected
value that is not in the list of orginal server side item list is viewed as
invalid. This can be easily fixed by allowing it. The reason this works
because when you bind a variable to a dropdown menu (h:selectOneMenu), it will
receive one value as long as it's the same type. In the api, it says: "In
addition to the standard validation behavior inherited from UIInput, ensure that
any specified value is equal to one of the available options." So to get this
to work, just have a boolean properly saying whether to validate this behavior
or not.

One reason for using this is that table sends back same drop down menu many
times. For large table and large number of menu items, this is very redundant,
and can be easily fixed using Javascript to populate the drop down menu instead.

Other reason would be highly dynamic website that utilize javascript heavily,
such as depends on certain radio button users click on, different dropdown menu
is populated as choice.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Cannot control row and column width (absolute or relative) in a grid panel
Cannot easily set row/column/cell background color.
All other html table stuffs.

I think all we need is something like html table. With all the bells and
whistles. However, the html table does not always work. It has to be JSF,
because for example, if you want the rendered attribute to be false, cannot do
so with html and JSF mixed components.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Have a dropdown menu which bind to a back bean variable of integer type.
However, the select item was created with String values (versus Integer values).
When users submit the form, nothing is processed, however, there is no error
message showing in the inline message wired to the dropdown menu (using the
"for" attribute).

Also, if change the select item to Integer, but the client submit a value that
is not one of the select items (modified using Javascript for example), the
behavior is same as above without any error message or processing. The page
just return silently.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

GroupRenderer is specified to emit a element around the child components
that it encapsulates. This is fine for most cases, but causes problems when
users want to add height and width CSS style attributes, which are ignored on
inline elements. Suggest adding a similar renderer (Block? --> <h:panelBlock>)
that is specified to render a

Our implementation to set up hidden fields in the form introduces
tightly coupled renderer dependencies. For the original cause of
this implementation see bugster report 5055795.

For example.. We expose public static methods on FormRenderer that
are used in CommandLinkRenderer as well as HiddenFieldRenderer.
(ex: FormRenderer.addNeededHiddenField....)
Anyone now using our CommandLinkRenderer must also use our FormRenderer..

For more information on this see:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=26

The EG has outlined some possible solutions - but whatever we do must be spec'd.

Environment

Operating System: All
Platform: All

Affected Versions

[1.2]

Next spec should support multi-component validation.

Environment

Operating System: All
Platform: All
URL: http://weblogs.java.net/pub/wlg/1625

Affected Versions

[2.0]

On Thu, 08 Apr 2004 15:56:21 -0700, Adam Winer [email protected] said:

AW> We built the following tags:
AW> <f:actionListener>
AW> <f:valueChangeListener>
AW> <f:converter>
AW> <f:validator>

AW> ... before we had MethodBindings. The first two support class names;
AW> the latter two, IDs. These are all still useful as-is, but it would be
AW> even more useful - and more consistent - to also support MethodBinding
AW> EL expressions in these tags.

AW> This was requested a couple times from the EG, but I don't think
AW> it ever got assigned a Scarab number.

AW> I'd recommend this as a must-have for 1.2 and a nice-to-have for 1.1.
AW> Seems like relatively little work to implement the feature (forgetting,
AW> as I sometimes do, about the time it takes to add tests for the
AW> feature.)

AW> – Adam

[email protected] 2004-04-12
[email protected] 2004-04-12

Comments last updated 2004-08-18 15:40:38.0

I've closed 4962916 as a duplicate of this bug. Make sure both issues are
addressed.
[email protected] 8/18/04 15:40 GMT
[email protected] 8/18/04 15:40 GMT

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

On Thu, 08 Apr 2004 16:49:03 -0700, Adam Winer [email protected] said:

AW> The faces-config.xml support for the decorator pattern is
AW> one of my favorite features in JSF, and I like pushing
AW> it at users whenever I get a chance. But it is a pain
AW> using it, especially on objects with large APIs (like ViewHandler).

AW> I'd recommend we follow the lead of the Servlet API and
AW> provide convenience classes for implementing the Decorator
AW> pattern. (They were a bit more than convenience classes
AW> for the Servlet API, but anyway...)

AW> This would make implementing the Decorator pattern much,
AW> much simpler. It also makes it much more robust - as things
AW> stand now, every time we add a method to any of these
AW> decoratable APIs in a new version of JSF, all existing
AW> Decorators will break!

AW> This would involve, as an extreme, adding the following ten
AW> classes to JSF:
AW> ApplicationFactoryWrapper
AW> NavigationHandlerWrapper
AW> ViewHandlerWrapper
AW> StateManagerWrapper
AW> FacesContextFactoryWrapper
AW> ResponseWriterWrapper
AW> PropertyResolverWrapper
AW> VariableResolverWrapper
AW> LifecycleFactoryWrapper
AW> RenderKitFactoryWrapper

AW> But of that long list, only four are especially useful:
AW> ViewHandlerWrapper
AW> StateManagerWrapper
AW> ResponseWriterWrapper
AW> PropertyResolverWrapper

AW> The rest are either rather esoteric, or are wrappers for
AW> single method APIs (where using a canned wrapper would
AW> be even harder than writing the wrapper from scratch).

AW> BTW, I'm aware this nothing built-in about decorator support
AW> for ResponseWriters. But we've found over the last few
AW> years of using an analogous concept that decorating ResponseWriters
AW> is very, very useful for things like:

AW> - Optimizing page content
AW> - Catching common HTML errors
AW> - Adding whitespace (the current RI pushes this task to each
AW> renderer)
AW> - Sliding in design-time hooks
AW> - Adding comments to the page output (e.g., this content
AW> was built by a UICommand with id='foo')

AW> ... all of which don't require bloating the base response writer
AW> or adding any performance or output size overhead for users not
AW> using the decorator. And we don't really need anything special
AW> to support decorating ResponseWriters - that can be done in the
AW> JSP page with some easy tags sliding inside of <f:view>.

AW> This would be a very nice improvement in JSF 1.1, and I
AW> don't think it's a huge amount of work, but I could
AW> understand punting it to JSF 1.2.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

Reporter: mplaine (mplaine)

Could you change the JSF specification so that h:dataTable header attribute
would be changed to headerClasses. In other words it would be possible to
assign different Classes to header columns. Basically it should work as
columnClasses attribute.

For more details... see the thread:
http://forum.java.sun.com/thread.jsp?forum=427&thread=514955

Environment

Operating System: All
Platform: All
URL: http://forum.java.sun.com/thread.jsp?forum=427&thread=514955

Affected Versions

[1.1]

EB> R1 something you can stick in your page, that will evaluate to the full,
EB> absolute, clientId of the named thing when the page is rendered. Like
EB> this:

AVK> <h:button id="button1"
AVK> onclick="button_setEnabled(button2,
AVK> false);button_clicked(button1);return"
AVK> ... />
AVK> <h:button id="button2" ... " />

AVK> then I want the result of the first one to be

AVK> onclick="button_setEnabled('myform:button2', false);
AVK> button_clicked('myform:button1'); return;"
AVK> ... />

EB> R2 This thing can be presenent in an attribute value, or as template
EB> text.

AVK> Definitely needed in an attribute value, for the method invocation. I
AVK> don't know whether it is necessary in tempate text. I have a feeling
AVK> some JavaScript interpreters barf if you mention the id before the
AVK> element is present.

EB> R3 This thing must only work within the scope of a naming
EB> container. In other words, I can't use this mechanism to refer
EB> to something in form B if I'm inside Form A.

EB> R4 This thing must work in a multi-include page scenario

EB> R5 This thing must work in a portlet scenario

Environment

Operating System: All
Platform: Sun

Affected Versions

[2.0]

The current spec says nothing about security when doing client side state
saving. We need to say that the state should be encoded using some minimal
level of security.

Environment

Operating System: All
Platform: All

Affected Versions

[2.2 Sprint 8]

JSF must handle the duplicate button press problem.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Let's allow the <h:dataTable> tag to support a new facet, called
"caption", the contents of which will be rendered as the
element.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

From forum:

PropertyResolver.setValue is called for UISelectBoolean components regardless of
whether they
are updated or not.
erik

[email protected] 2004-03-18

Evaluation last updated 2004-06-11 15:43:03.0

This bug does exist. I've created the first half of a systest for it. CHeck
out jsf-ri/web/jsp/selectBooleanValue.jsp. Instructions there on how to write
the HTMLUnit part of the test.
[email protected] 2004-04-08

Turns out that this is behavior for all input components. We push all the values
to the model tier regardless of whether the values changed or not. Changing this
behavior will require a spec change. Since we are past spec freeze, moving this
bug for jsfaces 1.2 release.
[email protected] 2004-04-28

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

image attribute of commandButton has to either take and absolute or relative
path to the image and not a context-relative path like graphicImage's url
attribute does?

Its not a big deal because you can get the same behavior by nesting a
graphicImage inside a commandLink, but it would be nice if the attributes were
consistent, preferably using either a relative link or if a "/" is the first
character, it leads with the context-root, not the absolute root.

------- Additional comments from jayashri Wed Jul 14 19:12:36 +0000 2004 -------

The same logic should be applied to outputLink as well.

------- Additional comments from rogerk Wed Jul 14 19:48:15 +0000 2004 -------

There was some pretty involved discussions going on in the eg mails
about graphicImage and outputLink renderers not behaving the same way.
graphicImage renderer prepends the context path if a leading slash is present...
However, outputLink renderer does not. (GraphicImageRenderer first uses
ViewHandler.getResourceURL before encoding)..Looks like the concenus on this
thread was to make OutputLinkRenderer behave the same way as GraphicImageRenderer...

But if we do this, we also need to update the standard-html-renderkit writeup
for OutputLinkRenderer as well....

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Date: Sun, 28 Mar 2004 14:23:57 -0800
Reply-To: Java Community Process JSR #127 Expert List [email protected]
Sender: Java Community Process JSR #127 Expert List [email protected]
From: Hans Bergsten [email protected]
Subject: [BUG/RFE] UIViewRoot event processing
Comments: To: Java Community Process JSR #127 Expert List [email protected]
Content-Type: text/plain; charset=us-ascii; format=flowed

The UIViewRoot JavaDocs for processDecodes() and processValidators() say that
the event queue is cleared if processing the events in this phase led to
FacesContext renderResponse() being called. Is this really necessary, or even
the right thing to do? If it is, shouldn't the same apply if FacesContext
responseSent() was called, and happen in all event processing phases, not just
these two?
[email protected] 2004-05-04

Comments last updated 2004-06-12 07:22:57.0

Please see EG thread
http://archives.java.sun.com/cgi-bin/wa?A2=ind0403&L=jsr-127-eg&P=R5035&D=0&I=-3&X=7601F801CA277DE89D&[email protected]
[email protected] 2004-05-04

Public Summary last updated 2004-06-10 21:16:40.0

We need to specify when the UIViewRoot event queue must be cleared.
[email protected] 2004-05-04

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

Leverage the -extension meta-data element by defining a common, best practice
set of such extension tags. Collect requirements from tools vendors.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

Craig R. McClanahan wrote:

[...]
It also seems that we want to think about JSFA162 a little more to
ensure that we've actually solved the problem it purports to solve.

Correct me if I'm wrong, but I believe all that's needed to support
the use of multiple render kits out-of-the-box is this:

• StateManager.SerializedView:
  Add a new property named "renderKitId"

• ResponseStateManager.writeState(FacesContext, SerializedView):
  Add the "renderKitId" property value to the response in such a way
  that it is sent as a request parameter named
  "javax,faces.renderKitId" on the post-back request for this view,
  e.g., as a hidden field for HTML. A null value for the "renderKitId"
  property means that the application's default render kit is used,
  so no render kit information needs to be included in the response.

• StateManager.saveSerializedView(FacesContext)
  Set the "renderKitId" property to the value returned by the
  UIViewRoot.getRenderKitId() unless it's the same as the value
  returned by the Application.getDefaultRenderKitId() method or
  HTML_BASIC_RENDER_KIT_ID if this method returns null.

• StateManager.restoreView(FacesContext, String)
  Remove the "renderKitId" parameter we added and instead specify that
  this method gets it from the "javax,faces.renderKitId" request
  parameter. If it's null, use the render kit ID returned by the
  Application.getDefaultRenderKitId() method, or the
  HTML_BASIC_RENDER_KIT_ID if this method returns null.

• ViewHandler.restoreView()
  Remove the stuff we added for getting the render kit id, because
  it's no longer a StateManager.restoreView() parameter.

• UIViewRoot.setRenderKitId()
  Specify that this method can (again) be called anytime between the
  end of the Process Validation phase and before the first component
  is rendered in the Render Response phase.

• <f:view>
  Add back the "renderKitId" attribute.

In addition to adding support for multiple kits in one app, these
changes also keeps the whole mechanism within the StateManager domain
instead of spreading it out between the StateManager and the
ViewHandler.

Thoughts?

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.1]

It is necessary to have a unique window Id in addition to the viewId to allow
for applications that have multiple instances of the same view, but perhaps in
different browser windows or frames.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

A previous version of the RI incorporated the cryptic clientId in messages (for
example, validation messages) as an attempt to show which component the message
was associated with. We need to come up with a better way of doing this. More
information from the archives:

The proper way involves adding a new property to our components that
describes the "name"/"prompt"/"label" etc. that can be incorporated
into validation messages but can still be translated, user-readable
text. Doing so is obviously an API change, but there's no way to
add this feature correctly without extending the JSF API.

– Adam

Environment

Operating System: All
Platform: All

Affected Versions

[1.2]

For phase listeners, possibly modify the phase processing to allow the
afterPhase method to be called in a finally block. If an error occurs in one of
the Phases, the afterPhase would never be called. This may prevent resource
cleanup and cause memory leaks in developer implementations.

Additional comments from adamwiner Thu Aug 12 20:18:13 +0000 2004 -------

This behavior should be specified in the 1.2 spec. I don't think anything
prevents it from being implemented in 1.1, but the EG should be queried.

Environment

Operating System: All
Platform: All

Affected Versions

[1.2]

On Thu, 19 Aug 2004 14:06:40 -0700, Adam Winer [email protected] said:

AW> Ed,
AW> One other thing I've seen a lot of users begging for
AW> is some sort of "onload" method that they can use for
AW> basic per-page initialization code (e.g., fire the
AW> database query now). Something as simple as:

AW> <f:view beginRender="#

{MethodBinding here}"
AW> endRender="#{MethodBinding here}

">

AW> ... or even (delivering PhaseEvents):

AW> <f:view beginPhase="#

{MethodBinding here}"
AW> endPhase="#{MethodBinding here}

">

AW> ... would be a huge plus to many.

AW> (Per-component init/cleanup methods would also
AW> be handy for some performance issues, but that's
AW> a lot less important.)

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

Migrate to schema for config files

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

HI,

This is the way i am doing currently.

FacesContext context = FacesContext.getCurrentInstance();
int iSortColumn =
Integer.parseInt(context.getExternalContext().getRequestParameterMap().get("sortColumn").toString());

But I was thinking of some elegant way like

UICommand command = event.getCompoonent();
command .getParamValue("ParamId")
from the component. I have the commandLink component reference.

KP

Environment

Operating System: All
Platform: All
URL: http://forum.java.sun.com/thread.jsp?forum=427&thread=551162&tstart=0&trange=15

Affected Versions

[1.1]

It would be easier for the end user if they could leverage the existing
<f:param> tag to configure a validator.
[email protected] 2004-03-05

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]

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

I think using href="javascript:document.forms......." is better solution then
using onclick DHTML event in rendered HTML code for commandLink component?

This is because:
1. browser do not handle unnecessary href="#" (which sometimes is very
unnecessary because scrolls page to the top of page before sending the request
to server)
2. in forum (f.g. http://forum.java.sun.com/thread.jsp?forum=427&thread=506830)
I read then onclick event for commandLink doesn't work because in html onclick
already used.

<h:commandLink id="link" action="goto">
<h:outputText value="#

{msg.linkName}

"/>
</h:commandLink>

Rendered as:

Next Page

My suggestion:

Next Page

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

The Standard Html Renderkit Docs need to be more explicit with respect to the
use of "style" "class" attributes for MessagesRenderer (and other renderers that do
similar manipulation - like <h:selectOneRadio> and <h:selectManyCheckbox>. )..

Currently, the "style" attribute is duplicated on the element for each
rendered message. So, if "positional value" is used for "style", all messages
get rendered on top of each other. The request is to place the "style"
attribute on an "outer" and the "class" attribute values on the "inner"
elements (for each message).. For example:

<h:messages binding="#

{Page1.messageList1}

" errorClass="errorMessage"
fatalClass="fatalMessage" id="messageList1" infoClass="infoMessage"
style="left: 48px; top: 432px; position: absolute"
warnClass="warnMessage"/>

renders as:

assuming those messages existed in facesContext.

See issue :

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

for detailed background.

Environment

Operating System: All
Platform: All

Affected Versions

[1.1]

the "j_security_check" feature of some J2EE containers is a quick and easy way
to provide role-based authentication to a web application. It would be nice if
we cloud allow our existing <h:form> <h:inputText> <h:inputSecret> components to
support this via some kind of flag.

Environment

Operating System: All
Platform: Sun

Affected Versions

[1.2]