[JAVASERVERFACES_SPEC_PUBLIC-1215] Add warning to javadoc of DelegatingMetaTagHandler.getTagHandlerDelegate Created: 12/Aug/13  Updated: 01/Aug/14

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

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


 Description   

The current spec has no javadoc for DelegatingMetaTagHandler.getTagHandlerDelegate(). [1] This issue proposes adding the following warning to the javadoc for this method.

Code that extends from DelagatingMetaTagHandler (directly or indirectly, as through extending ComponentHandler) must take care to decorate, not replace, the TagHandlerDelegate instance returned by this method. Failure to do so may produce unexpected results.

[1] http://docs.oracle.com/javaee/6/api/javax/faces/view/facelets/DelegatingMetaTagHandler.html#getTagHandlerDelegate%28%29



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1273] Clarify what happens to the current FacesContext during the execution of ViewMetadata.createMetadataView() Created: 03/Apr/14  Updated: 01/Aug/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3205 Postback executes <f:event type="preR... Closed

 Description   

See JAVASERVERFACES-3205.

first.xhtml
<f:view>
  <f:metadata>
    <f:viewParam name="id" value="#{outcomeTestFirstBean.firstId}"></f:viewParam>
  </f:metadata>

	<h:head>
	</h:head>
	<h:form>
		
		<h2>Problem description:</h2>
		When visiting this page using the following link: <a href="?id=11111">/first.jsf?id=11111</a> we can show that include-view-params causes a problem.<br/>
		Clicking the TestOutcomeLink poses no problem and will load the second page normally.<br/>
		Any postback will however try to execute the preRenderView event of the OutcomeTestSecondBean (because the metaData is parsed at ViewMetadataImpl.createMetadataView(FacesContext) line: 115)
		<br/><br/><br/>
		<h:link outcome="second" value="TestOutcomeLink" includeViewParams="true">
			<f:param name="extraParam" value="99999" />
		</h:link>
		<br/><br/><br/>
		<h:commandLink value="Postback goes BOOM" action="#{outcomeTestFirstBean.justAnAction}" />&nbsp;
		<h:commandButton value="Postback goes BOOM" action="#{outcomeTestFirstBean.justAnAction}" />
	</h:form>
</f:view>

and

second.xhtml
<f:view>
  <f:metadata>
    <f:viewParam name="id" value="#{outcomeTestSecondBean.secondId}"></f:viewParam>
    <f:event listener="#{outcomeTestSecondBean.load}" type="preRenderView" />
  </f:metadata>
	<h:head>
	</h:head>
	<h:form>
		<h:outputLabel value="#{outcomeTestSecondBean.secondId}" />
	</h:form>
</f:view>

When first.xhtml renders, the <h:link> will cause the <f:metadata>
section of second.xhtml to be executed. This will cause a dummy
UIViewRoot to be created and thrown away, per the spec. Unfortunately,
the <f:listener> in second.xhtml's <f:metadata> section ends up on
first.xhtml's UIViewRoot. The spec for
ViewMetadata.createMetadataView() must require the existing UIViewRoot,
if any, to be restored before returning from the method.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-1274] In ViewMetadata.createMetadataView() clarify state for temporary UIViewRoot Created: 10/Apr/14  Updated: 08/Sep/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-3205 Postback executes <f:event type="preR... Closed

 Description   

In ViewMetadata.createMetadataView(), specify

  • the new UIViewRoot must be set as the FacesContext's viewRoot before applying the tag handlers, restoring
    the old FacesContext in a finally block.
  • The content's of the current UIViewRoot's ViewMap must be copied to the ViewMap of the new UIViewRoot
    before applying the tag handlers.


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

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





[JAVASERVERFACES_SPEC_PUBLIC-1185] Pass Through attribute should have priority when rendering Created: 25/Apr/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Bruno Borges Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Tried the following code:

index.xhtml
<a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a>

The href attribute rendered contains the value anotherPage_fake.xhtml. In this case (and similar others), the pass through attribute should have priority in the rendering process, if it will compete with a static attribute.



 Comments   
Comment by Bruno Borges [ 13/Aug/13 ]

Digging more into Pass Through Attributes, I find this feature one of the best things I've ever seen in JSF in years, because it could bring development/designer preview without the need to run an app server. A feature that several frameworks permit, such as Apache Wicket and Tapestry. But if Pass Through Attributes doesn't override regular attributes, then it becomes not interesting.

The spec is not clear about this, and I think it should be provided an Errata, with a change in the current implementation.

Sample A

 
<script type="text/javascript"
             src="../../js/jQuery.js"
             p:src="${facesContext.externalContext.requestContextPath}/js/jQuery.js"></script>

Sample B

<script type="text/javascript" src="../../js/jQuery.js">
    <f:passThroughAttribute
       name="src"
       value="${facesContext.externalContext.requestContextPath}/js/jQuery.js" />
</script>

Either samples should end up with this:

<script type="text/javascript" src="/myapp-1.0-SNAPSHOT/js/jQuery.js"></script>
Comment by Frank Caputo [ 13/Aug/13 ]

Pass through attributes have priority as specified in the “Rendering Pass Through Attributes” section of the overview of the standard HTML_BASIC render kit: https://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/renderkit-summary.html#general_behavior_encoding

In <a href="anotherPage_fake.xhtml" jsf:outcome="/anotherPage.xhtml">Another Page</a> the href attribute becomes a pass through attribute and thus has priority.

Comment by Bruno Borges [ 13/Aug/13 ]

Hi Frank, thanks for pointing that out, but I disagree that "static" attributes should have priority when faced against calculated/dynamic attributes such as jsf:outcome.

If an element has both attributes (a static like 'href', and a dynamic as 'jsf:outcome'), the general idea is that the static attribute is for static preview/prototyping only, and should be replaced by the calculated value.

This is how other web frameworks have been doing for years.

Comment by jyeary [ 13/Aug/13 ]

The link you specified has some very specific text about priority.

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence. Pass through attributes are rendered as if they were passed to ResponseWriter.writeURIAttribute().

Unless I am reading this incorrectly, the jsf:outcome should take precedence over the static href attribute. I am on the fence on this though. I think that the pass through attributes are a great addition to the framework. However, if the renderer has the attribute defined, it can be set dynamically using EL. In this case, pass through attributes are simply duplicating the renderer specific attributes. This is for the case of the JSF components.

What advantages do we gain from the pass through taking precedence over the renderer specific attributes if they duplicate each other? I would say that the renderer specific attributes should take precedence.

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

Comment by Bruno Borges [ 13/Aug/13 ]

In the case of static HTML template text (UIInstructions) , it makes sense that the dynamic pass through should take precedence over the static attribute such as href.

This is what I'm looking for. I don't want to loose the "previability" of the page.

Comment by Ed Burns [ 28/Aug/13 ]

From the spec section cited by John and Frank:

The ResponseWriter must ensure that any pass through attributes are rendered on the outer-most markup element for the component. If there is a pass through attribute with the same name as a renderer specific attribute, the pass through attribute takes precedence.

Consider Bruno's original markup:

<a href="anotherPage_fake.xhtml" 
   jsf:outcome="/anotherPage.xhtml">Another Page</a>

Because this is an <a> element with a jsf:outcome attribute, it is treated as an h:link, specified in the following.

http://javaserverfaces.java.net/nonav/docs/2.2/renderkitdocs/HTML_BASIC/javax.faces.Outputjavax.faces.Link.html

Perhaps the root problem here is that there is another set of attributes that must be considered, separate from the set of renderer specific attributes. This is the set of attributes that the renderer itself must use when rendering the component. Let's call these renderer required attributes. I suggest that the spec be modified to define the term renderer required attributes, and to say that renderer required attributes take precedence over pass through attributes on the markup.

Unfortunately, there is no runtime representation of the set of renderer required attributes, so it's not possible for the spec to say that, though. We would need to have a way for each renderer to declare its set of renderer required attributes, then we could require the ResponseWriter to act accordingly based on the priority.

There is no conflict because "href" is not a renderer specific attribute.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Critical





[JAVASERVERFACES_SPEC_PUBLIC-904] Composite component file extensions Created: 29/Oct/10  Updated: 12/Aug/14

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

Type: Bug Priority: Critical
Reporter: aschwart Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: Macintosh


Issuezilla Id: 904
Status Whiteboard:

size_small importance_medium


 Description   

From jsr-314-open:

> Both MyFaces and Mojarra currently assume/require the file extension ".xhtml" for composite
> component resources. This seems overly restrictive. Composite component authors should be able
> to use other file extensions - eg. ".view.xml", or, as we would like to do here: ".jsf".

Thread starts here:

http://lists.jboss.org/pipermail/jsr-314-open-mirror/2010-October/000644.html



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

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





[JAVASERVERFACES_SPEC_PUBLIC-988] Dynamic include problem Created: 25/Apr/11  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 1.2, 2.0, 2.1
Fix Version/s: None

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

Status Whiteboard:

size_large importance_large


 Description   

JB> 2) the "dynamic UI include" problem - This is a scenario where you
JB> have several different types of include files and need to show a
JB> list of items (each "item" being the include template) where the
JB> list is only know at runtime. Let's make up a specific example here
JB> to illustrate:

JB> You have an event registration system that sells tickets online:

JB> - A user can buy multiple tickets (and different types of tickets)
JB> as part of the purchase process

JB> - Each ticket purchased has to have totally different information
JB> filled out

JB> - There are many different types of tickets (e.g.: attendee,
JB> sponsor, exhibitor, etc)

JB> - every time they "add a ticket" (it considers what kind of ticket
JB> they selected and adds that type of form to the list of forms that
JB> will need to be completed before proceeding with the purchase)

JB> Now obviously in this example you could build a "dynamic" template
JB> that based on an input variable renders itself differently and put
JB> this inside a <ui:repeat/> - or for that matter you could
JB> programmatically insert the elements comprising each type of form
JB> into the control tree. The problems with these approaches is that
JB> you're back to server programming for every little UI change (not to
JB> mention you've got one big component with potentially hundreds of
JB> pieces of logic in it). ASP.NET solves this by allowing you to
JB> define a .ascx file (much like a facelet include) and then
JB> programmatically include them into something akin to a JSF
JB> panelGroup. Then on postback you simply get an enumeration of the
JB> items and loop through them to retrieve the values of the class
JB> that's bound to the child components. Now with a lot of trickery and
JB> a ton of time for each implementation you can get something close
JB> with JSF but it's not at all intuitive or easy.



 Comments   
Comment by lamine_ba [ 26/Apr/11 ]
  • The JSF framework is a set of abstractions for building different types of web applications.
  • A business application is a set of polymorphic systems.
  • Different types of Customers
  • Different types of Contracts
  • Different types of Y

which leads to this recurrent design

public abstract class Y {
}


public class XY extends Y{
}

which once applied in an event registration system brings something like this

public abstract class Ticket {         
}


public class SponsorTicket extends Ticket {
}


public class AttendeeTicket extends Ticket {
}


public class Reservation {

      public void addTicket(Ticket ticket) {
      }         
      public void removeTicket(Ticket ticket) {
      }
      public Collection<Ticket> getTickets() {
      }
 }

Let's make something interesting now and let's override the toString() method to return the type of a ticket.

public class SponsorTicket extends Ticket {
        
     public String toString() {
            return "SponsorTicket";
     }
}


public class AttendeeTicket extends Ticket {

      public String toString() {
             return "AttendeeTicket";
       }

}

This technique is powerful in a polymorphic system once coupled with the power of a template engine to generate dynamic content following a pattern like this one :

             return-value${dynamic-value}
             
  • Let's design now our form web pages using the Velocity Template Engine
  • Reservation page

dynamic include of the derivate forms based on the toString() return value.

   #foreach($ticket in $reservation.tickets)
    #set($template="form" + $ticket + ".vm")         
    #include($template)
   #end
  • formSponsorTicket.vm
label 1 : <input type="text" value=".."/>
label 2 : <input type="text" value=".."/>
label 3 : <input type="text" value=".."/>
label 4 : <input type="text" value=".."/>
label 5 : <input type="text" value=".."/>

Because we have a polymorphic system, the forms will have some fields in common. Thus to avoid the duplication, it is better to create a common page (formTicket.vm) like we did for the abstract class Ticket.

#foreach($ticket in $reservation.tickets)
      #include("formTicket.vm")                                                
      #set($template="form" + $ticket + ".vm")
      #include($template)
#end

..............................................................................

  • Let's design now our form web pages using the Facelets Template Engine
  • Reservation Page

<ui:repeat value="#{reservation.tickets}" var="ticket">
       <ui:include src="formTicket.xhtml"/>                 
       <ui:include src="form${ticket}.xhtml"/>                 
</ui:repeat>

Common Page : formTicket.xhtml


label 1 : <h:inputText  value=".."/>
label 2 : <h:inputText  value=".."/>

Page : formSponsorTicket.xhtml


label 3 : <h:inputText  value=".."/>
label 4 : <h:inputText  value=".."/>
label 5 : <h:inputText  value=".."/>

-------------------------------------------------------------------------

Comparison of the solutions

The two solutions are the same even if I'm using two different template engines and what is quite amazing is that none of them works. Why? Because when you include a file in a iteration, you still get the whole context as model. No way to use the current object being iterated as model thus making you unable to do something like this

<ui:repeat value="#{reservation.tickets}" var="ticket"> 
    <ui:include src="formTicket.xhtml"/> (var="ticket" not used)
    ....................................................
</ui:repeat>

Velocity :

<input type="text" value="${ticket.property1}"/>

Facelets :

 <h:inputText  value="#{ticket.property1}"/>

Jason, You are doing a binding in your managed beans because you want to have a way to get this reference and as you may know, binding means coupling, maintenance nightmare, a change here and a change there.

To overcome this problem without using the problematic programmatic approach, we should have a way to set the model to use for the template to be included, something like this

 <ui:include src="formTicket.xhtml" model="${ticket}"/>

Reservation Page


<ui:repeat value="#{reservation.tickets}" var="ticket">
     <ui:include src="formTicket.xhtml"    model="#{ticket}"/> 
     <ui:include src="form#{ticket}.xhtml"  model="#{ticket}"/>
</ui:repeat>

Another alternative would be to use the JSF composite components feature which is the opposite side of the dynamic include approach
and one possible solution to leverage if the JSF runtime was able to generate dynamically the xml tags by following a pattern like this

  <namespace:#{tag-value}>

So instead of creating a facelets view for each type of ticket, we will create a composite component for each type of ticket and write something like this in the reservation page

Reservation Page

<ui:repeat value="#{reservation.tickets}" var="ticket">
    <ez:formTicket    model="#{ticket}"/>   (formTicket.xhtml)
    <ez:form#{ticket}  model="#{ticket}"/>  (formSponsorTicket.xhtml...)
</ui:repeat>

Composite component (formSponsorTicket.xhtml)

<composite:interface>
    <composite:attribute name="model" required="true"/>
</composite:interface>

<composite:implementation>

    label 3 : <h:inputText  value=" #{cc.attrs.model.property1}"/>
    label 4 : <inputText  value="#{cc.attrs.model.property2}"/>
    label 5 : <inputText  value="#{cc.attrs.model.property3}"/>

</composite:implementation>

If the dynamic tags generation is impossible for JSF, we can still make some if.........

<ui:repeat value="#{reservation.tickets}" var="ticket">
      <c:if test="#{ticket == 'SponsorTicket'}">
         <ez:formSponsorTicket    model="#{ticket}"/>.
       </c:if>
           ......
</ui:repeat>

we have two solutions and two possible new issues.

1) Facelets inclusion improvement
2) EL support for generating dynamic xml tags

These solutions have been realized from a page author perspective.

Comment by lamine_ba [ 27/Apr/11 ]

JB> Proposed solutions certainly appear valid – but this may actually be a little easier. If item 989 (http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-989) is implemented you could quite simply use that function to programmatically add the dynamic include to the control tree. This of course assumes that you can read, compile and include a facelet file programmatically (which I believe I’ve seen somewhere?)

MLB> Again Jason, thus you can programmatically create an UI representation for your object and attach this representation to its UI container
But this time the UI representation is not created directly from your java code. You take it from a resource, from a facelets file written maybe by a web designer. And the algorithm of your handleRepeatItem(Object currentObjectFromCollection, UIComponent currentContainerHoldingChildComponents) method will look something like that:

1)for the currentObjectFromCollection, find its UI resource file (facelets file)
2) load the resource file, compile it and create an UI representation from it
3) Attach the UI representation to its UI container : currentContainerHoldingChildComponents.add(representation)

But at this point, If I were you, I would say " Hey I don't see anymore what JSF did for me and the abstraction it brings to ease the job. Why do I have my hands dirty? Why things shouldn't be simpler as to give the resource name to the JSF runtime which will manage the details for me and create an UI representation (UIComponent) from my resource ".

javax.faces.Application class


public abstract class Application {

 public UIComponent createComponent(FacesContext context,
                                       Resource componentResource) {
}

public UIComponent createComponent(Resource resource) {
  // a simplification of the first method which use the current context

}


public UIComponent createComponent(String resourceName) { 

 // unification, componentType and resourceName must be supported

}

}

To move further Take a look at these issues below because they are related

Where to find the resources : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-809

Jason, you are managing 40 developers to develop business applications? Are these applications modular? How do you divide the work among your developers? How do you do the integration of the pieces (modules)? How do you reuse your past work when developing a new application? Do you always start from scratch?

Support for modular, reusable fragments of web applications : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-532
Plugin System : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-970

Have you a web designer in your team?

Multi-templating : http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-971

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-1147] Dynamical switching of state saving mechanism Created: 28/Nov/12  Updated: 01/Aug/14

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

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

Issue Links:
Related
is related to JAVASERVERFACES-1959 StateManager.isSavingStateInClient no... Closed
is related to JAVASERVERFACES-2616 Dynamical state saving mechanism Closed

 Description   

It should be possible to switch state saving dynamically per request via StateManager#isSavingStateInClient.
e.g. Therefore it would be possible to use server side state for view A and client side for view B.



 Comments   
Comment by kithouna [ 05/Mar/13 ]

I think this is a direct duplicate of JAVASERVERFACES_SPEC_PUBLIC-1056

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 to priority Major (because of its related issue).





[JAVASERVERFACES_SPEC_PUBLIC-810] Access to component ancestor chain during Facelets handler processing Created: 25/May/10  Updated: 12/Aug/14

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

Type: Improvement Priority: Major
Reporter: aschwart 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: Macintosh


Issuezilla Id: 810
Status Whiteboard:

size_large importance_medium

Tags: adf

 Description   

We have various JSP tag implementations that walk up the component ancestor chain during tag execution
for one reason or another. While porting these tags to Facelets, we have been forced to work around the
fact that Facelets does not connect the ancestor chain until after children have been processed.

While it may be too late to change Facelets behavior now, it would be helpful to provide access to the
ancestor chain through some API so that Facelets handlers can interact with parent/ancestor components.



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

2.1.

Comment by Ed Burns [ 01/Jun/10 ]

Add adf keyword

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

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.





Deprecate "targets" concept (JAVASERVERFACES_SPEC_PUBLIC-901)

[JAVASERVERFACES_SPEC_PUBLIC-755] passing through of actionListener, action,.. not possible between composite components Created: 27/Feb/10  Updated: 01/Aug/14

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

Type: Sub-task Priority: Major
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 8
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Attachments: Text File 755-cc-attribute-full-solution.patch     Text File 755-cc-attribute-Nested-No-EL.patch     Text File 755-cc-attribute-with-EL.patch     Zip Archive 755-reproducer.zip     Zip Archive composite-component-targets-test-4.zip     File composite-component-targets-test.war     File composite-component-targets-test.war     Zip Archive composite-component-targets-test.zip     Text File diffs.patch     Text File diffs.patch     File jsf-systest.war     File jsf-systest.war    
Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-901 Deprecate "targets" concept Closed
Issuezilla Id: 755
Status Whiteboard:

cat2 frame size_medium importance_large


 Description   

I already talked to Ed Burns about this at the JSFDays, but I thought opening a
spec issue won't be bad!

There are 4 special attributes on composite components (action, actionListener,
validator, valueChangeListener) which are not populated on #

{cc.attrs}

as
MethodExpressions, but added to their related components (defined via the
targets attribute of cc:attribute) directly via setAction(), addActionListener(),...

This works fine for all standard components. However if you nest another
composite component inside the implementation of our composite component, you
are not able to pass any of those 4 attributes through to the nested composite
component, because it (normally) is a UINamingContainer which does not implement
any of the needed interfaces.

To make this more clear imagine you have a composite component which is a
special commandButton (AJAX-commandButton or whatever) and you're creating e.g.
a LoginPanel composite component. This LoginPanel composite component has an
actionListener attribute to determine the actionListener for the login button
(which in our implementation is our composite component commandButton). Now we
are not able to pass the actionListener through to "our" commandButton, because
it is no ActionSource2 an the MethodExpression is not stored in
#

{cc.attrs.actionListener}

. The same applies to the 3 other attributes.

<cc:interface name="loginPanel">
<cc:attribute name="actionListener" targets="???" />
</cc:interface>
<cc:implementation>
<!-- other components -->
<ez:customCommandButton actionListener="???" />
</cc:implementation>



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

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by ganeshpuri [ 13/Oct/10 ]

I ran into this with my first large scale JSF 2.0 customer within a few days and
I think it should be urgently fixed, because usage of action, actionListener,
validator and valueChangeListener is essential to composite components and
nesting them will happen as soon a they are used in non trivial projects.

Comment by Ed Burns [ 13/Oct/10 ]

I am delighted to report that now taking the time to look at this more
closely, I observe that it appears to work.

In fact, we have an automated test and I'm about to attach the war.

Deploy the war and visit

http://localhost:8080/jsf-systest/faces/composite/nesting03.xhtml

Click the button. It works if you are navigated to a page with
<title>Navigation Result</title>.

The key enabler is you must declare the cc-relative client-id in the
targets.

SECTION: Using Page nesting03.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"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:ez="http://java.sun.com/jsf/composite/composite">
<head>
<title>Nesting 03</title>
</head>
<body>
<h:form>
<ez:nesting3 action="#

{compositeBean.doNav}

" />
</h:form>
</body>
</html>

SECTION: Defining Page nesting3.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"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:composite="http://java.sun.com/jsf/composite"
xmlns:ez="http://java.sun.com/jsf/composite/composite">
<head>
<title>Should Not Be Displayed</title>
</head>
<body>
<composite:interface>
<composite:attribute name="action" required="true" method-signature="String method()"
targets="wrapper:commandButton"/>
</composite:interface>
<composite:implementation>
<ez:wrapper id="wrapper">
<h:commandButton id="commandButton" value="Click Me" />
</ez:wrapper>
</composite:implementation>
</body>
</html>

SECTION: Managed Bean CompositeBean.java

public String doNav()

{ return "nestingNav"; }
Comment by Ed Burns [ 13/Oct/10 ]

Created an attachment (id=304)
mojarra systest.war

Comment by Jakob Korherr [ 13/Oct/10 ]

REOPENING

Thanks for looking into this, Ed, but unfortunately you got our scenario wrong.
Your scenario works, but imagine the following implementation section of nesting3:

<composite:implementation>
<ez:someOtherNestingComponent action="????" />
</composite:implementation>

and the page for someOtherNestingComponent:

<composite:interface>
<composite:attribute name="action" required="true"
method-signature="String method()" targets="commandButton"/>
</composite:interface>
<composite:implementation>
<h:commandButton id="commandButton" value="Click Me" />
</composite:implementation>

Thus you have a composite component with an action attribute that itself uses a
composite component with and action attribute that itself uses a
h:commandButton. How can you accomplish that?

Or to be more specific: what do you use for the action attribute of the inner
composite component since action is not published as #

{cc.attrs.action}

and how
do you prevent the ClassCastException for ActionSource2 for the inner composite
component (since the first composite component tries to retarget the action
listener to it)?

Is this enough documentation or should I provide a sample webapp?

Comment by Ed Burns [ 13/Oct/10 ]

Ahh, thanks for reopening this.

I have modified the systest and will attach a patch and a new version of it.

Deploy it and you can reproduce the problem by visiting
http://localhost:8080/jsf-systest/faces/composite/nesting09.xhtml

Comment by Ed Burns [ 13/Oct/10 ]

Created an attachment (id=305)
patch to systest that shows off the bug.

Comment by Ed Burns [ 13/Oct/10 ]

Created an attachment (id=306)
systest with patch applied.

Comment by Ed Burns [ 13/Oct/10 ]

I'm really sorry to do this, but we simply don't have time to make this into 2.1.

If someone wants to submit a patch, maybe we can get it in under the wire. If so, I suggest they start by
taking a look at FaceletViewHandlingStrategy.java, line 1408:

((ActionSource2) target)
.setActionExpression(
new ContextualCompositeMethodExpression(((sourceValue instanceof ValueExpression)
? (ValueExpression) sourceValue
: null),
me));

}

This is where the ClassCastException mentioned by Jakob originates.

I'd approach a first approximation of this feature by introducing some isCompositeComponent() test
there and take action accordingly.

Comment by Ed Burns [ 25/Oct/10 ]

On Friday 22 October at 18:33 EDT, Martin Marinschek wrote:

MM> Hi guys,

MM> my strong believe is that the target attribute should be immediately
MM> deprecated.

MM> It is wrongly placed where it is right now - an interface definition
MM> should never provide hooks into the implementation. It should only
MM> provide a meaningful context to which the implementation can refer.

The targets attribute is central to the entire concept of composite
components. I assert that it does not constitute a violation of the
abstraction because the targets attribute is not intended for
consumption by the page author. In fact, it is an implementation detail
that happens to reside within the <cc:interface> section.

MM> I am sorry I haven't voiced this objection before - but at the time
MM> this was discussed I was not very active on the EG, and then it was
MM> too late to talk about this.

Yes, I'll say! I recall that we talked about this in December 2007. I
know because we had the EG meeting while I was in the hotel at
JavaPolis and I remember such a unique venue.

>>>>> On Tue, 19 Oct 2010 14:30:17 -0500, Leonardo Uribe <lu4242@gmail.com> said:

LU> I like the way it works now. For example, tomahawk t:inputHtml
LU> component was rewritten into a composite component, and it is a good
LU> example about when it could be useful that the only requerimiento
LU> for a component to be composite is implement NamingContainer:

For what it's worth, Leonardo is happy with this way it works, provided
we address his other issues.

On Sat Oct 23 03:46:13 EDT 2010 Ganesh wrote:

G> Martin, I like your proposal on deprecating "targets". But how would
G> you then handle this case: Using a cc I nest <f:actionListener
G> "for=a" ... /> and inside the cc there is a <cc:actionSource name="a"
G> targets="b, c" /> where b and c are buttons? The logic of the "for"
G> attributes only includes this: "If present, this attribute refers to
G> the value of one of the exposed attached objects within the
G> composite component inside of which this tag is nested." IMO
G> deprecating "targets" would require opening "for" to refer to
G> multiple exposed attached objects within the composite component
G> inside of which this tag is nested just the way targets is doing this
G> right now. "targets" kind of bundles them right now.

Yes, exactly. There was a lot of back and forth between David Geary,
Ken Paulsen, Kito Mann, Andy Schwartz, and myself on this.

G> To make this more convenient omitting "for" could simply be a synonym
G> representing a "for" for all nested actionSources, actionSource2s
G> and CCs.

I prefer to be explicit here.

G> Please follow Jakob's proposal on adding action, actionListener,
G> valueChangeListener and validator the attributes map
G> (#

{cc.attrs.action}, #{cc.attrs.actionListener},
G> #{cc.attrs.valueChangeListener}, #{cc.attrs.validator}). This is what
G> a developer would expect to happen (at least I did so) and one could
G> easily pass them on to nested components.

JK> I think we should do this a little differently:

JK> 1) try to add the e.g. ActionListener to the component specified in
JK> the targets attribute, if possible. If it is not possible, log a
JK> warning.

JK> 2) also expose the "well-known" attributes ("action",
JK> "actionListener", ...) on the composite component attribute map, this
JK> means being able to access the action attribute via #{cc.attrs.action}

JK> (currently not possible, because those attributes are not put on the
JK> attribute map).

JK> Thus the user can use the targets attribute if he/she wants to (and of
JK> course, if it is possible) and also use #

{cc.attrs.action} to refer to
JK> the action attribute (like to any other attribute).

JK> Frankly I really don't understand why this was separated in the first
JK> place. Of course, the targets attribute is neat, but IMHO it is also
JK> kinda confusing. I find it a lot easier to access every attribute
JK> (regardless if well-known or custom) via #{cc.attrs.attributeName}.
JK> Furthermore using this approach you can support nesting normal
JK> components and also nesting composite components.

JK> In addition the targets attribute can't solve a scenario in which the
JK> action attribute of the inner component is required (most likely the
JK> attribute from a composite component), because you need to enter a
JK> value for the attribute, but you currently can't use
JK> #{cc.attrs.action}

, because this one points "nowhere".

Comment by lu4242 [ 26/Oct/10 ]

Created an attachment (id=319)
Patch to use cc.attrs.action EL

Comment by lu4242 [ 26/Oct/10 ]

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

Comment by lu4242 [ 26/Oct/10 ]

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

Comment by Ed Burns [ 27/Oct/10 ]

Thanks for the patch. I'm evaluating it now.

Comment by Ed Burns [ 27/Oct/10 ]

I applied the patch and re-ran a test page I had previously authored (on 13 October) and still see the
ClassCastException.

Can you please rework the patch to fix that?

Thanks,

Ed

This time I'll attach a zip of the simple xhtml files.

Comment by Ed Burns [ 27/Oct/10 ]

Created an attachment (id=325)
zip of composite component files

Comment by lu4242 [ 29/Oct/10 ]

Created an attachment (id=330)
Patch solving problem cc:attribute targets to nested composite components

Comment by lu4242 [ 29/Oct/10 ]

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

Comment by lu4242 [ 29/Oct/10 ]

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

Comment by lu4242 [ 03/Nov/10 ]

Created an attachment (id=335)
Full solution merging two previous patches

Comment by Ed Burns [ 04/Feb/11 ]

Snapshot of reproducer, in progress.

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-715] missing <f:behavior> (convenience) tag Created: 05/Jan/10  Updated: 01/Aug/14

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

Type: Bug Priority: Major
Reporter: mwessendorf 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: 715
Status Whiteboard:

cat2 javadoc size_medium importance_large draft


 Description   

For converters/validators there is a convenience tag to integrate (simple)
custom implementations of these.

For behaviors that is not the case. A <f:behavior> tag would nice; It should
"act" similar to its cousins, f:converter/validator



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

cat1

Comment by Ed Burns [ 16/Mar/10 ]

vdl

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-636] Clarification of Facelets-only (non-JSP) functionality Created: 24/Sep/09  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
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 validator06.jspx    
Issuezilla Id: 636
Status Whiteboard:

cat1 frame size_large importance_large

Tags: adf

 Description   

I would like to see the spec provide more explicit documentation of exactly which new features are not
available in JSP. I sent the following two proposals to the EG list:

1. Let's update the spec to state specifically what functionality (down to the tag/tag library level) is not
supported in JSP.

It is possible that this information is already present, but if not, I would like to see a section that
contains a list of all of the new tags that were added in JSF 2 that are specific to Facelets (ie. not
available in JSP).

2. Let's update the Facelets PDL docs to identify tags that are not present in JSP.

For example, the PDL doc for f:ajax should state that it is not available in JSP.

Regarding #1... I think it is important to have this information available in a centralized location, where
it can be easily found/understood by JSP users. #2 should also help to avoid confusion.



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete api subcomponent

Comment by rogerk [ 24/Feb/10 ]

Target 2.0 Rev A

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 15/Mar/10 ]

facelets

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by Ed Burns [ 02/Jun/10 ]

Please make sure to see issue 1402.

Comment by Ed Burns [ 07/Jun/10 ]

This is not a technically difficult issue, but it is a time consuming one.

I think the best way to do it is empirically. I'm writing an HtmlUnit test suite that exercises the jsp
accessible supported/unsupported status of the big ticket new features in JSF2.

So far it's looking like this:

public void testUnsupportedFeaturesAreUnsupported() throws Exception

{ // These features are not implemented in JSP assert500Response("/faces/jsf2jsp/head-gives-500.jspx"); assert500Response("/faces/jsf2jsp/body-gives-500.jspx"); assert500Response("/faces/jsf2jsp/outputScript-gives-500.jspx"); assert500Response("/faces/jsf2jsp/outputStylesheet-gives-500.jspx"); assert500Response("/faces/jsf2jsp/button-gives-500.jspx"); assert500Response("/faces/jsf2jsp/link-gives-500.jspx"); assert500Response("/faces/jsf2jsp/resource-ELResolver-gives-500.jspx"); assert500Response("/faces/jsf2jsp/ajax-gives-500.jspx"); assert500Response("/faces/jsf2jsp/event-gives-500.jspx"); assert500Response("/faces/jsf2jsp/metadata-gives-500.jspx"); }

public void testSupportedFeaturesAreSupported() throws Exception

{ // These features are implemented in JSP HtmlPage page = getPage("/faces/jsf2jsp/commandButton-parameter-children-gives-hidden- fields.jspx"); HtmlSubmitInput button = (HtmlSubmitInput) page.getElementById("reload"); page = button.click(); String text = page.asText(); assertTrue(text.contains("name01=value01")); assertTrue(text.contains("name02=value02")); page = getPage("/faces/jsf2jsp/resources.jspx"); text = page.asXml(); assertTrue(text.contains("duke.gif")); assertTrue(text.contains("vLibrary")); assertTrue(text.contains("2_01_1")); assert200Response("/faces/jsf2jsp/selectManyJsf2Features.jspx"); Test validatorTest = ValidatorTestCase.suite(); TestResult validatorResult = new TestResult(); validatorTest.run(validatorResult); assertTrue(validatorResult.failureCount() == 0); }
Comment by Ed Burns [ 07/Jun/10 ]

Because this issue is labor intensive, I'm wondering if we should push it to 2.1?

Comment by Ed Burns [ 11/Jun/10 ]

Move to 2.1.

Comment by Ed Burns [ 11/Jun/10 ]

Copy this from Neil Griffin's google doc linked from issue 714.

Availability of f:validateBean and f:validateRequired in JSP

Section 10.4 outlines the f: namespaced tags that are only applicable to Facelets (and not JSP). In that
section, f:validateBean, and f:validateRequired are listed. However, they are both listed as working with
JSP as well (kind of like f:validateRegex), as can be seen from the JSP TLDDocs [1].

According to Dan Allen: "those tags only work partially in JSP. Yes, they work as single field validators.
But the branch validator capability does not work (wrapping the validator tag around a branch). The
later feature is Facelets only. So the validators do have their feet in both ponds, but only Facelets has full
support. I suppose we could mention this tidbit in the JSP section."

I agree with Dan that it should be mentoned in the JSP section, but also, that f:validateBean and
f:validateRequired belong in both Section 10.4 and 9.4, with the limits of their functionality described in
each section.

[1] https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/jsp/index.html

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

ADF issues targeted at GlassFish 3.1 M5

Comment by Ed Burns [ 01/Jul/10 ]

Created an attachment (id=248)
jsf-ri/systest/web/validator06.jspx

Comment by Ed Burns [ 08/Jul/10 ]

I discovered that f:viewParam exists in the JSP jsf_core.tld. Does it really work?

Comment by Ed Burns [ 01/Sep/10 ]

Move to m6

Comment by Ed Burns [ 01/Sep/10 ]

Must be done by September 30th.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 13/Sep/10 ]

changelog

Comment by Ed Burns [ 13/Sep/10 ]

remove changelog_2_1 keyword.

Comment by Ed Burns [ 21/Aug/13 ]

The specification of StateManagementStrategy is too tight and needs to be loosened to allow greater flexibility of implementation.

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-609] ui:repeat varStatus incompletely specified. Created: 12/Aug/09  Updated: 01/Aug/14

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

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

Operating System: All
Platform: Macintosh


Issuezilla Id: 609
Status Whiteboard:

cat2 vdldoc size_small importance_small


 Description   

The varStatus attribute on ui:repeat supports some of the concepts present in JSTL's LoopTagStatus [1],
including the "begin" and "end" concept. However, the corresponding attributes from c:forEach are not
exposed on ui:repeat. This issue would like to fix that.

[1] http://java.sun.com/javaee/6/docs/api/javax/servlet/jsp/jstl/core/LoopTagStatus.html



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

Taking the documentatation from c:forEach [1]

begin If items specified: Iteration begins at the item located at the specified index. First item of the
collection has index 0. If items not specified: Iteration begins with index set at the value specified.

end

If items specified: Iteration ends at the item located at the specified index (inclusive). If items not
specified: Iteration ends when index reaches the value specified.

[1] http://java.sun.com/products/jsp/jstl/1.1/docs/tlddocs/c/forEach.html

Comment by Ed Burns [ 12/Aug/09 ]

Target to 2.1

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 14/Dec/09 ]

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

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

vdl

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

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 Manfred Riem [ 01/Aug/14 ]

Setting priority to Major





[JAVASERVERFACES_SPEC_PUBLIC-1359] Resolve views from dedicated folder Created: 02/Feb/15  Updated: 25/Feb/15

Status: In Progress
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Related
is related to JAVASERVERFACES_SPEC_PUBLIC-1099 Resolve views by convention from dedi... Resolved
is related to JAVASERVERFACES-3791 Implement JAVASERVERFACES_SPEC_PUBLIC... Open

 Description   

The Facelets VDL will by default try to resolve a view in the root of a web application or in META-INF/resources of a jar file (where the jar location automatically follows from using ServletContext#getResource)

In addition to this primary location I would like to propose loading views from a dedicated folder called "/views". This should be done in analogy to how contracts are loaded from "/contracts" and resources from "/resources", including the ability to let a user configure an alternative location.

The use case for this is letting the user easily configure a simple alternative location from where views are loaded and opening up more advanced processing by the runtime.

This more advanced processing is not part of this issue. This issue is strictly about providing a folder from which views (and only views) can be loaded.

Note that this issue is split-off from JAVASERVERFACES_SPEC_PUBLIC-1099, which asked about this folder but also asked about the advanced processing.



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

Sort of sub-issue of 1099





[JAVASERVERFACES_SPEC_PUBLIC-919] Allow inheritance for TagException and TagAttributeException Created: 17/Jan/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

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

Status Whiteboard:

size_small importance_small

Tags: 3_1-exclude

 Description   

javax.faces.view.facelets.TagAttributeException and javax.faces.view.facelets.TagException are final classes. If JSF implementation want provide "smarter" version of those classes, it is not possible now.

  • remove final modifier
  • add getTag() and getTagAttribute() methods
  • modify spec: change sentences like " rethrow the exception as a TagException" to "rethrow the exception as a INSTANCE OF TagException"


 Comments   
Comment by Ed Burns [ 18/Jan/11 ]

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 to priority Minor





[JAVASERVERFACES_SPEC_PUBLIC-918] InitialStateEvent is not fired from the ComponentHandler Created: 05/Jan/11  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_medium importance_large

Tags: 3_1-exclude

 Description   

Hi

I'm working on Mojarra 2.0.3 and no InitialStateEvent is fired.

In the spec it says:

The specification defines the following ComponentSystemEvent classes, all in package javax.faces.event.

  • InitialStateEvent must be published with a direct call to UIComponent.processEvent(), during the
    apply() method of the class javax.faces.webapp.vdl.ComponentHandler. Please see the javadocs for
    the normative specification.

I'm looking for a clean way (listener over extending the component handler) to interact with the initial state of the created component. I would like to have access to the Tag attributes specified on the tag on that event as well.

I want to use this event to validate required attributes and inject additional properties on the component like:

  • injecting a semantic id based on the value or action attribute
  • injecting the value attribute by using a specified id a the key in a resource bundle
  • etc.


 Comments   
Comment by Ed Burns [ 18/Jan/11 ]

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-958] Support explicitly defining the resource bundle for a composite component Created: 01/Apr/11  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_medium importance_small


 Description   

Composite components support defining an own ResourceBundle that is accessible via the EL expression "cc.resourceBundleMap". This resource bundle is found by naming convention. There should also be a way of explicitly defining the resource bundle for a composite component. The <cc:interface> tag could be extended with an "resourceBundle" attribute that contains the resource bundle name.



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

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





General purpose component metadata (JAVASERVERFACES_SPEC_PUBLIC-717)

[JAVASERVERFACES_SPEC_PUBLIC-953] Provide a way to find out if content was defined for a <ui:insert> Created: 28/Mar/11  Updated: 01/Aug/14

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

Type: Sub-task Priority: Minor
Reporter: Jakob Korherr Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Status Whiteboard:

size_medium importance_medium


 Description   

Currently there is no way to find out (except from ugly and/or implementation-specific hacks) to find out if a user provided content for a <ui:insert name="xxx"/> or not.

Scenario: Imagine you want to provide an optional search form, which the user can define via <ui:define name="searchForm">. Then you can insert it via <ui:insert name="searchForm" />. However, what if you have to render some additional markup around the user provided search form, but you don't want to render it if the user did not provide a search form?

One very ugly workaround is to use a h:panelGroup, which you bind to a bean, use <ui:insert name="searchForm" /> as the only child and check via the binding if the h:panelGroup has any children.

It would be very nice to have an EL expression to check this stuff, or maybe to have a special facelets tag which only renders its content if a specific template is available, e.g. (note that I am not very good with names) <ui:ifTemplateAvailable name="">....<ui:insert name="xxx" /> ...</ui:...>

From the MyFaces-impl point of view, I think it is not very hard to implement.



 Comments   
Comment by Jakob Korherr [ 28/Mar/11 ]

or <ui:ifDefined name="xxx">...</ui:ifDefined>

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-1033] BeanValidator "wrapping" functionality should be extended to any (e.g. custom) validator handled using the default ValidatorHandler (+ delegate) Created: 16/Aug/11  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL, Validation/Conversion
Affects Version/s: 2.1 Rev a
Fix Version/s: None

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


 Description   

As an apparently incidental side-effect of the implementation of Bean Validation support, this functionality is available in Mojarra. It is not, however, explicitly required per the specification. Having the ability to wrap custom validator tags around multiple EditableValueHolders as is possible with f:validateBean will improve the consistency of validator handling in facelets.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-987] Solve "Cascading Dropdown Problem" Created: 25/Apr/11  Updated: 01/Aug/14

Status: Reopened
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 1.1, 1.2, 2.0, 2.1
Fix Version/s: None

Type: Improvement 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

Attachments: Text File 20110510-i_spec_987.patch    
Status Whiteboard:

size_large impotance_large


 Description   

>>>>> On Sat, 23 Apr 2011 18:41:42 +0000, Jason Bonifay said:

JB> 1) the classic "cascading drop down problem" - this is a scenario
JB> where the first dropdown is dynamically populated with values and
JB> the selection available in the second dropdown is dependent on the
JB> value selected in the first dropdown (e.g.: select a country then
JB> the list of cities are dynamically populated). Important to note
JB> here - if dropdown #1 has static values this problem obviously
JB> trivial, the challenge arises from a dynamically defined list being
JB> dependent on the selected value from a parent list the is also
JB> dynamically defined. ASP.NET solves this (and other problems) by
JB> defining several "page lifecycle functions" akin to JSF but let's
JB> you easily override functions in the backing classes (i.e.:
JB> "page_init", "page_load" etc) to programmatically control where to
JB> populate each dropdown. Remember - You can't paint the values in
JB> dropdown #2 until you can retrieve the selected index from dropdown
JB> #1 - but you can't retrieve the selected index until you first fill
JB> the options so the framework can then bind the selected index.



 Comments   
Comment by lamine_ba [ 25/Apr/11 ]

One of the solutions to the "Cascading Dropdown problem " is to make the UISelect components aware of each other by adding a parent-child relations. If a selection occurs in the parent (change event), the child is update automatically. The JSF framework will send an Ajax call to invoke a method in the managed bean like for example : load_childs(parent_id ). By parent_id, I mean the value selected in the parent combo, the id of a country for example to invoke a method like load_cities(country_id ) for example. The selected value is the only thing a developer needs in order to run successfully his data access logic. A developer must provide in the UI the method to be called for the partial update. The JSF framework will manage transparently the interaction (display,update,remove,disable) with a client side approach. no UI binding in your managed beans thus making your application scalable.
one selection and multiple selection must be managed.

Comment by lamine_ba [ 27/Apr/11 ]

JB> Agreed. This seems to be the way that other frameworks (and the manual work-around I’ve implemented) are solving it and it seems to work quite well

MLB> Yes it is my opinion, the idea has already been tested and it works quite well. So, let's implement it..

Comment by i_oss [ 27/Apr/11 ]

Sorry I don't quite understand the problem, isn't the setter of <h:selectXXX value="#

{my.selectionSetter}

"/> the method you are looking for? if you change the items of dropdown #2 in the value-setter of #1, it should just work the way described above.

So I am not sure, which lifecylce-phase is missing here? Maybe if someone could point out at which time in the lifecycle "page_init" and "page_load" would take place?

Comment by lamine_ba [ 28/Apr/11 ]

we are talking about doing something like this : http://www.coderanch.com/t/510988/JSF/java/ajax-update-selectOneMenu.

"page_init" and "page_load" functions belong to ASP.NET lifecycle.

our problem is to update dynamically a dropdown based on a selection made on another dropdown (change event). and the solution should be something like this.

    <h:selectOneMenu value="#{bean.country}" id="countries">  
        <f:selectItems value="#{bean.countries}" />  
        <f:ajax event="change" render="cities"  />  
    </h:selectOneMenu>  


   <h:selectOneMenu value="#{bean.city}" id="cities">  
        <f:selectItems value="#{bean.cities}" />  
    </h:selectOneMenu>  
      
    
  @ManagedBean
  public class Bean {
   
  private Long country;
  private Long city;

  ............................................

  }
  
Comment by i_oss [ 29/Apr/11 ]

so it just should be:

(apart from Long probably not being very userfriendly in the rendered page )

public void setCountry(Long country) {
    // put checks for changes here, if it is a long running operation...
    this.cities = whateverToGetTheCitiesFor(country);
    this.country = country;
}

Or am I missing something here?

Still I'd like to know where page_init and page_load would be added to the lifecycle?

Comment by lamine_ba [ 29/Apr/11 ]

i_oss> (apart from Long probably not being very userfriendly in the rendered page )

You can choose whatever you want. I often use the Long type for my id and my primary key.

 
public class Country {

   @Id
   private Long id; // choose whatever you want, Long,Integer,String,....
   private String name;
}

i_oss>


public void setCountry(Long country) {
    // put checks for changes here, if it is a long running operation...
    this.cities = whateverToGetTheCitiesFor(country);
    this.country = country;
}

And you are saving three states which can be a good thing when you have the need to cache your data in order to prevent multiple time access


@ManagedBean
  public class Bean {
   
  private Long country;             //1
  private Long city;                //2
  private List<SelectItem> cities;  //3
  ............................................

  }

and you have created two methods


public List<SelectItem> whateverToGetTheCitiesFor(Long id country) {
}

public List<SelectItem> getCities() {   
   return cities;
}

which could be just one method


public List<SelectItem> getCities() {   
   // call your DAO here
}

Your solution is not my solution and that is the reason why I have just created a skeleton. The only thing I need myself is to be able to know the id of the country and the id of the city that have been selected. ( value="#

{bean.country}

", value="#

{bean.city}

").

i_oss> Or am I missing something here?

Yes, you are really missing something here. We are talking about ASP.net, not about JSF

JB>ASP.NET solves this (and other problems) by
JB> defining several "page lifecycle functions" akin to JSF but let's
JB> you easily override functions in the backing classes (i.e.:
JB> "page_init", "page_load" etc) to programmatically control where to
JB> populate each dropdown. Remember - You can't paint the values in
JB> dropdown #2 until you can retrieve the selected index from dropdown
JB> #1 - but you can't retrieve the selected index until you first fill
JB> the options so the framework can then bind the selected index.

This issue is not really an issue because you can create a working solution with JSF in 5 minutes. We were just unaware that we could realize it without using a programmatic approach. Its only merit is that it helps us find some ideas in how to ease the job and as soon as we have finished to describe them, it will be closed.

Comment by lamine_ba [ 01/May/11 ]
  • Cascading Dropdown implementation with JSF 2.0

  • The entities
public class Country {

	private Long id;
	private String name;	
	
}

public class City {

	private Long id;
	private String name;
	private Country country;
	
}

  • The DAO
public interface Dao {

public List<Country> getCountries();
	
public List<City> getCities(Long country_id);

}
  • The Managed Bean

@ManagedBean
public class Bean {

	private Long country_id=new Long(0);  // select the first option in the combo 
	private Long city_id=new Long(0);    // select the first option in the combo
	private @Inject Dao dao;
	
	public List<SelectItem> getCountries() {
		
		List<SelectItem> items=new ArrayList<SelectItem>();
		for(Country country:dao.getCountries())
			items.add(new SelectItem(country.getId(),country.getName()));
		return items;
	}
	
	public List<SelectItem> getCities() {
		
		List<SelectItem> items=new ArrayList<SelectItem>();
		for(City city: dao.getCities(country_id))
			items.add(new SelectItem(city.getId(),city.getName()));
		return items;
	}
	
	-----------------------------------------------------------------

}

  • The Facelets view

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

<h:head>

<h:outputScript name="jsf.js" library="javax.faces"/> 

</h:head>

<body>

<h:form>

<h:selectOneMenu value="#{bean.country_id}" id="countries">
        <f:selectItem itemLabel="-- Select a Country -- " itemValue="0"/>  
        <f:selectItems value="#{bean.countries}" />  
        <f:ajax event="change"  render="cities" /> 
</h:selectOneMenu>  

 <h:selectOneMenu value="#{bean.city_id}" id="cities">
        <f:selectItem itemLabel="-- Select a City -- " itemValue="0"/>    
        <f:selectItems value="#{bean.cities}" /> 
 </h:selectOneMenu>
 

</h:form>

</body>

</html>

  • The Conclusion

And That's all. we have created a cascading dropdown without using a programmatic approach like this ugly one. (http://www.juurlink.org/2011/02/dynamic-dependent-list-boxes/). We select a country in the first combo and automatically an ajax request is fired behind the scenes to update the other combo. This feature is really a powerful one until the idea to add a commandButton in your form to make a postback and save things, comes to you.


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

<h:head>

<h:outputScript name="jsf.js" library="javax.faces"/> 

</h:head>

<body>

<h:form>

<h:selectOneMenu value="#{bean.country_id}" id="countries">
        <f:selectItem itemLabel="-- Select a Country -- " itemValue="0"/>  
        <f:selectItems value="#{bean.countries}" />  
        <f:ajax event="change"  render="cities" /> 
</h:selectOneMenu>  

 <h:selectOneMenu value="#{bean.city_id}" id="cities">
        <f:selectItem itemLabel="-- Select a City -- " itemValue="0"/>    
        <f:selectItems value="#{bean.cities}" /> 
 </h:selectOneMenu>
 
<h:commandButton action="#{bean.save}"  value="Save">

</h:form>

</body>

</html>

And boum! you get a validation error. Sadly, the combo displaying your cities is saying that the value you have picked in its list is not a valid one because this same value is not anymore in its list". Isn't it a craziness statement?. After some long and hard hours debugging the jsf.js file and looking at the tree printed in the console by my PhaseListener, I came accross no rationale idea. Everything was fine. The partial view processing and rendering were done perfectly and the state of the combo was updated and saved. And suddenly when I was about to loose hope, comes this ironical idea : "Hey put the managed bean in the session scope".


@ManagedBean
@SessionScoped
public class Bean {

  public String save() {

    ----------------------

  }
}

and definitely that was the solution.......

Comment by lamine_ba [ 01/May/11 ]
  • Cascading Dropdown Implementation with JSF 2.2

  • The @SelectionModel annotation

creating SelectItem objects is a recurrent and tedious task for a developer. We must automate it. The developer will save time and we will gain in performance because we have a double iteration, one for creating a list of SelectItem objects and another iteration for creating from this same list another list of UISelectItem components. With this annotation, we can cut the first.

@SelectionModel(value="id",label="name") 

on a method returning a list or a Collection of Country means virtually

 new SelectItem(country.getId(),country.getName()) 

for each country.


@ManagedBean
@SessionScoped
public class Bean {

	
        @SelectionModel(value="id",label="name")
	public List<Country> getCountries() {
	  
           return dao.getCountries();	
	}
	
        @SelectionModel(value="id",label="name")
	public List<City> getCities() {
		
	   return  dao.getCities(country_id))
	
	}
	
	-----------------------------------------------------------------

}

If we bring a convention on how to get the value and the label on objects, we can make this annotation optional which will be again for us a gain of time and clarity.


@ManagedBean
@SessionScoped
public class Bean {

	
 	public List<Country> getCountries() {
	  
           return dao.getCountries();	
	}
	
 
	public List<City> getCities() {
		
	   return  dao.getCities(country_id))
	
	}
	
	-----------------------------------------------------------------

}
Comment by Ed Burns [ 10/May/11 ]

In progress prototype

Comment by i_oss [ 10/May/11 ]

The @SelectionModel is a nice idea.
At the moment you can avoid using SelectItems already by:
1) A Converter, and a sensible toString method on your beans (so this is the current "convention" for not using SelectItems and/or Annotations)
Drawbacks: This can't be tuned on a per <h:select...> basis, so the labels would always be the same and the value would be the full bean
2) Use itemValue and itemLabel on the <f:selectItems...>
Drawbacks: The template developer then has to know what value is expected, and how to build the label from the bean.

In case we create @SelectionModel, I think value and label should be EL with a implicit varname for the items in the list
for example: @SelectionModel(value="#

{item.id}

", label="#

{item.firstname}

#

{item.lastname}

")

Comment by lamine_ba [ 10/May/11 ]

Hi Imre. Yes The @SelectionModel is a nice idea to avoid using SelectItems. I had this idea because I was unaware that this annotation already exists in JSF 2.0 through another representation more cleaner, more simpler and more transparent.

2) Use itemValue and itemLabel on the <f:selectItems...>

public List<Country> getCountries() {
        return dao.getCountries();
}
<f:selectItems value="#{bean.countries}" 
var="country" itemValue="#{country.id}" itemLabel="#{country.name}" />

I prefer now this way which makes my annotation obsolete and there is no way to get an annotation through the Expression Language. But It would be wonderful to have such feature in the EL api.

2) Use itemValue and itemLabel on the <f:selectItems...>
Drawbacks: The template developer then has to know what value is expected, and how to build the label from the bean.

Yes I agree and that is why we want to bring a convention in JSF 2.2. In the real life, every man has an ID (fingerprint, DNA) and a name. In the software life, most of the objects we display are entities. So if we don't provide the information on how to resolve the ItemValue or the ItemLabel, their values will be resolved by invoking getId() and getName() on our objects.

JSF 2.2

public List<Country> getCountries() {
        return dao.getCountries();
}
<f:selectItems value="#{bean.countries}"/>

means virtually

<f:selectItems value="#{bean.countries}" var="country" 
itemValue="#{country.id}" itemLabel="#{country.name}" />

The var attribute like the ItemValue and ItemLabel is now optional and by default its value is equal to 'it'.

<f:selectItems value="#{bean.countries}" itemValue="#{it.id}" itemLabel="#{it.name}" />

so adhere to our JSF 2.2 convention and you will save time.

Comment by Ed Burns [ 10/May/11 ]

The most recent patch, a collaboration from Lamine and I, but mostly Lamine, shows one way to do this.

Comment by i_oss [ 10/May/11 ]

Hi Lamine, only a short note

<f:selectItems value="#{bean.countries}"/>

at the moment is equivalent to

<f:selectItems var="country" itemValue="#{country}" itemLabel="#{country.toString()}"/>

With the #

{country}

being coerced to/from String with a converter (if needed and existing).
So I don't think we want to change the convention that already exists, possibly breaking existing apps.

Comment by lamine_ba [ 11/May/11 ]

Hi Imre, I'm really sorry, I haven't thought about that.

There is already a behavior for

<f:selectItems value="#{bean.countries}"/>

If we change that, the existing apps will break and that is not really a good thing.

So I will just keep this part of my writing of course if you don't see any problem with it

The var attribute is now optional and by default its value is equal to 'it'.

<f:selectItems value="#{bean.countries}" itemValue="#{it.id}" itemLabel="#{it.name}" />
Comment by Jakob Korherr [ 12/May/11 ]

> The var attribute is now optional and by default its value is equal to 'it'.

Why are we using the term "it" here exactly? Should it mean "item"? In that case I would propose naming it "item" instead of "it", because "item" is a LOT more significant than "it" (and it's just two more letters...).

Comment by lamine_ba [ 12/May/11 ]

Hi Jakob. Why are we using the term "it"? That is a very good question. It is just something I have borrowed to Groovy.

Inside each closure, Groovy defines a default variable,
it, for one argument passed to the closure. This makes
it very easy to have a single parameter for your closures without
having to explicitly declare it. The it variable works
just like Perl’s $_ variable in subroutines:

namePrinter = { println "Hello, $

{it}

!" };
namePrinter("John"); // prints "Hello, John!"

If you prefer, we can name it "item". It is also a very nice proposal. I'll be happy with whatever name you'll choose as long as the var attribute is optional. That is the only thing I want.

Comment by Jakob Korherr [ 13/May/11 ]

Hi Lamine,

Thanks a lot for the clarification. I did not know that!

Nevertheless, I prefer "item" over "it". It really is a lot more significant in this case, because most attributes of <f:selectItems> which will use this implicit var are starting with the term "item" --> "itemLabel", "itemValue".

So it would be very great, if we could change that!

Comment by lamine_ba [ 13/May/11 ]

You are right Jakob and I vote for "item". Don't worry, nothing has been done yet. It was just an idea we were testing.

Comment by Ed Burns [ 09/Aug/11 ]

I don't think we made the var attribute optional after all.

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-1249] add "maxRepeats" attribute to ui:repeat. Created: 27/Dec/13  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

Type: New Feature 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


 Description   

It would be very handy if there were a "maxRepeats" attribute on ui:repeat such that the repetition would terminate when either of the following two conditions was true.

1. the collection is empty

2. the maxRepeats value has been reached in terms of number of iterations.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





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

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

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

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


Tags: composite, composite-component, null

 Description   

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

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

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

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

And an inner component:

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

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

And the actual page:

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

When running one can notice a couple of odd things:

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

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


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


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

    " val2="#

    {null}" val3="#{null}

    " val4="#

    {null}

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



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

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





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

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

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


 Description   

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

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



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1200] Search parent naming containers for component Created: 28/Jun/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

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

JSF 2.1.24



 Description   

It's logical that when you have a tree of components you shouldn't look in the child naming containers for a relative id name as duplicates are likely to exist. However it doesn't seem logical to not look in the parent container and take the first avaiable component with that relative id as no duplicates will exist in a single layer above.

I've therefore made an simple update in the UIComponentBase that will look in the parent for the component for the relative id. There's a number of places that this will work more intuitively, especailly for people with a more basic knowledge of JSF. The first is when using relative id's within a dataTable or repeat, all of a sudden relative ids no longer work which is quite confusing if you don't know why. The second is that when you pass a relative id into a custom component it won't be able to find it as the custom component will do the find method relative to itself. The other is when using cc.clientId or similar within a custom component (granted you can just easily add a : beforehand in this scenario). I'm sure there's other times as well where this would come in useful.

Below is the code that would need to be put in place of the existing code, there's only about 5 lines of code actually changed, I've already run this through the JSF tests and everything appeared to pass :

[code]

// Identify the base component from which we will perform our search
UIComponent base = this;
UIComponent initialBase = null;
if (expr.charAt(0) == sepChar) {
// Absolute searches start at the root of the tree
while (base.getParent() != null)

{ base = base.getParent(); }

// Treat remainder of the expression as relative
expr = expr.substring(1);
} else if (!(base instanceof NamingContainer)) {
// Relative expressions start at the closest NamingContainer or root
while (base.getParent() != null) {
if (base instanceof NamingContainer)

{ break; }

base = base.getParent();
}
initialBase = base;
}

// Evaluate the search expression (now guaranteed to be relative)
UIComponent result = null;
String[] segments = expr.split(SEPARATOR_STRING);
for (int i = 0, length = (segments.length - 1);
i < segments.length;
i++, length--) {
result = findComponent(base, segments[i], (i == 0));
// the first element of the expression may match base.id
// (vs. a child if of base)
if (i == 0 && result == null &&
segments[i].equals(base.getId()))

{ result = base; }

if (result Unable to render embedded object: File (= null && () not found.(result instanceof NamingContainer)) && length > 0)

{ throw new IllegalArgumentException(segments[i]); }

if (result == null)

{ break; }

base = result;
}

if( result == null && initialBase != null && initialBase.getParent() != null )

{ initialBase.getParent().findComponent(expr); }

[/code]



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

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

Comment by Ed Burns [ 13/Aug/14 ]

I'm concerned about the performance implications of your suggestion.





[JAVASERVERFACES_SPEC_PUBLIC-1297] Improvements over Facelet Functions Created: 02/Aug/14  Updated: 02/Aug/14

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

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


 Description   

There are some possible improvements that can be done about define facelet functions:

  • First of all, you need to register them in a .taglib.xml file. Example:

<function>
<function-name>formatMessage</function-name>
<function-class>net.myproject.view.util.JSFFunctions</function-class>
<function-signature>
java.lang.String formatMessage(java.lang.String, java.util.Locale, java.lang.String)
</function-signature>
</function>

Shouldn't be more simple to use annotations?

@FaceletLibrary(namespace="http://...")
public class MyLib {

@FaceletFunction
public static String joinWithSpaceDelim(String ...with) {

}

}

  • The function signature cannot receive optional parameters or arrays because internally facelets parse the method signature and only allow classes.

Other possible idea to consider is allow to define facelet functions in a similar way to the component/renderer pattern (facelet function component???). Example:

In the page:

#

{mylib:renderInformation('hello', 'world')}

@FaceletLibrary(namespace="http://...", renderKitId="RenderKitA")
CustomFaceletRendererA

@FaceletFunction
public String renderInformation(String a, String, b)

{ return "<p>"+a+" "+b+"</p>"; }

@FaceletLibrary(namespace="http://...", renderKitId="RenderKitA")
CustomFaceletRendererB

@FaceletFunction
public String renderInformation(String a, String, b)

{ return a+","+b; }

It is another way to define a "component". It is simpler and more limited, but easy to understand and very light.






[JAVASERVERFACES_SPEC_PUBLIC-1143] [jsr344] FaceletCache and FaceletFactory requires special methods to deal with composite components. Created: 13/Nov/12  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

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


 Description   

In JSF 2.1, FaceletCache API was added, defining 2 types of facelets:

  • Normal facelet: This is a facelet that was retrieved parsing files as usual. FaceletCache provide these methods:

public abstract V getFacelet(URL url) throws IOException;

public abstract boolean isFaceletCached(URL url);

  • View metadata facelet: This is a facelet that trim all content outside f:metadata. It is used to calculate the view metadata without build the whole view (GET requests). FaceletCache provide these methods:

public abstract V getViewMetadataFacelet(URL url) throws IOException;

public abstract boolean isViewMetadataFaceletCached(URL url);

But composite components requires also to calculate metadata. Right now in Mojarra, this step:

ViewDeclarationLanguage.getComponentMetadata(FacesContext context, Resource componentResource)

Is done using a norma facelet, but in MyFaces, since our implementation is bound to facelets template engine it is necessary an alternate facelet, to allow calculate the component metadata quickly, like with view metadata facelets.

This note was added in MyFaces implementation by myself about FaceletCacheImpl long time ago:

  • TODO: Note MyFaces core has another type of Facelet for read composite component
  • metadata. The reason behind do this in MyFaces is to retrieve some information
  • related to insertChildren/insertFacet that can be used as metadata and use that
  • information later to do the hack for composite components using templates, instead
  • rely on component relocation. This is not handled by FaceletCache included here
  • but in practice this should not be a problem, because the intention of this class
  • is handle Facelet instances created using custom ResourceResolver stuff, and
  • usually those pages are for views, not for composite components. Even if that is
  • true, composite component metadata Facelet is smaller (only add cc:xxx stuff) that
  • the other ones used for views or the one used to apply the composite component
  • itself.

The problem is with the introduction in JSF 2.2 of FaceletFactory, this flaw becomes more evident, because we also have special methods in FaceletFactory to deal with composite components:

public abstract class FaceletFactory

{ /** * Return a Facelet instance as specified by the file at the passed URI. The returned facelet is used * to create composite component metadata. * <p> * This method should be called from vdl.getComponentMetadata(FacesContext context) * </p> * * @since 2.0.1 * @param uri * @return * @throws IOException */ public abstract Facelet getCompositeComponentMetadataFacelet(String uri) throws IOException; /** * Create a Facelet used to create composite component metadata from the passed URL. This method checks if the * cached Facelet needs to be refreshed before returning. If so, uses the passed URL to build a new instance. * * @since 2.0.1 * @param url source url * @return Facelet instance * @throws IOException * @throws FaceletException * @throws FacesException * @throws ELException */ public abstract Facelet getCompositeComponentMetadataFacelet(URL url) throws IOException, FaceletException, FacesException, ELException; }

Since in JSF 2.2 the intention is expose FaceletFactory:

http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611

this implementation detail becomes relevant, because MyFaces needs to differentiate between a Facelet that creates composite component metadata and a normal facelet. It is more, there is no way to implement composite component spec using facelets template engine like MyFaces does without this detail.

The solution is add these methods to FaceletFactory:

public abstract Facelet getCompositeComponentMetadataFacelet(String uri) throws IOException;

public abstract Facelet getCompositeComponentMetadataFacelet(URL url)
throws IOException, FaceletException, FacesException, ELException;

and add these methods to FaceletCache:

public V getCompositeComponentMetadataFacelet(URL url) throws IOException;

public boolean isCompositeComponentMetadataFaceletCached(URL url);

protected FaceletCache.MemberFactory<V> getCompositeComponentMetadataMemberFactory()

and update the code properly. Without this change, implementations of FaceletFactory and FaceletCache will work only for Mojarra, and remember the idea of the spec is provide an API that can support different implementations. Really this is a big issue for us to be fixed in the spec before include FaceletFactory into the spec.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-1121] FaceletCache: some caching is incorrectly done in DefaultFaceletFactory Created: 12/Jul/12  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2 Sprint 13
Fix Version/s: None

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

Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-777 Define API to allow pluggable Facelet... Closed

 Description   

LU> I realized the FaceletCache API has a flaw.

LU> The original code from facelets 1.1.x has logic to cache the
LU> "conversion" between logical identifiers to find a specific facelet and
LU> its related URL.

LU> So inside DefaultFaceletFactory there is a map like this:

LU> private Map<String, URL> _relativeLocations;

LU> Checking the code deeper, I notice this cache store also the values
LU> returned by the ResourceResolver.

LU> Now suppose a scenario where you have a custom FaceletCache
LU> implementation, and by some coincidence there is some mechanism to load/
LU> unload some facelets in some way. Once a facelet is called,
LU> relativeLocations will hold the same key/value pair, so if a facelet is
LU> unloaded and then another one is loaded and it has the same association,
LU> it will fail to find the new one.

LU> A realistic scenario that will be part of JSF 2.2 spec is if you have
LU> a jar with some composite components and facelet files. For two
LU> different skins, there will be facelets with the same "logical
LU> identifiers", but with different URL. This issue prevents change the
LU> skins on the fly, because you can't clean that map.

LU> Who should hold that map? It should be hold by FaceletCache, not by
LU> FaceletFactory, because FaceletCache is the responsible to load/unload
LU> and hold facelets into memory.



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

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

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-906] cc:attribute method-signature should allow multiple definitions Created: 03/Nov/10  Updated: 12/Aug/14

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

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

Operating System: All
Platform: All


Attachments: Text File 906-cc-attribute-multiple-method-signature.patch    
Issuezilla Id: 906
Status Whiteboard:

size_medium importance_medium


 Description   

On JSF 2.0, cc:attribute method-signature only allows define one signature, but
there are examples on JSF that more that one method signature could be used for
a method. For example:

"action"

void method()
java.lang.Object method()

"actionListener"

void method()
void method(javax.faces.event.ActionEvent )

It could be useful to allow something like this

<cc:attribute
name="submitActionListener"
method-signature="void method();void method(javax.faces.event.ActionEvent )"/>

This is required to allow the new targetAttributeName to work as expected,
because in this case it is required to define method-signature property for
action, actionListener and valueChangeListener.



 Comments   
Comment by lu4242 [ 03/Nov/10 ]

Created an attachment (id=334)
Proposed patch solving this problem

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-902] ViewDeclarationLanguage selection enhancements Created: 29/Oct/10  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
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: All


Issuezilla Id: 902
Status Whiteboard:

size_large importance_medium


 Description   

Leonardo had suggested an elaborate XML syntax for VDL selection in http://lists.jboss.org/pipermail/jsr-
314-open-mirror/2010-October/000456.html. It's clear that we need something in this space, but not
clear what the best idea is.



 Comments   
Comment by Ed Burns [ 29/Oct/10 ]

target 2.2

Comment by Ed Burns [ 03/Nov/10 ]

There is some useful content on this issue at https://javaserverfaces.dev.java.net/issues/show_bug.cgi?
id=747

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-793] A comment different than <!-- -->, not sent to the HTML output, shall be allowed in JSF xhtml files. Created: 11/May/10  Updated: 01/Aug/14

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

Type: New Feature Priority: Minor
Reporter: grunt2000 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
depends on JAVASERVERFACES_SPEC_PUBLIC-697 more XML-centric model for Facelets Closed
Issuezilla Id: 793
Status Whiteboard:

size_medium importance_large

Tags: adf, adf_high

 Description   

Currently, any <!-- --> comment is sent to the HTML output, if this parameter is
not set in faces-config.xml:

<context-param>
<param-name>facelets.SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>

This is often done to avoid publishing comments that most of the time have for
audience the developers. However, if the choice is done to skip the comments,
all will be skipped, and you won't be able to send any public information you
would really like to see in comments, and more than that, special statements for
browser management (of the kind <!-- [IE7 ...] -->) won't reach the output.

Another way, if the facelets.SKIP_COMMENTS isn't used, is to surround each
internal comment with
<ui:remove><!-- My comment --></ui:remove>,
provided an initial declaration
xmlns:ui="http://java.sun.com/jsf/facelets"
is written at the beginning of the JSF xhtml file.

Whatever, choosing to edit the xml(s) files to add facelets.SKIP_COMMENTS or
surrounding internal comments with <ui:remove> +
xmlns:ui="http://java.sun.com/jsf/facelets", is clumsy.

Some kind of comment should be created
<%-- --%> or any other style, that would set an internal comment never published
in the HTML output.



 Comments   
Comment by grunt2000 [ 11/May/10 ]

(small mistake: the facelets.SKIP_COMMENTS context param is set in the web.xml
file, and not faces-config.xml).

Comment by Ed Burns [ 24/May/10 ]

Behavior change, move to 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by rogerk [ 21/Jun/10 ]

ownership

Comment by rogerk [ 28/Jun/10 ]

target 2.1_gf31_m4

Comment by Ed Burns [ 28/Jun/10 ]

Target Milestone 4

Comment by rogerk [ 10/Aug/10 ]

target

Comment by Ed Burns [ 11/Aug/10 ]

Also take a look at
<https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1768>.

Comment by rogerk [ 31/Aug/10 ]

starting

Comment by rogerk [ 31/Aug/10 ]

If you really need another comment that is not passed to output, I can introduce
a <ui:comment> tag that behaves the same as <ui:remove>. As you know, XML only
recognizes a distinguished set of characters and patterns (for example <%-- -->
would cause a SAX Parser Exception).

Comment by grunt2000 [ 01/Sep/10 ]

If a comment is added, it should not be a <ui:comment> one.

First, because in order to put a comment in an xhtml, the developer should not
have to add a:
xmlns:ui="http://java.sun.com/jsf/facelets" at the beginning of his files.

Implementing a pure comment in xhtml file must be a core feature of JSF, not
involving any tricks from the developer and being easy of use. <ui:comment> is
far too long to write.

Once JSP used <%! %> for hidden comments.
What about declaring something like: <' ... '> as an internal comment and
disallow JSF parsing its content?

Please, please, please... NOTHING beginning with <ui: !
Please no!

Comment by rogerk [ 01/Sep/10 ]

For most cases, a JSF 2.0 xhtml page will already require the
xmlns:ui="http://java.sun.com/jsf/facelets" declaration.
Again, to do what you ask for a smaller subset of JSF XHTML pages will require
some custom parsing at least to remove the special characters for the comment
before JSF (Facelets) parsing occurs - otherwise you will end up with SAX parse
exception. If you are worried about the length of <ui:comment> then perhaps a
shorter tag name.

Comment by rogerk [ 01/Sep/10 ]

Lower priority.

Comment by rogerk [ 02/Sep/10 ]

This may need more discussion if the reporter is not satisfied.
Will need to reevaluate for 2.2.

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Set priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-749] using JSF as template engine Created: 18/Feb/10  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2 Sprint 8
Fix Version/s: None

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

Operating System: All
Platform: All


Issue Links:
Duplicate
is duplicated by JAVASERVERFACES_SPEC_PUBLIC-477 Render a view programatically Closed
Issuezilla Id: 749
Status Whiteboard:

cat2 frame size_medium importance_large draft


 Description   

There is no easy way to get result from rendering of JSF page without going to
browser.
It would be very useful to have possibility directly initiate rendering of the
page and get corresponding result from it. Ability to use this approach will
allow developers easily adapt JSF as powerful template engine. In my case we
are using JSF as template engine to render HL7 messages. Also this functionality
would be helpful for testing purposes. For example "FacesTester" project
included some additional code just because there are a needs to get result of
rendering directly in java code.



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

cat2

Comment by vladperl [ 08/Mar/10 ]

It seems issue
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=477 is
relevant to this one.

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by rdelaplante [ 07/Jul/10 ]

Please consider providing the ability to sandbox the EL context. An example use
case is allowing users to edit email templates. I would want the users to be
able to access only the model objects my application provides to the template.
I do not want the user to gain full access everything in the application through EL.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 20/Dec/13 ]

This will probably be the top feature in JSF 2.3.

Comment by ova2 [ 21/Dec/13 ]

Wow, this would be a killer feature. We need it too for exporting a page to PDF. Currently we use PhantomJS (server-side browser) to call an JSF page to be exported via URL. By means of this new feature we could get an JSF page as a string and pass it direct to PhantomJS without the HTTP overhead.

Comment by tony.herstell [ 30/Apr/14 ]

Craig (see this site) is working on a JSF Mail plugin...
http://reallifejava.com/blog/

As well as Seamy stuff like
simpleBPM
simpleSecuirty

Think:
s/simeple/seam4/g

No promises though.

Comment by Ed Burns [ 01/May/14 ]

Tony, looks good. This is a very useful idea.

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-700] create javax.faces.Head and javax.faces.Body implicitly Created: 15/Dec/09  Updated: 12/Aug/14

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

Type: Improvement Priority: Minor
Reporter: mojavelinux 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: 700
Status Whiteboard:

size_medium importance_large


 Description   

If the page author does not specify <h:head> or <h:body> in the template, then
the VDL implementation should implicitly create the corresponding components and
place them into the tree where the <head> and <body> tags are found,
respectively. This allows the resource relocation feature (and other related
features) to be used without burdening the page author with remembering to add
<h:head> and <h:body>.

To have <head> and <body> be translated to <h:head> and <h:body> you just have
to provide a Facelets TagDecorator (about 15-25 loc) that will replace these two
tags at template compilation time, so the performance hit should be minimal.

The question remains, should that TagDecorator be part of an implementation (or
in case it is part of an implementation, should it be part of the compiler, as
then there is no need to have it in a Decorator).



 Comments   
Comment by mojavelinux [ 15/Dec/09 ]

Set milestone to 2.1

Comment by mojavelinux [ 16/Dec/09 ]

Please note that these components should only be created if <body> and <head>
are found. Obviously, these components may not (should not?) be needed inside of
a portlet.

Comment by Ed Burns [ 05/Jan/10 ]
      • Issue 702 has been marked as a duplicate of this issue. ***
Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 22/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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





[JAVASERVERFACES_SPEC_PUBLIC-695] Provide abbreviated xmlns value for composite components Created: 11/Dec/09  Updated: 01/Aug/14

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

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: 2 days
Time Spent: Not Specified
Original Estimate: 2 days
Environment:

Operating System: All
Platform: Sun


Issuezilla Id: 695
Status Whiteboard:

size_small importance_large


 Description   

Currently you have to say

xmlns:ez="http://java.sun.com/jsf/composite/ezcomp"

to declare that every XHTML file in resources/ezcomp should be treated as a
composite component.

In addition to this, you can now say

xmlns:ez="jsf/cc/ezcomp"

to get the same effect.



 Comments   
Comment by driscoll [ 12/Dec/09 ]

Per Dan Allen:

Heck, while we are here, why don't we just do:
>
> xmlns:f="jsf:core"
> xmlns:h="jsf:html"
> xmlns:ui="jsf:ui"
>

Comment by mojavelinux [ 18/Dec/09 ]

Update target milestone to 2.1. Change subcomponent to Facelets/VDL

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 ]

Move these to 2.2

Comment by tedgoddard [ 21/Feb/12 ]

Based on the implementation in com/sun/faces/facelets/tag/jsf/CompositeComponentTagLibrary.java, approximately 6 lines of code per namespace are required (and this is for the more complex case of the dynamic xmlns for composite components). The simplified namespaces do not look controversial, provided the old namespaces are still allowed thereby ensuring backwards compatibility.

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-249] Facets should accept arbitrary attributes... Created: 19/Mar/07  Updated: 01/Aug/14

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

Type: Improvement Priority: Minor
Reporter: dmlloyd 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: 249
Status Whiteboard:

cat2 frame size_medium importance_medium


 Description   

...or at least, components should be able to specify what attributes can be
handled by a facet. This is easily done using xsd, but not so easily done via tld.

However it would greatly simplify the attribute list of "containing" components
like UIData, which currently have to have attributes such as "headerClass" and
so on, and yet still don't cover all the attributes that a user may want to
specify to apply to the facet.

So instead of:
<h:dataTable headerClass="foo">
<f:facet name="header">...</f:facet>
</h:dataTable>

The user could specify:

<h:dataTable>
<f:facet name="header" styleClass="foo">...</f:facet>
</h:dataTable>



 Comments   
Comment by dmlloyd [ 19/Mar/07 ]

Change target to 2.0

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

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 Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-569] Listener Call order undefined Created: 09/Jun/09  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
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: 569
Status Whiteboard:

cat1 frame size_small importance_large


 Description   

The call order of listeners is apparently undefined, and the default behavior of
the RI is not the desirable one.

Consider a component with a listener attached to it, as well as two
setPropertyActionListeners.

<h:commandButton id="button2" value="<<"
actionListener="#

{switchlist.move2to1}

">
<f:setPropertyActionListener value="#

{listholder1}

"
target="#

{switchlistController.listHolder1}

"/>
<f:setPropertyActionListener value="#

{listholder2}

"
target="#

{switchlistController.listHolder2}

"/>
</h:commandButton>

What order will they be called?

First move2to1 will be called, then setListHolder1, then setListHolder2.

Which order should they be called?

Probably setListholder1, setListholder2, then move2to1. After all, it really
doesn't make sense to set properties after the main component's listener is
called.



 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 [ 24/Feb/10 ]

Agree.

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 15/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are valid 2.0 Rev a issues

Comment by Ed Burns [ 18/May/10 ]

I remember this issue. I'll take ownership. Set as P2.

Comment by Ed Burns [ 24/May/10 ]

take ownership.

Comment by rogerk [ 24/May/10 ]

ownership

Comment by rogerk [ 09/Jun/10 ]

Impl change - targeting for 2.1

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by rogerk [ 29/Jun/10 ]

target

Comment by rogerk [ 27/Aug/10 ]

For now - move to 2.2 (lack of time).
May revisit for 2.1 if time permits.

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





[JAVASERVERFACES_SPEC_PUBLIC-542] autocomplete attribute missing on form, input and select* components Created: 11/Apr/09  Updated: 04/Aug/14

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

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

Operating System: Linux
Platform: PC
URL: http://ocpsoft.com


Issue Links:
Dependency
depends on JAVASERVERFACES_SPEC_PUBLIC-638 Ajax Back Button Support Open
Issuezilla Id: 542
Status Whiteboard:

cat2 vdldoc size_small importance_medium


 Description   

It does work on h:inputText, but is not available on select** menus and etc. The
pdldocs do not list this attribute for:

inputTextArea
selectBooleanCheckbox
selectManyCheckbox
selectManyListbox
selectManyMenu
selectOneListbox
selectOneMenu
selectOneRadio

According to the W3C spec, these should all accept the autocomplete attribute:
http://www.w3.org/Submission/web-forms2/#the-autocomplete

Not only <input> allows the autocomplete property.
We should have that on the form as well:

See here for details:
http://msdn.microsoft.com/en-us/library/ms533486(VS.85).aspx

This is broken in JSF 1.1, JSF 1.2 and 2.0 EDR



 Comments   
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 Jason Lee [ 26/Jan/10 ]

Updating target milestone for 2.0 rev A. If you disagree, now's the time to speak
up!

Comment by Ed Burns [ 04/Mar/10 ]

cat1

Comment by Ed Burns [ 15/Mar/10 ]

cat2

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

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 ]

Elevate priority.





[JAVASERVERFACES_SPEC_PUBLIC-529] cannot set "title" attribute for "option" elements in a select (f:selectItem) Created: 25/Feb/09  Updated: 01/Aug/14

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

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

Operating System: All
Platform: All
URL: http://forums.java.net/jive/thread.jspa?messageID=330282


Issuezilla Id: 529
Status Whiteboard:

cat2 vdldocs size_small importance_small


 Description   

There's no way to set the title attribute of an HTML option element with the
f:selectItem tag.
The title attribute of an option element is valid HTML and is interpreted by
most browsers as a tooltip.



 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 Jason Lee [ 26/Jan/10 ]

Updating target milestone for 2.0 rev A. If you disagree, now's the time to speak
up!

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

vdldocs

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by Ed Burns [ 08/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage rkit docs

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-507] Facelets should skip comments by default Created: 16/Nov/08  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
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


Issuezilla Id: 507
Status Whiteboard:

cat2 frame size_small importance_large


 Description   

Facelets should skip comments by default, without having to ask in the context
params:

<context-param>
<param-name>facelets.SKIP_COMMENTS</param-name>
<param-value>true</param-value>
</context-param>

Right now, it doesn't, which means outputting comments to end users, and doing
EL substitution inside comments, both of which are not desired in the common case.

This request is also seen in the wild:

http://techdetails.blogmatrix.com/:entry:techdetails-2007-06-13-0000/



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

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by lincolnbaxter [ 26/Jan/10 ]

Categorized as part of Rev 2.0 A prep

Comment by rogerk [ 05/Mar/10 ]

cat2 - may require spec change (to specify this default)

Comment by Ed Burns [ 22/Mar/10 ]

frame

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 24/Jun/10 ]

Move these to M5

Comment by Ed Burns [ 30/Aug/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-501] Must be able to determine the ID of a composite component via EL Created: 06/Nov/08  Updated: 01/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.0
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: 501
Status Whiteboard:

cat2 frame size_medium importance_large draft


 Description   

It is a requirement for Ajax apps that they be able to determine the ID of the
enclosing composite component via EL.

This is probably be fixed when we incorporate the new EL method parameter
extensions.



 Comments   
Comment by driscoll [ 06/Nov/08 ]

Changed version to 2.0.

Changed priority to P2 - this is a pretty serious defect, though there is a
workaround possible by including a dummy panelgroup and doing a parse on the
resulting id.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by lincolnbaxter [ 26/Jan/10 ]

Categorized as part of Rev 2.0 A prep

This may already be partially implemented with the facelets ezcomp custom
component clientId expression: #

{cc.clientId}
Comment by rogerk [ 05/Mar/10 ]

cat1 - investigate

Comment by Ed Burns [ 15/Mar/10 ]

frame

Comment by Ed Burns [ 15/Mar/10 ]

2.0 rev a

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by Ed Burns [ 01/Aug/14 ]

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

Comment by Manfred Riem [ 01/Aug/14 ]

Setting priority to Minor





[JAVASERVERFACES_SPEC_PUBLIC-483] Create a decoration component based on ui:decorate that can be used for creating templated forms Created: 02/Oct/08  Updated: 01/Aug/14

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

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

Operating System: All
Platform: All


Issuezilla Id: 483
Status Whiteboard:

cat2 frame vdldoc size_medium importance_large draft


 Description   

Based on ui:decorate, s:decorate takes things a step further and exposes some
extra info via EL.

It nests a single EditableValueHolder and exposes via EL:

  • whether the field is required
  • whether any faces messages are enqueued at ERROR level for that EVH

additional info that we should consider exposing:

  • a List of the enqueued faces messages so the user can iterate over them and
    render them as they like


 Comments   
Comment by pmuir [ 02/Oct/08 ]

The h:message and h:label components should be enhanced to support the use of
this widget. If either of these components are nested inside a CRUD decorater, a
depth first search, starting at this component should be used to find the
component to attach to.

The component should first search up the tree for the CRUD decorator component.
The CRUD decorator component is then queried for it's nested input component.
The nested input component should be located using a depth first search:

protected static UIComponent getEditableValueHolder(UIComponent component) {
if (component instanceof EditableValueHolder)

{ return component.isRendered() ? component : null; }

for (Object child: component.getChildren()) {
if (child instanceof UIComponent)

{ UIComponent evh = getEditableValueHolder( (UIComponent) child ); if (evh!=null) return evh; }

}
return null;
}

If a null value is returned, the input component cannot be located, and an
exception should be thrown.

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by lincolnbaxter [ 26/Jan/10 ]

Categorized as part of Rev 2.0 A prep

Comment by rogerk [ 05/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

frame vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

GlassFish 3.1 M6 at the latest.

Comment by Ed Burns [ 10/Sep/10 ]

Move these to 2.2

Comment by balunasj [ 20/Apr/11 ]

[Comment from Dan Allen]
My feeling is that what we have in JSF 2 is more powerful than UIDecorate. However, that doesn't mean that we can't still take it further.

What we should be looking at is providing some sort of base class (or perhaps something simpler) to effectively do what we have in Seam Faces with the UIInputContainer [1]

The reason it's more flexible is because it can be extended. UIDecorate was really a closed set of functionality focused exclusively on form fields. It wasn't a general purpose decorator.

-Dan

[1] http://docs.jboss.org/seam/3/faces/reference/snapshot/en-US/html/components.html#UIInputContainer

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-264] f:param should respect the "rendered" attribute Created: 05/Jun/07  Updated: 04/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: 2.2 Sprint 8
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: dmlloyd 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: 264
Status Whiteboard:

cat2 vdldocs size_small importance_small


 Description   

When using <f:param> within <h:outputLink>, the "rendered" attribute of
<f:param> should be respected so that certain query parameters can be optionally
rendered.

<f:param> is implemented using the UIParam component, which has a "rendered"
property that is currently unused.

To implement this change, all that is needed is to modify the OutputLinkRenderer.



 Comments   
Comment by dmlloyd [ 05/Jun/07 ]

Target milestone = 2.0

Comment by Ed Burns [ 24/Sep/09 ]

Move to unscheduled target milestone

Comment by Ed Burns [ 24/Nov/09 ]

Prepare to delete "spec" subcomponent.

Comment by Ed Burns [ 04/Mar/10 ]

cat2

Comment by Ed Burns [ 22/Mar/10 ]

vdldoc

Comment by Ed Burns [ 15/May/10 ]

These are targeted at 2.1.

Comment by rogerk [ 17/Jun/10 ]

triage

Comment by Ed Burns [ 22/Jun/10 ]

edburns

Comment by Ed Burns [ 24/Jun/10 ]

Change target milestone.

Comment by rogerk [ 27/Oct/10 ]

triage potential rkit doc change

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 ]

Seems like an oversight that f:param does not do this already.





[JAVASERVERFACES_SPEC_PUBLIC-1196] CC-like conveniences for Facelet tags Created: 02/Jun/13  Updated: 13/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

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

Tags: ease-of-use, ease_of_development, facelets, tag, taglib

 Description   

In JSF 2.x there are composite components and Facelets tags. A prime difference between these two is that composite components become a component themselves in the component tree, while Facelets tags cause their "child" components to be inserted but they themselves do not become part of the tree.

Both these two artifacts have their own unique use cases, and thus the newer composite component cannot totally replace the older Facelet tags.

However, composite components being the more modern variant have several ease of use features such as the ability for being auto-registering when put into the /resources folder and the definition of its attributes directly into the defining .xhtml file.

Since Facelets tags are still very useful in modern JSF programming, I'd like to request them being upgraded to support auto-registering and attribute definition in the .xhtml file as well.

E.g.

/resources/mytag.xhtml
<ui:composition xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets">
    
    <ui:attribute name="foo" />
    
    ...
</ui:composition>

The above would register a Facelets tag just like the following in a -taglib.xml would do:

<tag>
    <tag-name>mytag</tag-name>
    <source>tags/mytag.xhtml</source>
    <attribute>
        <name>foo</name>	
    </attribute>
</tag>


 Comments   
Comment by Ed Burns [ 10/Jun/13 ]

This is a nice idea.

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-916] Support for generic types in Composite Component's attribute @type and @method-signature Created: 09/Dec/10  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

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

Status Whiteboard:

size_large importance_medium

Tags: 3_1-exclude

 Description   

Currently there is no way to infer type of cc:attribute's type, since you can only use fully qualified name of class like:

<composite:interface>
<composite:attribute name="value" type="java.util.List"/>
</composite:interface>

This is not sufficient for tools to implement features like validation and code completion of EL expressions inside <cc:implementation>

Allow definition of generic types in @type and @method-signature to improve composite component's usability:

<composite:interface>
<composite:attribute name="value" type="java.util.List<my.package.Person>"/>
</composite:interface>



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

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





[JAVASERVERFACES_SPEC_PUBLIC-956] Support rendering of client behaviors inside simple composite components Created: 01/Apr/11  Updated: 12/Aug/14

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

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

Status Whiteboard:

size_medium importance_medium


 Description   

It is already possible to attach behaviors to composite components that are retargeted to via <cc:clientBehavior> but is not possible to attach a behavior directly to a composite component, with no target).

UINamingContainer should implement ClientBehaviorHolder and support decoding of behaviors. It should be possible to configure the supported events using the <cc:clientBehavior> with no "name" attribute or maybe with the special keyword "@this" in the "targets" attribute.

The script of a behavior could be made available in the composite component implementation for example via an EL expression.

Example usage:

<cc:interface>
<cc:clientBehavior event="focus" />
</cc:interface>
<cc:implementation>
<fieldset onfocus="#

{cc.behaviorScript['focus']}

">
...



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

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





[JAVASERVERFACES_SPEC_PUBLIC-1008] Add ability for define tag to append to an existing definition Created: 22/May/11  Updated: 12/Aug/14

Status: Open
Project: javaserverfaces-spec-public
Component/s: Facelets/VDL
Affects Version/s: None
Fix Version/s: None

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


 Description   

In Facelets one can use a ui:define tag to define content in a template client. This named content can be inserted into a template by using ui:insert.

When the template client that defines the content is itself a template, its template client may also want to contribute to this content, typically by appending to it. This is currently not possible. The template needs to use a new ui:insert tag with a new name.

E.g.

template.xml

<f:view>            
    <ui:insert name="links"/>        
</f:view>

general.xml

<ui:composition template="template.xhtml">     
   <ui:define name="links">
         <h:link ... />
         <ui:insert name="links1"/>    
   </ui:define>        
 </ui:composition>

orders.xml

<ui:composition template="general.xhtml">     
   <ui:define name="links1">
      <h:link ... />
      <ui:insert name="links2"/>     
   </ui:define>        
 </ui:composition>

etc

Instead of manually 'chaining' defines and inserts in this way, Facelets could define tags or attributes for contributing to existing definitions. E.g.:

general.xml

<ui:composition template="template.xhtml">     
   <ui:append name="links">
      <h:link ... />    
   </ui:append>        
 </ui:composition>

orders.xml

<ui:composition template="general.xhtml">     
   <ui:append name="links">
      <h:link ... />    
   </ui:append>        
 </ui:composition>

Instead of introducing a new ui:append tag, a contribute="append" on ui:define could be used instead. Next to appending, prepending could be considered via a ui:contribute tag or contribute="prepend" attribute.



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

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





Generated at Tue Jul 07 20:00:32 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.