Re: [VOTE] Upgrade s:limitRendered to tomahawk
On Tue, 2008-07-01 at 18:44 -0500, Leonardo Uribe wrote: On Tue, Jul 1, 2008 at 6:18 PM, Mike Kienenberger [EMAIL PROTECTED] wrote: +1, but I also agree that it should be put into commons rather than Tomahawk if there's no limiting factor. There is one dependency to: org.apache.myfaces.shared_tomahawk.renderkit.RendererUtils Gerhard told me once that some parts of shared should be part of commons utils, doing an api and hide the impl copying shared classes using myfaces-builder-plugin:unpack goal. Another question is where to put it on commons, because there is no myfaces-commons-components module. For now, we have to upgrade it to tomahawk, since the previous ideas need a lot of discussion. What a weird component. I cannot imagine where it would be useful. Andrew, can you give an example of when it could be used? And even better, add that as documentation on the component.. I don't remember seeing a vote for promoting this component myself, and would be -0.2 on promoting it; I just can't imagine where it is useful. But if a promotion vote has already passed with 3 +1s then OK. By the way, the code used from RenderUtils is not much; just the renderChild method (which needs the renderChildren method). It's about 15 lines in total. But I also agree with Leonardo that there is a lot of work to be done in setting up a commons components module and now is not a good time to look into that. So if people really are using this in production then promoting to tomahawk is ok by me (as in no objection, but not +1). Regards, Simon
[jira] Commented: (TRINIDAD-1126) Contention at java.util.regex.Pattern.matcher.
[ https://issues.apache.org/jira/browse/TRINIDAD-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609806#action_12609806 ] Matthias Weßendorf commented on TRINIDAD-1126: -- Looks like this: http://sourceforge.net/tracker/index.php?func=detailaid=1577573group_id=18598atid=118598 is a similar issue Contention at java.util.regex.Pattern.matcher. -- Key: TRINIDAD-1126 URL: https://issues.apache.org/jira/browse/TRINIDAD-1126 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.8-core Reporter: Yuvaraja Srinivasan Priority: Minor Hi , We have carried 100users /5task scalability run and Observed contention issue from the following callstack. HTTPThreadGroup-43 prio=10 tid=0x637a0c20 nid=0x20bf8 waiting for monitor entry [0x6908d000..0x6908fb14] at java.util.regex.Pattern.matcher(Pattern.java:875) - waiting to lock 0x198b3848 (a java.util.regex.Pattern) at org.apache.myfaces.trinidadinternal.style.util.StyleUtils.convertToValidSelector(StyleUtils.java:50) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext.getStyleClass(CoreRenderingContext.java:305) at org.apache.myfaces.trinidad.render.CoreRenderer.renderStyleClass(CoreRenderer.java:643) at oracle.adf.view.rich.render.RichRenderer.renderStyleClass(RichRenderer.java:2002) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectShuttleRenderer._renderShuttleHeader(SimpleSelectShuttleRenderer.java:1104) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectShuttleRenderer._encodeSelectItemsContainer(SimpleSelectShuttleRenderer.java:666) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectShuttleRenderer.encodeElementContent(SimpleSelectShuttleRenderer.java:403) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectBaseRenderer._renderContent(SimpleSelectBaseRenderer.java:214) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectBaseRenderer.renderElementContent(SimpleSelectBaseRenderer.java:112) at oracle.adfinternal.view.faces.renderkit.rich.FormInputRenderer.encodeAllAsElement(FormInputRenderer.java:129) at oracle.adfinternal.view.faces.renderkit.rich.FormElementRenderer.encodeAll(FormElementRenderer.java:133) at oracle.adf.view.rich.render.RichRenderer.delegateRenderer(RichRenderer.java:1070) at oracle.adfinternal.view.faces.renderkit.rich.LabeledInputRenderer.renderFieldCellContents(LabeledInputRenderer.java:172) at oracle.adfinternal.view.faces.renderkit.rich.LabeledInputRenderer.encodeAll(LabeledInputRenderer.java:154) at oracle.adf.view.rich.render.RichRenderer.encodeAll(RichRenderer.java:1034) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:751) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:304) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer._encodeChild(PanelGroupLayoutRenderer.java:372) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer.access$300(PanelGroupLayoutRenderer.java:30) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer$EncoderCallback.processComponent(PanelGroupLayoutRenderer.java:621) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer$EncoderCallback.processComponent(PanelGroupLayoutRenderer.java:540) at org.apache.myfaces.trinidad.component.UIXComponent.processFlattenedChildren(UIXComponent.java:111) at org.apache.myfaces.trinidad.component.UIXComponent.processFlattenedChildren(UIXComponent.java:187) at org.apache.myfaces.trinidad.component.UIXComponent.processFlattenedChildren(UIXComponent.java:153) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer.encodeAll(PanelGroupLayoutRenderer.java:292) at oracle.adf.view.rich.render.RichRenderer.encodeAll(RichRenderer.java:1034) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:751) at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1339) at org.apache.myfaces.trinidad.component.UIXSwitcher.encodeChildren(UIXSwitcher.java:154) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:291) at
[jira] Commented: (TRINIDAD-1126) Contention at java.util.regex.Pattern.matcher.
[ https://issues.apache.org/jira/browse/TRINIDAD-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609807#action_12609807 ] Matthias Weßendorf commented on TRINIDAD-1126: -- see here: http://osdir.com/ml/java.grinder.user/2006-10/msg00017.html Contention at java.util.regex.Pattern.matcher. -- Key: TRINIDAD-1126 URL: https://issues.apache.org/jira/browse/TRINIDAD-1126 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.8-core Reporter: Yuvaraja Srinivasan Priority: Minor Hi , We have carried 100users /5task scalability run and Observed contention issue from the following callstack. HTTPThreadGroup-43 prio=10 tid=0x637a0c20 nid=0x20bf8 waiting for monitor entry [0x6908d000..0x6908fb14] at java.util.regex.Pattern.matcher(Pattern.java:875) - waiting to lock 0x198b3848 (a java.util.regex.Pattern) at org.apache.myfaces.trinidadinternal.style.util.StyleUtils.convertToValidSelector(StyleUtils.java:50) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext.getStyleClass(CoreRenderingContext.java:305) at org.apache.myfaces.trinidad.render.CoreRenderer.renderStyleClass(CoreRenderer.java:643) at oracle.adf.view.rich.render.RichRenderer.renderStyleClass(RichRenderer.java:2002) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectShuttleRenderer._renderShuttleHeader(SimpleSelectShuttleRenderer.java:1104) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectShuttleRenderer._encodeSelectItemsContainer(SimpleSelectShuttleRenderer.java:666) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectShuttleRenderer.encodeElementContent(SimpleSelectShuttleRenderer.java:403) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectBaseRenderer._renderContent(SimpleSelectBaseRenderer.java:214) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectBaseRenderer.renderElementContent(SimpleSelectBaseRenderer.java:112) at oracle.adfinternal.view.faces.renderkit.rich.FormInputRenderer.encodeAllAsElement(FormInputRenderer.java:129) at oracle.adfinternal.view.faces.renderkit.rich.FormElementRenderer.encodeAll(FormElementRenderer.java:133) at oracle.adf.view.rich.render.RichRenderer.delegateRenderer(RichRenderer.java:1070) at oracle.adfinternal.view.faces.renderkit.rich.LabeledInputRenderer.renderFieldCellContents(LabeledInputRenderer.java:172) at oracle.adfinternal.view.faces.renderkit.rich.LabeledInputRenderer.encodeAll(LabeledInputRenderer.java:154) at oracle.adf.view.rich.render.RichRenderer.encodeAll(RichRenderer.java:1034) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:751) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:304) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer._encodeChild(PanelGroupLayoutRenderer.java:372) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer.access$300(PanelGroupLayoutRenderer.java:30) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer$EncoderCallback.processComponent(PanelGroupLayoutRenderer.java:621) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer$EncoderCallback.processComponent(PanelGroupLayoutRenderer.java:540) at org.apache.myfaces.trinidad.component.UIXComponent.processFlattenedChildren(UIXComponent.java:111) at org.apache.myfaces.trinidad.component.UIXComponent.processFlattenedChildren(UIXComponent.java:187) at org.apache.myfaces.trinidad.component.UIXComponent.processFlattenedChildren(UIXComponent.java:153) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer.encodeAll(PanelGroupLayoutRenderer.java:292) at oracle.adf.view.rich.render.RichRenderer.encodeAll(RichRenderer.java:1034) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:751) at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1339) at org.apache.myfaces.trinidad.component.UIXSwitcher.encodeChildren(UIXSwitcher.java:154) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:291) at org.apache.myfaces.trinidadinternal.renderkit.html.RowLayoutRenderer.encodeChild(RowLayoutRenderer.java:116) at
[TRINIDAD]Java Script not executing on calling Service's addScript method
Hi,
I created a JSF Page with a tr:commandButton in it. Inside its action method I
wrote the following code:-
public String action(){
ExtendedRenderKitService service=
Service.getRenderKitService(FacesContext.getCurrentInsatnce(),ExtendedRenderKitService.class
);
service.addScript(FacesContext.getCurrentInsatnce(),alert( ' hello Trinidad '
););
}
This was supposed to open a Windows alert box with hello trinidad written on
clicking the command Button.
But Nothing happens on doing so!!! What am I doing wrong??? PL. help!
Thanks,
Dushyant
Bollywood, fun, friendship, sports and more. You name it, we have it on
http://in.promos.yahoo.com/groups/bestofyahoo/
EnumConverter in commons 1.1 branch
Hi, Leonardo has just deleted the EnumConverter from the jsf1.1 branch of commons. This converter was the reason for me to use a snapshot version in our production application. Is it really necessary to have the commons jsf1.1 branch java 1.4 compatible? I know jsf1.1 is, but commons is an extension, so why should we restrict commons? We may provide a retroweaved (if this is possible with this Converter) release for 1.4 users, as we do for tobago. Regards, Volker -- inexso - information exchange solutions GmbH Bismarckstraße 13 | 26122 Oldenburg Tel.: +49 441 4082 356 | FAX: +49 441 4082 355 | www.inexso.de
Re: EnumConverter in commons 1.1 branch
Volker Weber schrieb: Hi, Leonardo has just deleted the EnumConverter from the jsf1.1 branch of commons. This converter was the reason for me to use a snapshot version in our production application. Is it really necessary to have the commons jsf1.1 branch java 1.4 compatible? I know jsf1.1 is, but commons is an extension, so why should we restrict commons? We may provide a retroweaved (if this is possible with this Converter) release for 1.4 users, as we do for tobago. I think we really *should* have commons-1.1 compatible with java1.4. Setting up retroweaver, etc. is a pain in the butt. So if *you* (Volker) can provide a clean and simple patch to get this working, fine. But otherwise I'm happy with removing EnumConverter from commons1.1. You can always build the EnumConverter yourself, however you wish. Regards, Simon
Re: EnumConverter in commons 1.1 branch
On Wed, Jul 2, 2008 at 10:19 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Volker Weber schrieb: Hi, Leonardo has just deleted the EnumConverter from the jsf1.1 branch of commons. This converter was the reason for me to use a snapshot version in our production application. Is it really necessary to have the commons jsf1.1 branch java 1.4 compatible? I know jsf1.1 is, but commons is an extension, so why should we restrict commons? We may provide a retroweaved (if this is possible with this Converter) release for 1.4 users, as we do for tobago. I think we really *should* have commons-1.1 compatible with java1.4. I think that this is not necessary. Trinidad 1.0.x (which is the JSF 1.1 version) supports only Java5. Setting up retroweaver, etc. is a pain in the butt. So if *you* (Volker) can provide a clean and simple patch to get this working, fine. But otherwise I'm happy with removing EnumConverter from commons1.1. just because of JSF 1.1 uses outdated Java version? -M -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: EnumConverter in commons 1.1 branch
Matthias Wessendorf schrieb: On Wed, Jul 2, 2008 at 10:19 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Volker Weber schrieb: Hi, Leonardo has just deleted the EnumConverter from the jsf1.1 branch of commons. This converter was the reason for me to use a snapshot version in our production application. Is it really necessary to have the commons jsf1.1 branch java 1.4 compatible? I know jsf1.1 is, but commons is an extension, so why should we restrict commons? We may provide a retroweaved (if this is possible with this Converter) release for 1.4 users, as we do for tobago. I think we really *should* have commons-1.1 compatible with java1.4. I think that this is not necessary. Trinidad 1.0.x (which is the JSF 1.1 version) supports only Java5. Setting up retroweaver, etc. is a pain in the butt. So if *you* (Volker) can provide a clean and simple patch to get this working, fine. But otherwise I'm happy with removing EnumConverter from commons1.1. just because of JSF 1.1 uses outdated Java version? I may have spoken too soon. For myfaces core 1.1.x I think we should definitely stay with -source 1.4 -target 1.4 options. There won't be a whole lot of people running it on java1.4, but we currently support it so should stay with it. I guess that commons-1.1.x *could* be run by different rules. It is new, so we won't break any existing users if java15 is set as the minimum. Pros for java15 as minimum in commons-1.1: * can have EnumConverter * internal code can be cleaner * ??? Cons: * some users stuck on JSF1.1 + java14 might not be able to use the new lib. * ??? Anyone else got pros/cons? I can't think of anything particularly convincing either way.. Regards, Simon
[jira] Resolved: (TOMAHAWK-1266) t:stylesheet renders link to an empty page on tomcat-5.5.24 and above
[ https://issues.apache.org/jira/browse/TOMAHAWK-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Kitching resolved TOMAHAWK-1266. -- Resolution: Fixed I've now committed the patch. The t:stylesheet tag now requires an absolute path when used with inline or filtered attributes. The committed solution isn't the perfect solution (see comments in StylesheetRenderer) but should work ok. t:stylesheet renders link to an empty page on tomcat-5.5.24 and above - Key: TOMAHAWK-1266 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1266 Project: MyFaces Tomahawk Issue Type: Bug Components: Stylesheet Affects Versions: 1.1.5 Environment: linux, tomcat, myfaces-1.1.5, tomahawk-1.1.5 Reporter: Ronald Müller Assignee: Leonardo Uribe Fix For: 1.1.7-SNAPSHOT Attachments: stylesheet-patch.txt, StyleTest.war on tomcat-5.5.24 and above (also 6.0.x) t:stylesheet with filter-attribute set to 'true' renders a style-link that links to an empty page. without filtering everything works fine since t:stylesheet renders direct links to the css-files (not using the extension-filter). maybe this issue is related to the extension filter or it is a tomcat-issue only. since it definitely happens first time with tomcat-version 5.5.24. (5.0.x-5.5.23 working fine). i'll provide a minimal test-case as war-file. just deploy and request 'http://localhost:8080/StyleTest/styletest.faces'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1886) Translation is wrong for french
Translation is wrong for french
---
Key: MYFACES-1886
URL: https://issues.apache.org/jira/browse/MYFACES-1886
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.1.5
Environment: Windows 2000, Java 5
Reporter: Frank Bommeli
Priority: Trivial
The following translation is wrong:
javax.faces.convert.DateTimeConverter.CONVERSION = {1} : Conversion de '{0}'
en Date/Heure impossible.
The {0} is surrounded by single quotes ' which makes the text to not being
replaces.
Removing the quotes, solves the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1126) Contention at java.util.regex.Pattern.matcher.
[ https://issues.apache.org/jira/browse/TRINIDAD-1126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12609937#action_12609937 ] Matthias Weßendorf commented on TRINIDAD-1126: -- looks like the real issue is the synchronized in matcher(). Which is fixed in Java7: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6436458 Contention at java.util.regex.Pattern.matcher. -- Key: TRINIDAD-1126 URL: https://issues.apache.org/jira/browse/TRINIDAD-1126 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.8-core Reporter: Yuvaraja Srinivasan Priority: Minor Hi , We have carried 100users /5task scalability run and Observed contention issue from the following callstack. HTTPThreadGroup-43 prio=10 tid=0x637a0c20 nid=0x20bf8 waiting for monitor entry [0x6908d000..0x6908fb14] at java.util.regex.Pattern.matcher(Pattern.java:875) - waiting to lock 0x198b3848 (a java.util.regex.Pattern) at org.apache.myfaces.trinidadinternal.style.util.StyleUtils.convertToValidSelector(StyleUtils.java:50) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext.getStyleClass(CoreRenderingContext.java:305) at org.apache.myfaces.trinidad.render.CoreRenderer.renderStyleClass(CoreRenderer.java:643) at oracle.adf.view.rich.render.RichRenderer.renderStyleClass(RichRenderer.java:2002) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectShuttleRenderer._renderShuttleHeader(SimpleSelectShuttleRenderer.java:1104) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectShuttleRenderer._encodeSelectItemsContainer(SimpleSelectShuttleRenderer.java:666) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectShuttleRenderer.encodeElementContent(SimpleSelectShuttleRenderer.java:403) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectBaseRenderer._renderContent(SimpleSelectBaseRenderer.java:214) at oracle.adfinternal.view.faces.renderkit.rich.SimpleSelectBaseRenderer.renderElementContent(SimpleSelectBaseRenderer.java:112) at oracle.adfinternal.view.faces.renderkit.rich.FormInputRenderer.encodeAllAsElement(FormInputRenderer.java:129) at oracle.adfinternal.view.faces.renderkit.rich.FormElementRenderer.encodeAll(FormElementRenderer.java:133) at oracle.adf.view.rich.render.RichRenderer.delegateRenderer(RichRenderer.java:1070) at oracle.adfinternal.view.faces.renderkit.rich.LabeledInputRenderer.renderFieldCellContents(LabeledInputRenderer.java:172) at oracle.adfinternal.view.faces.renderkit.rich.LabeledInputRenderer.encodeAll(LabeledInputRenderer.java:154) at oracle.adf.view.rich.render.RichRenderer.encodeAll(RichRenderer.java:1034) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:751) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:304) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer._encodeChild(PanelGroupLayoutRenderer.java:372) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer.access$300(PanelGroupLayoutRenderer.java:30) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer$EncoderCallback.processComponent(PanelGroupLayoutRenderer.java:621) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer$EncoderCallback.processComponent(PanelGroupLayoutRenderer.java:540) at org.apache.myfaces.trinidad.component.UIXComponent.processFlattenedChildren(UIXComponent.java:111) at org.apache.myfaces.trinidad.component.UIXComponent.processFlattenedChildren(UIXComponent.java:187) at org.apache.myfaces.trinidad.component.UIXComponent.processFlattenedChildren(UIXComponent.java:153) at oracle.adfinternal.view.faces.renderkit.rich.PanelGroupLayoutRenderer.encodeAll(PanelGroupLayoutRenderer.java:292) at oracle.adf.view.rich.render.RichRenderer.encodeAll(RichRenderer.java:1034) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:224) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:751) at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1339) at org.apache.myfaces.trinidad.component.UIXSwitcher.encodeChildren(UIXSwitcher.java:154) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:291) at
Re: [VOTE] Upgrade s:limitRendered to tomahawk
Andrew, can you give an example of when it could be used? Check the documentation and the demo http://example.irian.at/example-sandbox-20080702/limitRendered.jsf http://myfaces.apache.org/sandbox/tlddoc/s/limitRendered.html It states its purpose as a JSF substitute for c:choose/c:when/c:otherwise to avoid JSP tag logic in JSF pages. Guess if you weren't so worried about bottom posting you would have had some time to research the documentation :)?
Re: [VOTE] Upgrade s:limitRendered to tomahawk
Andrew Robinson schrieb: Andrew, can you give an example of when it could be used? Check the documentation and the demo http://example.irian.at/example-sandbox-20080702/limitRendered.jsf http://myfaces.apache.org/sandbox/tlddoc/s/limitRendered.html It states its purpose as a JSF substitute for c:choose/c:when/c:otherwise to avoid JSP tag logic in JSF pages. I did read the javadoc that says this is a substitute for c:choose. But that wasn't helpful to me. In what kind of real-world page would I want to choose to render the first 3 children? Or child 4 and 7? The example page doesn't help much. It is demonstrating the functionality, not showing a real use case. I can possibly see wanting to render one specific child from a set. But even then, would I really want to specify which child via an *integer offset*? That seems to very tightly couple the page layout to the backing bean. Adding a new child component or rearranging them shouldn't affect *which ones* are rendered, but that's what an index-based approach to child selection will do. The traditional approach of a rendered attribute on each child that queries whether *it* needs to be rendered might be a little more verbose, but seems to provide a much more stable division between page and backing bean than having a backing bean method that returns a list of indexes into the child list. You must have had a real use case that pushed you to write this component. Can you please describe it? Regards, Simon
Re: [VOTE] Upgrade s:limitRendered to tomahawk
You must have had a real use case that pushed you to write this component.
Can you please describe it?
The same as all usages of c:choose /. The index based or more than
one are just added benefits I threw in. I can provide examples, but I
shouldn't have to. Just because someone can't think of when it would
be needed, doesn't mean it never would be useful, but I can appease
you curiosity. I created the component so that people would stop using
c:choose and c:if in JSF pages and complain that they don't work in
tables and such.
1) default c:choose functionality (render the first match):
s:limitRendered
h:outputText value=#{person.first} #{person.last}
rendered=#{prefs.firstThenLast} /
h:outputText value=#{person.last}, #{person.first}
rendered=#{prefs.firstThenLast} /
/s:limitRendered
2) render index based. This behaves much like the tr:switcher
component. But instead of using facets and facet names, it uses
s:limitRendered value=#{wizard.currentStep} type=index
h:panelGroup
h:outputText value=This is wizard step 1 /
/h:panelGroup
h:panelGroup
h:outputText value=This is wizard step 2 /
/h:panelGroup
h:panelGroup
h:outputText value=This is wizard step 3 /
/h:panelGroup
/s:limitRendered
h:commandButton action=#{wizard.prev}
rendered=#{wizard.currentStep gt 0} value=Prev /
h:commandButton action=#{wizard.next}
rendered=#{wizard.currentStep lt (wizard.numSteps - 1)} value=Next
/
h:commandButton action=#{wizard.finish}
rendered=#{wizard.currentStep eq (wizard.numSteps - 1)}
value=Finish /
3) render multiple children. Can be used much like -v vs - can
be used for command line verbosity
s:limitRendered value=#{verbosity}
h:outputText value=#{title} /
h:outputText value=#{usage} /
h:outputText value=#{description} /
/s:limitRendered
Now I cannot tell you all the reasons they may be useful, but I can
say that many time in Trinidad authors chose to only provide
functionality that they themselves could think of, making the
component useless for every use case they could not think of. Perhaps
I cannot think of great reasons to render more than one child at the
moment, but who is to say no one will ever want that?
The main use case is to stop this code:
h:outputText value=a rendered=#{value1 eq 'a'} /
h:outputText value=b rendered=#{value1 ne 'a' and value2 eq 'b'} /
h:outputText value=c rendered=#{value1 ne 'a' and value2 ne 'b'
and value3 eq 'c'} /
h:outputText value=otherwise rendered=#{value1 ne 'a' and value2
ne 'b' and value3 ne 'c'} /
etc.
Several times I have had the use case where I only want to render a
component if the previous one was not rendered. To get that
functionality, I always had to negate the test of the rendered of the
previous components then include the test for the current component.
This is much easier to write and definitely to maintain:
s:limitRendered
h:outputText value=a rendered=#{value1 eq 'a'} /
h:outputText value=b rendered=#{value2 eq 'b'} /
h:outputText value=c rendered=#{value3 eq 'c'} /
h:outputText value=otherwise /
/s:limitRendered
So for the most part, every use case in JSP to use c:choose / is a
use case to use limitRendered in JSF. As mentioned, the index based or
multiple support was just added functionality for rare use cases.
-Andrew
Re: [VOTE] Upgrade s:limitRendered to tomahawk
Andrew Robinson schrieb:
You must have had a real use case that pushed you to write this component.
Can you please describe it?
The same as all usages of c:choose /. The index based or more than
one are just added benefits I threw in. I can provide examples, but I
shouldn't have to.
I certainly think all new components should have to provide proper
use-cases. Having very rarely used components in Tomahawk:
* makes it hard for users to find what they want (steeper learning curve)
* increases the maintenance burden
* increases the jarfile size
So components should only go in if they are useful to a reasonable
number of people.
Just because someone can't think of when it would
be needed, doesn't mean it never would be useful, but I can appease
you curiosity.
It's not curiosity. There is a vast amount of crap in Tomahawk right
now, to the point where Tomahawk is close to dying. There hasn't been a
release for a year. The number of open bugs is vast. So everyone
*should* be watching carefully to see that we don't increase the problems.
That doesn't mean that good components cannot be added. But new stuff
does need to be evaluated for usefulness.
And the author of a component is often too close to the code to see
whether it can be improved (that applies equally to me). Having other
people look critically at the purpose and API is very useful. You are
free to point out any issues with components I write (eg Orchestra stuff).
I created the component so that people would stop using
c:choose and c:if in JSF pages and complain that they don't work in
tables and such.
1) default c:choose functionality (render the first match):
s:limitRendered
h:outputText value=#{person.first} #{person.last}
rendered=#{prefs.firstThenLast} /
h:outputText value=#{person.last}, #{person.first}
rendered=#{prefs.firstThenLast} /
/s:limitRendered
Yep, this is a good use case. As you demonstrate later in your email,
writing mutually-exclusive rendered expressions for a set of components
can get nasty.
I'm not a JSTL user, so your reference to c:choose wasn't perhaps as
clear to me as it might be to others. I think this way:
if (cond1) render component 1
else if (cond2) render component 2
else if (cond3) render component 3
else render component 4
Expanding the javadoc for the component a bit would be good, mentioning
that it simplifies rendered expressions for mutually-exclusive
components. The current docs don't mention that the implicit condition
associated with the choose clauses is the rendered expression; it
makes sense once I know what the component is doing but wasn't obvious
at first.
2) render index based. This behaves much like the tr:switcher
component. But instead of using facets and facet names, it uses
s:limitRendered value=#{wizard.currentStep} type=index
h:panelGroup
h:outputText value=This is wizard step 1 /
/h:panelGroup
h:panelGroup
h:outputText value=This is wizard step 2 /
/h:panelGroup
h:panelGroup
h:outputText value=This is wizard step 3 /
/h:panelGroup
/s:limitRendered
I'm not so sure about this. The tr:switcher makes sense to me; it
chooses a component to render by name which will not be easily broken by
page changes, and where the link between what the backing bean EL
expression returns and what facet is selected is clear (the name matches).
Selecting by index has a far smaller set of use-cases I think. And it
can promote code fragility; coupling an index returned by the backing
bean with an array defined in the page has potential for trouble. But
the wizard use-case is an example of a valid use of this functionality.
3) render multiple children. Can be used much like -v vs - can
be used for command line verbosity
s:limitRendered value=#{verbosity}
h:outputText value=#{title} /
h:outputText value=#{usage} /
h:outputText value=#{description} /
/s:limitRendered
Equivalent to this:
h:outputText value=#{title} rendered=#{verbosity =1}/
h:outputText value=#{usage} rendered=#{verbosity =2}/
h:outputText value=#{description} rendered=#{verbosity =3}/
Yes, the limitRendered approach is a little more efficient; only one EL
expression evaluated rather than 3. But any JSF developer understands
the latter, while no-one can understand the limitRendered approach
without looking up the docs first. And a pretty rare use case I would
think. Worth including perhaps if it didn't have any other negatives,
but I think it does: it forces the name of the component to be generic
and the documentation to be complex.
Now I cannot tell you all the reasons they may be useful, but I can
say that many time in Trinidad authors chose to only provide
functionality that they themselves could think of, making the
component useless for every use case they could not think of. Perhaps
I cannot think of great reasons to render more than one child at the
moment, but who is to say no one will ever want that?
Making
cleaning up whitespace in source files
Hi All, In the new checkstyle rules file I enabled checks for tab characters, as the myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the checkstyle report points out a lot of files containing tabs. It's no big deal, but do we want to: (a) disable the checkstyle rule and ignore tabs or (b) fix them? Tabs are a minor nuisance when viewing the source as some tools render 4 spaces, some 8. I've written a simple shellscript that can clean this up very easily, and am happy to do so. The script also removes trailing whitespace from lines, of which we also appear to have quite a lot. But doing this will create some large commit messages and make comparing files with past versions noisier. It can also cause svn conflicts if people have modified files they have not yet committed, unless they run the cleanup script against their own working dir before doing svn update. So, option (a) or (b)? Regards, Simon
Re: cleaning up whitespace in source files
Simon, Do you have a number? How many files do have tab characters? I think (b - fix them) would be the better solution. But only if that does not change every second file. --Manfred On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All, In the new checkstyle rules file I enabled checks for tab characters, as the myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the checkstyle report points out a lot of files containing tabs. It's no big deal, but do we want to: (a) disable the checkstyle rule and ignore tabs or (b) fix them? Tabs are a minor nuisance when viewing the source as some tools render 4 spaces, some 8. I've written a simple shellscript that can clean this up very easily, and am happy to do so. The script also removes trailing whitespace from lines, of which we also appear to have quite a lot. But doing this will create some large commit messages and make comparing files with past versions noisier. It can also cause svn conflicts if people have modified files they have not yet committed, unless they run the cleanup script against their own working dir before doing svn update. So, option (a) or (b)? Regards, Simon -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: EnumConverter in commons 1.1 branch
On Wed, Jul 2, 2008 at 5:01 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Matthias Wessendorf schrieb: On Wed, Jul 2, 2008 at 10:19 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Volker Weber schrieb: Hi, Leonardo has just deleted the EnumConverter from the jsf1.1 branch of commons. This converter was the reason for me to use a snapshot version in our production application. Is it really necessary to have the commons jsf1.1 branch java 1.4 compatible? I know jsf1.1 is, but commons is an extension, so why should we restrict commons? We may provide a retroweaved (if this is possible with this Converter) release for 1.4 users, as we do for tobago. I think we really *should* have commons-1.1 compatible with java1.4. I think that this is not necessary. Trinidad 1.0.x (which is the JSF 1.1 version) supports only Java5. Setting up retroweaver, etc. is a pain in the butt. So if *you* (Volker) can provide a clean and simple patch to get this working, fine. But otherwise I'm happy with removing EnumConverter from commons1.1. just because of JSF 1.1 uses outdated Java version? I may have spoken too soon. For myfaces core 1.1.x I think we should definitely stay with -source 1.4 -target 1.4 options. There won't be a whole lot of people running it on java1.4, but we currently support it so should stay with it. I guess that commons-1.1.x *could* be run by different rules. It is new, so we won't break any existing users if java15 is set as the minimum. Pros for java15 as minimum in commons-1.1: * can have EnumConverter * internal code can be cleaner * ??? Cons: * some users stuck on JSF1.1 + java14 might not be able to use the new lib. * ??? Anyone else got pros/cons? I can't think of anything particularly convincing either way.. Pros: * can have DateRestrictValidator I'll go with java15 as minimum for commons. Regards, Simon
Re: cleaning up whitespace in source files
On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All, In the new checkstyle rules file I enabled checks for tab characters, as the myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the checkstyle report points out a lot of files containing tabs. It's no big deal, but do we want to: (a) disable the checkstyle rule and ignore tabs or (b) fix them? +1 for (b) -M Tabs are a minor nuisance when viewing the source as some tools render 4 spaces, some 8. I've written a simple shellscript that can clean this up very easily, and am happy to do so. The script also removes trailing whitespace from lines, of which we also appear to have quite a lot. But doing this will create some large commit messages and make comparing files with past versions noisier. It can also cause svn conflicts if people have modified files they have not yet committed, unless they run the cleanup script against their own working dir before doing svn update. So, option (a) or (b)? Regards, Simon -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Created: (TRINIDAD-1139) partial submit (for ppr) does not work for content type xhtml (_submitPartialChange() does not submitForm() for xhtml)
partial submit (for ppr) does not work for content type xhtml
(_submitPartialChange() does not submitForm() for xhtml)
---
Key: TRINIDAD-1139
URL: https://issues.apache.org/jira/browse/TRINIDAD-1139
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.8-core
Environment: Mac OS X 10.5.4, Glassfish, JSF1.2, Firefox 3.0, Safari,
3.1.2
Reporter: burghard.w.v.britzke
xhtml rendered pages does not submit forms via _submitPartialChange()
I found the following code snippet in DebugCommon1_2_8.js in function
_submitPartialChange()
9176 // Get the actual form object
9177 if ((typeof form) == string)
9178 form = document[form];
9179
9180 if (!form)
9181 return false;
9182
the expression document[form] returns -- undefined for xhtml documents
so this function exits always without submitting.
my sample document
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titletest/title
/head
body onload=alert(document['formid']+' '+document.getElementById('formid'))
form id=formid action=test.html/form
/body
/html
alerts the following message: undefined [object HTMLFormElement]
there are other places where document[form] is used in DebugScript1_2_8.js
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: cleaning up whitespace in source files
Interesting question, Manfred. Here are the answers: Count of java files is done via: find . -name .svn -prune -o -name target -prune \ -o -name *.java -print | wc -l Count of java files with tabs is done by running detab1.sh (which just fixes tabs) then: svn status | grep ^M | wc -l Count of java files with tabs or trailing whitespace is done by running detab.sh then svn status as above. shared/trunk: # of java files: 396 # of files with tabs: 25 # of files with tabs/trailing spaces: 51 shared/trunk12: # of java files: 390 # of files with tabs: 31 # of files with tabs/trailing spaces: 133 core/trunk: # of java files: 351 # of files with tabs: 78 # of files with tabs/trailing spaces: 216 core/trunk12: # of java files: 503 # of files with tabs: 120 # of files with tabs/trailing spaces: 385 It's interesting how many more classes there are in jsf1.2 than in jsf1.1. Some of this is due to more unit tests, but much appears to be real new classes needed to implement the extended spec. On Wed, 2008-07-02 at 20:12 +0200, Manfred Geiler wrote: Simon, Do you have a number? How many files do have tab characters? I think (b - fix them) would be the better solution. But only if that does not change every second file. --Manfred On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All, In the new checkstyle rules file I enabled checks for tab characters, as the myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the checkstyle report points out a lot of files containing tabs. It's no big deal, but do we want to: (a) disable the checkstyle rule and ignore tabs or (b) fix them? Tabs are a minor nuisance when viewing the source as some tools render 4 spaces, some 8. I've written a simple shellscript that can clean this up very easily, and am happy to do so. The script also removes trailing whitespace from lines, of which we also appear to have quite a lot. But doing this will create some large commit messages and make comparing files with past versions noisier. It can also cause svn conflicts if people have modified files they have not yet committed, unless they run the cleanup script against their own working dir before doing svn update. So, option (a) or (b)? Regards, Simon
[jira] Commented: (TRINIDAD-1139) partial submit (for ppr) does not work for content type xhtml (_submitPartialChange() does not submitForm() for xhtml)
[
https://issues.apache.org/jira/browse/TRINIDAD-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610029#action_12610029
]
Matthias Weßendorf commented on TRINIDAD-1139:
--
how come that there is no name on form?
what is the actual content of the faces page ?
Like how did the source look like.
The HTML above is the reason, why there is undefined.
But I don't get why there is no name rendered on the form...
partial submit (for ppr) does not work for content type xhtml
(_submitPartialChange() does not submitForm() for xhtml)
---
Key: TRINIDAD-1139
URL: https://issues.apache.org/jira/browse/TRINIDAD-1139
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.8-core
Environment: Mac OS X 10.5.4, Glassfish, JSF1.2, Firefox 3.0, Safari,
3.1.2
Reporter: burghard.w.v.britzke
Original Estimate: 168h
Remaining Estimate: 168h
xhtml rendered pages does not submit forms via _submitPartialChange()
I found the following code snippet in DebugCommon1_2_8.js in function
_submitPartialChange()
9176 // Get the actual form object
9177 if ((typeof form) == string)
9178 form = document[form];
9179
9180 if (!form)
9181 return false;
9182
the expression document[form] returns -- undefined for xhtml documents
so this function exits always without submitting.
my sample document
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titletest/title
/head
body onload=alert(document['formid']+'
'+document.getElementById('formid'))
form id=formid action=test.html/form
/body
/html
alerts the following message: undefined [object HTMLFormElement]
there are other places where document[form] is used in DebugScript1_2_8.js
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-687) Readonly support for tc:selectOneRadio
Readonly support for tc:selectOneRadio -- Key: TOBAGO-687 URL: https://issues.apache.org/jira/browse/TOBAGO-687 Project: MyFaces Tobago Issue Type: Improvement Components: Themes Affects Versions: 1.0.17 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Fix For: 1.0.18, 1.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1139) partial submit (for ppr) does not work for content type xhtml (_submitPartialChange() does not submitForm() for xhtml)
[
https://issues.apache.org/jira/browse/TRINIDAD-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610047#action_12610047
]
Matthias Weßendorf commented on TRINIDAD-1139:
--
to be clear.
document[form] = document[nameOfMyForm], like form name=nameOfMyForm.
document.forms[id]= document.forms[idOfMyForm], like form id=idOfMyForm.
I think the JSF 1.2 spec requires rendering id and name.
partial submit (for ppr) does not work for content type xhtml
(_submitPartialChange() does not submitForm() for xhtml)
---
Key: TRINIDAD-1139
URL: https://issues.apache.org/jira/browse/TRINIDAD-1139
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.8-core
Environment: Mac OS X 10.5.4, Glassfish, JSF1.2, Firefox 3.0, Safari,
3.1.2
Reporter: burghard.w.v.britzke
Original Estimate: 168h
Remaining Estimate: 168h
xhtml rendered pages does not submit forms via _submitPartialChange()
I found the following code snippet in DebugCommon1_2_8.js in function
_submitPartialChange()
9176 // Get the actual form object
9177 if ((typeof form) == string)
9178 form = document[form];
9179
9180 if (!form)
9181 return false;
9182
the expression document[form] returns -- undefined for xhtml documents
so this function exits always without submitting.
my sample document
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titletest/title
/head
body onload=alert(document['formid']+'
'+document.getElementById('formid'))
form id=formid action=test.html/form
/body
/html
alerts the following message: undefined [object HTMLFormElement]
there are other places where document[form] is used in DebugScript1_2_8.js
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: cleaning up whitespace in source files
+1 for b Regards Bernd Matthias Wessendorf schrieb: On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi All, In the new checkstyle rules file I enabled checks for tab characters, as the myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the checkstyle report points out a lot of files containing tabs. It's no big deal, but do we want to: (a) disable the checkstyle rule and ignore tabs or (b) fix them? +1 for (b) -M Tabs are a minor nuisance when viewing the source as some tools render 4 spaces, some 8. I've written a simple shellscript that can clean this up very easily, and am happy to do so. The script also removes trailing whitespace from lines, of which we also appear to have quite a lot. But doing this will create some large commit messages and make comparing files with past versions noisier. It can also cause svn conflicts if people have modified files they have not yet committed, unless they run the cleanup script against their own working dir before doing svn update. So, option (a) or (b)? Regards, Simon
[jira] Commented: (TRINIDAD-1139) partial submit (for ppr) does not work for content type xhtml (_submitPartialChange() does not submitForm() for xhtml)
[
https://issues.apache.org/jira/browse/TRINIDAD-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610057#action_12610057
]
burghard.w.v.britzke commented on TRINIDAD-1139:
there is an id attribut and! a name attribute on the rendered form. this issue
does not depend on the absense of either attribute. I produced it with a simple
jsp which is to render xhtml (I attached it to this issue).
partial submit (for ppr) does not work for content type xhtml
(_submitPartialChange() does not submitForm() for xhtml)
---
Key: TRINIDAD-1139
URL: https://issues.apache.org/jira/browse/TRINIDAD-1139
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.8-core
Environment: Mac OS X 10.5.4, Glassfish, JSF1.2, Firefox 3.0, Safari,
3.1.2
Reporter: burghard.w.v.britzke
Original Estimate: 168h
Remaining Estimate: 168h
xhtml rendered pages does not submit forms via _submitPartialChange()
I found the following code snippet in DebugCommon1_2_8.js in function
_submitPartialChange()
9176 // Get the actual form object
9177 if ((typeof form) == string)
9178 form = document[form];
9179
9180 if (!form)
9181 return false;
9182
the expression document[form] returns -- undefined for xhtml documents
so this function exits always without submitting.
my sample document
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titletest/title
/head
body onload=alert(document['formid']+'
'+document.getElementById('formid'))
form id=formid action=test.html/form
/body
/html
alerts the following message: undefined [object HTMLFormElement]
there are other places where document[form] is used in DebugScript1_2_8.js
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Upgrade s:limitRendered to tomahawk
What Simon proposed makes a lot of sense to me.
On Wed, Jul 2, 2008 at 1:18 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Andrew Robinson schrieb:
You must have had a real use case that pushed you to write this
component.
Can you please describe it?
The same as all usages of c:choose /. The index based or more than
one are just added benefits I threw in. I can provide examples, but I
shouldn't have to.
I certainly think all new components should have to provide proper
use-cases. Having very rarely used components in Tomahawk:
* makes it hard for users to find what they want (steeper learning curve)
* increases the maintenance burden
* increases the jarfile size
So components should only go in if they are useful to a reasonable number of
people.
Just because someone can't think of when it would
be needed, doesn't mean it never would be useful, but I can appease
you curiosity.
It's not curiosity. There is a vast amount of crap in Tomahawk right now, to
the point where Tomahawk is close to dying. There hasn't been a release for
a year. The number of open bugs is vast. So everyone *should* be watching
carefully to see that we don't increase the problems.
That doesn't mean that good components cannot be added. But new stuff does
need to be evaluated for usefulness.
And the author of a component is often too close to the code to see whether
it can be improved (that applies equally to me). Having other people look
critically at the purpose and API is very useful. You are free to point out
any issues with components I write (eg Orchestra stuff).
I created the component so that people would stop using
c:choose and c:if in JSF pages and complain that they don't work in
tables and such.
1) default c:choose functionality (render the first match):
s:limitRendered
h:outputText value=#{person.first} #{person.last}
rendered=#{prefs.firstThenLast} /
h:outputText value=#{person.last}, #{person.first}
rendered=#{prefs.firstThenLast} /
/s:limitRendered
Yep, this is a good use case. As you demonstrate later in your email,
writing mutually-exclusive rendered expressions for a set of components can
get nasty.
I'm not a JSTL user, so your reference to c:choose wasn't perhaps as clear
to me as it might be to others. I think this way:
if (cond1) render component 1
else if (cond2) render component 2
else if (cond3) render component 3
else render component 4
Expanding the javadoc for the component a bit would be good, mentioning that
it simplifies rendered expressions for mutually-exclusive components. The
current docs don't mention that the implicit condition associated with the
choose clauses is the rendered expression; it makes sense once I know what
the component is doing but wasn't obvious at first.
2) render index based. This behaves much like the tr:switcher
component. But instead of using facets and facet names, it uses
s:limitRendered value=#{wizard.currentStep} type=index
h:panelGroup
h:outputText value=This is wizard step 1 /
/h:panelGroup
h:panelGroup
h:outputText value=This is wizard step 2 /
/h:panelGroup
h:panelGroup
h:outputText value=This is wizard step 3 /
/h:panelGroup
/s:limitRendered
I'm not so sure about this. The tr:switcher makes sense to me; it chooses a
component to render by name which will not be easily broken by page changes,
and where the link between what the backing bean EL expression returns and
what facet is selected is clear (the name matches).
Selecting by index has a far smaller set of use-cases I think. And it can
promote code fragility; coupling an index returned by the backing bean with
an array defined in the page has potential for trouble. But the wizard
use-case is an example of a valid use of this functionality.
3) render multiple children. Can be used much like -v vs - can
be used for command line verbosity
s:limitRendered value=#{verbosity}
h:outputText value=#{title} /
h:outputText value=#{usage} /
h:outputText value=#{description} /
/s:limitRendered
Equivalent to this:
h:outputText value=#{title} rendered=#{verbosity =1}/
h:outputText value=#{usage} rendered=#{verbosity =2}/
h:outputText value=#{description} rendered=#{verbosity =3}/
Yes, the limitRendered approach is a little more efficient; only one EL
expression evaluated rather than 3. But any JSF developer understands the
latter, while no-one can understand the limitRendered approach without
looking up the docs first. And a pretty rare use case I would think. Worth
including perhaps if it didn't have any other negatives, but I think it
does: it forces the name of the component to be generic and the
documentation to be complex.
Now I cannot tell you all the reasons they may be useful, but I can
say that many time in Trinidad authors chose to only provide
functionality that they themselves could think of, making the
component useless for every use case they could not think of.
[jira] Issue Comment Edited: (TRINIDAD-1139) partial submit (for ppr) does not work for content type xhtml (_submitPartialChange() does not submitForm() for xhtml)
[
https://issues.apache.org/jira/browse/TRINIDAD-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610057#action_12610057
]
bubi edited comment on TRINIDAD-1139 at 7/2/08 3:18 PM:
there is an id attribut and! a name attribute on the rendered form. this issue
does not depend on the absence of either attribute. I produced it with a simple
jsp which is to render xhtml (I attached it to this issue).
was (Author: bubi):
there is an id attribut and! a name attribute on the rendered form. this
issue does not depend on the absense of either attribute. I produced it with a
simple jsp which is to render xhtml (I attached it to this issue).
partial submit (for ppr) does not work for content type xhtml
(_submitPartialChange() does not submitForm() for xhtml)
---
Key: TRINIDAD-1139
URL: https://issues.apache.org/jira/browse/TRINIDAD-1139
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.8-core
Environment: Mac OS X 10.5.4, Glassfish, JSF1.2, Firefox 3.0, Safari,
3.1.2
Reporter: burghard.w.v.britzke
Attachments: test.jspx
Original Estimate: 168h
Remaining Estimate: 168h
xhtml rendered pages does not submit forms via _submitPartialChange()
I found the following code snippet in DebugCommon1_2_8.js in function
_submitPartialChange()
9176 // Get the actual form object
9177 if ((typeof form) == string)
9178 form = document[form];
9179
9180 if (!form)
9181 return false;
9182
the expression document[form] returns -- undefined for xhtml documents
so this function exits always without submitting.
my sample document
?xml version=1.0 encoding=UTF-8 ?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
head
titletest/title
/head
body onload=alert(document['formid']+'
'+document.getElementById('formid'))
form id=formid action=test.html/form
/body
/html
alerts the following message: undefined [object HTMLFormElement]
there are other places where document[form] is used in DebugScript1_2_8.js
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ANNOUNCE] Podcast with Ted Goddard of ICEsoft
Hello, Believe it or not, JSFCentral has more content :-). We just posted an interview with ICEsoft senior architect Ted Goddard. It was recorded in May of 2007 at the JavaOne conference in San Francisco, CA. Here's an excerpt: Kito: Okay, so you talk about Ajax Framework and Ajax Push, let' s talk about the Ajax Framework part. Is ICEfaces a component suite or framework or both? Ted: It' s both really. ICEfaces starts off with an architecture for updating the page. Once you have the ability to generally update the page, you start using a technique we call Direct-to-DOM rendering. Then you can build a bunch of interesting components around that. We also make use of some JavaScript libraries like Prototype and Script.aculo.us so that we can expose the capabilities of Script.aculo.us to the developer. Script.aculo.us is a really nice JavaScript API but what if you are not a JavaScript developer? Then you need a nice Java API for working with Script.aculo.us, so what we do is provide Script.aculo.us effects modeled in JSF so that the JSF developer can have drag and drop and effects capabilities. Kito: You mentioned Direct-to-DOM techniques, what is that? Ted: Direct-to-DOM is the technique that ICEfaces uses to render the JSF components. The way it works is, instead of rendering to a stream as JSF normally would, ICEfaces components render into a document object model on the server. That allows us to efficiently detect just the changes to that DOM and send just the changes down to the browser. The ability to send just the changes to a browser page is one of the key user interface features of Ajax. When you interact with an Ajax application, you don' t want a full page refresh, you just want the page to be updated in place. This change detection through the Document Object Model on the server is a very effective way to do that. Read the full article or download the podcast here: http://www.jsfcentral.com/articles/goddard-06-08.html. ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com/ http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.jsfcentral.com/ http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988 Come to the first annual JSFOne Conference this September! Visit http://www.jsfone.com for details.
[jira] Commented: (MYFACES-1740) NullPointer exception in ErrorPageWriter
[ https://issues.apache.org/jira/browse/MYFACES-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610115#action_12610115 ] Leonardo Uribe commented on MYFACES-1740: - I have checked in deep this issue and the check is fine, since while exists UIViewRoot component to be scanned, all children must be instances of UIComponent (all components inherits from UIComponent). I'll close this issue as fixed, but first I'll do some test first and see if I can reproduce the error. NullPointer exception in ErrorPageWriter Key: MYFACES-1740 URL: https://issues.apache.org/jira/browse/MYFACES-1740 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.6 Environment: Oracle Application Server 10.1.3.1 Myfaces 1.1.6 + Tomahawk + Ajax4JSF (also happens without the AJAX library) Java 5 In a Suse 9 Box Reporter: Ricardo Ramírez Assignee: Leonardo Uribe Priority: Minor Since I updated to 1.1.6, my error log has a lot of these: java.lang.NullPointerException: javax.faces.webapp._ErrorPageWriter.isText(_ErrorPageWriter.java:344) javax.faces.webapp._ErrorPageWriter.writeComponent(_ErrorPageWriter.java:220) javax.faces.webapp._ErrorPageWriter.debugHtml(_ErrorPageWriter.java:143) javax.faces.webapp._ErrorPageWriter.handleException(_ErrorPageWriter.java:359) javax.faces.webapp.FacesServlet.handleLifecycleException(FacesServlet.java:182) javax.faces.webapp.FacesServlet.service(FacesServlet.java:145) com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:64) I'm sorry, I've tried reproduced the problem, but I can't. In my single-machine installation, it works fine. Once I load it in the productions servers, with 100+ concurrent users, I start getting this issue. The application itself works fine, and the users haven't reported an unavailable service, but i get like 20 or so of this exceptions daily. Any chance that at line 344 of ErrorPageWriter: return (c.getClass().getName().startsWith(com.sun.facelets.compiler)); would be changed to: return c != null (c.getClass().getName().startsWith(com.sun.facelets.compiler)); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1887) Print Multiple exceptions information thrown on update model
Print Multiple exceptions information thrown on update model
Key: MYFACES-1887
URL: https://issues.apache.org/jira/browse/MYFACES-1887
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 1.2.3, 1.1.6-SNAPSHOT
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
When update model phase is executed, if multiple error occur when setting the
values (could occur when a value is set to a EL expression), the errors should
be added to the org.apache.myfaces.errorHandling.exceptionList, so the
FacesServlet can manage it properly like this:
Exception while ...message 1..
Exception while ...message 2..
Caused by:
cause 1...
cause 2...
.stackTrace 1.
.stackTrace 2.
Checking the code there is some errors like this (class UIInput myfaces core
1.1.5):
private void queueExceptionInRequest(FacesContext context, ValueBinding
binding, Exception e) {
List li = (List)
context.getExternalContext().getRequestMap().get(ERROR_HANDLING_EXCEPTION_LIST);
if(null==li) {
li = new ArrayList();
context.getExternalContext().getRequestMap().put(ERROR_HANDLING_EXCEPTION_LIST,
li);
li.add(new FacesException(Exception while setting value for
expression : +
binding.getExpressionString()+ of component with path :
+ _ComponentUtils.getPathToComponent(this),e));
}
}
Note the bad closing '}', it causes that previous errors be lost.
The idea is add a method to be called from FacesServlet like this:
class _ErrorPageWriter
public static void handleExceptionList(FacesContext facesContext, List
exceptionList) throws ServletException, IOException {
...handle it..
}
if no method on custom ErrorPageWriter is defined, the old way is used (just
show the first exception).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1888) catch Throwable errors when using ErrorPageWriter (myfaces error handling)
[
https://issues.apache.org/jira/browse/MYFACES-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-1888:
Status: Patch Available (was: Open)
catch Throwable errors when using ErrorPageWriter (myfaces error handling)
--
Key: MYFACES-1888
URL: https://issues.apache.org/jira/browse/MYFACES-1888
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 1.1.6-SNAPSHOT, 1.2.3
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: patchHandleErrorListUpdatePhase11.patch
One possible enhancement to the myfaces error handling capability is catch
Throwable errors when using myfaces error handling.
This should be done taking into account what the spec says about it:
- Call the execute() method of the saved Lifecycle instance, passing the
FacesContext instance for this request as a parameter. If the execute()
method throws a FacesException, re-throw it as a ServletException with
the FacesException as the root cause.
Call the render() method of the saved Lifecycle instance, passing the
FacesContext instance for this request as a parameter. If the render() method
throws a FacesException, re-throw
The idea is catch and rethrow non Exception classes like errors (extends from
Throwable or Error classes directly). If Myfaces error handling is used use
it to show the error page with the info, taking into account that not all
info could be available.
The idea is do this on FacesServlet:
try {
_lifecycle.execute(facesContext);
if (!handleQueuedExceptions(facesContext))
{
_lifecycle.render(facesContext);
}
}
catch (Exception e)
{
handleLifecycleException(facesContext, e);
}
catch (Throwable e)
{
//Handle Error and Throwable error cases (out-of-memory-errors,
).
handleLifecycleThrowable(facesContext, e);
}
finally
{
facesContext.release();
}
Please note that any change should not break old functionality.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1887) Print Multiple exceptions information thrown on update model
[
https://issues.apache.org/jira/browse/MYFACES-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-1887:
Status: Patch Available (was: Open)
Print Multiple exceptions information thrown on update model
Key: MYFACES-1887
URL: https://issues.apache.org/jira/browse/MYFACES-1887
Project: MyFaces Core
Issue Type: Improvement
Affects Versions: 1.1.6-SNAPSHOT, 1.2.3
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: patchHandleErrorListUpdatePhase11.patch,
patchHandleErrorListUpdatePhase12.patch
When update model phase is executed, if multiple error occur when setting the
values (could occur when a value is set to a EL expression), the errors
should be added to the org.apache.myfaces.errorHandling.exceptionList, so the
FacesServlet can manage it properly like this:
Exception while ...message 1..
Exception while ...message 2..
Caused by:
cause 1...
cause 2...
.stackTrace 1.
.stackTrace 2.
Checking the code there is some errors like this (class UIInput myfaces core
1.1.5):
private void queueExceptionInRequest(FacesContext context, ValueBinding
binding, Exception e) {
List li = (List)
context.getExternalContext().getRequestMap().get(ERROR_HANDLING_EXCEPTION_LIST);
if(null==li) {
li = new ArrayList();
context.getExternalContext().getRequestMap().put(ERROR_HANDLING_EXCEPTION_LIST,
li);
li.add(new FacesException(Exception while setting value for
expression : +
binding.getExpressionString()+ of component with path :
+ _ComponentUtils.getPathToComponent(this),e));
}
}
Note the bad closing '}', it causes that previous errors be lost.
The idea is add a method to be called from FacesServlet like this:
class _ErrorPageWriter
public static void handleExceptionList(FacesContext facesContext, List
exceptionList) throws ServletException, IOException {
...handle it..
}
if no method on custom ErrorPageWriter is defined, the old way is used (just
show the first exception).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
