JIRA time outs
I am having trouble getting JIRA to work . http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10600 Mostly getting timeouts about 50% of the time - a lot of 408s and one 409. On one occasion the browser rendered a page full of high ASCI characters. I also noticed sometimes when clicking on the 'login' link (upper right), I am not actually taken to the login page, but rather the JIRA home page. On one occasion, I got a Server too busy response . Dennis Byrne
Re: svn commit: r380866 - in /incubator/tobago/trunk: tobago-core/src/main/java/org/apache/myfaces/tobago/component/ tobago-core/src/main/java/org/apache/myfaces/tobago/taglib/component/ tobago-exampl
Hi Volker, I would prefer an actionListener and a SortActionEvent instead of a sortActionListener. I don't like the x XYZActionListener. Can you change it? Regards Bernd [EMAIL PROTECTED] schrieb: Author: weber Date: Fri Feb 24 15:37:31 2006 New Revision: 380866 URL: http://svn.apache.org/viewcvs?rev=380866view=rev Log: add sortActionListener attribute to sheet Modified: incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/Sorter.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/UIData.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/taglib/component/SheetTag.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/TobagoDemoController.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/model/solar/SolarObject.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/overview/OverviewController.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/overview/SheetConfig.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/overview/sheetControl.jsp incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/SheetRenderer.java incubator/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-sheet.js Modified: incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java URL: http://svn.apache.org/viewcvs/incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java?rev=380866r1=380865r2=380866view=diff == --- incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java (original) +++ incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java Fri Feb 24 15:37:31 2006 @@ -23,30 +23,7 @@ import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ACCESS_KEY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ACTION_STRING; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ALIGN; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_DISABLED; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_FOR; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_HOVER; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_LABEL; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_LABEL_WITH_ACCESS_KEY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_READONLY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_RENDER_RANGE; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_RENDER_RANGE_EXTERN; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_SORTABLE; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_VALUE; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_NAVIGATE; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_RESET; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_SCRIPT; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_CHECKBOX; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_LABEL; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_RADIO; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_OUT; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_SELECT_BOOLEAN_CHECKBOX; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_SELECT_ONE_RADIO; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_CREATE_SPAN; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ESCAPE; +import static org.apache.myfaces.tobago.TobagoConstants.*; import org.apache.myfaces.tobago.el.ConstantMethodBinding; import org.apache.myfaces.tobago.event.SheetStateChangeEvent; import org.apache.myfaces.tobago.renderkit.RendererBase; @@ -55,33 +32,22 @@ import javax.faces.FactoryFinder; import javax.faces.application.Application; -import javax.faces.component.ActionSource; -import javax.faces.component.EditableValueHolder; -import javax.faces.component.UIColumn; +import javax.faces.component.*; import javax.faces.component.UICommand; -import javax.faces.component.UIComponent; -import
Re: StartupServletContextListener in tomhawk-sandbox-examples web.xml but not in examples-simple web.xml
Lets remove from sandbox to be consistent. +1 But I added the listener to your archetype, because of I added the Jetty6 plugin for mvn. So calling jetty:run will start the container and deploy the sample app, without getting that error message ;-) -Matthias On 2/24/06, Mike Kienenberger [EMAIL PROTECTED] wrote: We have inconsistently defined a listener entry in the tomahawk-sandbox-examples web.xml file but not in the myfaces-example-simple web.xml file. listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener I found out because sandbox examples work as-is with jetty 5.1.8, but the simple examples do not. I'm guessing we want to remove the listener declaration from sandbox. I wouldn't be opposed to adding it to simple, though :) I'm guessing it's problematic to have the listener defined in both the tld file and the web.xml file on most containers, but I don't know for sure. -Mike -- Matthias Wessendorf Zülpicher Wall 12, 239 50674 Köln http://www.wessendorf.net mwessendorf-at-gmail-dot-com
Re: svn commit: r380866 - in /incubator/tobago/trunk: tobago-core/src/main/java/org/apache/myfaces/tobago/component/ tobago-core/src/main/java/org/apache/myfaces/tobago/taglib/component/ tobago-exampl
Hi Bernd, the sheet was already using a actionListener methodBinding to do the sort. The (mainly) only thing i did was to enable defining the methodBinding to use in the sheetTag. Hmmm, when i started to write this mail, i thought it where mutch more complicated to change this to queue a SortActionEvent instead of an standard ActionEvent, because the event is generated in the CommandRendererBase, but i just got an idea how to catch and replace this ActionEvent with a SortActionEvent. This could be done in the queueEvent() method of UIData. Thoughts? Regards, Volker Bernd Bohmann wrote: Hi Volker, I would prefer an actionListener and a SortActionEvent instead of a sortActionListener. I don't like the x XYZActionListener. Can you change it? Regards Bernd [EMAIL PROTECTED] schrieb: Author: weber Date: Fri Feb 24 15:37:31 2006 New Revision: 380866 URL: http://svn.apache.org/viewcvs?rev=380866view=rev Log: add sortActionListener attribute to sheet Modified: incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/Sorter.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/UIData.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/taglib/component/SheetTag.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/TobagoDemoController.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/model/solar/SolarObject.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/overview/OverviewController.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/overview/SheetConfig.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/overview/sheetControl.jsp incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/SheetRenderer.java incubator/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-sheet.js Modified: incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java URL: http://svn.apache.org/viewcvs/incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java?rev=380866r1=380865r2=380866view=diff == --- incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java (original) +++ incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java Fri Feb 24 15:37:31 2006 @@ -23,30 +23,7 @@ import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ACCESS_KEY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ACTION_STRING; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ALIGN; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_DISABLED; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_FOR; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_HOVER; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_LABEL; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_LABEL_WITH_ACCESS_KEY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_READONLY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_RENDER_RANGE; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_RENDER_RANGE_EXTERN; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_SORTABLE; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_VALUE; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_NAVIGATE; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_RESET; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_SCRIPT; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_CHECKBOX; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_LABEL; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_RADIO; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_OUT; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_SELECT_BOOLEAN_CHECKBOX; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_SELECT_ONE_RADIO; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_CREATE_SPAN; -import
Re: svn commit: r380693 [9/9] - in /myfaces: core/branches/1_1_2/assembly/ core/branches/1_1_2/impl/ core/branches/1_1_2/impl/src/main/java/org/apache/myfaces/application/ core/branches/1_1_2/impl/src
;)
I think Manfred is working on a branch, so you shouldn't be in danger
while dancing.
regards,
Martin
On 2/25/06, Dennis Byrne [EMAIL PROTECTED] wrote:
DJ Manfred,
Are you done remixing commons, or should we postpone commits until the end of
the weekend?
Dennis Byrne
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, February 24, 2006 10:47 AM
To: commits@myfaces.apache.org
Subject: svn commit: r380693 [9/9] - in /myfaces:
core/branches/1_1_2/assembly/ core/branches/1_1_2/impl/
core/branches/1_1_2/impl/src/main/java/org/apache/myfaces/application/
core/branches/1_1_2/impl/src/main/java/org/apache/myfaces/application/jsp/
core/bran...
Modified:
myfaces/tomahawk/branches/1_1_2/sandbox/core/src/main/java/org/apache/myfaces/custom/script/Script.java
URL:
http://svn.apache.org/viewcvs/myfaces/tomahawk/branches/1_1_2/sandbox/core/src/main/java/org/apache/myfaces/custom/script/Script.java?rev=380693r1=380692r2=380693view=diff
==
---
myfaces/tomahawk/branches/1_1_2/sandbox/core/src/main/java/org/apache/myfaces/custom/script/Script.java
(original)
+++
myfaces/tomahawk/branches/1_1_2/sandbox/core/src/main/java/org/apache/myfaces/custom/script/Script.java
Fri Feb 24 07:47:18 2006
@@ -19,8 +19,8 @@
import javax.faces.context.FacesContext;
import javax.faces.el.ValueBinding;
-import org.apache.myfaces.renderkit.html.HTML;
-import org.apache.myfaces.util._ComponentUtils;
+import org.apache.myfaces.shared.renderkit.html.HTML;
+import org.apache.myfaces.shared.util._ComponentUtils;
/**
* @author Matthias Wessendorf (changed by $Author$)
@@ -28,12 +28,12 @@
*/
public class Script extends UIOutput {
- public static final String COMPONENT_TYPE =
org.apache.myfaces.Script;
- public static final String COMPONENT_FAMILY = javax.faces.Output;
- private static final String DEFAULT_RENDERER_TYPE =
org.apache.myfaces.Script;
-
- private String src = null;
- private String type = HTML.SCRIPT_TYPE_TEXT_JAVASCRIPT;
+public static final String COMPONENT_TYPE = org.apache.myfaces.Script;
+public static final String COMPONENT_FAMILY = javax.faces.Output;
+private static final String DEFAULT_RENDERER_TYPE =
org.apache.myfaces.Script;
+
+private String src = null;
+private String type = HTML.SCRIPT_TYPE_TEXT_JAVASCRIPT;
//
Constructor
public Script() {
@@ -50,28 +50,28 @@
}
//
getter/setter
- public String getSrc() {
+public String getSrc() {
if (src != null) return src;
ValueBinding vb = getValueBinding(src);
return vb != null ?
_ComponentUtils.getStringValue(getFacesContext(), vb) : null;
- }
+}
- public void setSrc(String src) {
- this.src = src;
- }
+public void setSrc(String src) {
+this.src = src;
+}
- public String getType() {
+public String getType() {
if (type != null) return type;
ValueBinding vb = getValueBinding(type);
return vb != null ?
_ComponentUtils.getStringValue(getFacesContext(), vb) : null;
- }
+}
- public void setType(String type) {
- this.type = type;
- }
+public void setType(String type) {
+this.type = type;
+}
//
StateHolder
public void restoreState(FacesContext context, Object state) {
@@ -93,5 +93,5 @@
}
-
+
}
Modified:
myfaces/tomahawk/branches/1_1_2/sandbox/core/src/main/java/org/apache/myfaces/custom/script/ScriptRenderer.java
URL:
http://svn.apache.org/viewcvs/myfaces/tomahawk/branches/1_1_2/sandbox/core/src/main/java/org/apache/myfaces/custom/script/ScriptRenderer.java?rev=380693r1=380692r2=380693view=diff
==
---
myfaces/tomahawk/branches/1_1_2/sandbox/core/src/main/java/org/apache/myfaces/custom/script/ScriptRenderer.java
(original)
+++
myfaces/tomahawk/branches/1_1_2/sandbox/core/src/main/java/org/apache/myfaces/custom/script/ScriptRenderer.java
Fri Feb 24 07:47:18 2006
@@ -21,26 +21,26 @@
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
-import org.apache.myfaces.renderkit.html.HTML;
-import org.apache.myfaces.renderkit.html.HtmlRenderer;
+import org.apache.myfaces.shared.renderkit.html.HTML;
+import org.apache.myfaces.shared.renderkit.html.HtmlRenderer;
/**
* @author Matthias Wessendorf (changed by $Author$)
* @version $Revision$ $Date$
*/
public class ScriptRenderer extends HtmlRenderer {
-
- public void encodeEnd(FacesContext context,
Re: svn commit: r380866 - in /incubator/tobago/trunk: tobago-core/src/main/java/org/apache/myfaces/tobago/component/ tobago-core/src/main/java/org/apache/myfaces/tobago/taglib/component/ tobago-exampl
I think so, but now I go to a Kohlfahrt. We can discuss this tommorrow :-) Volker Weber schrieb: Hi Bernd, the sheet was already using a actionListener methodBinding to do the sort. The (mainly) only thing i did was to enable defining the methodBinding to use in the sheetTag. Hmmm, when i started to write this mail, i thought it where mutch more complicated to change this to queue a SortActionEvent instead of an standard ActionEvent, because the event is generated in the CommandRendererBase, but i just got an idea how to catch and replace this ActionEvent with a SortActionEvent. This could be done in the queueEvent() method of UIData. Thoughts? Regards, Volker Bernd Bohmann wrote: Hi Volker, I would prefer an actionListener and a SortActionEvent instead of a sortActionListener. I don't like the x XYZActionListener. Can you change it? Regards Bernd [EMAIL PROTECTED] schrieb: Author: weber Date: Fri Feb 24 15:37:31 2006 New Revision: 380866 URL: http://svn.apache.org/viewcvs?rev=380866view=rev Log: add sortActionListener attribute to sheet Modified: incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/Sorter.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/UIData.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/taglib/component/SheetTag.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/TobagoDemoController.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/model/solar/SolarObject.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/overview/OverviewController.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/overview/SheetConfig.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/overview/sheetControl.jsp incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/SheetRenderer.java incubator/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-sheet.js Modified: incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java URL: http://svn.apache.org/viewcvs/incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java?rev=380866r1=380865r2=380866view=diff == --- incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java (original) +++ incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java Fri Feb 24 15:37:31 2006 @@ -23,30 +23,7 @@ import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ACCESS_KEY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ACTION_STRING; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ALIGN; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_DISABLED; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_FOR; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_HOVER; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_LABEL; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_LABEL_WITH_ACCESS_KEY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_READONLY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_RENDER_RANGE; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_RENDER_RANGE_EXTERN; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_SORTABLE; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_VALUE; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_NAVIGATE; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_RESET; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_SCRIPT; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_CHECKBOX; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_LABEL; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_RADIO; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_OUT; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_SELECT_BOOLEAN_CHECKBOX; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_SELECT_ONE_RADIO; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_CREATE_SPAN;
Re: [jira] Created: (TOMAHAWK-156) DataList doesn't validate or update model in 1.1.2 nightlies
Jira seems to be down - so I'm adding this comment to the list.
I just committed what Dennis was doing for processDecodes with
processUpdates and processValidators as well.
@Mike Y: Does that fix your problem?
@Mike K: you tried with the sandbox, can you try with my proposed fix as well?
regards,
Martin
On 2/24/06, Mike Youngstrom (JIRA) dev@myfaces.apache.org wrote:
DataList doesn't validate or update model in 1.1.2 nightlies
Key: TOMAHAWK-156
URL: http://issues.apache.org/jira/browse/TOMAHAWK-156
Project: MyFaces Tomahawk
Type: Bug
Components: Data List
Versions: 1.1.2-SNAPSHOT
Reporter: Mike Youngstrom
Priority: Critical
DataList appears to be broken in 1.1.2-nightlies. My form elements are not
being validated or updated. If I downgrade to 1.1.1 everything works fine.
Here is the test case:
---test.jsp-
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h %
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t%
f:view
h:form
t:dataList value=#{test.values} var=value
h:message for=item/
h:inputText id=item required=true
value=#{value.value}/br/
/t:dataList
br/
h:commandButton/
/h:form
/f:view
--Test.java(A SESSION managed bean named test)
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class Test {
List values;
public List getValues() {
if(values == null) {
values = new ArrayList();
{
Map valuesMap = new HashMap();
valuesMap.put(value, Groovy);
values.add(valuesMap);
}
{
Map valuesMap = new HashMap();
valuesMap.put(value, Dude);
values.add(valuesMap);
}
{
Map valuesMap = new HashMap();
valuesMap.put(value, Bob);
values.add(valuesMap);
}
}
return values;
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: svn commit: r380866 - in /incubator/tobago/trunk: tobago-core/src/main/java/org/apache/myfaces/tobago/component/ tobago-core/src/main/java/org/apache/myfaces/tobago/taglib/component/ tobago-exampl
What's Kohlfahrt? just being curious ;) regards, Martin On 2/25/06, Bernd Bohmann [EMAIL PROTECTED] wrote: I think so, but now I go to a Kohlfahrt. We can discuss this tommorrow :-) Volker Weber schrieb: Hi Bernd, the sheet was already using a actionListener methodBinding to do the sort. The (mainly) only thing i did was to enable defining the methodBinding to use in the sheetTag. Hmmm, when i started to write this mail, i thought it where mutch more complicated to change this to queue a SortActionEvent instead of an standard ActionEvent, because the event is generated in the CommandRendererBase, but i just got an idea how to catch and replace this ActionEvent with a SortActionEvent. This could be done in the queueEvent() method of UIData. Thoughts? Regards, Volker Bernd Bohmann wrote: Hi Volker, I would prefer an actionListener and a SortActionEvent instead of a sortActionListener. I don't like the x XYZActionListener. Can you change it? Regards Bernd [EMAIL PROTECTED] schrieb: Author: weber Date: Fri Feb 24 15:37:31 2006 New Revision: 380866 URL: http://svn.apache.org/viewcvs?rev=380866view=rev Log: add sortActionListener attribute to sheet Modified: incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/Sorter.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/UIData.java incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/taglib/component/SheetTag.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/TobagoDemoController.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/model/solar/SolarObject.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/overview/OverviewController.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/overview/SheetConfig.java incubator/tobago/trunk/tobago-example/tobago-example-demo/src/main/webapp/overview/sheetControl.jsp incubator/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/SheetRenderer.java incubator/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-sheet.js Modified: incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java URL: http://svn.apache.org/viewcvs/incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java?rev=380866r1=380865r2=380866view=diff == --- incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java (original) +++ incubator/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/component/ComponentUtil.java Fri Feb 24 15:37:31 2006 @@ -23,30 +23,7 @@ import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ACCESS_KEY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ACTION_STRING; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_ALIGN; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_DISABLED; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_FOR; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_HOVER; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_LABEL; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_LABEL_WITH_ACCESS_KEY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_READONLY; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_RENDER_RANGE; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_RENDER_RANGE_EXTERN; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_SORTABLE; -import static org.apache.myfaces.tobago.TobagoConstants.ATTR_VALUE; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_NAVIGATE; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_RESET; -import static org.apache.myfaces.tobago.TobagoConstants.COMMAND_TYPE_SCRIPT; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_CHECKBOX; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_LABEL; -import static org.apache.myfaces.tobago.TobagoConstants.FACET_RADIO; -import static org.apache.myfaces.tobago.TobagoConstants.RENDERER_TYPE_OUT; -import static
Re: svn commit: r380866 - in /incubator/tobago/trunk: tobago-core/src/main/java/org/apache/myfaces/tobago/component/ tobago-core/src/main/java/org/apache/myfaces/tobago/taglib/component/ tobago-exampl
Martin Marinschek wrote: What's Kohlfahrt? Whoow, i found a english description: http://www.armin-grewe.com/holiday/kohlfahrt/kohlfahrt.htm Regards, Volker just being curious ;) regards, Martin On 2/25/06, Bernd Bohmann [EMAIL PROTECTED] wrote: I think so, but now I go to a Kohlfahrt. We can discuss this tommorrow :-) -- Don't answer to From: address! Mail to this account are droped if not recieved via mailinglist. To contact me direct create the mail address by concatenating my forename to my senders domain.
validation in model classes with PropertyVetoException
Hi,
I have never really felt good about the validation framework of JSF (and
Struts for that matter). The problem is that you are forced to put
validation logic into your view layer, which in the case of JSF means
polluting your jsp with validator tags.
This becomes especially problematic when you have more than one GUI for
your application, because then you have to duplicate the validation logic.
What I would prefer is to be able to do validations JavaBeans-style,
meaning I want to put my validation logic inside the setters of the
model classes, throwing PropertyVetoExceptions when the validation
fails. That way, your model classes will never be in an inconsistent state.
I have been working on way to do this in MyFaces. It involves
registering a custom PropertyResolver (thanks to Jan Dockx for this hint
:-) ) and a small change to the UIInput class.
The custom PropertyResolver checks if the thrown Exception is a
PropertyVetoException, and then wraps it in an EvaluationException, so
as to be JSF spec compliant:
} catch (Exception e) {
if (e instanceof PropertyVetoException)
{
PropertyVetoException pve = (PropertyVetoException) e;
throw new EvaluationException(pve.getMessage(), pve);
} else {
throw new EvaluationException(Exception setting value of index
+ index + of bean + base.getClass().getName(), e);
}
}
The UIInput needs a change in the updateModel method. In the current myfaces
implementation
the UIInput catches all runtime exceptions and adds an error message with key
CONVERSION_MESSAGE_ID
to the FacesContext.
In order for my PropertyVetoException message to be displayed, I have to check
if the original
cause of the RuntimeException happens to be a PropertyVetoException, in which
case the FacesMessage
contains the message of the PropertyVetoException.
I don't think that this change would compromise the JSF spec compliance of
myfaces, and the default
behaviour would not change unless you register that custom PropertyResolver.
Therefore I would like
to suggest applying this change to the myfaces sourcetree.
What do you think?
Kind regards,
Jurgen
Error in INPUTCALANDER in DefaultAddResource
Hi, I used "inputCalendar" of myfaces for a calendar popup, and I used also the property serverSideTabSwitch=true to the panelTabbedPane for navigative different pannels by executing tabChangeListener, but it generate error when I click on the 'Calandar' button. It says following way:org.apache.myfaces.renderkit.html.util.DefaultAddResource serveResourceSEVERE: Error while serving resource: calendar.HtmlCalendarRenderer/DB/drop1.gif, message : null ClientAbortException: java.net.SocketException: Connection reset by peer: socket write error< /div> at org.apache.catalina.connector.OutputBuffer.doFlush . etc.--- How can I get rid of it? However, without the tabChangeListener it does not raise any error.Regards, Aloke__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: JIRA time outs
On Sat, Feb 25, 2006 at 08:38:02AM +, Dennis Byrne wrote: I am having trouble getting JIRA to work . http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10600 Mostly getting timeouts about 50% of the time - a lot of 408s and one 409. On one occasion the browser rendered a page full of high ASCI characters. I also noticed sometimes when clicking on the 'login' link (upper right), I am not actually taken to the login page, but rather the JIRA home page. On one occasion, I got a Server too busy response . The server load is currently very high, probably due to an experimental patch recently applied to fix mod_proxy_ajp problems: https://issues.apache.org/jira/browse/INFRA-697 People are looking into the load problem right now, so hopefully it will be fixed soon. --Jeff Dennis Byrne
Re: Error in INPUTCALANDER in DefaultAddResource
Hi! It says following way: org.apache.myfaces.renderkit.html.util.DefaultAddResource serveResource SEVERE: Error while serving resource: calendar.HtmlCalendarRenderer/DB/drop1.gif, message : null ClientAbortException: java.net.SocketException: Connection reset by peer: socket write error /div at org.apache.catalina.connector.OutputBuffer.doFlush Which version of MyFaces do you use? If its not the latest svn head, could you please try so. And - Please post the full stack trace. --- Mario
[jira] Resolved: (TOMAHAWK-62) Impossible to hide footer in dataTable
[ http://issues.apache.org/jira/browse/TOMAHAWK-62?page=all ]
Mario Ivankovits resolved TOMAHAWK-62:
--
Resolution: Fixed
now if all facet within the header (or footer) have rendered=false (also
throug binding) the header (or footer) wont be rendered any more
Impossible to hide footer in dataTable
--
Key: TOMAHAWK-62
URL: http://issues.apache.org/jira/browse/TOMAHAWK-62
Project: MyFaces Tomahawk
Type: Bug
Reporter: Guy Bashan
Assignee: Mario Ivankovits
Priority: Trivial
It is impossible to hide the footer in a dataTable. There are cases in which
the same table should sometimes show the footer and in other cases do not
show it. For example:
t:dataTable id=results value=#{analyze.rows} var=row
width=100%
cellpadding=0
cellspacing=0
border=0
styleClass=reportTable
headerClass=reportTitle
footerClass=reportTableTotal
rowClasses=reportRowLight,reportRowDark
rowOnMouseOver=selectedRow = this.className;
this.className='reportRowOver'
rowOnMouseOut=this.className = selectedRow
t:columns value=#{analyze.columnHeaders} var=column
styleClass=#{analyze.styleClass}
style=text-align:#{column.alignment}
f:facet name=header
t:htmlTag value=nobrh:outputText value=#{column.title}
escape=false//t:htmlTag
/f:facet
h:outputText value=#{analyze.columnValue} escape=false /
f:facet name=footer
h:outputText value=#{analyze.colFooter.title}
escape=false/
t:htmlTag value=b
h:outputText value=#{analyze.colFooter.total}/
/t:htmlTag
/f:facet
/t:columns
/t:dataTable
I tried hiding the footer with: f:subview wrapping the footer and as a footer
child, but both seems to be not working.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (TOMAHAWK-62) Impossible to hide footer in dataTable
[ http://issues.apache.org/jira/browse/TOMAHAWK-62?page=all ]
Mario Ivankovits closed TOMAHAWK-62:
Impossible to hide footer in dataTable
--
Key: TOMAHAWK-62
URL: http://issues.apache.org/jira/browse/TOMAHAWK-62
Project: MyFaces Tomahawk
Type: Bug
Reporter: Guy Bashan
Assignee: Mario Ivankovits
Priority: Trivial
It is impossible to hide the footer in a dataTable. There are cases in which
the same table should sometimes show the footer and in other cases do not
show it. For example:
t:dataTable id=results value=#{analyze.rows} var=row
width=100%
cellpadding=0
cellspacing=0
border=0
styleClass=reportTable
headerClass=reportTitle
footerClass=reportTableTotal
rowClasses=reportRowLight,reportRowDark
rowOnMouseOver=selectedRow = this.className;
this.className='reportRowOver'
rowOnMouseOut=this.className = selectedRow
t:columns value=#{analyze.columnHeaders} var=column
styleClass=#{analyze.styleClass}
style=text-align:#{column.alignment}
f:facet name=header
t:htmlTag value=nobrh:outputText value=#{column.title}
escape=false//t:htmlTag
/f:facet
h:outputText value=#{analyze.columnValue} escape=false /
f:facet name=footer
h:outputText value=#{analyze.colFooter.title}
escape=false/
t:htmlTag value=b
h:outputText value=#{analyze.colFooter.total}/
/t:htmlTag
/f:facet
/t:columns
/t:dataTable
I tried hiding the footer with: f:subview wrapping the footer and as a footer
child, but both seems to be not working.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: validation in model classes with PropertyVetoException
I think the complaint about the validation framework of
JSF is only half right.
It's bad that validation rules are specified in the view,
and especially bad that they're specified in the actual
JSP.
However, it's absolutely correct that validation *happens*
in the view. For example, how are you going to do
Javascript validation in the client if the information
about validation rules is entirely buried in the model layer?
What JSF is missing is a way to automatically derive
its validation from metadata exposed by the model - e.g.,
why not have:
h:inputText value=#{myBean.foo}/
... and then have:
/**
* @greaterThan 5
* @lessThan 15
*/
public int getFoo() { ... }
This seems the right way to go; PropertyVetoExceptions, not so
much.
There's also a more basic problem with the mechanics of your
suggestion: you're moving your validation out of the Process Validation
phase and into Update Model. That's a *huge* change, and not
one I'd recommend. For one thing, you can't roll back updateModels()
that have already succeeded, so you've ended with a partially valid
set of values added to the model
-- Adam
On 2/25/06, Jurgen Lust [EMAIL PROTECTED] wrote:
Hi,
I have never really felt good about the validation framework of JSF (and
Struts for that matter). The problem is that you are forced to put
validation logic into your view layer, which in the case of JSF means
polluting your jsp with validator tags.
This becomes especially problematic when you have more than one GUI for
your application, because then you have to duplicate the validation logic.
What I would prefer is to be able to do validations JavaBeans-style,
meaning I want to put my validation logic inside the setters of the
model classes, throwing PropertyVetoExceptions when the validation
fails. That way, your model classes will never be in an inconsistent state.
I have been working on way to do this in MyFaces. It involves
registering a custom PropertyResolver (thanks to Jan Dockx for this hint
:-) ) and a small change to the UIInput class.
The custom PropertyResolver checks if the thrown Exception is a
PropertyVetoException, and then wraps it in an EvaluationException, so
as to be JSF spec compliant:
} catch (Exception e) {
if (e instanceof PropertyVetoException)
{
PropertyVetoException pve = (PropertyVetoException) e;
throw new EvaluationException(pve.getMessage(), pve);
} else {
throw new EvaluationException(Exception setting value of
index
+ index + of bean + base.getClass().getName(), e);
}
}
The UIInput needs a change in the updateModel method. In the current myfaces
implementation
the UIInput catches all runtime exceptions and adds an error message with key
CONVERSION_MESSAGE_ID
to the FacesContext.
In order for my PropertyVetoException message to be displayed, I have to
check if the original
cause of the RuntimeException happens to be a PropertyVetoException, in which
case the FacesMessage
contains the message of the PropertyVetoException.
I don't think that this change would compromise the JSF spec compliance of
myfaces, and the default
behaviour would not change unless you register that custom PropertyResolver.
Therefore I would like
to suggest applying this change to the myfaces sourcetree.
What do you think?
Kind regards,
Jurgen
[jira] Created: (MYFACES-1155) UIViewRoot.getRenderKitId() does not return null
UIViewRoot.getRenderKitId() does not return null Key: MYFACES-1155 URL: http://issues.apache.org/jira/browse/MYFACES-1155 Project: MyFaces Core Type: Bug Components: JSR-127 Versions: 1.1.0, 1.1.1 Environment: RI 1.0, RI 1.1, all version of MyFaces Reporter: Dennis Byrne Assigned to: Dennis Byrne This started in bugzilla http://issues.apache.org/bugzilla/show_bug.cgi?id=38294 . MyFaces impl is following the 1.0 behavior, not the 1.1 behavior. http://java.sun.com/javaee/javaserverfaces/1.1/docs/api/javax/faces/component/UIViewRoot.html#getRenderKitId() http://java.sun.com/javaee/javaserverfaces/1.0/docs/api/javax/faces/component/UIViewRoot.html#getRenderKitId() This is a little more complex than just making the method return null. Doing so breaks more than half the tests. I would appreciate it if anyone knew how to find out if this is affected by TCK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: validation in model classes with PropertyVetoException
h:inputText value=#{myBean.foo}/
... and then have:
/**
* @greaterThan 5
* @lessThan 15
*/
public int getFoo() { ... }
This seems the right way to go; PropertyVetoExceptions, not so
much.
That would indeed be the ideal way, but we are clearly not there yet.
There is an article about this on the Sun Developer Network:
http://java.sun.com/developer/technicalArticles/J2SE/constraints/annotations.html
In the meantime, it would be nice if we can work with what we do have.
In many cases, the JSF validation framework is very good, but I prefer
having my constraints enforced in one central place, the model classes.
There's also a more basic problem with the mechanics of your
suggestion: you're moving your validation out of the Process Validation
phase and into Update Model. That's a *huge* change, and not
one I'd recommend. For one thing, you can't roll back updateModels()
that have already succeeded, so you've ended with a partially valid
set of values added to the model
True. That is a definite drawback of this approach. However, it would be
nice if the developer could choose this approach, which is what my
suggestion allows: It allows you to show the message of the
PropertyVetoException, whereas the current implementation catches all
exceptions from the model and shows a generic error message in the browser.
If you want the default behaviour, no problem, but if you want the
PropertyVetoException alternative, just plugin the custom PropertyResolver.
I'm preparing a patch now, which I'll post on JIRA so you can testdrive
it if you want.
Jurgen
Patch available in JIRA
Without logging in to JIRA, I was able to the change the status of MYFACES-1149 to Patch Available . https://issues.apache.org/jira/browse/MYFACES-1149?page=all I did this accidently a few days ago - I seem to remember clicking on a Provide Patch link . Now, even though I am logged in, I cannot see how to revert the status ; even using the Edit this issue link. Also, can we prevent this situation in the future by requiring a patch when a user changes the status of an issue to Patch Available. Dennis Byrne
Re: new InputSuggestAjax: so buggy or still under construction?
Both are as we speak still a little bit under construction, the reason why we moved to dojo is, that prototype is problematic regarding namespace hijacking. The table select is a totally new development so things like that can happen, as for the input suggest please file a bug on this one (please also for the table select), I know Gerald Müllan currently is working on it. (same goes for the table suggesT) since both components are pushed massively forward as we speak you can expect the situation to calm down soon. Volker Weber schrieb: Hi, i just took a first look at the new inputSugestAjax in sandbox examples and i'm a bit disappointed. I expect something like the address input in my email client, i start typing and became suggestions (so far so good) but if i never accept a suggestion and still type the address, nothing from suggestion sould used. See first attached image (inputSuggestAjax.gif) what i get when i type my email without waiting for suggestions after each typed character. Typing into the tableSuggest field sometimes completely breaks the page layout, see second image. Any ideas whats going wrong here? Are there any dojo examples online where i can test this? I think i stay in tobago with prototype/script.aculo.us in the meantime. Regards, Volker
[jira] Resolved: (TOMAHAWK-152) t:selectOneRadio and t:radio should do the same when check the selected item
[ http://issues.apache.org/jira/browse/TOMAHAWK-152?page=all ] Volker Weber resolved TOMAHAWK-152: --- Resolution: Fixed patch applied t:selectOneRadio and t:radio should do the same when check the selected item Key: TOMAHAWK-152 URL: http://issues.apache.org/jira/browse/TOMAHAWK-152 Project: MyFaces Tomahawk Type: Bug Components: selectOneRadio / radio Versions: 1.1.2-SNAPSHOT Reporter: Volker Weber Assignee: Volker Weber Priority: Minor Fix For: 1.1.2-SNAPSHOT Attachments: HtmlRadioRenderer.diff The check for selected is difference between layout=spread and other: On pageDirection and lineDirection layout the stringvalues are checked and on spread layout the real value objects are checked. This results in different behavior when using f:selectItem itemValue=true itemLabel=True / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (TOMAHAWK-152) t:selectOneRadio and t:radio should do the same when check the selected item
[ http://issues.apache.org/jira/browse/TOMAHAWK-152?page=all ] Volker Weber closed TOMAHAWK-152: - t:selectOneRadio and t:radio should do the same when check the selected item Key: TOMAHAWK-152 URL: http://issues.apache.org/jira/browse/TOMAHAWK-152 Project: MyFaces Tomahawk Type: Bug Components: selectOneRadio / radio Versions: 1.1.2-SNAPSHOT Reporter: Volker Weber Assignee: Volker Weber Priority: Minor Fix For: 1.1.2-SNAPSHOT Attachments: HtmlRadioRenderer.diff The check for selected is difference between layout=spread and other: On pageDirection and lineDirection layout the stringvalues are checked and on spread layout the real value objects are checked. This results in different behavior when using f:selectItem itemValue=true itemLabel=True / -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-1154) PortletExternalContextImpl#encodeNamespace postfixes the namespace instead of prefixes it
[ http://issues.apache.org/jira/browse/MYFACES-1154?page=comments#action_12367791 ] Henrik Bentel commented on MYFACES-1154: hi Last fall I submitted a patch that appends the portlet namespace instead of prepend it. Reason was that Myfaces would wrap elements in span tags if the ID didn't start with _ID. Here's the issue link: http://issues.apache.org/jira/browse/MYFACES-702 I didn't see the section in the spec that requires prepending but if that is correct then a different solution to MYFACES-702 should probably be found. PortletExternalContextImpl#encodeNamespace postfixes the namespace instead of prefixes it - Key: MYFACES-1154 URL: http://issues.apache.org/jira/browse/MYFACES-1154 Project: MyFaces Core Type: Bug Components: JSR-127 Versions: 1.1.2-SNAPSHOT Reporter: Dave Brondsema Assignee: Stan Silvert Priority: Trivial PortletExternalContextImpl#encodeNamespace appends the namespace, whereas the specification requires that it prepend it -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
purpose of StylesheetRendererTest
This class has two test methods and neither asserts anything . Any reason to keep this ? Dennis Byrne
Pro JSF and Ajax: it's good
My copy of Pro JSF and Ajax showed up on Friday, and I sat down to read it this weekend. I had put it on preorder, based only on the credibility built up by reading the author's posts on JSF. Below is the review I posted on Amazon. I believe that this book will be on the bookshelf of anyone writing JSF components. Congrats to Jonas and John on a job well done. Steve -- The first round of books on JSF were survey books that attempt to cover all of this complex, sophisticated framework. Pro JSF and Ajax focuses on one important facet of JSF -- component development -- and does it well. It starts with a quick overview of the major architectural elements of JSF, and then quickly moves to building custom components in Chapter 2. The first component built is a simple date entry component; a second, more sophisticated example is a 'deck' implementation (a deck is a collapsing navigational/browsing UI element). The authors then provide a succinct overview of client side rich internet technologies -- Ajax, XUL (supported by Firefox) and HTC (the DHTML behavior language that is supported by Internet Explorer). They then deploy these technologies to build rich client versions of the date and deck components. The book does a good job of bridging the gap between JSF 1.1 and 1.2 implementations; the code in the book targets 1.1, but discusses how implementation would differ in 1.2. For someone starting out developing in JSF, I'd recommend this book in combination with the strong survey of JSF in JavaServer Faces by Hans Bergsten.
