[JAVASERVERFACES_SPEC_PUBLIC-631] Specify target facet name when inserting into composite component Created: 18/Sep/09  Updated: 01/Aug/14

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

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

Operating System: All
Platform: Macintosh


Attachments: Text File 631-cc-insertFacet-targetName.patch     Zip Archive composite-component-targets-test-2.zip     File composite-component-targets-test.war    
Issuezilla Id: 631
Status Whiteboard:

size_medium importance_medium

Tags: adf

 Description   

As discussed on jsr-314-open...

As currently specified, composite:insertFacet's "name" attribute serves two purposes:

1. It identifies the name of the facet on the containing composite component to insert.
2. It identifies the name of the facet on the target component into which the facet is being inserted.

As a result, the name of the facet exposed by the composite component must match the name of the
facet on the implementation component into which the facet is being inserted. So, for example, if I
have a composite component as follows:

<composite:interface>
<composite:facet name="caption"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>
</composite:implementation>

Everything is happy, since both the composite component and the h:panelGrid expose a "caption" facet.

However, if I want to define a composite component with two h:panelGrid components and two
captions:

<composite:interface>
<composite:facet name="caption"/>
<composite:facet name="backupCaption"/>
</composite:interface>

<composite:implementation>
<h:panelGrid>
<composite:insertFacet name="caption"/>
</h:panelGrid>

<h:panelGrid>
<!-- Uh oh. -->
<composite:insertFacet name="backupCaption"/>
</h:panelGrid>
</composite:implementation>

I am out of luck, since I now have a mismatch between the composite component facet name and the
h:panelGrid facet name.

I think that we could/should solve this in one of two ways:

1. Add an attribute to composite:insertFacet that allows a target facet name to be specified:

<h:panelGrid>
<composite:insertFacet name="backupCaption" targetName="caption"/>
</h:panelGrid>

2. Specify that the target facet name can be picked up from a wrapping <f:facet> tag:

<h:panelGrid>
<f:facet name="caption">
<composite:insertFacet name="backupCaption"/>
</f:facet>
</h:panelGrid>



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 04/Mar/10 ]

Because we now have renderFacet and insertFacet, I'm wondering if this is still valid? Can you re-
open if so?

Comment by aschwart [ 30/Sep/10 ]

I find the insertFacet tag to be useless without this fix. I think that we should address this, perhaps for
2.2.

Comment by Ed Burns [ 30/Sep/10 ]

Don't know how this ended up being assigned to javaserverfowner. I thought we
re-assigned all of those.

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=322)
Patch with solution involving add "targetName" attribute

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=323)
WAR file from test project

Comment by lu4242 [ 27/Oct/10 ]

Created an attachment (id=324)
Test demo using maven. To run type: mvn clean -Djsf=mojarra jetty:run

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Jakob Korherr [ 31/Oct/10 ]

IMHO it should be targeted for 2.1

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-654] Add sychronous calls for jsf.ajax.request Created: 21/Oct/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 654
Status Whiteboard:

size_medium importance_small


 Description   

Allow synchronous calls from jsf.ajax.request.

Presumably this could be done with an option flag of async: false (with true
being the default).



 Comments   
Comment by driscoll [ 02/Nov/09 ]

Change target milestone.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by jasonzhang2002gmailcom [ 05/Feb/13 ]

A critical feature to have especially in cascading ajax call.

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-626] Add standard way to modify browser history in Ajax Created: 04/Sep/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issue Links:
Dependency
blocks JAVASERVERFACES_SPEC_PUBLIC-1 multi-component validation Resolved
Issuezilla Id: 626
Status Whiteboard:

size_medium importance_medium


 Description   

A standard way to modify the browser history in Ajax would be useful, so the
back button would work with JSF Ajax apps (loaded with GET, anyway).



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 18/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-620] Allow components to emit ajax xml Created: 21/Aug/09  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 620
Status Whiteboard:

cat2 frame size_medium importance_medium


 Description   

currently, all components are wrapped in the overall <update> CDATA when
emitting their rendered output.

One proposal would be to add a marker interface, which would cause the component
to NOT be part of the visit by the overall <update> - instead, it's tree would
be visited at the end of the process, and would be responsible for adding it's
own xml to the document before close. This would enable the component to emit
directives like <insert> <delete> and <eval>.

Currently, the only way to get this functionality is to override the
facesservlet (like ICEFaces) or have other methods, which could be called by
action methods or listeners.



 Comments   
Comment by rogerk [ 24/Aug/09 ]

Take ownership

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-616] Executing inline script tags Created: 19/Aug/09  Updated: 04/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 616
Status Whiteboard:

size_medium importance_medium


 Description   

Currently, the specification is silent on whether embedded script tags should be
executed during an update or insert on the client.

There are plans for both MyFaces and Mojarra to support this functionality, so
it's probably a very good idea to bake this into the specification.



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

take ownership

Comment by rogerk [ 24/Aug/09 ]

Take Ownership

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

Elevate priority.





[JAVASERVERFACES_SPEC_PUBLIC-612] Add method attribute to the f:valueChangeListener and f:actionListener tags Created: 15/Aug/09  Updated: 04/Aug/14

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

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

Operating System: Linux
Platform: PC


Attachments: Java Source File ActionListenerHandler.java     Java Source File ActionListenerTag.java     Java Source File ValueChangeListenerHandler.java     Java Source File ValueChangeListenerTag.java    
Issuezilla Id: 612
Status Whiteboard:

size_small importance_medium


 Description   

In order to enhance functionality with EL2, requiring fewer component
binding/DataModel objects. Allow the <f:actionListener> tag to support a
"method" attribute, which will be executed on triggering of the ValueChangeEvent.

If the method-signature includes ValueChangeEvent, it should be passed as a
parameter. If not part of the signature, it should be omitted.



 Comments   
Comment by lincolnbaxter [ 15/Aug/09 ]

<f:valueChangeListener> and <f:actionListener> should both support the method
attribute.

Comment by Ed Burns [ 24/Aug/09 ]

take ownership

Comment by lincolnbaxter [ 14/Sep/09 ]

Created an attachment (id=226)
2/4

Comment by lincolnbaxter [ 14/Sep/09 ]

Created an attachment (id=227)
1/4

Comment by lincolnbaxter [ 14/Sep/09 ]

Created an attachment (id=228)
3/4

Comment by lincolnbaxter [ 14/Sep/09 ]

Created an attachment (id=229)
4/4

Comment by lincolnbaxter [ 14/Sep/09 ]

Attached patch files (impl only). Since I am not a JCA signee yet.. someone else
should probably run with the actual source from here. I'll keep working on the
spec design with the EG until I get the paperwork to submit code.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 25/Sep/09 ]

Retarget to 2.next

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

Elevate priority.





[JAVASERVERFACES_SPEC_PUBLIC-864] ExceptionHandler.getRootCause() should use isAssignableFrom() Created: 08/Jul/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All
URL: https://issues.apache.org/jira/browse/MYFACES-2796


Issuezilla Id: 864
Status Whiteboard:

size_small importance_small


 Description   

The spec (javadoc) of ExceptionHandler.getRootCause() currently says the
following: "Unwrap the argument t until the unwrapping encounters an Object
whose getClass() is not equal to FacesException.class or
javax.el.ELException.class. If there is no root cause, null is returned."

I think instead of checking for equals() we should check for isAssignableFrom(),
because there are a lot of sub-classes (especially for ELException), which
should also be unwrapped.

See also the related MyFaces-issue at
https://issues.apache.org/jira/browse/MYFACES-2796



 Comments   
Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-493] Unified EL could be more unified Created: 09/Oct/08  Updated: 01/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 493
Status Whiteboard:

EGTop5 size_medium importance_medium draft


 Description   

I recently raised an issue against Mojarra...

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

...which turned out to be, according to Ryan...

"There are two different ELContext instances in play when using JSP/JSF. The
ELContext provided by the JSP runtime includes a FunctionMapper... The
ELContext provided by Faces [does not]. JSF has no requirement by the
specification to parse the TLD to provide a FunctionMapper for the second case."

This means you cannot programmatically create ValueExpressions that use
functions...

createValueExpression( elContext, "#

{ss:bar()}

"

...even if those functions are declared on the same page. See the linked
Mojarra bug for a test case.

If the 'unified EL' were unified such that both JSP and JSF used the same
ELContext, this problem may be resolved. This fix would help
http://metawidget.org, which does a lot of programmatic ValueExpression
creation.



 Comments   
Comment by pmuir [ 10/Oct/08 ]

This is a JBoss top 5 issue

Comment by Ed Burns [ 15/Oct/08 ]

Change target milestone to 2.0

Comment by Ed Burns [ 24/Sep/09 ]

I assert now that method invocation works, you don't need this.

Comment by kennardconsulting [ 24/Sep/09 ]

The 'need' for this is less about functionality (there have always been
workarounds) and more about 'not surprising the user'. In terms of 'not
surprising the user' the need is not changed by the (welcome) addition of
method invocation.

Let me explain. Even with method invocation, the user is still able to declare
a namespace and write EL expressions in their pages like this...

<h:outputText value="#

{ss:bar()}

"/>

The problem is if I try to write a custom JSF component that needs to do a bit
of processing on the value expression, and my component internally tries to
do...

createValueExpression( elContext, "#

{ss:bar()}

" )

...then it won't work. The exact same expression that the user passed in to my
component cannot be manipulated by my component internally.

Please reconsider the WONTFIX.

Regards,

Richard

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-468] create "relocationTarget" tag and renderer Created: 11/Sep/08  Updated: 04/Aug/14

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 468
Status Whiteboard:

EGEasy5 size_small importance_medium


 Description   

At JSFOne 2008, Ian Hlavats, creator of the JSFToolbox DreamWeaver plugin, pointed out that content
developers don't like to cede rendering of head and body. In these cases, he asserted the content
developer would be willing to add something like

<h:relocationTarget target="head" />

into their head.



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

Tag as EGEasy5

Comment by Ed Burns [ 23/Sep/08 ]

target 2.0

Comment by kito75 [ 16/Oct/08 ]

I don't quite follow. So what would this do? Move the content within this tag to
the head?

Comment by Ed Burns [ 10/Aug/09 ]

Move to 2.1. Yes, it would basically just be a "relocate stuff here" tag.

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by Ed Burns [ 12/Jan/10 ]

Target 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Ed Burns [ 04/Aug/14 ]

Increase priority.





[JAVASERVERFACES_SPEC_PUBLIC-237] ResponseWriter write escape arg Created: 25/Jan/07  Updated: 01/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 237
Status Whiteboard:

EGTop5 effort_hard size_medium importance_medium draft


 Description   

Consideration: add optional escape boolean arg to ResponseWriter write methods
to control escaping.

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



 Comments   
Comment by rogerk [ 19/Mar/08 ]

Targeting for 2.0.

Comment by josefreire [ 20/Mar/08 ]

This issue is relevant when building a <f:selectOneMenu> and one of the
SelectItem has an itemValue that contains Unicode characters (like ç, á, ã).

On submit the validation fails due to the invalid characters.

This is a serious issue because many applications have decode tables that are
build by interface from outside systems, and one day you can wake up with a
broken application.

The workaround is to manually escape (using for example
StringEscapeUtils.escapeHtml) when building the SelectItems and unescaping
manually on receive.

The current behavior is always escaping itemValue, so this leads to a
double-escaping issue.

However, I believe this problem might be solved by changing the validation, and
not changing the ResponseWriter.

Looking at the HTML4 Spec I have found no hint that the existing restrictions on
Unicode characters should ever exist for itemValue since the "value" attribute
on the <OPTION> element is defined as CDATA, so Unicode characters should be
allowed.

I think the validation of the itemValue should be relaxed to allow more complex
values, like strings with Unicode characters.

Comment by rogerk [ 22/Aug/08 ]

Status Whiteboard

Comment by Ed Burns [ 12/Sep/08 ]

effort_hard

Comment by Ed Burns [ 12/Sep/08 ]

change target_milestone to 2.0

Comment by Ed Burns [ 28/Jul/09 ]

Pushing to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by rogerk [ 20/Jan/10 ]

Target 2.1

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by rogerk [ 27/Oct/10 ]

triage

Comment by rogerk [ 16/Nov/10 ]

triage

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





Generated at Wed Feb 10 07:30:34 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.