From michelle92@example.org Thu Nov 01 06:32:14 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 81656 invoked from network); 1 Nov 2007 06:32:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 06:32:14 -0000 Received: (qmail 77625 invoked by uid 500); 1 Nov 2007 06:32:01 -0000 Delivered-To: michelle92@example.org Received: (qmail 77591 invoked by uid 500); 1 Nov 2007 06:32:01 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 77578 invoked by uid 99); 1 Nov 2007 06:32:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Oct 2007 23:32:01 -0700 X-ASF-Spam-Status: No, hits=-98.0 required=10.0 tests=ALL_TRUSTED,URIBL_BLACK X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 06:32:11 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id 5223B71422B for <michelle92@example.org>; Wed, 31 Oct 2007 23:31:51 -0700 (PDT) Message-ID: <17057553.1193898711334.JavaMail.jira@brutus> Date: Wed, 31 Oct 2007 23:31:51 -0700 (PDT) From: "Leonardo Uribe (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Updated: (MYFACES-1741) JSR-252 Issue 21 - Provided an additional "binding" attribute for the core Converter, Listener and Validator tags has wrong behaviour In-Reply-To: <11936202.1191793310656.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/MYFACES-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-1741: ------------------------------------ Status: Patch Available (was: Open) > JSR-252 Issue 21 - Provided an additional "binding" attribute for the core Converter, Listener and Validator tags has wrong behaviour > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: MYFACES-1741 > URL: https://issues.apache.org/jira/browse/MYFACES-1741 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 > Affects Versions: 1.2.0 > Environment: Tomcat 6.0.14, Myfaces 1.2.1-SNAPSHOT (Oct 7 2007) > Reporter: Leonardo Uribe > Fix For: 1.2.1-SNAPSHOT > > Attachments: patchBindingCLVV.patch > > > There is a problem with the behaviour of binding attribute from actionListeners, validators and converters. > I have this test. The objective is explore how binding attribute is doing things comparing jsf ri 1.2 and > myfaces 1.2.1-SNAPSHOT, trying to detect bugs on myfaces :) > bindingCLV.jsp > <%@ page session="false" contentType="text/html;charset=utf-8"%> > <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> > <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> > <html> > <f:view beforePhase="#{bindingCLVBean.beforePhase}" > afterPhase="#{bindingCLVBean.afterPhase}"> > <%@include file="inc/head.inc"%> > <body> > <f:loadBundle > basename="org.apache.myfaces.examples.resource.example_messages" > var="example_messages" /> > <h1>Myfaces Examples JSF 1.2 Additions</h1> > <h:messages></h:messages> > <h:form id="form"> > <h:panelGrid id="grid" columns="3"> > <h:outputLabel value="BigInt" for="bigint"></h:outputLabel> > <h:inputText id="bigint" binding="#{bindingCLVBean.input1}" value="#{bindingCLVBean.bigint}"> > <f:converter converterId="javax.faces.BigInteger" binding="#{bindingCLVBean.converterBigint}"/> > <f:validator validatorId="org.apache.myfaces.bindingCLV.DummyValidator" > binding="#{bindingCLVBean.validatorBigint}"/> > </h:inputText> > <h:message for="bigint"></h:message> > <h:outputLabel value="BigDecimal" for="bigdecimal"></h:outputLabel> > <h:inputText id="bigdecimal" binding="#{bindingCLVBean.input2}" value="#{bindingCLVBean.bigdecimal}"> > <f:converter converterId="javax.faces.BigDecimal" binding="#{bindingCLVBean.converterBigdecimal}"/> > <f:validator validatorId="org.apache.myfaces.bindingCLV.DummyValidator" > binding="#{bindingCLVBean.validatorBigdecimal}"/> > </h:inputText> > <h:message for="bigdecimal"></h:message> > </h:panelGrid> > <h:commandButton id="button1" value="press me" action="#{bindingCLVBean.update}" > > <f:actionListener type="org.apache.myfaces.bindingCLV.DummyActionListener" > binding="#{bindingCLVBean.listener}" /> > </h:commandButton> > </h:form> > </body> > </f:view> > </html> > Bean: > package org.apache.myfaces.bindingCLV; > import java.math.BigDecimal; > import java.math.BigInteger; > import javax.faces.application.FacesMessage; > import javax.faces.component.html.HtmlInputText; > import javax.faces.context.FacesContext; > import javax.faces.convert.Converter; > import javax.faces.event.ActionListener; > import javax.faces.event.PhaseEvent; > import javax.faces.validator.Validator; > import org.apache.commons.logging.Log; > import org.apache.commons.logging.LogFactory; > public class BindingCLVBean { > private BigInteger bigint; > > private BigDecimal bigdecimal; > > private Converter converterBigint; > > private Converter converterBigdecimal; > > private Validator validatorBigint; > > private Validator validatorBigdecimal; > > private HtmlInputText input1; > > private HtmlInputText input2; > > private ActionListener listener; > > Log log = LogFactory.getLog(BindingCLVBean.class); > > public void beforePhase(PhaseEvent phaseEvent){ > FacesContext facesContext = FacesContext.getCurrentInstance(); > > facesContext.addMessage(null, new FacesMessage("This is the message for phase before "+phaseEvent.getPhaseId().toString())); > facesContext.addMessage(null, new FacesMessage("Component:"+this.getInput1())); > facesContext.addMessage(null, new FacesMessage("Validator:"+this.getValidatorBigdecimal())); > facesContext.addMessage(null, new FacesMessage("Converter:"+this.getConverterBigdecimal())); > facesContext.addMessage(null, new FacesMessage("ActionListener:"+this.getListener())); > log.info("This is the message for phase before "+phaseEvent.getPhaseId().toString()+" : "); > } > > public void afterPhase(PhaseEvent phaseEvent){ > FacesContext facesContext = FacesContext.getCurrentInstance(); > > facesContext.addMessage(null, new FacesMessage("This is the message for phase after "+phaseEvent.getPhaseId().toString())); > facesContext.addMessage(null, new FacesMessage("Component:"+this.getInput1())); > facesContext.addMessage(null, new FacesMessage("Validator:"+this.getValidatorBigdecimal())); > facesContext.addMessage(null, new FacesMessage("Converter:"+this.getConverterBigdecimal())); > facesContext.addMessage(null, new FacesMessage("ActionListener:"+this.getListener())); > log.info("This is the message for phase after "+phaseEvent.getPhaseId().toString()+" : "); > } > > public BigInteger getBigint() { > return bigint; > } > public void setBigint(BigInteger bigint) { > this.bigint = bigint; > } > public BigDecimal getBigdecimal() { > return bigdecimal; > } > public void setBigdecimal(BigDecimal bigdecimal) { > this.bigdecimal = bigdecimal; > } > public Converter getConverterBigint() { > return converterBigint; > } > public void setConverterBigint(Converter converterBigint) { > this.converterBigint = converterBigint; > } > public Converter getConverterBigdecimal() { > return converterBigdecimal; > } > public void setConverterBigdecimal(Converter converterBigdecimal) { > this.converterBigdecimal = converterBigdecimal; > } > public Validator getValidatorBigint() { > return validatorBigint; > } > public void setValidatorBigint(Validator validatorBigint) { > this.validatorBigint = validatorBigint; > } > public Validator getValidatorBigdecimal() { > return validatorBigdecimal; > } > public void setValidatorBigdecimal(Validator validatorBigdecimal) { > this.validatorBigdecimal = validatorBigdecimal; > } > > public String update(){ > FacesContext context = FacesContext.getCurrentInstance(); > return "update"; > } > public HtmlInputText getInput1() { > return input1; > } > public void setInput1(HtmlInputText input1) { > this.input1 = input1; > } > public HtmlInputText getInput2() { > return input2; > } > public void setInput2(HtmlInputText input2) { > this.input2 = input2; > } > public ActionListener getListener() { > return listener; > } > public void setListener(ActionListener listener) { > this.listener = listener; > } > } > When you call the page the first time, this is the output for <h:messages> tag : > JSF RI: > * This is the message for phase before RENDER_RESPONSE 6 > * Component:javax.faces.component.html.HtmlInputText@164de59 > * Validator:null > * Converter:null > * ActionListener:null > Myfaces: > * This is the message for phase before RENDER_RESPONSE(6) > * Component:javax.faces.component.html.HtmlInputText@18c5e67 > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@89c116 > * Converter:javax.faces.convert.BigDecimalConverter@1e3bbd7 > * ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@4133b0 > QUESTION 1: Why do I create an object that I do not use?. Myfaces is wrong, and JSF RI has the correct behaviour. > The first time that I load a page, it's unnecesary to create those objects. > And when you press the button or submit the form: > JSF RI: > * This is the message for phase before APPLY_REQUEST_VALUES 2 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after APPLY_REQUEST_VALUES 2 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before PROCESS_VALIDATIONS 3 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after PROCESS_VALIDATIONS 3 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:null > * This is the message for phase before UPDATE_MODEL_VALUES 4 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:null > * This is the message for phase after UPDATE_MODEL_VALUES 4 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:null > * This is the message for phase before INVOKE_APPLICATION 5 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:null > * This is the message for phase after INVOKE_APPLICATION 5 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@391da0 > * This is the message for phase before RENDER_RESPONSE 6 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@391da0 > Myfaces: > * This is the message for phase before APPLY_REQUEST_VALUES(2) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after APPLY_REQUEST_VALUES(2) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before PROCESS_VALIDATIONS(3) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after PROCESS_VALIDATIONS(3) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before UPDATE_MODEL_VALUES(4) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after UPDATE_MODEL_VALUES(4) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before INVOKE_APPLICATION(5) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after INVOKE_APPLICATION(5) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before RENDER_RESPONSE(6) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@1c958af > * Converter:javax.faces.convert.BigDecimalConverter@1dd7736 > * ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@bd93cd > QUESTION 2: Why I not have bindings assigned before INVOKE_APPLICATION ?(in this time is of value have a binding attribute) . > Again JSF RI has the correct behaviour and Myfaces is wrong. Myfaces create the validators, converters and > actionListeners on correct time, but not assign bindings when is supposed to do. If I assign a binding for > converter, validator or actionListener, I should be assigned minimum before INVOKE_APPLICATION, or better, > converters and validators on PROCESS_VALIDATIONS, and actionListeners in INVOKE_APPLICATION. > Looks a little bit difficult but I will try to find a solution for this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 06:32:18 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 81748 invoked from network); 1 Nov 2007 06:32:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 06:32:18 -0000 Received: (qmail 78344 invoked by uid 500); 1 Nov 2007 06:32:05 -0000 Delivered-To: michelle92@example.org Received: (qmail 78081 invoked by uid 500); 1 Nov 2007 06:32:04 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 78070 invoked by uid 99); 1 Nov 2007 06:32:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Oct 2007 23:32:04 -0700 X-ASF-Spam-Status: No, hits=-98.0 required=10.0 tests=ALL_TRUSTED,URIBL_BLACK X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 06:32:29 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id B85A571418F for <michelle92@example.org>; Wed, 31 Oct 2007 23:31:50 -0700 (PDT) Message-ID: <12781642.1193898710745.JavaMail.jira@brutus> Date: Wed, 31 Oct 2007 23:31:50 -0700 (PDT) From: "Leonardo Uribe (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Commented: (MYFACES-1741) JSR-252 Issue 21 - Provided an additional "binding" attribute for the core Converter, Listener and Validator tags has wrong behaviour In-Reply-To: <11936202.1191793310656.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/MYFACES-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539290 ] Leonardo Uribe commented on MYFACES-1741: ----------------------------------------- After asking some questions on jsf ri dev mailing list, I finally understand the reasons about why create a delegator for actionListener, converter, validator and valueChangeListener. The actual behaviour in simple words is this. when you have a code like this: <f:actionListener binding="#{mybean}"/> <f:converter binding="#{mybean}"/> <f:validator binding="#{mybean}"/> <f:valueChangeListener binding="#{mybean}"/> or <f:actionListener type="#{'anyid'}" binding="#{mybean}"/> <f:converter converterId="#{'anyid'}" binding="#{mybean}"/> <f:validator validatorId="#{'anyid'}" binding="#{mybean}"/> <f:valueChangeListener type="#{'anyid'}" binding="#{mybean}"/> jsf ri 1.2_05 create a class that acts like a delegator to avoid create an instance of mybean instead of get the reference of the bean (through a lazy loading). If you have a component that define the type, converterId or validatorId as a simple String without EL, the behaviour is like the spec says (what myfaces does right now). The value of binding variable is irrelevant at each phase. It's just a way to custom create of components, so it's not necessary to define it previous INVOKE_APPLICATION phase. With this information, I have created a solution that is equivalent to jsf ri behaviour. In the patch there are this modifications: 1. Create proper classes that acts as delegate pattern, and implements StateHolder called: org.apache.myfaces.taglib.core.DelegateActionListener org.apache.myfaces.taglib.core.DelegateConverter org.apache.myfaces.taglib.core.DelegateValidator org.apache.myfaces.taglib.core.DelegateValueChangeListener 2. Create two classes called org.apache.myfaces.taglib.core.ConvertImplTag org.apache.myfaces.taglib.core.ValidatorImplTag There are other children classes from ConverterTag and ValidatorTag that does not implement this behaviour, so make a modification on it is wrong. It's better to create classes that implement this specific behaviour to this components. 3. Modify GenericListenerTag, ActionListenerTag and ValueChangeListenerTag to implement this behaviour. The issue on javaserverfaces issue tracker (explaining the reason why they do the changes) is #471 There whas a issue that change the behaviour form jsf ri 1.2_04-p02 to 1.2_05 is #631, to remain jsf ri compatible with trinidad converters: " ...... If 'converterId' attribute isn't an expression we should return the converter instead of the BindingConverter. ......" In a conversation with Ryan Lubke: ".... The change that was introduced was this: If id is specified and is a literal, then the converter will never change, so assign the actual converter instance instead of the binding instance. This was needed to support certain functionality provided by trinidad. ..." "... As it stands in the RI now, we're trying to accomodate what the spec says (i.e. literal id means actual instance instead of delegate) and improving upon the spec in how binding *should* have been spec'd out. Since the Trinidad component set relies on the current spec behavior, I think this hybrid solution is the best that we can do until JSF 2.0 clarifies this situation. ..." > JSR-252 Issue 21 - Provided an additional "binding" attribute for the core Converter, Listener and Validator tags has wrong behaviour > ------------------------------------------------------------------------------------------------------------------------------------- > > Key: MYFACES-1741 > URL: https://issues.apache.org/jira/browse/MYFACES-1741 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 > Affects Versions: 1.2.0 > Environment: Tomcat 6.0.14, Myfaces 1.2.1-SNAPSHOT (Oct 7 2007) > Reporter: Leonardo Uribe > Fix For: 1.2.1-SNAPSHOT > > Attachments: patchBindingCLVV.patch > > > There is a problem with the behaviour of binding attribute from actionListeners, validators and converters. > I have this test. The objective is explore how binding attribute is doing things comparing jsf ri 1.2 and > myfaces 1.2.1-SNAPSHOT, trying to detect bugs on myfaces :) > bindingCLV.jsp > <%@ page session="false" contentType="text/html;charset=utf-8"%> > <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> > <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> > <html> > <f:view beforePhase="#{bindingCLVBean.beforePhase}" > afterPhase="#{bindingCLVBean.afterPhase}"> > <%@include file="inc/head.inc"%> > <body> > <f:loadBundle > basename="org.apache.myfaces.examples.resource.example_messages" > var="example_messages" /> > <h1>Myfaces Examples JSF 1.2 Additions</h1> > <h:messages></h:messages> > <h:form id="form"> > <h:panelGrid id="grid" columns="3"> > <h:outputLabel value="BigInt" for="bigint"></h:outputLabel> > <h:inputText id="bigint" binding="#{bindingCLVBean.input1}" value="#{bindingCLVBean.bigint}"> > <f:converter converterId="javax.faces.BigInteger" binding="#{bindingCLVBean.converterBigint}"/> > <f:validator validatorId="org.apache.myfaces.bindingCLV.DummyValidator" > binding="#{bindingCLVBean.validatorBigint}"/> > </h:inputText> > <h:message for="bigint"></h:message> > <h:outputLabel value="BigDecimal" for="bigdecimal"></h:outputLabel> > <h:inputText id="bigdecimal" binding="#{bindingCLVBean.input2}" value="#{bindingCLVBean.bigdecimal}"> > <f:converter converterId="javax.faces.BigDecimal" binding="#{bindingCLVBean.converterBigdecimal}"/> > <f:validator validatorId="org.apache.myfaces.bindingCLV.DummyValidator" > binding="#{bindingCLVBean.validatorBigdecimal}"/> > </h:inputText> > <h:message for="bigdecimal"></h:message> > </h:panelGrid> > <h:commandButton id="button1" value="press me" action="#{bindingCLVBean.update}" > > <f:actionListener type="org.apache.myfaces.bindingCLV.DummyActionListener" > binding="#{bindingCLVBean.listener}" /> > </h:commandButton> > </h:form> > </body> > </f:view> > </html> > Bean: > package org.apache.myfaces.bindingCLV; > import java.math.BigDecimal; > import java.math.BigInteger; > import javax.faces.application.FacesMessage; > import javax.faces.component.html.HtmlInputText; > import javax.faces.context.FacesContext; > import javax.faces.convert.Converter; > import javax.faces.event.ActionListener; > import javax.faces.event.PhaseEvent; > import javax.faces.validator.Validator; > import org.apache.commons.logging.Log; > import org.apache.commons.logging.LogFactory; > public class BindingCLVBean { > private BigInteger bigint; > > private BigDecimal bigdecimal; > > private Converter converterBigint; > > private Converter converterBigdecimal; > > private Validator validatorBigint; > > private Validator validatorBigdecimal; > > private HtmlInputText input1; > > private HtmlInputText input2; > > private ActionListener listener; > > Log log = LogFactory.getLog(BindingCLVBean.class); > > public void beforePhase(PhaseEvent phaseEvent){ > FacesContext facesContext = FacesContext.getCurrentInstance(); > > facesContext.addMessage(null, new FacesMessage("This is the message for phase before "+phaseEvent.getPhaseId().toString())); > facesContext.addMessage(null, new FacesMessage("Component:"+this.getInput1())); > facesContext.addMessage(null, new FacesMessage("Validator:"+this.getValidatorBigdecimal())); > facesContext.addMessage(null, new FacesMessage("Converter:"+this.getConverterBigdecimal())); > facesContext.addMessage(null, new FacesMessage("ActionListener:"+this.getListener())); > log.info("This is the message for phase before "+phaseEvent.getPhaseId().toString()+" : "); > } > > public void afterPhase(PhaseEvent phaseEvent){ > FacesContext facesContext = FacesContext.getCurrentInstance(); > > facesContext.addMessage(null, new FacesMessage("This is the message for phase after "+phaseEvent.getPhaseId().toString())); > facesContext.addMessage(null, new FacesMessage("Component:"+this.getInput1())); > facesContext.addMessage(null, new FacesMessage("Validator:"+this.getValidatorBigdecimal())); > facesContext.addMessage(null, new FacesMessage("Converter:"+this.getConverterBigdecimal())); > facesContext.addMessage(null, new FacesMessage("ActionListener:"+this.getListener())); > log.info("This is the message for phase after "+phaseEvent.getPhaseId().toString()+" : "); > } > > public BigInteger getBigint() { > return bigint; > } > public void setBigint(BigInteger bigint) { > this.bigint = bigint; > } > public BigDecimal getBigdecimal() { > return bigdecimal; > } > public void setBigdecimal(BigDecimal bigdecimal) { > this.bigdecimal = bigdecimal; > } > public Converter getConverterBigint() { > return converterBigint; > } > public void setConverterBigint(Converter converterBigint) { > this.converterBigint = converterBigint; > } > public Converter getConverterBigdecimal() { > return converterBigdecimal; > } > public void setConverterBigdecimal(Converter converterBigdecimal) { > this.converterBigdecimal = converterBigdecimal; > } > public Validator getValidatorBigint() { > return validatorBigint; > } > public void setValidatorBigint(Validator validatorBigint) { > this.validatorBigint = validatorBigint; > } > public Validator getValidatorBigdecimal() { > return validatorBigdecimal; > } > public void setValidatorBigdecimal(Validator validatorBigdecimal) { > this.validatorBigdecimal = validatorBigdecimal; > } > > public String update(){ > FacesContext context = FacesContext.getCurrentInstance(); > return "update"; > } > public HtmlInputText getInput1() { > return input1; > } > public void setInput1(HtmlInputText input1) { > this.input1 = input1; > } > public HtmlInputText getInput2() { > return input2; > } > public void setInput2(HtmlInputText input2) { > this.input2 = input2; > } > public ActionListener getListener() { > return listener; > } > public void setListener(ActionListener listener) { > this.listener = listener; > } > } > When you call the page the first time, this is the output for <h:messages> tag : > JSF RI: > * This is the message for phase before RENDER_RESPONSE 6 > * Component:javax.faces.component.html.HtmlInputText@164de59 > * Validator:null > * Converter:null > * ActionListener:null > Myfaces: > * This is the message for phase before RENDER_RESPONSE(6) > * Component:javax.faces.component.html.HtmlInputText@18c5e67 > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@89c116 > * Converter:javax.faces.convert.BigDecimalConverter@1e3bbd7 > * ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@4133b0 > QUESTION 1: Why do I create an object that I do not use?. Myfaces is wrong, and JSF RI has the correct behaviour. > The first time that I load a page, it's unnecesary to create those objects. > And when you press the button or submit the form: > JSF RI: > * This is the message for phase before APPLY_REQUEST_VALUES 2 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after APPLY_REQUEST_VALUES 2 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before PROCESS_VALIDATIONS 3 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after PROCESS_VALIDATIONS 3 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:null > * This is the message for phase before UPDATE_MODEL_VALUES 4 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:null > * This is the message for phase after UPDATE_MODEL_VALUES 4 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:null > * This is the message for phase before INVOKE_APPLICATION 5 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:null > * This is the message for phase after INVOKE_APPLICATION 5 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@391da0 > * This is the message for phase before RENDER_RESPONSE 6 > * Component:javax.faces.component.html.HtmlInputText@14aa2db > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@10df4e2 > * Converter:javax.faces.convert.BigDecimalConverter@1485542 > * ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@391da0 > Myfaces: > * This is the message for phase before APPLY_REQUEST_VALUES(2) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after APPLY_REQUEST_VALUES(2) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before PROCESS_VALIDATIONS(3) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after PROCESS_VALIDATIONS(3) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before UPDATE_MODEL_VALUES(4) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after UPDATE_MODEL_VALUES(4) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before INVOKE_APPLICATION(5) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase after INVOKE_APPLICATION(5) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:null > * Converter:null > * ActionListener:null > * This is the message for phase before RENDER_RESPONSE(6) > * Component:javax.faces.component.html.HtmlInputText@16752c9 > * Validator:org.apache.myfaces.bindingCLV.DummyValidator@1c958af > * Converter:javax.faces.convert.BigDecimalConverter@1dd7736 > * ActionListener:org.apache.myfaces.bindingCLV.DummyActionListener@bd93cd > QUESTION 2: Why I not have bindings assigned before INVOKE_APPLICATION ?(in this time is of value have a binding attribute) . > Again JSF RI has the correct behaviour and Myfaces is wrong. Myfaces create the validators, converters and > actionListeners on correct time, but not assign bindings when is supposed to do. If I assign a binding for > converter, validator or actionListener, I should be assigned minimum before INVOKE_APPLICATION, or better, > converters and validators on PROCESS_VALIDATIONS, and actionListeners in INVOKE_APPLICATION. > Looks a little bit difficult but I will try to find a solution for this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 06:58:20 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 86337 invoked from network); 1 Nov 2007 06:58:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 06:58:20 -0000 Received: (qmail 91350 invoked by uid 500); 1 Nov 2007 06:58:02 -0000 Delivered-To: michelle92@example.org Received: (qmail 91299 invoked by uid 500); 1 Nov 2007 06:58:02 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 91105 invoked by uid 99); 1 Nov 2007 06:58:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Oct 2007 23:58:02 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 06:58:28 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id 97C3671418F for <michelle92@example.org>; Wed, 31 Oct 2007 23:57:50 -0700 (PDT) Message-ID: <12213524.1193900270612.JavaMail.jira@brutus> Date: Wed, 31 Oct 2007 23:57:50 -0700 (PDT) From: "Leonardo Uribe (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Commented: (MYFACES-1729) label attribute does not resolve EL expresion (JSR 252 Issue 6 related) In-Reply-To: <7667046.1190080663735.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/MYFACES-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539295 ] Leonardo Uribe commented on MYFACES-1729: ----------------------------------------- Fortunately there was a discussion about this on javaserverfaces dev list that mention this trick the last week that helps me to understand what are they doing. I have looked at the RI, and they have this trick on MessageFactory: static Object getLabel(FacesContext context, UIComponent component) { Object o = component.getAttributes().get("label"); if (o == null || (o instanceof String && ((String) o).length() == 0)) { o = component.getValueExpression("label"); } // Use the "clientId" if there was no label specified. if (o == null) { o = component.getClientId(context); } return o; } As I supposed by deduction creating my solution, they return the ValueExpression of label for later evaluation. But In my solution I get the expression string instead the ValueExpression Object. At creating a message: static FacesMessage getMessage(Locale locale, String messageId, Object... params) { /*.......... */ // At this point, we have a summary and a bundle. FacesMessage ret = new BindingFacesMessage(locale, summary, detail, params); /*.......... */ } So, they have a custom FacesMessage that resolve bindings on demand. The implementation of getDetail shows this: public String getDetail() { String pattern = super.getDetail(); resolveBindings(); return getFormattedString(pattern, resolvedParameters); } My solution evaluate all the detail and summary String in one step, trying to minimize the changes, they save the array of params, the message string and resolve them later. It's a different solution to the same problem, but I think it's compatible with my solution. > label attribute does not resolve EL expresion (JSR 252 Issue 6 related) > ----------------------------------------------------------------------- > > Key: MYFACES-1729 > URL: https://issues.apache.org/jira/browse/MYFACES-1729 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-252 > Affects Versions: 1.2.1-SNAPSHOT > Environment: Tomcat 6, Windows XP > Reporter: Leonardo Uribe > Attachments: patchFinalSolution.patch > > > When validation is applied to the following page: > <%@ page session="false" contentType="text/html;charset=utf-8"%> > <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%> > <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%> > <html> > <f:view> > <%@include file="inc/head.inc"%> > <body> > <f:loadBundle basename="org.apache.myfaces.examples.resource.example_messages" var="example_messages"/> > <h1>Myfaces Examples JSF 1.2 Additions</h1> > <h:messages id="messageList" styleClass="error"/> > <h:form id="form1"> > <h:panelGrid columns="4"> > <h:outputLabel for="form1:number1" > value="#{example_messages['sample1_number']} 1 :" /> > <h:outputText value="#{validationController.number1ValidationLabel}" /> > <h:inputText label="#{example_messages['sample1_number']}" > id="number1" value="#{calcForm.number1}" maxlength="10" > size="25" required="true"> > <f:validateLongRange minimum="1" maximum="10" /> > </h:inputText> > <h:message id="number1Error" for="form1:number1" styleClass="error" /> > </h:panelGrid> > <h:panelGrid columns="4"> > <h:outputLabel for="form1:number2" > value="#{example_messages['sample1_form']} 2 :" /> > <h:outputText value="#{validationController.number2ValidationLabel}" /> > <h:inputText label="#{example_messages['sample1_form']}" > id="number2" value="#{calcForm.number2}" maxlength="10" > size="25" required="true"> > <f:validateLongRange minimum="20" maximum="50" /> > </h:inputText> > <h:message id="number2Error" for="form1:number2" styleClass="error" /> > </h:panelGrid> > <h:panelGrid columns="2"> > <h:outputLabel for="form1:result" > value="#{example_messages['sample1_result']} :" /> > <h:outputText id="result" value="#{calcForm.result}" /> > </h:panelGrid> > <h:panelGrid columns="4"> > <h:commandButton id="addButton" > value="#{example_messages['sample1_add']}" action="none"> > <f:actionListener > type="org.apache.myfaces.examples.example1.CalcActionListener"></f:actionListener> > </h:commandButton> > <h:commandButton id="subtractButton" > value="#{example_messages['sample1_sub']}" action="none"> > <f:actionListener > type="org.apache.myfaces.examples.example1.CalcActionListener"></f:actionListener> > </h:commandButton> > <h:commandLink id="href1" action="none"> > <h:outputText value="#{example_messages['sample1_add_link']}" /> > <f:actionListener > type="org.apache.myfaces.examples.example1.CalcActionListener"></f:actionListener> > </h:commandLink> > <h:commandLink id="href2" action="none"> > <h:outputText value="#{example_messages['sample1_sub_link']}" /> > <f:actionListener > type="org.apache.myfaces.examples.example1.CalcActionListener"></f:actionListener> > </h:commandLink> > </h:panelGrid> > </h:form> > </body> > </f:view> > </html> > If you use the attribute label on inputText like this: > <h:inputText label="#{example_messages['sample1_number']}" > id="number1" value="#{calcForm.number1}" maxlength="10" > size="25" required="true"> > <f:validateLongRange minimum="1" maximum="10" /> > </h:inputText> > and a validation error happens, the EL expression inside label attribute returns null. On a message box this looks like: > null: Validation Error: Specified attribute is not between the expected values of 20 and 50. > On JSF RI 1.2 this works correctly. null is replaced by the expression inside the bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 08:43:16 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 28333 invoked from network); 1 Nov 2007 08:43:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 08:43:16 -0000 Received: (qmail 70019 invoked by uid 500); 1 Nov 2007 08:43:03 -0000 Delivered-To: michelle92@example.org Received: (qmail 69969 invoked by uid 500); 1 Nov 2007 08:43:03 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 69958 invoked by uid 99); 1 Nov 2007 08:43:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 01:43:03 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of michelle92@example.org designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO wa-out-1112.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 08:43:03 +0000 Received: by wa-out-1112.google.com with SMTP id l24so535919waf for <michelle92@example.org>; Thu, 01 Nov 2007 01:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Qzj9mwBtT58KbCLoBqBLfcUCipZNFGswOmHumv8tsic=; b=ZhKM7C2F7g5dFvOb9nGaTcCgArCJRptXSQ2D+oOwvj24XF54PEW2B64s5R8/Fj9QlwvtEn/hj7ijvX443vPV3unXcmd65aYFZcA+kbhWDM+OYulBi4WGtzTdQ3GTTggOn3DkB8ZAvdNEOL6GpjqU1KmB6mdNBr6X16umHAFXFlk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=MerqoHGFqYPJsFP5Yo8OITGoooh7ahnwBfC5Tm7A4omQDIHA+QF3XYkLONhVNn9KE4o/SiN/cIxllIU2zNmaZkzC0BLAm2SCqBRVw0CP7yb/3AsLOxr/PHPYcUin+p+u3i6i5BWvLTny3Bnsneu8GPtX4De7WrgiKx1tNQa8ASI= Received: by 83.161.120.155 with SMTP id p2mr381476waa.1193906558980; Thu, 01 Nov 2007 01:42:38 -0700 (PDT) Received: by 83.161.120.155 with HTTP; Thu, 1 Nov 2007 01:42:38 -0700 (PDT) Message-ID: <michelle92@example.org> Date: Thu, 1 Nov 2007 09:42:38 +0100 From: "Volker Weber" <michelle92@example.org> Sender: michelle92@example.org To: "MyFaces Development" <michelle92@example.org> Subject: Re: [result][vote] start up the MyFaces Commons project In-Reply-To: <michelle92@example.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <michelle92@example.org> <michelle92@example.org> <michelle92@example.org> <michelle92@example.org> <michelle92@example.org> <michelle92@example.org> <michelle92@example.org> <michelle92@example.org> <michelle92@example.org> <michelle92@example.org> X-Google-Sender-Auth: f28af3af97df4fa2 X-Virus-Checked: Checked by ClamAV on apache.org Hi, see inline 2007/10/31, Manfred Geiler <michelle92@example.org>: > A taglib and a faces-config in the META-INF are loaded/registered > automatically. loading/register converters, validators, components, ... has no inluence to the application as long they are not used. Other things like ViewHandler, ... should not included in the faces-config as mario wrote. > And as I already mentioned, it should be possible to use the commons utils > from the core impl. Automatically loading extensions(!) is not what we want > when using the myfaces core implementation. We have already shared for this. When introducing the shared code there was a discussion about/against putting this into a own jar with dependency in impl. The result was against, because is should be possible to replace the two RI jars by just two myfaces jars. I don't like the repackaging of shared into impl and tomahawk, but i don't think this commons-utils should be a renamed shared? > There is some stuff in shared that makes sense to be moved to commons utils. > So this is not only theoretical. > > And don't forget about all those (renderkit-independent!) converters and > validators. People might argue for putting them into a jsfcommons components > artifact. What about the Joda converter that Matthias suggested? What is the > reason it should go into Trinidad? It is not renderkit-specific or somehow > related to Trinidad. So, a perfect candidate for jsfcommons-components, > right? Converters and Validators should go into the commons, as long there is nothing of the faces-config which makes influence to a running app just py putting this jar into classpath. > (There would even be place for a separate jsfcommons-converters artifacts, > IMHO) > > BTW, I do not understand why some of you are so scared by multiple > jsfcommons artifacts. > The Apache Commons Proper consists of 35 different "Components" and nobody > cares. Quite the contrary, everybody is glad there is not only one bloated > commons.jar when he/she needs just commons-logging or some of the DbUtils, > right? I'm not scared about multiple jsf-commons artifacts, i'ts perfectly ok for me to have a jsfcommons-validators, jsfcommons-converters, jsfcommons-components (if someone could describe what is going in here), and so on. I didn't know before that jsfcommons-utils was proposed as jsf-developer utils and i don't know why we need this as replacement for shared. Imho the myfaces-jsf-commons should contain classes and tools for application developers. I have no problem in making shared a own artifact, but i don't like the name commons-util for that. I also don't like having validators, converters and maybe other non components in a *-components artifact. Regards, Volker > > --Manfred > > > > On 10/31/07, Volker Weber < michelle92@example.org> wrote: > > What is the problem having a taglib in the jar? > > > > 2007/10/31, Manfred Geiler <michelle92@example.org>: > > > > > > > > > On 10/31/07, Mario Ivankovits <michelle92@example.org> wrote: > > > > Hi! > > > > > > > > > > > which is itself an "umbrella" project for two artifacts** > called > > > > > > "MyFaces JSF Commons Utils" and "MyFaces JSF Commons > Components" > > > > > > > > > > I suggest that I prepare an initial setup, and check it in, so that > > > > > there is some concrete stuff we can talk about. > > > > > Ok? > > > > I still don't get why we should increase the number of modules here. > > > > Two artifacts means two jars, no? > > > Yes, sure. > > > > > > > > > > And then, what is a Component? I think we agreed that we just want to > > > > add render-less components, no? Else it has to go into tomahawk. The > > > > Commons should not be just a "component-library without (the dreaded) > > > > shared". > > > > > > > > Is a UrlNavigationHandler a Component then or a util? It has no > > > > component yet, but what if it has one in the future? > > > > I know, we then can simply just add this component to the Components, > > > > but why should we split the stuff? > > > > > > > > In this case I'd have a > > > org.apache.myfaces.commons.urlNavigationHandler > > > > package where everything lives in. > > > > > > > > org.apache.myfaces.commons.urlNavigationHandler (the > api) > > > > org.apache.myfaces.commons.urlNavigationHandler.impl > > > > > org.apache.myfaces.commons.urlNavigationHandler.component > > > > etc > > > > > > > > > > > > > > > > > Also renderkit independent "components" need a taglib in the META-INF > dir. > > > This is the main difference between a "component" and a goodie class a > user > > > can decide to use or not. > > > > > > --Manfred > > > > > > > > > > > > -- > > http://www.irian.at > Your JSF powerhouse - JSF Consulting, > Development and Courses in English and > German > > Professional Support for Apache MyFaces From michelle92@example.org Thu Nov 01 10:27:12 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 67459 invoked from network); 1 Nov 2007 10:27:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 10:27:12 -0000 Received: (qmail 2627 invoked by uid 500); 1 Nov 2007 10:26:59 -0000 Delivered-To: michelle92@example.org Received: (qmail 2576 invoked by uid 500); 1 Nov 2007 10:26:59 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 2565 invoked by uid 99); 1 Nov 2007 10:26:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 03:26:58 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 10:27:10 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id 95F12714204 for <michelle92@example.org>; Thu, 1 Nov 2007 03:26:50 -0700 (PDT) Message-ID: <8567167.1193912810602.JavaMail.jira@brutus> Date: Thu, 1 Nov 2007 03:26:50 -0700 (PDT) From: "Matthias Wronka (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Created: (TOBAGO-530) tc:messages / tc:message should support different markups / style-classes per severity (Fatal, Error, Warn, Info) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org tc:messages / tc:message should support different markups / style-classes per severity (Fatal, Error, Warn, Info) ----------------------------------------------------------------------------------------------------------------- Key: TOBAGO-530 URL: https://issues.apache.org/jira/browse/TOBAGO-530 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka By now, all messages use the style-class .tobago-validation-message -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 10:33:15 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 69391 invoked from network); 1 Nov 2007 10:33:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 10:33:15 -0000 Received: (qmail 8165 invoked by uid 500); 1 Nov 2007 10:33:02 -0000 Delivered-To: michelle92@example.org Received: (qmail 7717 invoked by uid 500); 1 Nov 2007 10:33:01 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 7706 invoked by uid 99); 1 Nov 2007 10:33:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 03:33:01 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 10:33:28 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id A57FF7141F1 for <michelle92@example.org>; Thu, 1 Nov 2007 03:32:50 -0700 (PDT) Message-ID: <12123675.1193913170656.JavaMail.jira@brutus> Date: Thu, 1 Nov 2007 03:32:50 -0700 (PDT) From: "Matthias Wronka (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Created: (TOBAGO-531) tc:message should support a range of severities to be displayed MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org tc:message should support a range of severities to be displayed --------------------------------------------------------------- Key: TOBAGO-531 URL: https://issues.apache.org/jira/browse/TOBAGO-531 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Matthias Wronka Priority: Minor It would be nice to be able to set the severity of messages that are displayed by the messages-tag. In this way it would be possible to display error-messages in another place than e.g. info-messages. The tag could look like this: <tc:messages minSeverity="error" maxSeverity="fatal" /> with no severity specified, always all severities are displayed (ordered by severity (1st order) and occurance (2nd order)). With just a minSeverity specified the maxSeverity is automatically set to "fatal". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 12:54:19 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 8964 invoked from network); 1 Nov 2007 12:54:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 12:54:19 -0000 Received: (qmail 40000 invoked by uid 500); 1 Nov 2007 12:54:04 -0000 Delivered-To: michelle92@example.org Received: (qmail 39940 invoked by uid 500); 1 Nov 2007 12:54:04 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 39929 invoked by uid 99); 1 Nov 2007 12:54:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 05:54:03 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 12:54:29 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id 24317714231 for <michelle92@example.org>; Thu, 1 Nov 2007 05:53:51 -0700 (PDT) Message-ID: <28967317.1193921631145.JavaMail.jira@brutus> Date: Thu, 1 Nov 2007 05:53:51 -0700 (PDT) From: "Galina Gavrilo (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Commented: (MYFACES-1744) Validation messages is shown for SelectOneMenu in case first child is not SelectItems or SelectItem In-Reply-To: <17211826.1192030851371.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/MYFACES-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539355 ] Galina Gavrilo commented on MYFACES-1744: ----------------------------------------- Patch suitable, but ,what the procedure to include this patch into official build? Is it possible and how to achieve this? Thanks in advance. > Validation messages is shown for SelectOneMenu in case first child is not SelectItems or SelectItem > --------------------------------------------------------------------------------------------------- > > Key: MYFACES-1744 > URL: https://issues.apache.org/jira/browse/MYFACES-1744 > Project: MyFaces Core > Issue Type: Bug > Affects Versions: 1.1.5 > Environment: Windows XP > Reporter: Galina Gavrilo > Attachments: _SelectItemsIterator.patch, SelectItemsIterator.patch > > > If SelectOneMenu has child of another type than SelectItems or SelectItem at first place in the children list (e.g. itomahawk jsValueChangeListener), validation of combobox fails with message "Value is not a valid option." Value range is empty in this case because _SelectItemsIterator hasNext() method returns false if first child is not of type SelectItems or SelectItem. It should just skip such children, and should continue looking for values. Right? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 13:18:31 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 15514 invoked from network); 1 Nov 2007 13:18:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 13:18:30 -0000 Received: (qmail 78606 invoked by uid 500); 1 Nov 2007 13:18:01 -0000 Delivered-To: michelle92@example.org Received: (qmail 78570 invoked by uid 500); 1 Nov 2007 13:18:01 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 78558 invoked by uid 99); 1 Nov 2007 13:18:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 06:18:01 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 13:18:28 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id 97322714159 for <michelle92@example.org>; Thu, 1 Nov 2007 06:17:50 -0700 (PDT) Message-ID: <25435269.1193923070607.JavaMail.jira@brutus> Date: Thu, 1 Nov 2007 06:17:50 -0700 (PDT) From: "Udo Schnurpfeil (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Resolved: (TOBAGO-520) Datepicker does not render time-component when associated to Timestamp In-Reply-To: <6873181.1193219210621.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/TOBAGO-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-520. ------------------------------------ Resolution: Fixed Fix Version/s: 1.0.13 > Datepicker does not render time-component when associated to Timestamp > ---------------------------------------------------------------------- > > Key: TOBAGO-520 > URL: https://issues.apache.org/jira/browse/TOBAGO-520 > Project: MyFaces Tobago > Issue Type: Bug > Components: Core > Affects Versions: 1.0.12 > Reporter: Matthias Wronka > Fix For: 1.0.13 > > > The datepicker does not render the timecomponent anymore if the corresponding value-binding points to a timestamp. Instead it sets the time-portion of the timestamp to 00:00:00 when clicking ok in the datepicker (overwriting the previously set time). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 15:30:27 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 59123 invoked from network); 1 Nov 2007 15:30:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 15:30:27 -0000 Received: (qmail 61951 invoked by uid 500); 1 Nov 2007 15:10:09 -0000 Delivered-To: michelle92@example.org Received: (qmail 61921 invoked by uid 500); 1 Nov 2007 15:10:09 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 61910 invoked by uid 99); 1 Nov 2007 15:10:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 08:10:09 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 15:10:29 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id AA66D71422B for <michelle92@example.org>; Thu, 1 Nov 2007 08:09:50 -0700 (PDT) Message-ID: <18349433.1193929790643.JavaMail.jira@brutus> Date: Thu, 1 Nov 2007 08:09:50 -0700 (PDT) From: "Matthias Wronka (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Created: (TOBAGO-532) Popup Z-Index-Problem with DatePicker and InputSuggest in IE MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Popup Z-Index-Problem with DatePicker and InputSuggest in IE ------------------------------------------------------------ Key: TOBAGO-532 URL: https://issues.apache.org/jira/browse/TOBAGO-532 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.12 Environment: This problem occurs (only ?!) on InternetExplorer (I checked version 6) Reporter: Matthias Wronka Priority: Critical If a popup contains a Datefield the corresponding datepicker is opend behind the popup-window. On other browsers than IE the Datepicker is rendered in the front but the modal-window-layer is rendered behind the first popup, so the first popup is not disabled. This is a little tricky as there seems to be a dependency to the way, the popup is used. This can be reproduced in your demo: http://tobago.atanion.net/tobago-example-demo/faces/reference/popup.jsp The popup opend via the menu shows the problem at once (popup is opend via popup-reference). If you open the popup via the Open button (popup is a facet of the button) the calendar first works fine. But if you than press ok (without filling the required field) the calendar is opened behind the popup. A similar problem exists with the InputSuggest-Layer for an InputField in the popup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 15:36:53 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 62140 invoked from network); 1 Nov 2007 15:36:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 15:36:52 -0000 Received: (qmail 76264 invoked by uid 500); 1 Nov 2007 15:20:01 -0000 Delivered-To: michelle92@example.org Received: (qmail 76224 invoked by uid 500); 1 Nov 2007 15:20:01 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 76208 invoked by uid 99); 1 Nov 2007 15:20:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 08:20:01 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 15:20:29 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id CC5DD714231 for <michelle92@example.org>; Thu, 1 Nov 2007 08:19:50 -0700 (PDT) Message-ID: <20025993.1193930390834.JavaMail.jira@brutus> Date: Thu, 1 Nov 2007 08:19:50 -0700 (PDT) From: "Udo Schnurpfeil (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Issue Comment Edited: (TOBAGO-530) tc:messages / tc:message should support different markups / style-classes per severity (Fatal, Error, Warn, Info) In-Reply-To: <8567167.1193912810602.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/TOBAGO-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539387 ] lofwyr edited comment on TOBAGO-530 at 11/1/07 8:18 AM: ----------------------------------------------------------------- 1. An order possibility (sort by severity or occurrence) may be useful. 2. A maxItems attribute can make the tc:message tag obsolete was (Author: lofwyr): 1. An order possibility (sort by severity or occurrence) may be useful. 2. An maxItems attribute can make the tc:message tag obsolete > tc:messages / tc:message should support different markups / style-classes per severity (Fatal, Error, Warn, Info) > ----------------------------------------------------------------------------------------------------------------- > > Key: TOBAGO-530 > URL: https://issues.apache.org/jira/browse/TOBAGO-530 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core > Affects Versions: 1.0.12 > Reporter: Matthias Wronka > > By now, all messages use the style-class .tobago-validation-message -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 15:37:50 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 62405 invoked from network); 1 Nov 2007 15:37:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 15:37:50 -0000 Received: (qmail 76196 invoked by uid 500); 1 Nov 2007 15:20:01 -0000 Delivered-To: michelle92@example.org Received: (qmail 76164 invoked by uid 500); 1 Nov 2007 15:20:01 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 76151 invoked by uid 99); 1 Nov 2007 15:20:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 08:20:01 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 15:20:29 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id 9D01871422B for <michelle92@example.org>; Thu, 1 Nov 2007 08:19:50 -0700 (PDT) Message-ID: <18761308.1193930390603.JavaMail.jira@brutus> Date: Thu, 1 Nov 2007 08:19:50 -0700 (PDT) From: "Udo Schnurpfeil (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Commented: (TOBAGO-530) tc:messages / tc:message should support different markups / style-classes per severity (Fatal, Error, Warn, Info) In-Reply-To: <8567167.1193912810602.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/TOBAGO-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539387 ] Udo Schnurpfeil commented on TOBAGO-530: ---------------------------------------- 1. An order possibility (sort by severity or occurrence) may be useful. 2. An maxItems attribute can make the tc:message tag obsolete > tc:messages / tc:message should support different markups / style-classes per severity (Fatal, Error, Warn, Info) > ----------------------------------------------------------------------------------------------------------------- > > Key: TOBAGO-530 > URL: https://issues.apache.org/jira/browse/TOBAGO-530 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Core > Affects Versions: 1.0.12 > Reporter: Matthias Wronka > > By now, all messages use the style-class .tobago-validation-message -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 15:52:13 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 66117 invoked from network); 1 Nov 2007 15:52:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 1 Nov 2007 15:52:13 -0000 Received: (qmail 84674 invoked by uid 500); 1 Nov 2007 15:26:01 -0000 Delivered-To: michelle92@example.org Received: (qmail 84645 invoked by uid 500); 1 Nov 2007 15:26:01 -0000 Mailing-List: contact michelle92@example.org; run by ezmlm Precedence: bulk List-Help: <mailto:michelle92@example.org> List-Unsubscribe: <mailto:michelle92@example.org> List-Post: <mailto:michelle92@example.org> List-Id: <dev.myfaces.apache.org> Reply-To: "MyFaces Development" <michelle92@example.org> Delivered-To: mailing list michelle92@example.org Received: (qmail 84632 invoked by uid 99); 1 Nov 2007 15:26:01 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 08:26:01 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO brutus.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2007 15:26:29 +0000 Received: from brutus (localhost [83.161.120.155]) by brutus.apache.org (Postfix) with ESMTP id 9CF6B71422B for <michelle92@example.org>; Thu, 1 Nov 2007 08:25:50 -0700 (PDT) Message-ID: <5053624.1193930750620.JavaMail.jira@brutus> Date: Thu, 1 Nov 2007 08:25:50 -0700 (PDT) From: "shafi khan (JIRA)" <michelle92@example.org> To: michelle92@example.org Subject: [jira] Created: (TRINIDAD-792) Making Reorder,Remove ChildComponentChange generic to all the attributes MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Making Reorder,Remove ChildComponentChange generic to all the attributes ------------------------------------------------------------------------ Key: TRINIDAD-792 URL: https://issues.apache.org/jira/browse/TRINIDAD-792 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Affects Versions: 1.2.3-core Reporter: shafi khan Fix For: 1.2.3-core This is to avoid the requirement that " id attribute should always be specified for the children' in case of RemoveChildComponentChange, ReorderChildrenComponentChange. This makes the user to always specify 'id' attribute explicitly on the children. This leads to an increase of html output. Instead they can have custom attribute on the component. The users will have to pass custom attribute's value and custom attribute's name to the RemoveChildComponentChange's constructor. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. From michelle92@example.org Thu Nov 01 15:52:52 2007 Return-Path: <michelle92@example.org> Delivered-To: michelle92@example.org Received: (qmail 66362 invoked from network); 1 Nov 2007
{'source': 'Apache Software Foundation Public Mail Archives'}