<< Back to previous view
UIData needs review on a couple of fronts (JAVASERVERFACES_SPEC_PUBLIC-935)

[JAVASERVERFACES_SPEC_PUBLIC-322] Add interfaces to javax.faces.component package Created: 21/Nov/07  Updated: 08/Nov/13

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

Type: Sub-task Priority: Critical
Reporter: mwessendorf Assignee: Unassigned
Resolution: Unresolved Votes: 7
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-236 UIData is Fundamentally Broken and Ne... Resolved
Issuezilla Id: 322
Status Whiteboard:

EGTop5 effort_moderate cat2 javadoc size_medium importance_medium draft

Tags:
Participants: Ed Burns, kito75, mwessendorf and rogerk

 Description   

There are currently nice interfaces, like ValueHolder and EditableValueHolder.
But this isn't enough.

The minimal contract of creating a (custom) JSF component is UIComponent.
It is not necessary to extend something like UIComponentBase or even UIInput,
which is good.

For instance for checking if a component is able to be validated, some do a
instanceof UIInput, which would fail in some cases (as in Trinidad). Luckily
enough, we have the EditableValueHolder interfaces, so checking against that is
fine.

I noticed a lot of issues in the past with UIForm, since there is not "Form"
interface for that. One of the issues, when making Tomahawk working with
Trinidad/ADF Faces was that the Trinidad/ADF Faces form isn't extending UIForm
(which isn't wrong). We ended up, using a String-based identifier (component
family) for ensuring the component (from Trinidad) is a form. With an interface
for Form (like for EditableValueHolder) there weren't a need for "checking Strings".

This is true for "table components" as well. A "table interface" would be nice.



 Comments   
Comment by mwessendorf [ 19/Aug/08 05:40 AM ]

On an interface for "Form", I can think about things like:
-autoComplete
-usesUpload (bool, when TRUE => set enctype="multipart/form-data")
(and/or enctype)
-prependId
-defaultCommand (executed when hitting ENTER inside the form)

On an interfaces for Tables (call it structuredData or so, since it could be
implemented in a custom Tree, for instance) I can think of these:
-var ?
See Trinidad's UIXCollection CLASS, which is the base for all structured Data
(in Trinidad):
http://myfaces.apache.org/trinidad/trinidad-api/apidocs/org/apache/myfaces/trinidad/component/UIXCollection.html

Again such a "generic" interfaces could be useful when creating tree's (instead
of extending UIData (like Tomahawk or the Hans Bergsten book).

But... it is really important to have STRONG types, instead of messing around
with Strings (component family)

Comment by Ed Burns [ 21/Aug/08 07:28 AM ]

Add status whiteboard: EGTop5

Comment by Ed Burns [ 12/Sep/08 04:27 PM ]

effort_moderate

Comment by Ed Burns [ 12/Sep/08 04:47 PM ]

change target_milestone to 2.0

Comment by Ed Burns [ 17/Sep/08 02:55 PM ]

As discussed at JSFOne, I think we need a behavioral interface for components that manage collections of
children, such as trees, tables, and such.

Comment by Ed Burns [ 15/Oct/08 11:28 AM ]
      • Issue 189 has been marked as a duplicate of this issue. ***
Comment by kito75 [ 16/Oct/08 04:06 PM ]

It'd make sense to expose a isPostBack() method (which I think is on
FacesContext in 2.0) through the Form interface, as well.

Comment by Ed Burns [ 21/Oct/08 01:37 PM ]
      • Issue 245 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 28/Jul/09 12:58 PM ]

We just didn't get to this one. Sorry Matzew.

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by Ed Burns [ 24/Feb/10 03:17 AM ]

I really don't think this is a P1 also.

Comment by kito75 [ 24/Feb/10 07:56 AM ]

Matthias, aren't your example form properties more renderer-specific?

Comment by Ed Burns [ 04/Mar/10 01:14 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 06:47 AM ]

javadoc

Comment by Ed Burns [ 22/Mar/10 11:05 AM ]

components

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 10:24 AM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 10:58 AM ]

triage

Comment by rogerk [ 16/Nov/10 12:20 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-329] Add new single HTML radio button component that isn't bound to a list Created: 05/Feb/08  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


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

cat2 renderkitdoc size_medium importance_small

Tags:
Participants: Ed Burns, rdelaplante, rogerk and sheetalv

 Description   

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

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



 Comments   
Comment by rdelaplante [ 05/Feb/08 08:13 PM ]

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

Comment by Ed Burns [ 09/Sep/08 02:00 PM ]

Per 20080827 EG Meeting, push to 2.1

Comment by Ed Burns [ 10/Sep/08 08:27 AM ]

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

Comment by rdelaplante [ 10/Sep/08 08:50 AM ]

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

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

Comment by rdelaplante [ 10/Sep/08 08:56 AM ]

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

Comment by rdelaplante [ 17/Sep/08 05:36 PM ]

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

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

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

Comment by rdelaplante [ 17/Sep/08 05:38 PM ]

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

Comment by rdelaplante [ 23/Mar/09 12:51 PM ]

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

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

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by rogerk [ 05/Mar/10 07:18 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 06:53 AM ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:39 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 10:59 AM ]

triage

Comment by rogerk [ 16/Nov/10 12:20 PM ]

triage

Comment by rdelaplante [ 20/Apr/12 09:57 PM ]

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

<t:selectOneRadio id="upgradesRadio" layout="spread" value="#{model.upgradeSelection}">
<f:selectItems value="#{model.availableUpgrades}" var="upgrade" itemLabel="#{upgrade.description}"/>
<f:ajax/>
</t:selectOneRadio>

... custom HTML layout ...

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

... custom HTML layout ...

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

Comment by rdelaplante [ 30/Aug/13 06:22 PM ]

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





[JAVASERVERFACES_SPEC_PUBLIC-546] Add a way to check for the attributes set on a compositecomponent. Created: 23/Apr/09  Updated: 24/Jan/14

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

Type: Improvement Priority: Critical
Reporter: ioss Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 546
Status Whiteboard:

cat2 frame size_small importance_small

Tags:
Participants: Ed Burns, ioss and rogerk

 Description   

We probably need a way to conditionally add attributes to components in the implementation of a
compositecomponent (cc) or at least be able to check, if an attribute was set on the cc.
Especially it is not (easily) possible to find out by using EL, if an attribute on the cc has been set or
resolves to null/"" as #{empty cc.attrs.attributename} will be true eitherway.

Examples:
1) There are components which will change their behaviour if an attribute is set (even to null or "")
contrary to not being set.

2) There may be attributes which are not allowed to be set to null

3) Lets say I have a component
<c:set var="bean" value="#{someBackingBean.selectedItem}" />
<x:beanInput id="phoneNumber" />
<x:beanInput id="street" value="#{bean.address.street}" />

implemented in this way:
...
<h:inputLabel id="#{id}Label" for="#{id}" />
<h:inputText id="#{id}" value="#{empty value ? bean[id] : value}" />
...
if #{bean.address.street} is null, we will end up with a value bound to bean.street, which probably is not
the desired effect.

Two proposals:

  • add something like <f:insertAttribute name="attributename" value="attributenameOnCC" /> which
    will only add the attribute, if it was set on the cc
    This would also allow to have some sort of workaround for paththrough attributes.
    Example:
    <my:customcomponent onmouseoverLeft="alert('left')" onmouseoverRight="alert('right')" ... />
    with implementation:
    <h:sometag id="Leftone" ...>
    <c:foreach var="event" items="#{fx:split("mouseover,mouseout,click,focus,blur")}">
    <f:insertAttribute name="on#{event}" value="on#{event}Left" />
    </c:foreach>
    </h:sometag>
  • Introduce a way to check if an attribute was set on the cc by EL. Something like
    cc.attrsIsSet.nameofattr => true/false.
    (with cc being available, developers could write EL-functions themselves, but it would be helpful to
    have an easier way to check it)


 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 01:17 PM ]

cat2

Comment by Ed Burns [ 17/Mar/10 02:05 PM ]

frame

Comment by Ed Burns [ 27/Apr/10 10:57 AM ]

no sig change

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 02:17 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 12:23 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-772] f:selectItems value="#{myMap}" underspecified Created: 17/Mar/10  Updated: 20/Dec/13

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

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

Operating System: All
Platform: All


File Attachments: Text File issue-772-test.patch    
Issue Links:
Related
is related to JAVASERVERFACES-1687 Renderers for UISelectMany don't supp... Closed
Issuezilla Id: 772
Status Whiteboard:

size_medium importance_large

Tags:
Participants: Ed Burns and lu4242

 Description   

The documentation of UISelectItems says:

Map - The keys of this object (once converted to Strings) are assumed to be
labels, and the values of this object (once converted to Strings) are assumed to
be values, of SelectItem instances that will be constructed dynamically and
added to the set of available options for the parent component, in the order
provided by an iterator over the keys.

This behavior comes from jsf 1.1, but in jsf 2.0 it was added some new
attributes (from f:selectItems tlddoc):

Version 2 of the specification introduces several new attributes, described
below. These are: var, itemValue, itemLabel, itemDescription, itemDisabled, and
itemLabelEscaped.

Now, what happen if some user do something like this:

<f:selectItems value="#{myMap}" var="item"
itemLabel="#{item.value.someLabelProperty}" itemValue="#{item.value}">

It just does not work, because there is no clear definition about what should
f:selectItems do in this case.

The proposal for solve this one is if var property is set and value implements
Map interface, use the entry object as var, so the user can choose between the
key and some attribute on the item value.



 Comments   
Comment by Ed Burns [ 18/May/10 02:11 PM ]

This is important for 2.0 Rev a.

Comment by Ed Burns [ 24/May/10 10:56 AM ]

up to p2

Comment by Ed Burns [ 24/May/10 12:55 PM ]

take ownership.

Comment by Ed Burns [ 24/May/10 04:14 PM ]

Leonardo, please re-open this if I am misunderstanding you.

The tlddoc for f:selectItems states that the "value" attribute may be any Collection or array. Map is
neither.

There is a related mojarra issue filed to track the fact that using Map as the type of the enclosing
UISelectMany's value is not working, though, as you point out, it should work.

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

Comment by lu4242 [ 24/May/10 04:56 PM ]

The documentation of f:selectItems and UISelectItems class is in fact different.
I'm taking into account the documentation of UISelectItems as the valid one.
Since f:selectItems creates a UISelectItems instance, the behavior implemented
is the one described on UISelectItems.

If you try to use something like this:

<f:selectItems value="#{someMap}"/>

it works since jsf 1.1.

I'll reopen it, because anyway it is necessary to update the documentation.

Comment by Ed Burns [ 27/May/10 10:04 AM ]

Leonardo, we can either specify that the "var" attribute is unsupported for f:selectItems where value is
a Map, or we can push this to 2.1. I am constrained to these choice because to make "f:selectItems
var points to map" work needs a behavior change.

Your call.

Ed

Comment by Ed Burns [ 27/May/10 10:10 AM ]

2.1.

Comment by lu4242 [ 28/May/10 04:04 PM ]

Ok, sounds reasonable let it for 2.1

Comment by Ed Burns [ 01/Jun/10 10:29 AM ]

Created an attachment (id=236)
patch showing this issue

Comment by Ed Burns [ 08/Jun/10 01:10 PM ]

triage

Comment by Ed Burns [ 24/Jun/10 02:41 PM ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 01:31 PM ]

Move these to 2.2





[JAVASERVERFACES_SPEC_PUBLIC-819] add "disabled" attribute for h:button Created: 11/Jun/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 819
Status Whiteboard:

size_small importance_small

Tags:
Participants: Ed Burns and rogerk

 Description   

From issue 714:

  • VDLDocs for h:button don't mention a disabled attribute, but the h:link one does have the disabled
    attribute. My guess would be that both should have this attribute?


 Comments   
Comment by Ed Burns [ 11/Jun/10 08:23 PM ]

assign to sheetal

Comment by rogerk [ 27/Oct/10 02:25 PM ]

triage

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

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





[JAVASERVERFACES_SPEC_PUBLIC-106] add an external-attribut to url-rendering components Created: 24/Aug/05  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 106
Status Whiteboard:

cat2 javadoc sig size_medium importance_small

Tags:
Participants: Ed Burns, martenlehmann, rogerk and sheetalv

 Description   

I'd like to propose to add an external attribute to all components, that work
with url's. Usually, session-id's are stored in cookies. But if a browser
doesn't support cookies, the client has disabled it or the administrator
configured the java server to encode the cookie in the url instead of setting a
cookie by default [1], the session-id is encoded into the url where you don't
expect it. While it's surely wanted in url's of the same application context,
you will end up with an unexpected url at external addresses:

<h:outputLink value="http://www.yahoo.com"><h:outputText
value="yahoo"/></h:outputLink>

will generate:

<a href="http://www.yahoo.com;jsessionid=aoX0DYNXlII43PaHPx">yahoo</a>

An external="true" (false by default) could simply pass the url unchanged.

[1] You can do this in Resin if caucho.com with

<session-config>
<enable-cookies>false</enable-cookies>
</session-config>



 Comments   
Comment by Ed Burns [ 27/Feb/06 01:54 PM ]

I think this is a good idea, especially given the javadoc for
ExternalContext.encodeResourceURL():

http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/context/ExternalContext.html#encodeResourceURL(java.lang.String)

Comment by Ed Burns [ 13/Mar/06 01:27 PM ]

Fix checked in.

Comment by Ed Burns [ 24/Mar/06 12:40 PM ]

I didn't get to this one. Targeting for 2.0

Comment by Ed Burns [ 20/Aug/08 08:26 PM ]
      • Issue 171 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 12:30 PM ]

cat2

Comment by Ed Burns [ 17/Mar/10 02:00 PM ]

javadoc

Comment by Ed Burns [ 27/Apr/10 09:03 AM ]

sig change, new parameter on ExternalContext.encodeResourceURL.

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 11:42 AM ]

triage

Comment by Ed Burns [ 24/Jun/10 01:32 PM ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 12:33 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-130] new approach for <h:messages> and to access validation-errors Created: 28/Oct/05  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


File Attachments: GIF File form-with-messages-included.gif     GIF File message-summary.gif    
Issuezilla Id: 130
Status Whiteboard:

cat2 renderkitdoc sig size_medium importance_small

Tags:
Participants: Ed Burns, kithouna, martenlehmann, rogerk and sheetalv

 Description   

<h:message> and <h:messages> are a good start to place error-messages of
form-validations somewhere, but its behaviour and attributes are very limited in
what you can do with it. I noticed that you can't even define a stylesheet for
the table itself when you set <h:messages layout="table"/>, but only for the
<span>s within the <td>s of the table.

It's hard to explain what one needs to be able to do better and which api is
required to achieve this. I don't know which plans for this might be in queue
for JSF 2.0 and I'm surely not the best to design the perfect api. But I have
attached two screenshots to this issue where you can see which flexibility of
error-messages is prevalent in the web and that JSF is just at the very
beginning in this topic and much more features are needed.

In short these are:

  • a way to check if any validation errors have occured
  • a way to access the error-message(s?) of a certain component-id
  • a way to get a list of all fields that threw a validation-error

This shouldn't be solved by new jsf-tags, but by #{...} expressions.

And regarding the table-layout I mentioned at the beginning, it is surely
usefull to add a tableStyle and tableStyleClass-attribut to the api.



 Comments   
Comment by martenlehmann [ 28/Oct/05 11:13 AM ]

Created an attachment (id=68)
output similar to <h:messages layout="table"/>

Comment by martenlehmann [ 28/Oct/05 11:16 AM ]

Created an attachment (id=69)
complex form with errors, please note the warning triangle conditionally rendered, a new row for the error-messages and a changed background of the text-input to highlight the invalid field.

Comment by martenlehmann [ 28/Oct/05 11:18 AM ]

In some way, this is a prosecution of issue 104 I created some time ago.

Comment by rogerk [ 03/Mar/06 10:30 AM ]

Think we can do this for 2.0 along with our improved message strategy.

Comment by Ed Burns [ 20/Dec/07 04:05 PM ]

When adding messages to the FacesContext, as much context information as
possible should be added to the message. For example, look at the Facelets
Location class.

Comment by Ed Burns [ 24/Sep/09 08:42 AM ]

Move to 2.1

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by Ed Burns [ 04/Mar/10 12:32 PM ]

This one ties into the question of how much we should do in the standard
components. Custom messages components can do a better job of this.

Comment by Ed Burns [ 17/Mar/10 02:02 PM ]

As an example, I point to PrimeFaces Growl h:messages component. I'll ask Cagatay Civici to
comment on this.

Comment by Ed Burns [ 17/Mar/10 02:04 PM ]

renderkitdoc

Comment by Ed Burns [ 27/Apr/10 10:58 AM ]

sig change

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:00 PM ]

triage

Comment by rogerk [ 27/Oct/10 10:52 AM ]

triage

Comment by rogerk [ 16/Nov/10 11:34 AM ]

triage

Comment by kithouna [ 04/Mar/13 05:04 PM ]

Did Catagay ever respond to this? This issue has been open for some 7.5 years now. Maybe decision should be made about it?





[JAVASERVERFACES_SPEC_PUBLIC-137] Leverage selectItem.getDescription() to generate "title" attribute Created: 20/Jan/06  Updated: 24/Jan/14

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

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

Operating System: All
Platform: Sun


Issuezilla Id: 137
Status Whiteboard:

cat2 renderkitdoc size_small importance_medium

Tags:
Participants: Ed Burns and rogerk

 Description   

Whenever we render a SelectItem, we could use the getDescription( ) method to
render a "title" html attribute for additional 508 compliance.

Ed



 Comments   
Comment by Ed Burns [ 20/Jan/06 01:24 PM ]

>>>>> On Thu, 19 Jan 2006 13:42:59 +0100, Jean-Baptiste BUGEAUD said:

bjb> Dear JSR abd EG Members,
bjb> On §4.2.2.1 of JSF1.2 PFD describing the properties of SelectItem, it is
bjb> written :

bjb> « description / RW / String / A description of this selection item, for
bjb> use in development tools. »

This is a good idea but because it would have a big change on the
renderers I'm deferring it to the next release.

bjb> IMHO, a description for a specific item is important data that should be
bjb> represented to user screen in order to enhance the page accessibility.

bjb> As an example, (X)HTML got an attribute on most tags that is title, and
bjb> this description for HTML rendering should ge there if defined. This is
bjb> the same exact behaviour the disabled property is disabling the
bjb> selection in HTML using the disabled attribute.

bjb> So the sentence in the spec should be something like :
bjb> « A description of this selection item, that can be rendered to the user »

bjb> Such a description attribute should be IMHO present to most tag so that
bjb> the same accessibility level can be provided to the page using dynamic
bjb> content.
bjb> See WAI for more elements on accessibility : http://www.w3.org/WAI/

bjb> Regards,
bjb> Jean-Baptiste BUGEAUD

Comment by Ed Burns [ 24/Sep/09 08:43 AM ]

2.1

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by rogerk [ 05/Mar/10 07:01 AM ]

cat2

Comment by Ed Burns [ 17/Mar/10 02:05 PM ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 12:11 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 10:52 AM ]

triage

Comment by rogerk [ 16/Nov/10 11:34 AM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-206] It would be nice if SelectItem was made Generic Created: 11/Aug/06  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 206
Status Whiteboard:

cat2 javadoc size_small importance_small

Tags:
Participants: Ed Burns, rogerk, sheetalv and youngm

 Description   

Can SelectItem's value be added as a generic of SelectItem? I think it would
come in handy. If a good idea can this make it into 1.2.1?

Mike



 Comments   
Comment by Ed Burns [ 15/Oct/08 11:40 AM ]

I'm sorry, Mike, I don't understand what you mean. Can you please be more explicit?

Thanks,

Ed

Comment by youngm [ 15/Oct/08 01:51 PM ]

Change SelectItem's definition to:

public class SelectItem<V> {
private V value = null;
public SelectItem(V value) {...}
public V getValue() {...}
public void setValue(V value) {...}
}

So that I could access the value contained in SelectItem without having to cast it.

Mike

Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 12:38 PM ]

cat2

Comment by Ed Burns [ 17/Mar/10 02:11 PM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:42 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 10:54 AM ]

triage

Comment by rogerk [ 16/Nov/10 11:35 AM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-212] Input Controls, rendering the Id Created: 03/Oct/06  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 212
Status Whiteboard:

EGEasy5 effort_moderate cat2 renderkitdoc size_small importance_small

Tags:
Participants: Ed Burns, rogerk and Ryan Lubke

 Description   

If we render the name on input controlls, we should render the id, many
javascript libraries work by ids, and autogenerated identifiers are not included
in the output.

Orginally under https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=309



 Comments   
Comment by Ryan Lubke [ 03/Oct/06 04:55 PM ]

Targeting for 2.0

Comment by Ryan Lubke [ 20/Aug/08 01:04 PM ]

Fixing in 2.0. Will close once changes are applied.

Comment by rogerk [ 17/Oct/08 09:16 AM ]

whiteboard

Comment by Ed Burns [ 28/Jul/09 12:27 PM ]

Didn't get to this one. Sorry.

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by Ed Burns [ 04/Mar/10 12:39 PM ]

cat2

Comment by Ed Burns [ 17/Mar/10 02:12 PM ]

rk

Comment by Ed Burns [ 22/Mar/10 06:35 AM ]

rk

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 08:21 AM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 10:55 AM ]

triage

Comment by rogerk [ 16/Nov/10 11:35 AM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-217] Add a styleClass attribute to h:column Created: 12/Oct/06  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


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

cat2 renderkitdoc size_small importance_small

Tags:
Participants: codylerum, dmlloyd, Ed Burns, i_oss, Mark Struberg, mojavelinux and rogerk

 Description   

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

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

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



 Comments   
Comment by dmlloyd [ 13/Oct/06 11:51 AM ]

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

Comment by dmlloyd [ 26/Jan/07 10:14 AM ]

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

Comment by Ed Burns [ 15/Oct/08 11:43 AM ]

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

Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by mojavelinux [ 01/Mar/10 02:13 PM ]

Update milestone and component.

Comment by mojavelinux [ 01/Mar/10 02:56 PM ]

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

Comment by Ed Burns [ 03/Mar/10 02:23 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:13 AM ]

renderkit

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 08:23 AM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 10:55 AM ]

triage

Comment by rogerk [ 16/Nov/10 11:36 AM ]

triage

Comment by Mark Struberg [ 12/May/11 03:47 PM ]

hi!

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

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

Comment by i_oss [ 12/May/11 07:06 PM ]

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

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

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

Not so important: Introduce varstatus as for ui:repeat / c:forEach, even if you can calculate index/last/first/etc. from #{component}, I think most template authors will not know that + it gets ugly.

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

Comment by codylerum [ 03/Oct/13 10:33 PM ]

+1

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





[JAVASERVERFACES_SPEC_PUBLIC-225] Add new facets for <h:column> in <h:dataTable> Created: 09/Nov/06  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


File Attachments: JPEG File datatable.jpg    
Issuezilla Id: 225
Status Whiteboard:

cat2 renderkitdoc size_medium importance_small

Tags:
Participants: amitev, dmlloyd, Ed Burns and rogerk

 Description   

I propose that there should be some new facets added to the <h:column> tag
inside of a data table, in addition to the existing "header" and "footer". The
description is as follows:

<f:facet name="prebody"/> - Cause a row to be rendered inside the <tbody> of the
table, using <td> cells, before any rows rendered automatically by the value=""
attribute of the dataTable.

<f:facet name="postbody"/> - Cause a row to be rendered inside the <tbody> of
the table, using <td> cells, after any rows rendered automatically by the
value="" attribute of the dataTable. An example use case is rendering a row in
which the user might enter data to add to the table.

Ideally, there would be a way to render an arbitrary number of header, footer,
prebody, and postbody cells, but the facet mechanism does not seem to allow for
this at present.



 Comments   
Comment by amitev [ 01/Dec/06 06:56 AM ]

Created an attachment (id=109)
data table

Comment by Ed Burns [ 15/Oct/08 11:45 AM ]

Leaving off the list for 2.0. Not important enough.

Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 07:07 AM ]

cat2

Comment by Ed Burns [ 17/Mar/10 02:14 PM ]

renderkitdoc

Comment by Ed Burns [ 22/Mar/10 06:36 AM ]

components

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 08:26 AM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 10:56 AM ]

triage

Comment by rogerk [ 16/Nov/10 11:37 AM ]

triage

Comment by amitev [ 11/Oct/12 10:46 AM ]

You should look at richfaces approach with breakBefore property on the column - http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=dataTable





[JAVASERVERFACES_SPEC_PUBLIC-247] h:panelGroup layout="block" doens't render a div only if style specified Created: 12/Mar/07  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 247
Status Whiteboard:

cat2 renderkitdoc size_small importance_small

Tags:
Participants: agoria, Ed Burns, rogerk and Stephan.M

 Description   

I can't understand why you have chosen such behavior.

IMHO
<h:panalGroup layout="block" >

should render a "div" when "style" attribute is specified and also when not.

I could need a div element because of CSS (and I don't want to use direct
classes or style):

#zone1 div { color: red; }

etc...

In general I don't agree with the fact that html (the content) depends on
"style" and/or "styleClass" attribute (the style).



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 07:09 AM ]

cat2 - looks like rkit docs change

Comment by Ed Burns [ 17/Mar/10 02:16 PM ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 01:52 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 10:57 AM ]

triage

Comment by rogerk [ 16/Nov/10 11:38 AM ]

triage

Comment by Stephan.M [ 18/May/12 10:17 AM ]

this issue exists now several times in the bug tracker, please consider a fix:





[JAVASERVERFACES_SPEC_PUBLIC-328] Standardize virtual forms Created: 05/Feb/08  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-431 Option to bypass the required attribu... Open
Issuezilla Id: 328
Status Whiteboard:

cat2 frame size_medium importance_medium

Tags:
Participants: Ed Burns, kito75, rdelaplante, rogerk and sheetalv

 Description   

I find the "virtual forms" feature in NetBeans Visual Web very useful. This
lets me have multiple submit buttons, and I can tell it which fields apply to
which submit buttons. I can submit the form without filling in required fields
that do not participate in the submit button's virtual form, and without those
fields being validated.

http://developers.sun.com/jscreator/learning/tutorials/2/virtual_form.html
http://www.netbeans.org/kb/55/virtual-forms.html



 Comments   
Comment by Ed Burns [ 09/Sep/08 02:00 PM ]

Per 20080827 EG Meeting, push to 2.1

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by kito75 [ 24/Feb/10 08:20 AM ]

This should probably be combined with further tweaks in the validation model.
There are some cases where you may want to skip validation altogether (whether
it's required validation or another form a validation) and still update the
model – a couple of JSF Days attendees were asking me how to do this today.

I like some of the ideas here: http://code.google.com/p/commons-validator-ext/

Comment by Ed Burns [ 04/Mar/10 01:15 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 06:52 AM ]

frame

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:35 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 10:58 AM ]

triage

Comment by rogerk [ 16/Nov/10 12:20 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-353] Only halt component processing on disabled not readOnly Created: 08/Apr/08  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 353
Status Whiteboard:

EGTop5 effort_moderate cat2 size_medium importance_large draft

Tags:
Participants: Ed Burns, kito75, rogerk, Ryan Lubke, sheetalv and youngm

 Description   

Currently the renderkit docs for input specify that in decode no further
processing of a component should take place if it is readOnly or disabled.

I'd like to propose that this get modified to only apply to "disabled".
According to (http://www.w3.org/TR/html401/interact/forms.html#adef-readonly)
readonly input elements cannot be modified by the user. However, they can be
modified by a script and it IS submitted with the form.

For example. You might have a standard "datepicker" JS component. I may attach
a javascript datepicker to an inputText component. If I want only the
datePicker JS to modify the inputtext then I would set it to "readOnly". This
will restrict user modification of the field but allow Script modification.
When this form is submitted I would expect JSF to process the date entered using
the date picker JS just like it would a non "readonly" input element.

The big difference between disabled and readonly is disabled elements are not
submitted with the form.

I would expect JSF to process 'readOnly" elements but not "disabled" elements.

Mike



 Comments   
Comment by Ryan Lubke [ 08/Apr/08 11:03 AM ]

Updated target milestone.

Comment by rogerk [ 22/Aug/08 08:51 AM ]

Status Whiteboard

Comment by Ed Burns [ 12/Sep/08 04:32 PM ]

effort_moderate

Comment by Ed Burns [ 12/Sep/08 04:47 PM ]

change target_milestone to 2.0

Comment by Ed Burns [ 28/Jul/09 01:07 PM ]

Push to 2.1

Comment by Ed Burns [ 24/Nov/09 07:47 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by kito75 [ 24/Feb/10 07:48 AM ]

Changed subcomponent to Components/Renderers.

Comment by rogerk [ 05/Mar/10 07:22 AM ]

cat2

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:46 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 29/Jun/10 12:12 PM ]

target

Comment by rogerk [ 01/Jul/10 11:58 AM ]

re-target

Comment by rogerk [ 27/Aug/10 06:05 AM ]

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

Comment by rogerk [ 16/Nov/10 12:21 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-424] SelectItemGroup: escape and disabled properties are ignored Created: 14/Jul/08  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 424
Status Whiteboard:

EGTop5 cat1 renderkitdoc size_medium importance_medium draft

Tags:
Participants: Ed Burns, kito75, rogerk and Ryan Lubke

 Description   

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

The implementation team has addressed the disabled handling, however, we can't
properly address the escape property for an attribute value without hacks to the
response writer (note: we've tried this in the past with mixed results).

Also See:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=237

As the fix for that will resolve this as well.



 Comments   
Comment by Ed Burns [ 09/Sep/08 01:43 PM ]

EGTop5

Comment by Ed Burns [ 15/Oct/08 06:43 AM ]

Change target milestone to 2.0

Comment by Ed Burns [ 29/Jul/09 02:00 PM ]

Like 237, moved to 2.1

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by kito75 [ 24/Feb/10 08:11 AM ]

Changed subcomponent to Components/Renderers.

Comment by Ed Burns [ 04/Mar/10 01:25 PM ]

cat1

Comment by Ed Burns [ 16/Mar/10 11:12 AM ]

rk

Comment by Ed Burns [ 15/May/10 07:52 AM ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 12:55 PM ]

take ownership.

Comment by Ed Burns [ 28/May/10 03:27 PM ]

Because this depends on issue 237, which has been moved to 2.1, this issue must also be moved to 2.1.

Comment by rogerk [ 17/Jun/10 07:17 PM ]

triage

Comment by Ed Burns [ 24/Jun/10 01:32 PM ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 12:37 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-459] Ability to escape HTML in UIMessage and UIMessages Created: 02/Sep/08  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 459
Status Whiteboard:

cat2 renderkit size_small importance_medium

Tags:
Participants: balusc, Ed Burns, kito75 and rogerk

 Description   

It would be useful to have an 'escape' attribute in UIMessage as well as
UIMessages, with the defaule value set to true. Just similar as UIOutput has.



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by kito75 [ 24/Feb/10 10:38 AM ]

Changed subcomponent to Components/Renderers.

Comment by rogerk [ 05/Mar/10 07:27 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:25 AM ]

renderkit

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 01:53 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 11:07 AM ]

triage

Comment by rogerk [ 16/Nov/10 12:22 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-462] Support for WAI ARIA Created: 05/Sep/08  Updated: 24/Jan/14

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

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

Operating System: All
Platform: Macintosh


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

cat2 frame size_large importance_large draft

Tags:
Participants: Ed Burns, kito75 and rogerk

 Description   

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



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by kito75 [ 24/Feb/10 10:43 AM ]

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

Comment by Ed Burns [ 04/Mar/10 01:30 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:27 AM ]

frame

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 12:19 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 11:08 AM ]

triage rkit docs

Comment by rogerk [ 16/Nov/10 12:23 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-471] Enhance SelectItem to include itemTitle property and HTML label Created: 15/Sep/08  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 471
Status Whiteboard:

cat2 renderkitdoc sig javadoc size_small importance_medium

Tags:
Participants: Ed Burns, kito75, mdirkse and rogerk

 Description   

Let me describe the use case that led me to file this enhancement request:

On the project that I'm currently working on I needed to render a set of HTML
checkboxes that have images as identifying labels instead of text. To enhance
the usability of the checkboxes I also wanted to render a "title" element for
each checkbox, so that the user would have a tooltip while hovering over the
checkbox (this is legal according to the (X)HTML spec, and browsers pick up on it).

Currently, neither of these is possible with JSF (I'm using 1.2_09). As a
workaround, I rendered a seperate list of images and aligned everything using
CSS. The downside is that the images aren't contained within the appropriate
label tag, so clicking them doesn't affect the checkbox (this can be fixed with
javascript, but that's a pain). I then coded up a replacedment for f:selectItem
that extended the normal SelectItem, UISelectItem and SelectItemTag and included
an itemTitle attribute.

But it would be great if this was supported out of the box by JSF. Ideally, this
should work:

<f:selectItem itemValue="foo" itemTitle="bar">
<h:graphicImage url="/images/foobar.png"/>
</f:selectItem>

which would then render:

<label for="foobarid">
<img src="/images/foobar.png" />
</label>
<input name="foobarselector" id="foobarid" value="foo" title="bar" type="checkbox">

Would this be possible?

Regards,
Maarten



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by kito75 [ 24/Feb/10 10:52 AM ]

Changed subcomponent to Components/Renderers.

Comment by rogerk [ 05/Mar/10 07:29 AM ]

cat2 - would be rkit docs change

Comment by Ed Burns [ 22/Mar/10 11:28 AM ]

renderkitdoc

Comment by Ed Burns [ 27/Apr/10 09:00 AM ]

sig change: new methods on UISelectItem.

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 02:07 PM ]

target

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 11:09 AM ]

triage rkit docs

Comment by rogerk [ 16/Nov/10 12:23 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-478] rendered attribute is overloaded Created: 02/Oct/08  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 478
Status Whiteboard:

EGTop5 cat2 javadoc size_medium importance_large draft

Tags:
Participants: Ed Burns, pmuir and rogerk

 Description   

The rendered attribute is used to control whether a widget is rendered on the
page as well as whether it should be included in processing the postback. This
in itself is not a problem (except that the word rendered is misleading to
users), however the value of rendered is revaluated when the form is submitted,
and this value is used to decide whether to process the component.

Unfortunately, there is no easy way around this, especially if we move towards a
more stateless lifecycle. This may be a simple matter of better educating users.



 Comments   
Comment by pmuir [ 10/Oct/08 05:21 AM ]

A JBoss top priority issue issue

Comment by Ed Burns [ 15/Oct/08 06:43 AM ]

Change target milestone to 2.0

Comment by Ed Burns [ 24/Sep/09 07:17 AM ]

This is important for 2.1

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by Ed Burns [ 04/Mar/10 01:34 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 10:51 AM ]

javadoc

Comment by Ed Burns [ 22/Mar/10 11:06 AM ]

rendered

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 08:06 PM ]

triage

Comment by Ed Burns [ 24/Jun/10 02:41 PM ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 01:31 PM ]

Move these to 2.2





[JAVASERVERFACES_SPEC_PUBLIC-547] selectedClass/unselectedClass should also exist for selectOneRadio Created: 25/Apr/09  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 547
Status Whiteboard:

cat2 renderkitdoc size_small importance_small

Tags:
Participants: cayhorstmann, Ed Burns, rogerk and Ryan Lubke

 Description   

As per issue 228, selectedClass/unselectedClass have been added to
selectManyCheckbox, but for consistency, shouldn't they also exist for
selectOneRadio?

Sorry for filing a new issue, but the system wouldn't let me add a comment to
the existing issue.



 Comments   
Comment by Ryan Lubke [ 27/Apr/09 09:45 AM ]

Assigning to the spec team.

Comment by Ed Burns [ 27/Apr/09 09:56 AM ]

Assigning this for 2.1

Comment by Ed Burns [ 27/Apr/09 09:57 AM ]

Accept for 2.1

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by rogerk [ 05/Mar/10 07:48 AM ]

cat2

Comment by Ed Burns [ 17/Mar/10 02:06 PM ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 01:13 PM ]

triage

Comment by Ed Burns [ 24/Jun/10 01:32 PM ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 12:46 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-560] Add @AjaxResource to simplify use of the standard Ajax resource Created: 06/May/09  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 560
Status Whiteboard:

cat2 javadoc size_medium importance_small

Tags:
Participants: Ed Burns, kito75, rogerk and sheetalv

 Description   

In order to use the standard JSF Ajax resource in a component or renderer, the
developer must use the following annotation:

@ResourceDependency (name="jsf.js", library="javax.faces",
target="head")

This requires that the developer remembers specific literal strings. I propose a
simple meta annotation:

@AjaxResourceDependency

Which includes the above parameters.



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 01:24 PM ]

This is something like a CDI stereotype.

Comment by Ed Burns [ 17/Mar/10 02:13 PM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:51 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 12:24 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:31 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-561] Add a <h:outputAjaxScript> component Created: 06/May/09  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 561
Status Whiteboard:

cat2 renderkitdoc size_medium importance_small

Tags:
Participants: Ed Burns, kito75, rogerk and sheetalv

 Description   

In order to use the standard JSF Ajax resource inside of a VDL file, the
developer must use the following annotation:

<h:outputScript name=�jsf.js� library=�javax.faces�
target=�body�/>

This requires that the developer remembers specific literal strings. I propose a
simple UI component that simply hard codes these values internally:

<h:outputAjaxScript/>



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 07:50 AM ]

cat2 - it's baaaaaaaaack

Comment by Ed Burns [ 17/Mar/10 02:14 PM ]

rk

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:55 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 12:25 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:31 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-563] Make h:outputScript work with composite components Created: 11/May/09  Updated: 24/Jan/14

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

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

Operating System: All
Platform: Macintosh


Issue Links:
Related
is related to JAVASERVERFACES-1117 Make h:outputScript work with composi... Closed
Issuezilla Id: 563
Status Whiteboard:

cat1 vdldoc size_medium importance_medium

Tags:
Participants: driscoll, Ed Burns, rogerk and Ryan Lubke

 Description   

Currently, h:outputScript will not work inside the implementation section of a
composite component, if the corresponding JavaScript references the composite
component with a value expression (#{cc.attrs...}) because the request that
fetches the JavaScript knows nothing about the composite component.

The reason h:outputScript does not work in this case is not obvious to the
average developer, and violates the principle of least astonishment. If it's
possible to make this work by somehow sending a request or component id along
with the request for the JavaScript, we should make this work for a 2.0
maintenance release, or for 2.1.



 Comments   
Comment by driscoll [ 11/May/09 10:56 AM ]

I'm attaching my email from the EG mailing list below:

I agree that we should document how to do this: Which is why I wrote a demo
that does this (basic-ezcomp/spinner-final) - and blogged about it
http://weblogs.java.net/blog/driscoll/archive/2008/11/jsf_20_writing.html

The problem is not solvable the way that you think it is: I struggled with this
too, until Ryan walked me through it. The problem is one of the web, not one of
the JSF, exactly.

So, look at it this way: The JavaScript file is served ONCE, from ONE known
address. This is good - it allows us to cache the JavaScript file. This is bad

  • because we do the # variable substitution before we serve the file, we can't
    do #{cc} substitutions in it, that file could (and will) be shared across views
  • and even across different web surfing sessions, after all, that's the whole
    point of the resource mechanism... Efficient use of caching for resources.

So, how to address this? One way is in the demo - just set the cc.clientId as a
context, and use that context in the function calls.
In a different demo (ajax-switchlist) I save that context into state, and use
that in each call. Either way works, and both require about four lines of
(javascript) code.

If you make it so that we make those substitutions into the javascript file,
then you also need to output that javascript file with a view unique name. And
that's probably a bad idea for most uses, since that shoots caching in the head.
We could add a "perview" attribute to each resource, I guess, but since the
workaround is so easy, once you know it, and the cost is the loss of caching,
I'd argue this isn't a good idea.

I urge you to run through the demos I wrote (basic-ajax, basic-ezcomp,
basic-ajax-edittext, ajax-switchlist) - they're all small, and in each of them,
I try to tackle one small problem and solve it. In many of them, I ran into
problems just like this, and worked through them. They're not documented (except
in blogs), but they are all small pieces of code.

Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 07:52 AM ]

cat1 - investigate and possibly close based in Jim's comments

Comment by Ed Burns [ 15/Mar/10 01:50 PM ]

vdldoc

Comment by Ed Burns [ 15/Mar/10 01:59 PM ]

2.0 rev a

Comment by Ed Burns [ 02/May/10 10:06 AM ]

Move to 2.1. Find related issue that calls for documenting the behavior
of evaluating ELExpressions from Resource.getInputStream().

Comment by Ed Burns [ 15/May/10 07:52 AM ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 18/May/10 02:02 PM ]

Forgot to change target milestone.

Comment by rogerk [ 18/Jun/10 03:06 AM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 12:25 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:33 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-579] composite component VEs should be stored in the VE map Created: 24/Jun/09  Updated: 24/Jan/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 579
Status Whiteboard:

cat2 frame javadoc size_large importance_small

Tags:
Participants: Ed Burns, guyv, rogerk and Ryan Lubke

 Description   

Section '5.6.2.2 Composite Component Attributes ELResolver' states that
ValueExpressions should be stored in the attributes map of the CC. This is
different from how ValueExpressions are dealt with for normal components. The
behavior for CCs should be identical to that of normal components, i.e.
ValueExpressions should be stored in the ValueExpression Map.



 Comments   
Comment by Ryan Lubke [ 24/Jun/09 08:57 AM ]

ViewHandlingStrategy.retargetMethodExpressions() is also affected by this.

Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 07:55 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:01 AM ]

frame

Comment by Ed Burns [ 22/Mar/10 11:07 AM ]

component

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 02:05 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 12:25 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:34 PM ]

triage





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 580
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, mojavelinux and rogerk

 Description   

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

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

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



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by mojavelinux [ 18/Dec/09 01:24 PM ]

Update target milestone to 2.1

Comment by mojavelinux [ 18/Dec/09 01:27 PM ]

Update subcomponent to Components/Renderers

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 23/Jun/10 08:11 AM ]

triage

Comment by rogerk [ 27/Oct/10 12:25 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:34 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-583] Message/Messages Rendering When No Messages Created: 06/Jul/09  Updated: 24/Jan/14

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 583
Status Whiteboard:

cat2 renderkitdoc size_small importance_medium

Tags:
Participants: Ed Burns and rogerk

 Description   

Need to spec the following which coincides with
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1088 :

For a message tag, if there is a user specified "id" value, and there are no
messages to output, then output an empty <span> tag, containing only that 'id'
attribute.

For a messages tag, if there is a user specified "id" value, output an empty
<div> tag, containing only that 'id' attribute if both of the following
conditions are true:

  • there are no messages to output
  • the messages block is not the special case of messages for development stage


 Comments   
Comment by rogerk [ 06/Jul/09 11:16 AM ]

Target says 2.1 but will be for 2.0 MR.

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by rogerk [ 20/Jan/10 11:27 AM ]

Target 2.0 Rev A

Comment by Ed Burns [ 04/Mar/10 12:13 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 06:35 AM ]

rk

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 09:38 PM ]

triage

Comment by rogerk [ 27/Oct/10 12:26 PM ]

triage - rkit docs

Comment by rogerk [ 16/Nov/10 12:35 PM ]

triage





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 600
Status Whiteboard:

cat2 frame size_small importance_large

Tags:
Participants: Ed Burns and ntruchsess

 Description   

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

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

will not assign anything to bean.comp

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



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:42 AM ]

Prepare to delete "implementation" subcomponent.

Comment by Ed Burns [ 24/Feb/10 09:53 AM ]

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

Comment by Ed Burns [ 04/Mar/10 01:35 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 06:47 AM ]

frame

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 02:12 PM ]

triage

Comment by Ed Burns [ 24/Jun/10 02:41 PM ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 01:31 PM ]

Move these to 2.2





[JAVASERVERFACES_SPEC_PUBLIC-601] Support for "class" attribute in composite components Created: 04/Aug/09  Updated: 24/Jan/14

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 601
Status Whiteboard:

cat2 frame size_small importance_medium

Tags:
Participants: Ed Burns, rogerk and rostislav

 Description   

The Facelets library adds a "class" alias pointing to the "styleClass" attribute
for all the JSF components. Since this is now available out of the box in JSF2
it will be good if the same feature is enabled for the composite components.

Currently supported, but not sure if specified:
<h:outputText value="Text" class="text" />

Currently unsupported, but good to have:
<composite:outputText value="Text" class="text" />

More description and a RI patch at:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1234



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 24/Feb/10 09:54 AM ]

too big for 2.0 Rev a

Comment by rogerk [ 05/Mar/10 07:59 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 06:52 AM ]

frame

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 02:14 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 12:59 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:35 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-625] Unable to reset client ID when a component is re-parented Created: 02/Sep/09  Updated: 24/Jan/14

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

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

Operating System: All
Platform: Macintosh


Issue Links:
Related
is related to JAVASERVERFACES-817 setParent don't reset the clientID pr... Closed
Issuezilla Id: 625
Status Whiteboard:

cat2 javadoc size_medium importance_large

Tags:
Participants: Ed Burns, rogerk and Ryan Lubke

 Description   

Consider the case where a component Z is a child of NamingContainer A. Call
getClientId() on Z. Then reparent component Z to be a child of NamingContainer
B. Calling getClientId() will return the client ID that that includes the id of
NamingContainer A.

It would be good to have a method in UIComponent to clear the clientID since
this value will, most times, be cached.



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:42 AM ]

Prepare to delete "implementation" subcomponent.

Comment by rogerk [ 05/Mar/10 08:04 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 10:46 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 23/Jun/10 07:27 AM ]

triage

Comment by rogerk [ 27/Oct/10 01:03 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:36 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-627] Inconsistent column styles handling with h:dataTable Created: 09/Sep/09  Updated: 04/Feb/14

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

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

Operating System: All
Platform: All


Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-217 Add a styleClass attribute to h:column Open
Issuezilla Id: 627
Status Whiteboard:

cat2 renderkitdoc size_small importance_small

Tags:
Participants: Ed Burns, frankwhofmann, lu4242, mojavelinux and rogerk

 Description   

I think the handling of column classes of the h:dataTable is not consistent.
Looking at the code on the calling page, you have the 'columnClasses' attribute
on the one side and h:column tags within the xhml body on the other side. Both
should correspond to each other, especially because the data type displayed in
the column and it's visual style are closely connected (e.g. you would
right-justify a number type and display booleans as a checkbox-like symbol).

I now you decide, that you want to use the 'rendered' attribute on some of the
h:column subelements to temporarily hide those columns, the mapping between
columns and its style class should not be lost. But this is the case with the
current implementation.

A static columnClasses attribute should do and should stay consistent with the
static h:column tags in the xhtml code. The dynamic behaviour should happen on
the serverside, rendering subsets of the given columns should also consider the
right subset of the given columnClasses.

Note that instead of putting comma-separated styleClass names into the attribute
of the h:dataTable the spec could also allow to put them as a single-valued
styleClass attribute directly into the corresponding h:column subelement – the
whole issue would not exist then.

So IMHO it's an unnecessary implementation effort to constantly supply an
appropriate sublist (also needed to be converted to a comma-separted string) as
a dynamic 'columnClasses' attribute to h:dataTable.

[see also JSF-2-RI issue 1258 at
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1258 – Contrary to
my misleading comment there this not a matter of whether PPR/ajax is used or not]



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by mojavelinux [ 01/Mar/10 03:00 PM ]

Link issues.

Comment by mojavelinux [ 01/Mar/10 03:01 PM ]

Update milestone and component.

Comment by Ed Burns [ 03/Mar/10 11:35 AM ]

DG> +1. columnClasses is clumsy for large tables, and h:column's lack of style
DG> and styleClass is non-intuitive. We have to make it clear which has
DG> precedence between h:dataTable's columnClasses and h:column's styleClass,
DG> though.

Comment by Ed Burns [ 03/Mar/10 11:45 AM ]

Here's the first on this. From Craig McClanahan in 2002:

CM> Attribute "columnClasses" - Some renderers support an attribute of
CM> this name, which contains a comma-delimited list of CSS style
CM> classes that will be used in sequence. If a rendered table has more
CM> columns than the number of class names in this list, it will be
CM> restarted from the beginning as many times as needed. However, the
CM> first column in a new row will always be rendered with the first
CM> class listed here.

But then, interestingly, David Geary says, on 18 Dec 2003:

DG> The columnClasses attribute doesn't work for tables that add or
DG> remove columns. I suggest we remove that attribute and add a
DG> styleClass attribute to <h:column>.

Hans Bergsten later followed up on 22 Jan 2004:

HB> I'm going through my mailbox and found this old suggestion from
HB> David, and I can't see that it was discussed at all.

HB> It may be too late, but maybe we can consider this a bug and still fix
HB> it for 1.0. That would also solve a problem reported in the forum:

HB> <http://forum.java.sun.com/thread.jsp?forum=427&thread=484248>

HB> With a "styleClass" attribute on <h:column>, the forum issue could
HB> be handled with a JSF EL expression:

HB> <h:data_table var="foo" ...>
HB> <h:column styleClass="#{foo.style}">
HB> ...
HB> </h:column>
HB> </h:data_table>

And later, on 5 Feb 2004

HB> I guess this one didn't make it (which is too bad), but we must at
HB> least include that the <h:column> action exists, even if it doesn't
HB> have any attributes or a renderer.

HB> A problem with putting all renderer attribute descriptions in a separate
HB> file is that we don't have any real description of the HTML tag
HB> library, and actions without a renderer aren't described at all (the
HB> <h:column> action may be the only one). Maybe section 9.5 should still
HB> have a subsection per action, but refer to the renderer document for
HB> details in case the combo is described there.

So we see that this is something that has simply been dropped.

Comment by Ed Burns [ 04/Mar/10 12:04 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:23 AM ]

renderkit

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 12:59 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 01:03 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:37 PM ]

triage

Comment by lu4242 [ 04/Feb/14 04:32 PM ]

This issue has been reported recently on stackoverflow:

http://stackoverflow.com/questions/21555952/myfaces-datatable-columnclasses-strange-behaviour

It shows that the behavior of columnClasses is not intuitive. Since we cannot really change columnClasses without break some existing code, JAVASERVERFACES_SPEC_PUBLIC-217 should be fixed.





[JAVASERVERFACES_SPEC_PUBLIC-634] Add an escape attribute to h:messages and h:message like in h:outputText Created: 22/Sep/09  Updated: 27/Dec/13

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

Type: Improvement Priority: Major
Reporter: rdelaplante Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 634
Status Whiteboard:

cat2 renderkitdoc size_small importance_medium

Tags:
Participants: bleathem, cagatay_civici, Ed Burns, kellerapps, rdelaplante, rogerk and sheetalv

 Description   

I want to output an HTML link as part of my error message, but can't because the
HTML is escaped by h:messages. I searched Google for a workaround and found
many people have the same problem. There have even been tickets created against
JSF RI and MyFaces years ago.

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=746
http://issues.apache.org/jira/browse/MYFACES-155



 Comments   
Comment by Ed Burns [ 24/Sep/09 09:13 AM ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 07:40 AM ]

Prepare to delete api subcomponent

Comment by rogerk [ 24/Feb/10 08:18 AM ]

Target 2.0 Rev A

Comment by Ed Burns [ 04/Mar/10 11:40 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 10:49 AM ]

rk

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by sheetalv [ 10/Jun/10 12:40 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 01:04 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:37 PM ]

triage

Comment by kellerapps [ 18/Apr/11 01:09 PM ]

I understand the use case. I'm not convinced HTML is the best way to express this sort of thing. Maybe Message should be enriched to express link & emphasis.

Comment by bleathem [ 03/Apr/12 05:53 PM ]

RichFaces supports this attribute with it's rich:message component (see: http://docs.jboss.org/richfaces/latest_4_X/vdldoc/rich/message.html)

Primefaces also supports this attirbute in it's message tag:
http://blog.primefaces.org/?p=1894

It seems to me it's something the community is asking for, and should be rolled into the spec.

Comment by cagatay_civici [ 03/Apr/12 08:54 PM ]

I agree that this should be in spec, I've seen various posts in PrimeFaces forum and stackoverflow from users who are looking for this.

Comment by rdelaplante [ 04/Apr/12 05:30 PM ]

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.





[JAVASERVERFACES_SPEC_PUBLIC-641] Consider disallowing composite component recursion Created: 25/Sep/09  Updated: 27/Dec/13

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 641
Status Whiteboard:

cat2 javadoc size_medium importance_medium

Tags:
Participants: Ed Burns, rogerk and Ryan Lubke

 Description   

Consider:

Using Page:
-----------------------
<h:form id="f">
<cc:compcomp id="outer" attr="foo"/>
</h:form>

compcomp.xhtml
----------------------
<cc:implementation>
#{component.clientId} Do something fancy here<br />
<c:if test="#{cc.attrs.attr != 'stop'}">
<test:compcomp id="inner" attr="stop">
<h:outputText value="#{cc.clientId}
#{cc.attrs.attr}"/><br />
</test:compcomp>
</c:if>
<cc:insertChildren />
#{component.clientId} Do even more fancy stuff here... <br />
</cc:implementation>

Should this be allowed?

In the example above, <h:outputText value="#{cc.clientId} #{cc.attrs.attr}"/>
will display the inner composite client ID and the value 'stop', when the actual
intent was to display the outer id and the value 'foo'.

The updated #{cc} resolution semantics require that #{cc} expressions resolve
the composite component relative to the template they were defined in, however,
with the current API, we have no way to disambiguate which component to use.



 Comments   
Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 02:02 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 10:52 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 23/Jun/10 07:31 AM ]

triage

Comment by rogerk [ 27/Oct/10 01:07 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:38 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-648] Make it possible to ask a Renderer for its family and renderer-type. Created: 10/Oct/09  Updated: 27/Dec/13

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 648
Status Whiteboard:

cat2 javadoc size_medium importance_medium

Tags:
Participants: Ed Burns and rogerk

 Description   

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



 Comments   
Comment by Ed Burns [ 24/Nov/09 07:48 AM ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 01:53 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 10:53 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 23/Jun/10 07:20 AM ]

size_medium importance_medium

Comment by rogerk [ 23/Jun/10 07:20 AM ]

triage

Comment by rogerk [ 27/Oct/10 01:08 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:38 PM ]

triage





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

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

Type: Task Priority: Major
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 677
Status Whiteboard:

cat2 vdldoc size_small importance_small

Tags:
Participants: Ed Burns, Jakob Korherr, mojavelinux, paul_dijou and rogerk

 Description   

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

However, the spec never mentions that fact.



 Comments   
Comment by mojavelinux [ 18/Dec/09 01:42 PM ]

Update milestone to 2.0 Rev a

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

Comment by Ed Burns [ 04/Mar/10 12:09 PM ]

cat2

Comment by Ed Burns [ 04/Mar/10 01:07 PM ]
      • Issue 522 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 22/Mar/10 11:26 AM ]

vdldoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 01:18 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by Ed Burns [ 30/Jun/10 07:20 PM ]

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

On Wed, 13 Nov 2002, Craig McClanahan wrote:

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

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

On Fri, 15 Nov 2002 Adam Winer wrote:

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

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

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

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

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

Comment by Jakob Korherr [ 02/Jul/10 05:45 AM ]

Yes, of course this is OK for me!

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

Thanks!

Comment by Ed Burns [ 02/Aug/10 10:24 AM ]

fix summary as described

Comment by rogerk [ 27/Oct/10 01:15 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:42 PM ]

triage

Comment by paul_dijou [ 13/Jun/12 10:01 AM ]

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

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

Regards





[JAVASERVERFACES_SPEC_PUBLIC-686] Missing public constant for INTERPRET_EMPTY_STRING_SUBMITTED_VALUES_AS_NULL Created: 02/Dec/09  Updated: 23/Dec/13

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 686
Status Whiteboard:

cat1 javadoc size_small importance_medium

Tags:
Participants: Ed Burns, rogerk and Ryan Lubke

 Description   

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

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



 Comments   
Comment by Ed Burns [ 04/Mar/10 01:59 PM ]

cat1

Comment by Ed Burns [ 16/Mar/10 10:47 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:52 AM ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 10:46 AM ]

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

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 23/Jun/10 07:26 AM ]

triage

Comment by rogerk [ 27/Oct/10 01:16 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:44 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-693] h:panelGrid should warn about table layout Created: 11/Dec/09  Updated: 23/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 693
Status Whiteboard:

cat2 renderkitdoc size_small importance_medium

Tags:
Participants: driscoll, Ed Burns and rogerk

 Description   

The PDL for h:panelGrid should warn that table layout is not considered a very
effective way of organizing a page, and should instead mention css and the
styleClass attribute as a way to layout pages.



 Comments   
Comment by rogerk [ 11/Dec/09 11:53 AM ]

2.next

Comment by Ed Burns [ 14/Dec/09 08:59 AM ]

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

Comment by Ed Burns [ 16/Feb/10 06:16 PM ]

2.0 Rev b

Comment by rogerk [ 24/Feb/10 08:19 AM ]

Target 2.0 Rev A

Comment by Ed Burns [ 04/Mar/10 12:10 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:26 AM ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 23/Jun/10 07:48 AM ]

triage

Comment by rogerk [ 27/Oct/10 01:17 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:46 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-701] behavior simplification Created: 16/Dec/09  Updated: 23/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 701
Status Whiteboard:

size_large importance_large

Tags:
Participants: Ed Burns, mojavelinux and rogerk

 Description   

I (David Geary) would like to see a simplification along the lines of the
simplifications we made to component development for JSF 2.0 with composite
components.

Ideally, it would be great if we could just implement, for example, a JS file
(like we now just implement a view template for composite components), and have
that transform into a behavior, complete with tag, that page authors can attach
to components, again, similar to the way we transform view templates with
composite component implementations into component tags.

There does seem to be a fair bit of boilerplate (20+ lines) that you have to add
to every single component that you want to be behavior aware. It should be
possible to capture that for the simple case, at least (i.e., the component is
otherwise not operating on any DOM events).



 Comments   
Comment by mojavelinux [ 16/Dec/09 08:11 AM ]

Set milestone to 2.1

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 23/Jun/10 08:12 AM ]

triage

Comment by rogerk [ 27/Oct/10 01:18 PM ]

triage - nice

Comment by rogerk [ 16/Nov/10 12:46 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-704] UIRepeat et al are not specified Created: 16/Dec/09  Updated: 23/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 704
Status Whiteboard:

cat2 javadoc size_medium importance_large draft

Tags:
Participants: Ed Burns, mwessendorf and rogerk

 Description   

with JSF 2.0, thanks to Facelets, there is a <ui:repeat>. While I understand
that tags/rendering behavior is part of the internals of an implementation, I am
not really sure if the underlying/related components should be "hidden" by the
spec as well.

For instance: I noticed that in MyFaces the UIRepeat extends UIComponentBase and
implements NamingContainer, while with the JSF RI / Mojarra, the UIRepeat "just"
extends the UINamingContainer...

... and oh yes... I know that UINamingContainer extends UIComponentBase and
implements NamingContainer....

but instanceof UINamingContainer doesn't say TRUE for the MyFaces UIRepeat

See a community related discussion here:
http://markmail.org/message/wllfudu4ge7n5gxa



 Comments   
Comment by Ed Burns [ 04/Mar/10 01:58 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:28 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 23/Jun/10 07:25 AM ]

triage

Comment by Ed Burns [ 19/Jul/10 11:35 AM ]

https://glassfish.dev.java.net/issues/show_bug.cgi?id=11785

On Mon Apr 12 15:57:00 +0000 2010, mohammadalavi MA wrote

MA> I've found 2 bugs in jsf 1.2 here's the list
MA>
MA>
MA> 1.when h:dataTable's parent is ui:repeat from facelet duplicated ids
MA> are generated for child component because UIData's
MA> isNestedWithinUIData method reports true
MA> only when the parent is an instance of UIData and UIRepeat is not.
MA> of course the problem happens because the UIData's getClientId method
MA> caches the parent client id when isNestedWithinUIData returns false
MA> if it never cache parent client id this problem wont happen.
MA>
MA> public String getClientId(FacesContext context) {
MA> if (context == null) { MA> throw new NullPointerException(); MA> }
MA> if (rowIndex >= 0) { MA> String cidBuilder = new StringBuilder(); MA> return cidBuilder.append(super.getClientId(context)) MA> .append(NamingContainer.SEPARATOR_CHAR).append(rowIndex) MA> .toString(); MA> } else { MA> return super.getClientId(context); MA> }
MA> }
MA> 2.TableMetaInfo a static inner class in BaseTableRenderer is used for
MA> managing style for columns and rows, the getCurrentColumnClass method
MA> doesn't work as expected it doesn't repeat the styles when number of
MA> columns is grater than column classes it should be implemented as
MA> follows:
MA>
MA> public String getCurrentColumnClass() {
MA>
MA> String style = null;
MA> if (columnStyleCounter < columnClasses.length &&
MA> columnStyleCounter < columnCount) { MA> style = columnClasses[columnStyleCounter++]; MA> }
MA> if(columnStyleCounter >= columnClasses.length) { MA> columnStyleCounter = 0; MA> }
MA> return ((style != null && style.length() > 0) ? style : null);

Comment by rogerk [ 27/Oct/10 01:27 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:46 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-713] h:datatable component to handle multiple entities lists Created: 02/Jan/10  Updated: 23/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 713
Status Whiteboard:

cat2 renderkitdoc size_medium importance_large

Tags:
Participants: Ed Burns, longbeach and rogerk

 Description   

I think a nice feature for the h:datatable component would be to make it handle
lists that have multiple entities.

For instance, JPQL queries can return results based on multiple entities.
Currently one needs to create a DTO to handle these results and iterate through
it in a h:datable component. They're might be other solutions of course but it
would be neat if that could be handled natively with the h:datable component.



 Comments   
Comment by Ed Burns [ 04/Mar/10 12:11 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:30 AM ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 02:06 PM ]

target

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 01:28 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:46 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-739] ExternalContext => getServerInfo() is missing Created: 04/Feb/10  Updated: 20/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 739
Status Whiteboard:

cat2 javadoc size_small importance_small

Tags:
Participants: Ed Burns, mwessendorf and rogerk

 Description   

ExternalContext => getServerInfo() is missing



 Comments   
Comment by Ed Burns [ 04/Mar/10 12:16 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:37 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by rogerk [ 18/Jun/10 03:07 AM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 02:00 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:48 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-751] Implement Serializable on DataModel Created: 20/Feb/10  Updated: 20/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 751
Status Whiteboard:

cat2 javadoc size_small importance_large draft

Tags:
Participants: Ed Burns, ramiromagalhaes and rogerk

 Description   

Certain servers, such as Weblogic, have a clustering mechanism that allows
objects stored in session to be replicated through its cluster nodes by
serializing such objects.

It seems to me to be pretty usual for people to put in session instances of
DataModel, but this can't be done while leveraging the clustering mechanisms
above mentioned without some workaround like extending some DataModel
implementation and then making this extension implement java.io.Serializable.

So, I propose changing DataModel so that it implements java.io.Serializable.



 Comments   
Comment by Ed Burns [ 04/Mar/10 12:22 PM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:04 AM ]

javadoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 02:13 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 02:05 PM ]

triage

Comment by ramiromagalhaes [ 11/Nov/10 04:47 AM ]

Is there a reason for the postponing of this issue to JSF 2.2? I mean, this
issue is simple to implement, will simplify the usage of JSF and I do not see
any backward compatibility issue being raised by doing it.

Comment by rogerk [ 16/Nov/10 12:48 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-756] <h:column> hides native HTML <td> tag attributes. Created: 02/Mar/10  Updated: 20/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 756
Status Whiteboard:

cat2 renderkitdoc size_small importance_small

Tags:
Participants: Ed Burns, lincolnbaxter and rogerk

 Description   

There's no simple way of setting the HTML attributes on each column (width,
align, etc.) You have to go through CSS styles, which is a more complex way
(albeit better long-term way) of making static width tables / columns.

<h:column> should support the native HTML tag attributes applicable for <td>
elements:

A complete list of attributes can be found here
(http://w3schools.com/tags/tag_td.asp) but the most critical are:

align, valign



 Comments   
Comment by Ed Burns [ 04/Mar/10 11:52 AM ]

cat2

Comment by Ed Burns [ 22/Mar/10 11:40 AM ]

renderkitdoc

Comment by Ed Burns [ 15/May/10 07:54 AM ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 01:34 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 02:09 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:49 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-764] Layout manager components Created: 09/Mar/10  Updated: 20/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 764
Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns and rogerk

 Description   

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

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



 Comments   
Comment by Ed Burns [ 18/May/10 02:05 PM ]

Move to unscheduled.

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 23/Jun/10 07:19 AM ]

triage

Comment by rogerk [ 27/Oct/10 02:11 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:53 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-770] add component resources depending on the owner component state Created: 17/Mar/10  Updated: 20/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 770
Status Whiteboard:

size_large importance_small

Tags:
Participants: Ed Burns, lu4242 and rogerk

 Description   

All this text is extracted from jsr-314-open mailing list and it is put here as
reference.

[jsr-314-open] add component resources depending on the owner component state

Trying to use the new JSF 2.0 Resource Api I have found one case that maybe it
is of interest on this list.

Suppose a component that needs to add some specific javascript/css file based on
a value. In tomahawk we can do it something like this on the renderer:

if( tabbedPane.isClientSide() ){
addResource.addJavaScriptAtPosition(facesContext,
AddResource.HEADER_BEGIN, HtmlTabbedPaneRenderer.class, "dynamicTabs.js");

This code works because the response is buffered and post-processed.

The problem is how to do that with JSF 2.0?

One could think on use a listener attached to PreRenderComponentEvent, but this
event is called before encodeBegin, so it is useless in this case, because we
need to call it before the whole view is rendered.

Then, you can think do something like this:

@ListenerFor(systemEventClass = PreRenderViewEvent.class)
public class HtmlTabbedPaneRenderer extends HtmlRenderer
......

It does not work too. The reason is the listener is attached to the component
instance, and only the UIViewRoot instance receives the event. If we do the same
as f:event does when PreRenderViewEvent is found (suscribe the listener on
UIViewRoot) we lose the component we are referencing, because it is replaced by
UIViewRoot.

I can solve this one creating a wrapper for ViewHandler that publish a custom
event for all components before render view. but the big question is if jsf 2.0
should support this use case out of the box.

>> Cagatay Civici
>> Why not listening to PostAddToViewEvent with;
>>
>>
>> @ListenerFor(systemEventClass = PostAddToViewEvent.class)
>>public class HtmlTabbedPane extends UIComponentBase { >>}
>>
>> and in event listener;
>>
>> if(this.isClientSide()) {
>> viewroot.addComponentResource(...);
>>

Does not work too because in a postback, PostAddToViewEvent occur in the
following cases:

  • With Partial State Saving enabled when the view is build but before the state
    of the component is restored.
  • With Partial State Saving disabled when the view is "refreshed", because all
    component nodes are detached and attached to the tree.

Now suppose the component has a ValueExpression attached to the property, and
the value changes on Invoke Application Phase. With partial state saving the
tree was already build, so it doesn't catch the logic. With partial state saving
disabled, the event occur twice, the first time when the tree structure is
build, the second time when the view is updated, so again it doesn't work,
because if the resource component (it is transient too) was already added, it
cannot be removed later.

>> Ed Burns
>>
>>Please correct me if I'm wrong, but the problem you state above seems to
>>be just another example of the garden variety "conditional value changes
>>between requests or during a request".
>>

Yes and no. The difference with other examples of the garden is to add a
component resource, we need to do it in the right time, since it requires to
update the component tree adding components before render it, but after we know
which view will be rendered. Please note by a previous fix, all component
resources are transient.

As a side note, if someone wants to do this in a composite component he/she
probable do this:

<c:if test="#{cc.attrs.....}">
<h:outputStylesheet ..../>
</c:if>

And it works in myfaces because we have a fix for the c:if problem.

>> Do we need PreAddComponentResourceEvent and
>> PostAddComponentResourceEvent?

In my opinion is only necessary to add only one event. The right place is after
resolve PreRenderViewEvent, because only in that time we know the current
component tree is the view that will be rendered.

It is not possible to use PreRenderComponentEvent because it is called on
encodeBegin and the view header was already rendered.

It is not possible to use PreRenderViewEvent like this:

@ListenerFor(systemEventClass = PreRenderViewEvent.class)
public class HtmlTabbedPaneRenderer extends HtmlRenderer

because the listener is attached to the component when it is created, but the
event is only received by the current UIViewRoot. If we fix the algorithm on
Application class to attach this listener to the current UIViewRoot instance,
the source of the event will be UIViewRoot, and traverse the tree to find the
component is worse. Note other option is publish PreRenderViewEvent for all
child components, but after know the view that will be rendered.

In conclusion, for make this use case possible we need two things:

1. The right time to add the resource to the component tree.
2. The component with its state restored and updated.

Thinking more about it, another option about put this code could be on
vld.buildView method, but note when partial state saving is enabled this method
return immediately (maybe it is possible to change it).



 Comments   
Comment by Ed Burns [ 18/May/10 02:10 PM ]

Move to 2.1

Comment by Ed Burns [ 08/Jun/10 01:09 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 02:12 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:53 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-776] <h:form> should support method=GET Created: 24/Mar/10  Updated: 08/Nov/13

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

Type: Improvement Priority: Major
Reporter: lincolnbaxter Assignee: Unassigned
Resolution: Unresolved Votes: 12
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 3 days
Environment:

Operating System: All
Platform: All


Issuezilla Id: 776
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: arjan tijms, Ed Burns, kito75, lincolnbaxter and rogerk

 Description   

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

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

or even simpler:

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

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

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



 Comments   
Comment by Ed Burns [ 18/May/10 02:12 PM ]

Requires impl change. Move to 2.1.

Comment by Ed Burns [ 08/Jun/10 01:33 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 02:12 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:53 PM ]

triage

Comment by kito75 [ 20/Apr/11 06:52 AM ]

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

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

Comment by lincolnbaxter [ 20/Apr/11 02:16 PM ]

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

Comment by arjan tijms [ 08/May/12 09:35 PM ]

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

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





[JAVASERVERFACES_SPEC_PUBLIC-792] Cannot call UIComponent.getCurrentComponent() from UIComponent.restoreState() or UIComponent.saveState() Created: 11/May/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 792
Status Whiteboard:

size_medium importance_large

Tags: adf
Participants: Ed Burns and lu4242

 Description   

From jsr-314-open list:

The javadoc of UIComponent.processRestoreState() says this:

"....Perform the component tree processing required by the Restore View phase
of the request processing lifecycle for all facets of this component, all
children of this component, and this component itself, as follows.

  • Call the restoreState() method of this component.
  • Call pushComponentToEL(javax.faces.context.FacesContext,
    javax.faces.component.UIComponent).
  • Call the processRestoreState() method of all facets and children of this
    UIComponent in the order determined by a call to getFacetsAndChildren(). After
    returning from the processRestoreState() method on a child or facet, call
    popComponentFromEL(javax.faces.context.FacesContext)..."

The javadoc of UIComponent.processSaveState() says this:

".....Perform the component tree processing required by the state saving portion
of the Render Response phase of the request processing lifecycle for all facets
of this component, all children of this component, and this component itself, as
follows.

  • consult the transient property of this component. If true, just return null.
  • Call pushComponentToEL(javax.faces.context.FacesContext,
    javax.faces.component.UIComponent).
  • Call the processSaveState() method of all facets and children of this
    UIComponent in the order determined by a call to getFacetsAndChildren(),
    skipping children and facets that are transient. Ensure that
    popComponentFromEL(javax.faces.context.FacesContext) is called correctly after
    each child or facet.
  • Call the saveState() method of this component.
  • Encapsulate the child state and your state into a Serializable Object and
    return it....."

The question is: Doesn't suppose that when you call
UIComponent.getCurrentComponent() inside UIComponent.restoreState(), it returns
the "current component"?. There is one case when we need to do this call and is
on the wrapper used by UIComponent.subscribeToEvent(). The javadoc of this
method says this:

"....Install the listener instance referenced by argument componentListener as a
listener for events of type eventClass originating from this specific instance
of UIComponent. The default implementation creates an inner SystemEventListener
instance that wraps argument componentListener as the listener argument. This
inner class must call through to the argument componentListener in its
implementation of
SystemEventListener.processEvent(javax.faces.event.SystemEvent) and its
implementation of SystemEventListener.isListenerForSource(java.lang.Object)
must return true if the instance class of this UIComponent is assignable from
the argument to isListenerForSource...."

Both myfaces and mojarra has the wrapper described by the javadoc, and that one
is responsible to save/restore the system event listeners attached. To restore
the "component" reference required, both implementations call
UIComponent.getCurrentComponent() and both call processEvent but for the parent!.

It is obviously a bug (I don't see a valid reason why do the algorithm
described), if you look other methods like processDecodes, you see the right
pattern:

  • If the rendered property of this UIComponent is false, skip further
    processing.
  • Call pushComponentToEL(javax.faces.context.FacesContext,
    javax.faces.component.UIComponent).
  • Call the processDecodes() method of all facets and children of this
    UIComponent, in the order determined by a call to getFacetsAndChildren().
  • Call the decode() method of this component.
  • Call popComponentFromEL(javax.faces.context.FacesContext) from inside of a
    finally block, just before returning.
  • If a RuntimeException is thrown during decode processing, call
    FacesContext.renderResponse() and re-throw the exception.

I'll change myfaces algorithm to look like processDecodes(). But anyway, it is
necessary to do the proper change on mojarra and on spec javadoc.



 Comments   
Comment by Ed Burns [ 11/May/10 09:19 AM ]

LU> To restore the "component" reference required, both implementations
LU> call UIComponent.getCurrentComponent() and both call processEvent
LU> but for the parent!

Is the bug that we call processEvent on the parent, and not the
"correct" instance?

Comment by Ed Burns [ 18/May/10 12:48 PM ]

>>>>> On Tue, 11 May 2010 11:29:26 -0500, Leonardo Uribe said:

LU> In this case, I'm thinking the bug is do not include restoreState /
LU> saveState on the call. In other words, instead do this:

LU> * Call the restoreState() method of this component.
LU> * Call pushComponentToEL(javax.faces.context.FacesContext,
LU> javax.faces.component.UIComponent).
LU> * Call the processRestoreState() method of all facets and children of
LU> this UIComponent in the order determined by a call to
LU> getFacetsAndChildren(). After returning from the processRestoreState()
LU> method on a child or facet, call
LU> popComponentFromEL(javax.faces.context.FacesContext)..."

LU> Do the following

LU> * Call pushComponentToEL(javax.faces.context.FacesContext,
LU> javax.faces.component.UIComponent).
LU> * Call the restoreState() method of this component.
LU> * Call the processRestoreState() method of all facets and children of
LU> this UIComponent in the order determined by a call to
LU> getFacetsAndChildren(). After returning from the processRestoreState()
LU> method on a child or facet, call
LU> popComponentFromEL(javax.faces.context.FacesContext)..."

LU> In myfaces code, I found I did the latests in our pss algorithm. Really I
LU> discover this bug when I disable pss and try a tomahawk example. As it was
LU> described, both myfaces and mojarra fell in the ilusion the latest strategy
LU> was used.

Comment by Ed Burns [ 24/May/10 11:05 AM ]
      • Issue 799 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 24/May/10 12:55 PM ]

take ownership.

Comment by Ed Burns [ 26/May/10 05:40 PM ]

I made the change in my local workspace and am now re-running our automated test suite.

Comment by Ed Burns [ 26/May/10 06:51 PM ]

Hmm, I ran into a very strange case when I changed the code as you suggested.

Before the change: this works

nesting05.xhtml uses composite component

<ez:nesting6 id="nesting6" bean="#{compositeBean}" />

the composite component has this:

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

<composite:implementation>
<ez:nesting7 id="nesting7" action="#{cc.attrs.bean.action}"
actionListener="#{cc.attrs.bean.actionListener}"
validator="#{cc.attrs.bean.validate}"
valueChangeListener="#{cc.attrs.bean.valueChange}"
bean="#{cc.attrs.bean}"/>
</composite:implementation>

nesting7.xhtml has

<composite:interface>
<composite:attribute name="action" method-signature="String method()"
targets="form1:command" />
<composite:attribute name="actionListener" method-signature="void
method(javax.faces.event.ActionEvent)" targets="form2:command2" />
<composite:attribute name="validator" method-signature="void
validate(javax.faces.context.FacesContext, javax.faces.component.UIComponent, java.lang.Object)"
targets="form4:input" />
<composite:attribute name="valueChangeListener" method-signature="void
valueChange(javax.faces.event.ValueChangeEvent)" targets="form5:input2" />
<composite:attribute name="bean" type="com.sun.faces.composite.CompositeBean" />
</composite:interface>
<composite:implementation>
<h:form id="form1">
<h:commandButton id="command" value="action" />
</h:form>
<br />
<h:form id="form2">
<h:commandButton id="command2" value="actionListener" />
</h:form>
<br />
<h:form id="form3">
<h:commandButton id="command3" value="custom" action="#{cc.attrs.bean.custom}"/>
</h:form>
<br />
<h:form id="form4">
<h:inputText id="input" />
<h:commandButton id="command" value="valiator"/>
</h:form>
<br />
<h:form id="form5">
<h:inputText id="input2" />
<h:commandButton id="command" value="valueChange" />
</h:form>
</composite:implementation>

Clicking the action button with id "command" gives me:

Action invoked: nesting6:nesting7:form1:command.

With the change in place, I get a facelets error stating that "bean" is a required attribute, even
though it is, in fact, given on the using page, nesting05.xhtml.

Rather than investigate this further, I'm going to push this to 2.1.

Comment by lu4242 [ 28/May/10 04:10 PM ]

Strange. That example does not seems to be related. There is not any problems in
myfaces, because the only place where UIComponent.getCurrentComponent() is
called is from UIComponent system event listener wrapper. I think it is safe to
do the change (at least on myfaces codebase), because it is very unlikely this
scenario happens.

Comment by Ed Burns [ 01/Jun/10 07:42 AM ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 01:11 PM ]

triage

Comment by Ed Burns [ 24/Jun/10 02:41 PM ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 02:50 PM ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 03/Nov/10 03:06 PM ]

2.2

Comment by Ed Burns [ 19/Dec/13 10:57 PM ]

2.3





[JAVASERVERFACES_SPEC_PUBLIC-795] UIViewParameter state saving algorithm Created: 12/May/10  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 6
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 795
Status Whiteboard:

size_small importance_medium

Tags:
Participants: Ed Burns, Jakob Korherr, kithouna, nullone and rogerk

 Description   

From the mail "State saving of UIViewParameter" on jsr-314-open:

UIViewParameter uses the submittedValue to store its value in the state for the
next postback, because obviously the view parameter won't be in the request
parameter map of the next request (which is the postback). But because its
submittedValue is null after the conversions and validations, it has to be set
again before the state is generated. To accomplish that, the spec currently
states to override encodeAll() and make the call to setSubmittedValue() there.
In addition, encodeAll() has to be called in UIViewRoot.encodeEnd() for every
UIViewParameter in the view. This works perfectly for normal requests, but when
you are using an AJAX request the state is generated before
UIViewRoot.encodeEnd() is called an thus the submittedValue for every
UIViewParameter is null in the state. This means that the value of every
UIViewParameter will be null in the following request.

Now the easiest solution to this problem, which I also already committed to
MyFaces trunk (again see [1] for details), is to do mostly the same as in
UIViewRoot.encodeEnd() just also in PartialViewContext.
processPartial() when the PhaseId is RENDER_RESPONSE before the state is
generated to make it work for AJAX-requests.

However I don't really like this solution, because we have to think of handling
UIViewParameters in a special way every time we change something on any render
mechanism. Why don't we just override saveState() on UIViewParameter and set the
submittedValue there before the state is saved. This will have the same result,
but without the code in UIViewRoot, PartialViewContext and
UIViewParameter.encodeAll() and without future headaches. I also already
uploaded a patch for this to the MyFaces issue at [1].

Answer to this from Martin Marinschek: "This is just a so much better solution
. We should spec this one."

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



 Comments   
Comment by Ed Burns [ 17/May/10 06:42 AM ]

Move to 2.1.

I agree with this approach.

Comment by Ed Burns [ 08/Jun/10 01:16 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 02:17 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:55 PM ]

triage

Comment by kithouna [ 28/Feb/13 09:48 AM ]

Was anything ever done for this one?

Comment by nullone [ 28/Feb/13 08:18 PM ]

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.

Is that really amazing or the team is sleeping on its way?





[JAVASERVERFACES_SPEC_PUBLIC-796] Use the model value for a UIViewParameter only on a postbacks Created: 12/May/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 796
Status Whiteboard:

size_small importance_small

Tags:
Participants: Ed Burns, Jakob Korherr and rogerk

 Description   

Imagine you have a page with a required UIViewParameter called input. You will
get a validation error as long as you don't access the view with ?input=abc. Now
if you do that once, "abc" will be saved as the submittedValue in the state of
the UIViewParameter for every postback and thus will be available for every
further postback. If you now access the view again with a GET request
(non-postback), but without ?input=abc, you will again get a validation error.
However, if you hit any button or link on the view to generate another postback
to the view, the validation error will be gone, because UIViewParameter takes
the value from before ("abc") out of the model (managed-bean) and sets it in the
state. Thus you haven't provided it via ?input=abc, but you will now have a
value of "abc" for your UIViewParameter, which seems kinda wrong to me. The
solution to this one is to get the value from the model to set it as the
submittedValue in UIViewParameter only if the current request is a postback.
However I don't know if this really is an error or the expected behaviour. I
personally just think that it is weird.

Answer from Martin Marinschek: "I absolutely agree that we should do this only
on a postback - everything else is really, really weird behaviour."



 Comments   
Comment by Ed Burns [ 17/May/10 06:42 AM ]

Move to 2.1.

I agree with this approach.

Comment by Ed Burns [ 08/Jun/10 01:17 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 02:17 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:56 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-797] Use a custom renderer on a composite component Created: 13/May/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 797
Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns, lu4242 and rogerk

 Description   

See discussion on "[jsr-314-open] Use a Renderer on a composite component"

Below there are extracts of this one:

Leonardo Uribe says:

The javadoc of Application.createComponent(FacesContext context, Resource
componentResource) says this:

".....Call UIComponent.setRendererType(java.lang.String) on the UIComponent
instance, passing "javax.faces.Composite" as the argument........"

Now suppose a custom composite component extending from UIInput, but
implementing NamingContainer/UniqueIdVendor. The component family in this case
is "javax.faces.Input". The result is the component will not work because the
renderer used for composite components assumes the family
"javax.faces.NamingContainer". This is ok, because the user just need to
register a custom renderer for its composite component under that
family/rendererType like the spec says.

The problem is why it is mandatory to set "javax.faces.Composite" as renderer
type. The javadoc should say:

"...If the renderer type is not set (return null), Call
UIComponent.setRendererType(java.lang.String) on the UIComponent instance,
passing "javax.faces.Composite" as the argument...". In that case, a user can
override the rendererType on the constructor and avoid this hack that works with
the current spec:

public void setRendererType(String rendererType)
{
//Ignore this call !
if (!"javax.faces.Composite".equals(rendererType))

{ super.setRendererType(rendererType); }

}

Why override the default Renderer and use a custom one? Let's suppose the
component proposed needs some custom code for converter, or for decode. The
right place to put that kind of code is the Renderer class, not the component,
but note it is possible to put that on the component class.

Does that sounds reasonable? should I create an issue for this one?

Ed Burns says:

LU> The problem is why it is mandatory to set "javax.faces.Composite" as
LU> renderer type. The javadoc should say:

LU> "...If the renderer type is not set (return null), Call
LU>
UIComponent.setRendererType(java.lang.String)<file:///D:/jdk-1_5_0-doc/jsf20/mojarra-2.0.3-SNAPSHOT/docs/javadocs/javax/faces/component/UIComponent.html#setRendererType%28java.lang.String%29>on
LU> the
LU> UIComponent instance, passing "javax.faces.Composite" as the argument...".
LU> In that case, a user can override the rendererType on the constructor and
LU> avoid this hack that works with the current spec:

I understand the problem you have uncovered. Take a look at the
renderkit docs for javax.faces.NamingContainer/javax.faces.Composite.
There are specific requirements in there that depend on the composite
component metadata specification.

I thought it would be toooooooo subtle to allow the Renderer to be
customized beause this contract must also be followed in the custom
renderer case.

LU> Why override the default Renderer and use a custom one? Let's
LU> suppose the component proposed needs some custom code for converter,
LU> or for decode. The right place to put that kind of code is the
LU> Renderer class, not the component, but note it is possible to put
LU> that on the component class.

Yes I understand that the Renderer is the right place for such things
but the chosen programming model for customization of composite
components is to override the top level component. Simple. If we're
going to change that I need a more compelling reason than correctness.

Leonardo Uribe says:

The current behavior of javax.faces.NamingContainer/javax.faces.Composite
renderer says that everything
inside the facet UIComponent.COMPOSITE_FACET_NAME should be rendered. But sometimes
the markup of the component changes according to its inner state. One simple
example is
h:commandLink. If this component is disabled, it should be rendered a <span>
instead use <a>.
Other example is tomahawk displayValueOnly property, that when is set to true,
only the value
needs to be rendered.

Ok, if I have a composite component the first thought is use c:if tag, but
remember that with
partial state saving enabled this tag is evaluated when the view is build, not
when it is
rendered. Other alternative is use a component that allows to render one child
at the time, and
it is on myfaces commons (mc:renderOne, old sandbox s:limitRendered). The third
alternative is
use a custom renderer. The example I'm trying to do is this (all non relevant
code has been removed:

public void encodeEnd(FacesContext context, UIComponent component)
throws IOException
{
UIComponent compositeFacet = (UIComponent) component
.getFacet(UIComponent.COMPOSITE_FACET_NAME);
CompositeInputHtml editor = (CompositeInputHtml) component;
if( HtmlRendererUtils.isDisplayValueOnly(editor) )

{ encodeDisplayValueOnly(context, editor); }

else if ( useFallback(editor) )

{ encodeEndFallBackMode(context, editor); }

else
{
if( ! isVisible(editor) ){ encodeHidden(context, editor); }
else if( ! hasAnotherPropertyThatPreventsRenderThisOneCorrectly(
context ) )

{ compositeFacet.encodeAll(context); }

else

{ encodeEndFallBackMode(context, editor); }

}
}

It is possible to think in other cases, like a composite component like this:

<composite:implementation>
<f:facet name="normal">
......some html markup......
</f:facet>
<f:facet name="disabled">
......some html markup......
</f:facet>
<f:facet name="special">
......some html markup......
</f:facet>
<composite:implementation>

And use a custom renderer to control when one or other facet should be rendered.

Note that in fact, with the hack on the component class on setRendererType, it
is possible
to override the Renderer without problem, so for my particular problem I can
live with it.
The question is if the spec should enforce the use of
javax.faces.NamingContainer/javax.faces.Composite renderer for composite components
or not.



 Comments   
Comment by Ed Burns [ 24/May/10 11:03 AM ]

Nice idea, move to 2.1.

Comment by Ed Burns [ 08/Jun/10 01:12 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 02:20 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:58 PM ]

triage





[JAVASERVERFACES_SPEC_PUBLIC-807] Need to pass FacesContext instance to system event listeners Created: 24/May/10  Updated: 19/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 807
Status Whiteboard:

size_small importance_medium

Tags:
Participants: Ed Burns, Hanspeter Duennenberger, lu4242 and rogerk

 Description   

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

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

public class HtmlStylesheetRenderer extends Renderer implements
ComponentSystemEventListener
{

public void processEvent(ComponentSystemEvent event)

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

......
}

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



 Comments   
Comment by Ed Burns [ 25/May/10 12:04 PM ]

Move to 2.1

Comment by Ed Burns [ 08/Jun/10 01:07 PM ]

triage

Comment by Ed Burns [ 22/Jun/10 09:04 PM ]

rogerk

Comment by rogerk [ 27/Oct/10 02:22 PM ]

triage

Comment by rogerk [ 16/Nov/10 12:59 PM ]

triage

Comment by Hanspeter Duennenberger [ 19/Nov/10 08:18 AM ]

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

Thus the below code would look like:

public void processEvent(ComponentSystemEvent event)

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




[JAVASERVERFACES_SPEC_PUBLIC-888] UIInput.submittedValue returns Object, but Converter suggest only String is allowed Created: 23/Sep/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 888
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, lu4242 and rogerk

 Description   

The current conversion model is not good enough on some cases when it
is required the submitted value be something different than String, or on
more complex components that requires to send information from multiple html
"input" components.
This issue has been discussed earlier on myfaces list, as you can
see on the comments at the end of this mail:

To understand what's missing, I'll resume how the current conversion model
works. This could be redundant, but the intention is expose the reasons about
why it is wanted to extend the current model in a understandable way.

Every component that is used as a input has at least one "value binding" to a
bean. In UIInput, the user just set "value" property with an EL expression to
indicate that the value sent should be assigned to that expression.

Now suppose a form with this component that is submitted. The input component
should first create the "submittedValue" from the information available on
request parameter map. This is done on UIComponent or Renderer decode() method.
Then, this value is converted to the type required by the "value binding",
through Converter interface and later, if conversion fails by some reason, the
information stored on "submittedValue" will be used to render the component later.

Therefore, "submittedValue" must satisfy three conditions:

1. It should contain all info sent by the component through request parameter
map, otherwise the renderer will not be able to render the component correctly.
2. It should be on a way that can be converted to the type indicated by "value
binding", that means the submittedValue type should be a public class, so the
renderer can instantiate it and conversion model can process it.
3. The component should be responsible to define the type used by submitted
value, according to its needs.

Now, let's take a look at the current Converter interface:

public interface Converter

{ /** * used to map the submittedValue to the "value binding". */ Object getAsObject(FacesContext context, UIComponent component, String value) throws ConverterException; /** * used to convert the "value binding" into a String to be used * on the renderer. */ String getAsString(FacesContext context, UIComponent component, Object value) throws ConverterException; }

Note that JSF provide some converters for the most common types, so the user can
specify which converter use or let JSF decide which one fits best, using
the converters registered with "forClass" mapping. Yes, that's ok, but only for
components with only one "<input>". In that case, assume String as submitted
value type looks better and keep things simple.

Things start to get confusing when you see the signature of
UIInput.getSubmittedValue():

public Object getSubmittedValue()

Does the conversion model did not make the assumption that String is the only
type to be used by submittedValue?

But this assumption fails when a more complex component is required. The typical
example is a component that handles date/time values. In that case, the
date/time value can be decomposed into its elements (year, month, day, hour,
minutes ....). In this case, a component developer could want to send all that
info into multiple "<input>" parameters through request parameter map. So, to
use the model proposed, all that information should be used to encode a String,
just to later decode it on the converter used to construct the "value binding"
required, but later it will be decoded/encoded by the renderer again to render
the component.

The proposal to put into consideration is do the following modifications on jsf:

  • Add a class called BusinessConverter (maybe you can find other name but for
    now let it as is) :

public interface BusinessConverter

{ public Object getBusinessValue(FacesContext context, UIComponent component, Object submittedValue); public Object getAsSubmittedValue(FacesContext context, UIComponent component, Object value); }

Really is similar to Converter interface but does not force submittedValue to be
String, instead it lets it open.

  • Add the following methods to Application class :

public abstract void addBusinessConverter(Class<?> submittedClass,
Class<?> targetClass,
String converterClass);

public abstract void addBusinessConverter(String businessConverterId,
String businessConverterClass);

public abstract Converter createBusinessConverter(Class<?> submittedClass,
Class<?> targetClass);

public abstract Converter createBusinessConverter(String businessConverterId);

public abstract Iterator<String> getBusinessConverterIds();

public abstract Iterator<Class<?>> getBusinessConverterTypes(Class<?>
submittedClass);

Again, it is similar to converter methods on Application class, but in this case
it takes into consideration the submittedClass. Therefore, a component that
define as submittedClass java.util.Date, could retrieve the converters that can
handle this conversion. From some point of view, the current Converter interface
is a particular case when submittedClass is java.lang.String.

  • Add the following methods to UIOutput class :

public BusinessConverter getBusinessConverter();

public void setBusinessConverter(BusinessConverter converter);

/**

  • Return the value type the submitted value will take on
  • decode() method. In my opinion, allow just one submittedValueType is
  • enough.
    */
    public Class<?> getSubmittedValueClass();

The idea is provide a way to configure business converter, just like Converter.
Note this implies change some stuff on UIInput too.

  • Add an annotation @FacesBusinessConverter.
  • Add a component f:businessConverter in the same way as f:converter.

I would like to put into consideration this idea. My personal opinion is this
should be included at the spec level for two reasons:

  • It is clear there is a contradiction between UIInput.getSubmittedValue() and
    Converter interface.
  • It could be good to have a common repository for business converters, and use
    JSF annotations to register it.

I have some code I'm working but it is better to know if you think it is worth
or not before continue. If it is necessary I can help with the implementation.

Suggestions are welcome

best regards,

Leonardo Uribe

Note: As an historical comment, currently, Trinidad has a workaround for handle
handle "oracle types", from the binding layer, using an interfaces called
TypedConverter as you can see below:

package org.apache.myfaces.trinidadinternal.convert;

public interface TypeConverter

{ /** * converts the given Object into an instance of the * targetType. * @return an instance of the targetType. */ Object convert(Object source, Class<?> targetType); }

The idea behind this interface is provide a way that trinidad can "understand"
specific types and include them when are resolved, but note this class is not
part of trinidad api. The reason is this is just an internal workaround.

COMMENTS FROM OTHER PEOPLE SUPPORTING THIS ISSUE:

Martin Koci

MK>> maybe this is a stupid question but:
MK>>
MK>> >From UIInput javadoc:
MK>>
MK>> ... decoded value of this component, usually but >>>not necessarily a
MK>> String<<<, must be stored - but not yet converted - using
MK>> setSubmittedValue() ....
MK>>
MK>> from UIInput.getConvertedValue:
MK>>
MK>> ... and the submitted value is a >>>String<<<, locate a Converter as
MK>> follows
MK>>
MK>> Question: why is Converter tied only to String? Whole specification
MK>> speaks about submitted value as of "raw representation of value from
MK>> client" but not necessarily String. And 3.3 Conversion Model: "This
MK>> section describes the facilities provided by JavaServer Faces to support
MK>> type conversion between server-side Java objects and their (typically
MK>> String-based) representation in presentation markup."
MK>> But Converter.getAsObject expects only String as this "raw
MK>> representation" and "typically String-based" formulation from spec now
MK>> means "always String-based".
MK>> It seems to me that Converter introduces unnecessary dependency on
MK>> String-based representation - even ResponseWriter.write* accepts
MK>> java.lang.Object as value ....
MK>>
MK>> What I try to do is JSF-based server view with custom NOT-string based
MK>> protocol where "raw representations from client" can be java object like
MK>> Integer or more complex. Creating of:
MK>>
MK>> interface Converter2 { MK>> Object getAsObject(FacesContext,UIComponent,Object) MK>> Object getAsRepresentation(FacesContext,UIComponent,Object) MK>> }
MK>>
MK>> solves my problem but I must reprogram significant part of JSF api.

Martin Marinschek

MM>> MK>> So on JSF level conversion String <-> Object is unable to solve this
MM>> MK>> problem - I simply need Object <-> Object conversion which is not
MM>> MK>> supported yet.
MM>>
MM>> Yes, this is true - this is obviously a spec problem.
MM>>
MM>> If the submitted value is an object, it should also be allowed to
MM>> convert it. A converter is more than just a string to object (and
MM>> back) converter, it is an artefact which transforms information from
MM>> its representation for output (and this output could be anything, and
MM>> certainly doesn't have to be string based) to its representation which
MM>> the business model (or also an artefact within JSF, like a validator)
MM>> understands.
MM>>
MM>> So I agree. This hasn't come up so far cause nobody uses non string
MM>> based output models for JSF.
MM>>
MM>> Note that my notion of a business converter (discussed on this mailing
MM>> list a while ago) for converting between a business model
MM>> representation and a representation in a JSF artefact like the
MM>> renderer (e.g. you use joda.Date in the business model, but the JSF
MM>> date picker renderer only understands the normal java date) is also
MM>> hinting in the direction that such an additional converter API would
MM>> be necessary. I discussed this with the EG (and also Ed privately),
MM>> and there wasn't much interest for adding this.



 Comments   
Comment by Ed Burns [ 19/Oct/10 01:15 PM ]

Target for 2.2.

Comment by rogerk [ 27/Oct/10 02:47 PM ]

triage

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

triage





[JAVASERVERFACES_SPEC_PUBLIC-889] <ui:repeat> inner variable can't be transmitted to a composite. Created: 26/Sep/10  Updated: 17/Dec/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 889
Status Whiteboard:

size_medium importance_small

Tags:
Participants: grunt2000 and rogerk

 Description   

This source code based on a <c:forEach> loop is able to work:

<c:forEach var="adresse" items="#{assoCtrl.association.adresses}">
<territoire:adresse adresse="#{adresse}" />
</c:forEach>


But this one, based on an <ui:repeat> loop, fails:

<ui:repeat var="adresse" value="#{assoCtrl.association.adresses}">
<territoire:adresse adresse="#{adresse}" />
</ui:repeat>

This message is received:
"<territoire:adresse> The following attribute(s) are required, but no values
have been supplied for them: adresse. "


As a test, I changed the content of my loop that way:
<ui:repeat var="adresse" value="#{assoCtrl.association.adresses}">
<!-- The address content is: #{adresse} -->
</ui:repeat>

And found that the HTML page is displayed, no Exception thrown by JSF 2.0.3
then. (I see that content on the HTML page that is created: <!-- The address
content is: Adresse [nom: , complément de nom: null, complément de voie: null,
voie: , code postal: 00000, ville: , pays: France, commentaire: null, types
adresse: []] -->).

Therefore, I think that the transmission of the var parameter of <ui:repeat> is
faulty when an inner composite is targeted. I made some tries by promoting the
value part of <ui:repeat> to various scopes, but without success.

Regards,
Grunt.



 Comments   
Comment by rogerk [ 27/Oct/10 02:38 PM ]

triage

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

triage





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 903
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns, kellerapps and rogerk

 Description   

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



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

2.2

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

triage

Comment by kellerapps [ 18/Apr/11 12:56 PM ]

JSF components should support safe HTML. gwt recently added this. Should this be a separate issue?





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

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 908
Status Whiteboard:

size_small importance_medium

Tags:
Participants: rogerk

 Description   

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

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



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

triage

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

triage





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

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

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

Operating System: All
Platform: All


Issuezilla Id: 910
Status Whiteboard:

size_medium importance_small

Tags:
Participants: Ed Burns and rogerk

 Description   

Name: gm110360 Date: 03/17/2004

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

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

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

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

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

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

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

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

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

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



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

triage





[JAVASERVERFACES_SPEC_PUBLIC-911] Support JSR-276 metadata in standard components Created: 15/Nov/10  Updated: 08/Nov/13

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

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

Operating System: All
Platform: All


Issuezilla Id: 911
Status Whiteboard:

size_large importance_medium

Tags:
Participants: Ed Burns

 Description   

Modify the spec for the standard JSF components to include JSR-276 metadata.



 Comments   
Comment by Ed Burns [ 15/Nov/10 07:07 PM ]

This is from old CR 6204877:
The metadata format for a sun-faces-config.xml file includes the ability to
declare a <base-component-type> for a <component> definition, which can be used
by tools to inherit property metadata (and other information) from the base
component class. In standard-html-renderkit.xml, this facility is used, but
only for the concrete HTML component classes. It should also be used to reflect
the inheritance of the generic component classes. In particular, to document that:

  • UIInput is a subclass of UIOutput.
  • UISelectBoolean is a subclass of UIInput.
  • UISelectMany is a subclass of UIInput.
  • UISelectOne is a subclass of UIInput.

Without this, tools that want to analyze a third party component declaration
that extends UIInput will miss, for example, the fact that UIInput includes all
the ValueHolder properties (because of inheritance from UIOutput) as well as the
EditableValueHolder properties that it implements directly.

In particular, this has caused problems for Creator, which has code generators
that create component, BeanInfo, and tag classes (not just tag classes like the
RI has).

craig.mcclanahan@sun.com 2004-12-07 02:38:51 GMT





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

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk

 Description   

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

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

private static boolean isEmpty(Object value) {

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

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

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






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

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

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

Status Whiteboard:

size_small importance_medium

Tags:
Participants: rogerk

 Description   

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

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

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

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






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

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: rogerk

 Description   

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

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

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

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

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






[JAVASERVERFACES_SPEC_PUBLIC-935] UIData needs review on a couple of fronts Created: 31/Jan/11  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: rogerk Assignee: Unassigned
Resolution: Unresolved Votes: 4
Σ Remaining Estimate: 3 days, 23 hours, 30 minutes Remaining Estimate: Not Specified
Σ Time Spent: 1 hour, 16 minutes Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Sub-Tasks:
Key
Summary
Type
Status
Assignee
JAVASERVERFACES_SPEC_PUBLIC-322 Add interfaces to javax.faces.compone... Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-479 UIData should support the collection ... Sub-task Resolved Ed Burns  
JAVASERVERFACES_SPEC_PUBLIC-963 Alignment/extending of iterating ui c... Sub-task Open  
JAVASERVERFACES_SPEC_PUBLIC-965 Provide a component for iterating ove... Sub-task Open  
Status Whiteboard:

size_medium importance_medium

Tags:
Participants: lu4242 and rogerk

 Description   

Note that the following will most likely apply to 1.2 as well

From Martin Marinschek:
-----------------------------

a) if invokeOnComponent returns successfully for any of the facets,
invokeOnComponent should return with true - currently it doesn't (maybe there is
a reason for this I fail to see?)

b) I think that the NumberConversionException thrown from the current version of
this method is dangerous in the sense that if the client-id is not actually
valid (the component is not yet anymore in the table) but was a sub-component of
a naming-container in a facet (client-id
tableClientId:namContainerId:subCompId), the long client-id will trigger the
code to check if the component is in one of the rows and you will suddenly get a
number conversion exception popping up from the table. This is not the case with
other components and invokeOnComponent, and so should be done differently.
Instead, this NumberConversion exception has to be silently ignored - or a
better solution for this algorithm has to be found (I didn't find one in a
decent time-frame, however, and just ignored the NumberConversion exception in
my version).

As a side-note: could it be that you guys keep track of the state of children of
transient nodes? I seem to be running into this from time to time. Leonardo
mentioned this as an implementation difference to MyFaces to me, so maybe you
could check if this is the case (I don't think this would make sense - a
transient component would certainly mean every sub-component has to be transient
as well).



 Comments   
Comment by lu4242 [ 18/Apr/11 09:05 AM ]

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.





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

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

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

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

size_medium importance_medium

Tags:
Participants: balusc, dennishoersch, rogerk and vabp

 Description   

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

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

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

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

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

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

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

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

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

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

=> Is this really the intention ?

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

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

ah, ok.

basically the fix is this:

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

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

else

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

}

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

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

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

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

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

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

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

Fair point.



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

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

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

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

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

Is there any decision made?

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





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

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Ed Burns and rogerk

 Description   

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

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

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



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

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





[JAVASERVERFACES_SPEC_PUBLIC-951] Unable to map composite component facet to new name Created: 23/Mar/11  Updated: 08/Nov/13

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

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

All


Status Whiteboard:

size_small importance_large

Tags:
Participants: kenpaulsen, Manfred Riem and persapiens

 Description   

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:

Page:
<my:component>
<f:facet name="fooHeader">
<h:outputText value="foo" />
</f:facet>
<f:facet name="barHeader">
<h:outputText value="bar" />
</f:facet>
</my:component>

Component:
<cc:implementation>
...
<h:dataTable ...>
<cc:insertFacet name="fooHeader" />
...
</h:dataTable>
<h:dataTable ...>
<cc:insertFacet name="barHeader" />
</h:dataTable>

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.

To solve this, I propose adding "localName" (or something similar) to the insertFacet tag:

<cc:insertFacet name="barHeader" localName="header" />

Thanks!

-Ken



 Comments   
Comment by persapiens [ 06/Nov/11 12:26 AM ]

I have problem to create composite components using cc:renderFacet inside a p:datatable

Page:

<sds:crud>
<f:facet name="listColumns" >
<p:column >
<f:facet name="header">
My column
</f:facet>
<h:outputText value="#{s}" />
</p:column>
</f:facet>
</sds:crud>

My Component (crud):

<cc:interface >
<cc:facet name="listColumns" required="true" />
</cc:interface>

<cc:implementation>
<p:dataTable value="#{teste.list()}" var="s">
<cc:renderFacet name="listColumns" />
</p:dataTable>
</cc:implementation>

If I use cc:insertChildren it works, however I need to use facets.

Comment by Manfred Riem [ 13/Feb/12 07:30 PM ]

Ken,

Have you tried doing the following?

<cc:implementation>
<h:dataTable>
<f:facet name="header">
<cc:renderFacet name="fooHeader"/>
</f:facet>
</h:dataTable>
</cc:implementation>





[JAVASERVERFACES_SPEC_PUBLIC-956] Support rendering of client behaviors inside simple composite components Created: 01/Apr/11  Updated: 08/Nov/13

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

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

Status Whiteboard:

size_medium importance_medium

Tags:
Participants: Mathias Werlitz

 Description   

It is already possible to attach behaviors to composite components that are retargeted to via <cc:clientBehavior> but is not possible to attach a behavior directly to a composite component, with no target).

UINamingContainer should implement ClientBehaviorHolder and support decoding of behaviors. It should be possible to configure the supported events using the <cc:clientBehavior> with no "name" attribute or maybe with the special keyword "@this" in the "targets" attribute.

The script of a behavior could be made available in the composite component implementation for example via an EL expression.

Example usage:

<cc:interface>
<cc:clientBehavior event="focus" />
</cc:interface>
<cc:implementation>
<fieldset onfocus="#{cc.behaviorScript['focus']}">
...






UIData needs review on a couple of fronts (JAVASERVERFACES_SPEC_PUBLIC-935)

[JAVASERVERFACES_SPEC_PUBLIC-965] Provide a component for iterating over hierarchical data Created: 07/Apr/11  Updated: 08/Nov/13

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

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

Status Whiteboard:

size_large importance_medium

Tags:
Participants: kito75 and Mathias Werlitz

 Description   

With the integration of Facelets into JSF 2.0 a component for iterating over list data (UIRepeat) that does not render any markup itself was introduced in the spec. This is very useful for creating "table" like composite components that render custom markup.
A similar component for rendering hierarchical data does not exist. There should be a general component(s) for iterating tree structures e.g. "UITreeData", that does not render any output itself but allows rendering of hierarchical HTML tree structures like <ul><li>.
There is currently no support of rendering hierarchical data structures with facelets/composite components with an unlimited depth (and user defined markup). Nesting a composite component inside itself is not an option as it leads to an infinitely nested component tree.

A component that only iterates a hierarchical data structure would allow creating "tree" like composite components that render custom markup.

The usage could look something like:
<ul>
<ui:tree value="#{myTree}" var="node" varStatus="status">
<li>Node value: #{node.someData}
<ul>
<ui:treeChilds />
</ul>
</li>
</ui:tree>
</ul>

It is possible to implement a similar "workaround" component on top of UIData with a special renderer for UIData + UIColum and a UIOutput for the "tree childs". The iteration over the tree nodes can be recursively done in the renderer of the "tree childs".
Using UIData as the wrapping base component saves the developer from implementing the complicated state saving and tree visiting. The downside is: it is not easy to "trick" UIData to use hierarchical data with a special DataModel. This is because it only supports an integer as the index of the current row. A more general base class would be much more suitable. See improvement JAVASERVERFACES_SPEC_PUBLIC-963.
BTW: The described "workaround" component is used on the CeBit site (http://www.cebit.de/en/about-the-trade-show/programme/exhibitors-products/sector-index) and even supports AJAX out of the box. I may provide the source for illustration.

I think the suggested component really should be part of the spec as it significantly enhances the possibilities when creating composite components. Creating an own tree component is easy with it. It could also be a base for many other "tree" component implementations.



 Comments   
Comment by kito75 [ 19/Apr/11 01:54 PM ]

I would argue that any such component should render as a simple tree (with basic features like expanding/collapsing nodes, images for folders and leaves, etc.) by default, like UIData does. I would also expect a standard TreeModel.

Comment by Mathias Werlitz [ 19/Apr/11 11:54 PM ]

Well the idea is not to implement a complex tree component, but allow rendering of hierachical markup like <ul><li> in general, leaving the developer of an application the flexibility to render any content.

Infact my "workaround" component uses a special DataModel impl. (to let UIData think the nodes are sequential rows) and a very simple interface for tree nodes. But this interface only allows to get the childs of a node, nothing more. The component does not know anything about the tree state, it does only iterate over the data. Tree state is part of a custom user definded model (in this case: of the node) and the facelets template.





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

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

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

Status Whiteboard:

size_large importance_large

Tags:
Participants: Ed Burns and lamine_ba

 Description   

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

JB> Example tag

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

JB> .... child components here

JB> </ asp:Repeater>

JB> Corresponding method on the backing class

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

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



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

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

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

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

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

public void handleRepeatItem(Object currentObjectFromCollection, UIComponent currentContainerHoldingChildComponents)

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





[JAVASERVERFACES_SPEC_PUBLIC-1002] Order of isRendered and pushComponentToEL prevents rendered="#{}" based on component implicit object Created: 17/May/11  Updated: 08/Nov/13

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

Type: Bug Priority: Major
Reporter: Martin Kočí Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Martin Kočí

 Description   

Current specification for lifecycles methods:
1) processDecodes
2) processValidators
3) processUpdates
4) encodeAll
4) encodeBegin

explicitly says that:

1) If the rendered property of this UIComponent is false, skip further processing.
2) call pushComponentToEL

But in that order of invocations it is impossible to achieve rendered like this:

<h:outputText rendered="#{component.id eq 'outputTextId'}" id="outputTextId" />

i.e. any rendered ValueEpression based on component itself.






[JAVASERVERFACES_SPEC_PUBLIC-1013] process and encode methods: add equivalent to VisitResult Created: 29/May/11  Updated: 08/Nov/13

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

Type: New Feature Priority: Major
Reporter: Martin Kočí Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: performance
Participants: Martin Kočí

 Description   

this is typical implementation of custom component's method:

MyComponent.java
MyComponent.processDecodes:

if (!isRendered()) {
  return;
}
super.processDecodes(context);
// do specific stuff

If MyComponent extends UIInput, then if component has ValueExpression for "rendered" (and VE resolves to true), it is evaluated 3x:

  1. MyComponent.processDecodes
  2. javax.faces.component.UIInput.processDecodes(FacesContext)
  3. javax.faces.component.UIComponentBase.processDecodes(FacesContext)


Suggestion:
add a useful return value for execute and render lifecycle methods like visitTree has already. Then code can be optimized:

MyComponent.java
MyComponent.processDecodes:


if (!super.processDecodes(context))
 return;

// do specific stuff

Considerations:

  • Blake's Axiom of Boolean Properties: You will regret making your property a boolean (http://www.mail-archive.com/dev@myfaces.apache.org/msg52753.html). Create new Enum or reuse existing VisitResult as return value
  • if change to exiting API is not possible, add new method like "UIComponent.isXYZPhaseExecutable"
  • if change to API is not possible at all, find a way similar as ELContext.setPropertyResolved(boolean): a property on context "current execute/render method is executable on this component"





[JAVASERVERFACES_SPEC_PUBLIC-1018] h:button,h:commandButton: generate an HTML BUTTON if there is content. Created: 16/Jun/11  Updated: 08/Nov/13

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

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

All


Tags: button input HTML render
Participants: ejp

 Description   

Visual representations of buttons appear to be presently crippled by the inability to include mixed content, e.g. a standard <BUTTON> with an image and a label. h:button and h:commandButton are presently specified only to render as an INPUT with an appropriate type. If there is content inside the tag could they please render as a BUTTON instead? so it works intuitively as expected? Or some other feature to the same end?






[JAVASERVERFACES_SPEC_PUBLIC-1022] Support base classes as source class for SystemEvents Created: 05/Jul/11  Updated: 08/Nov/13

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

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

Tags:
Participants: lu4242

 Description   

Originally created on https://issues.apache.org/jira/browse/MYFACES-3185 by Carsten Dimmek:

Registering a system event listener in the faces-config need a concrete class like HtmlInputText. If you wan't to register a listener for let's say all UIInputs you need to explicit configure all subclasses.

<system-event-listener>
<system-event-listener-class>view.RequiredValidationListener</system-event-listener-class>
<system-event-class>javax.faces.event.PostValidateEvent</system-event-class>
<source-class>javax.faces.component.html.HtmlInputText</source-class>
</system-event-listener>

<system-event-listener>
<system-event-listener-class>view.RequiredValidationListener</system-event-listener-class>
<system-event-class>javax.faces.event.PostValidateEvent</system-event-class>
<source-class>javax.faces.component.html.HtmlInputSecret</source-class>
</system-event-listener>

etc.

Supporting base classes would be great:

<system-event-listener>
<system-event-listener-class>view.RequiredValidationListener</system-event-listener-class>
<system-event-class>javax.faces.event.PostValidateEvent</system-event-class>
<source-class>javax.faces.component.UIInput</source-class>
</system-event-listener>

a fine-grained configuration would be still possible through SystemEventListener.isListenerForSource(Object source)






[JAVASERVERFACES_SPEC_PUBLIC-1024] Allow parents of forms as render targets of ajax requests Created: 11/Jul/11  Updated: 08/Nov/13

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

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

Tags: ajax facelets javascript
Participants: arjan tijms, frederickkaempfer and swathireddy12

 Description   

Currently it is not possible to use parents of forms as render targets in <f:ajax/> or jsf.ajax.request. If an element containing one or more forms is specified in the render attribute, these forms' ViewState is not updated during the Ajax request. In my opinion it is not clear from the JSDocs, if parents of forms are allowed as render targets or not. Mojarra currently does not create an error in that case, however the jsf.ajax.request method does not create a ViewState field for descendant forms either.

Judging from the JSDoc the request method's execute parameter is not limited to forms and children of forms, it just takes a list of arbitrary client ids. It's also possible to specify '@all' for the whole view thus most likely a parent of multiple forms, which works as expected.

However the JSDoc for jsf.ajax.response states the following for ViewState updates:

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

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

locate and update the submitting form's javax.faces.ViewState value with the CDATA contents from the response. Locate and update the javax.faces.ViewState value for all forms specified in the render target list.

This will clearly not work if only forms that are contained in the render target list directly are considered, because the list could also contain parents of forms.

For more information see the corresponding Mojarra bug report:

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



 Comments   
Comment by frederickkaempfer [ 12/Jul/11 07:50 AM ]

"Judging from the JSDoc the request method's execute parameter "

This was meant to be the render parameter.

Comment by frederickkaempfer [ 12/Sep/11 01:21 PM ]

This issue is related to (or even included in) http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790. Since this is obviously a spec bug and a fix is quite simple (updating all forms instead of only a subset defined by the render attribute on an ajax request, see Ed Burns' comment on 790) it would definitely be worth considering for 2.2.

Comment by arjan tijms [ 08/Jan/12 01:22 PM ]

Simple test case from duplicate issue JAVASERVERFACES-1788:

<h:panelGroup layout="block" id="group">
    <h:form>
        <h:commandLink value="Link A">
            <f:ajax />
        </h:commandLink>
    </h:form>
</h:panelGroup>

<h:form>
    <h:commandLink value="Link B">
        <f:ajax render=":group" />
    </h:commandLink>
</h:form>
  1. Press Link A - view state is submitted
  2. Press Link B, then Link A - view state is not submitted anymore
Comment by swathireddy12 [ 22/Aug/13 11:51 AM ]

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

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

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





[JAVASERVERFACES_SPEC_PUBLIC-1029] viewParam value lost after validation errors Created: 02/Aug/11  Updated: 08/Nov/13

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

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

Tags: validation state
Participants: arjan tijms

 Description   

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

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

The following reproduces this:

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

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

    <h:body>

        <h:messages />

        #{viewParamBean.id} <br/>

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

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

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

    private long id;    
    private String text;

    public void actionMethod() {

    }

    public long getId() {
        return id;
    }

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

    public String getText() {
        return text;
    }

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

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

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

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

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

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

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

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






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

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

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

Tags:
Participants: arjan tijms

 Description   

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

E.g.

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

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

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

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

E.g.

@FacesComponent("components.CustomComponent")
public class CustomComponent extends UIComponentBase {

    @Attribute
    @VariableName(type="#{attributes.value[0]}" scope="component")
    private String var;

    @Attribute
    @VariableSource
    private List<Item> value;

In this example, the component declares that the var attribute is the name for data that is made available during the 'scope of the component' and that the type of this data is an element from the value attribute.

Additionally, it should also be possible that a fixed type is specified, e.g:

@FacesComponent("components.CustomComponent")
public class CustomComponent extends UIComponentBase {

    @Attribute
    @VariableName(type="com.example.SomeType" scope="component")
    private String var;

Of course the given syntax is just a quick sketch of the idea. Maybe @VariableExportName is a better name, @VariableSource might not be needed, etc.

This issue is somewhat related to JAVASERVERFACES_SPEC_PUBLIC-594



 Comments   
Comment by arjan tijms [ 02/Nov/11 01:06 PM ]

Issue JAVASERVERFACES_SPEC_PUBLIC-984 might also be somewhat related to this.





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

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

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

Tags:
Participants: andy_bosch, muellermi and Neil Griffin

 Description   

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

The three attributes that I would like to propose are:

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


 Comments   
Comment by Neil Griffin [ 24/Nov/12 06:31 PM ]

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

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

Comment by andy_bosch [ 24/Nov/12 08:21 PM ]

I like that idea. Would definitly makes sense!

Comment by muellermi [ 25/Nov/12 08:03 AM ]

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

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

overwrite=allow|deny|rename

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

Comment by Neil Griffin [ 26/Nov/12 04:18 PM ]

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

Comment by muellermi [ 26/Nov/12 08:23 PM ]

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





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

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

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

Tags:
Participants: balusc

 Description   

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






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

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

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

All


Tags: css outputStylesheet
Participants: paul_dijou

 Description   

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

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



 Comments   
Comment by paul_dijou [ 29/Oct/12 08:51 AM ]

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

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

Comment by paul_dijou [ 13/Nov/12 12:28 PM ]

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





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

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

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

N/A


Tags:
Participants: jontyl

 Description   

The javadoc descriptions in UIComponent for the abstract metho