[jira] [Created] (TRINIDAD-2417) Renderer for tr:document directly instantiates Html/Head/Body-Renderer
Daniel Niklas created TRINIDAD-2417:
---
Summary: Renderer for tr:document directly instantiates
Html/Head/Body-Renderer
Key: TRINIDAD-2417
URL: https://issues.apache.org/jira/browse/TRINIDAD-2417
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.1-core
Reporter: Daniel Niklas
Priority: Minor
The {{DocumentRenderer}} instantiates directly the Renderers of html, body and
head. This prevents other Renderers declared in {{faces-config-xml}} to be
used.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2417) Renderer for tr:document directly instantiates Html/Head/Body-Renderer
[ https://issues.apache.org/jira/browse/TRINIDAD-2417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Niklas updated TRINIDAD-2417: Status: Patch Available (was: Open) Renderer for tr:document directly instantiates Html/Head/Body-Renderer Key: TRINIDAD-2417 URL: https://issues.apache.org/jira/browse/TRINIDAD-2417 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Daniel Niklas Priority: Minor Attachments: TRINIDAD-2417-patch-1.txt The DocumentRenderer instantiates directly the Renderers of html, body and head. This prevents other Renderers declared in faces-config-xml to be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2349) TreeRenderer renders duplicate IDs
[ https://issues.apache.org/jira/browse/TRINIDAD-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537757#comment-13537757 ] Daniel Niklas commented on TRINIDAD-2349: - This is the same issue as TRINIDAD-1778. One Issue should be marked as duplicate. TreeRenderer renders duplicate IDs -- Key: TRINIDAD-2349 URL: https://issues.apache.org/jira/browse/TRINIDAD-2349 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Daniel Niklas Priority: Trivial Attachments: TRINIDAD-2349_patch-1.diff The TreeRenderer renders duplicate client IDs. The method #renderStampCell renders the client id of the tree instead of the stamp-id. This problem is logged like the following example: WARNUNG: The id j_idt21 is used more than once -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2351) tr:tree is not skinable
Daniel Niklas created TRINIDAD-2351: --- Summary: tr:tree is not skinable Key: TRINIDAD-2351 URL: https://issues.apache.org/jira/browse/TRINIDAD-2351 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Daniel Niklas The component tr:tree ist not entirely skinable, because there are missing some Skinning-Selectors. Especially there is no selector af|tree. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2351) tr:tree is not skinable
[ https://issues.apache.org/jira/browse/TRINIDAD-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Niklas updated TRINIDAD-2351: Status: Patch Available (was: Open) tr:tree is not skinable - Key: TRINIDAD-2351 URL: https://issues.apache.org/jira/browse/TRINIDAD-2351 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Daniel Niklas Attachments: TRINIDAD-2351_patch-1.diff The component tr:tree ist not entirely skinable, because there are missing some Skinning-Selectors. Especially there is no selector af|tree. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (TRINIDAD-2351) tr:tree is not skinable
[ https://issues.apache.org/jira/browse/TRINIDAD-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13537812#comment-13537812 ] Daniel Niklas edited comment on TRINIDAD-2351 at 12/21/12 12:04 PM: Patch based on http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/trinidad-imp. Patch contains: - new method #getDefaultStyleClass -- returns af|tree - new Skinning-Selectors TREE_STYLE - new Skinning-Selectors TREE_INDENT_STYLE_CLASS - new Skinning-SelectorsTREE_NODE_SPACER_STYLE_CLASS - new Skinning-Selectors TREE_NODE_ICON_CELL - renders width/height of Icons instead of fix value from Renderer (when available) Some notes to the patch: The patch aims to be compatible! The patch does _not_ change rendering of the attributes width and height. This would be a reasonable change too, but it would break compatibility in a certain manner. With the new Skinning-Selectors, you can overwrite these settings (css -- !important). was (Author: dniklas): Patch based on http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/trinidad-imp. Patch contains: - new method #getDefaultStyleClass -- returns af|tree - new Skinning-Selectors TREE_STYLE - new Skinning-Selectors TREE_INDENT_STYLE_CLASS - new Skinning-SelectorsTREE_NODE_SPACER_STYLE_CLASS - new Skinning-Selectors TREE_NODE_ICON_CELL - renders width/height of Icons instead of fix value from Renderer (when available) tr:tree is not skinable - Key: TRINIDAD-2351 URL: https://issues.apache.org/jira/browse/TRINIDAD-2351 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Daniel Niklas Attachments: TRINIDAD-2351_patch-1.diff The component tr:tree ist not entirely skinable, because there are missing some Skinning-Selectors. Especially there is no selector af|tree. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2348) HeadRenderer renders meta tags in wrong order for IE
Daniel Niklas created TRINIDAD-2348:
---
Summary: HeadRenderer renders meta tags in wrong order for IE
Key: TRINIDAD-2348
URL: https://issues.apache.org/jira/browse/TRINIDAD-2348
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.1-core
Reporter: Daniel Niklas
Priority: Minor
Sometimes one have to put {{meta http-equiv=X-UA-Compatible content=IE=xxx
/}} into {{head}} to get a specific document mode in IE. (Details:
http://msdn.microsoft.com/en-us/library/jj676915%28v=vs.85%29.aspx)
This tag *must* be rendered as *first element* (or directly after the title
element). This is _not_ possible, because the HeadRenderer renders
generator-Tag as first meta-tag. This causes the wrong document mode in IE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2348) HeadRenderer renders meta tags in wrong order for IE
[ https://issues.apache.org/jira/browse/TRINIDAD-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13529789#comment-13529789 ] Daniel Niklas commented on TRINIDAD-2348: - test-page: tr:document xmlns=http://www.w3.org/1999/xhtml; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trh=http://myfaces.apache.org/trinidad/html; title=test page f:facet name=metaContainer meta http-equiv=X-UA-Compatible content=IE=edge / /f:facet tr:form tr:panelHeader text=Test-Anwendung: Meine Einstellungen / /tr:form /tr:document Open this page in IE, press F12 check document mode. HeadRenderer renders meta tags in wrong order for IE Key: TRINIDAD-2348 URL: https://issues.apache.org/jira/browse/TRINIDAD-2348 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Daniel Niklas Priority: Minor Sometimes one have to put meta http-equiv=X-UA-Compatible content=IE=xxx / into head to get a specific document mode in IE. (Details: http://msdn.microsoft.com/en-us/library/jj676915%28v=vs.85%29.aspx) This tag *must* be rendered as *first element* (or directly after the title element). This is _not_ possible, because the HeadRenderer renders generator-Tag as first meta-tag. This causes the wrong document mode in IE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2348) HeadRenderer renders meta tags in wrong order for IE
[ https://issues.apache.org/jira/browse/TRINIDAD-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Niklas updated TRINIDAD-2348: Status: Patch Available (was: Open) HeadRenderer renders meta tags in wrong order for IE Key: TRINIDAD-2348 URL: https://issues.apache.org/jira/browse/TRINIDAD-2348 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Daniel Niklas Priority: Minor Attachments: TRINIDAD-2348_patch-1.diff Sometimes one have to put meta http-equiv=X-UA-Compatible content=IE=xxx / into head to get a specific document mode in IE. (Details: http://msdn.microsoft.com/en-us/library/jj676915%28v=vs.85%29.aspx) This tag *must* be rendered as *first element* (or directly after the title element). This is _not_ possible, because the HeadRenderer renders generator-Tag as first meta-tag. This causes the wrong document mode in IE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2349) TreeRenderer renders duplicate IDs
Daniel Niklas created TRINIDAD-2349: --- Summary: TreeRenderer renders duplicate IDs Key: TRINIDAD-2349 URL: https://issues.apache.org/jira/browse/TRINIDAD-2349 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Daniel Niklas Priority: Trivial The TreeRenderer renders duplicate client IDs. The method #renderStampCell renders the client id of the tree instead of the stamp-id. This problem is logged like the following example: WARNUNG: The id j_idt21 is used more than once -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2349) TreeRenderer renders duplicate IDs
[ https://issues.apache.org/jira/browse/TRINIDAD-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Niklas updated TRINIDAD-2349: Status: Patch Available (was: Open) TreeRenderer renders duplicate IDs -- Key: TRINIDAD-2349 URL: https://issues.apache.org/jira/browse/TRINIDAD-2349 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Daniel Niklas Priority: Trivial Attachments: TRINIDAD-2349_patch-1.diff The TreeRenderer renders duplicate client IDs. The method #renderStampCell renders the client id of the tree instead of the stamp-id. This problem is logged like the following example: WARNUNG: The id j_idt21 is used more than once -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-1910) portal: common.js is included serveral times
[ https://issues.apache.org/jira/browse/TRINIDAD-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13020197#comment-13020197 ] Daniel Niklas commented on TRINIDAD-1910: - Hi Scott, i'm not a fan of workarounds, too! On the other side we needed a lot of patches and workarounds to get trinidad working within a poral (ie. PPR). And we have a lot of crucial applications working since 2008! We are very interested in better trinidad-support for portal environment! Perhaps it might be mor useful to consider which versions we could improve. We are planning to migrate to JSF2.0/Portlet2.0. I think here are much more possibilties to improve something like this. What ist the current status of 2.0-APIs and a portal bridge?! A configurable interim solution might be useful, too. portal: common.js is included serveral times Key: TRINIDAD-1910 URL: https://issues.apache.org/jira/browse/TRINIDAD-1910 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.10-core Reporter: Daniel Niklas Attachments: Page.js-trinidad-1910-patch.txt, XhtmlUtils-patch.txt The commons.js is included several times, when you have more than one trinidad-porlet on your portal-site. In XhtmlUtils#writeLibImport there is a mechanism to prevent including javascript libs more than one time (portal environment). This mechanism is not working, when you have more than one Trinidad-portlets within different web apps. The problem is, that the key contains the webapp context! Here _uixJSL for example contains: /webapp-one/adf/jsLibs/Common1_0_10.js -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-1910) portal: common.js is included serveral times
[ https://issues.apache.org/jira/browse/TRINIDAD-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13019236#comment-13019236 ] Daniel Niklas commented on TRINIDAD-1910: - TRINIDAD-53 - last activity 12/Jun/07 TRINIDAD-1705 - last activity 03/Feb/10 We are working in portal environment - we need a lot of patches and workarounds for Trinidad! Without this stop gap we are not able to use Trinidad for our productive applications! There seems to be no progress since years. portal: common.js is included serveral times Key: TRINIDAD-1910 URL: https://issues.apache.org/jira/browse/TRINIDAD-1910 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.10-core Reporter: Daniel Niklas Attachments: Page.js-trinidad-1910-patch.txt, XhtmlUtils-patch.txt The commons.js is included several times, when you have more than one trinidad-porlet on your portal-site. In XhtmlUtils#writeLibImport there is a mechanism to prevent including javascript libs more than one time (portal environment). This mechanism is not working, when you have more than one Trinidad-portlets within different web apps. The problem is, that the key contains the webapp context! Here _uixJSL for example contains: /webapp-one/adf/jsLibs/Common1_0_10.js -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-1910) portal: common.js is included serveral times
[ https://issues.apache.org/jira/browse/TRINIDAD-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12909200#action_12909200 ] Daniel Niklas commented on TRINIDAD-1910: - one more comment: this patch only works for portlets using the dame trinidad version! portal: common.js is included serveral times Key: TRINIDAD-1910 URL: https://issues.apache.org/jira/browse/TRINIDAD-1910 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.10-core Reporter: Daniel Niklas Attachments: XhtmlUtils-patch.txt The commons.js is included several times, when you have more than one trinidad-porlet on your portal-site. In XhtmlUtils#writeLibImport there is a mechanism to prevent including javascript libs more than one time (portal environment). This mechanism is not working, when you have more than one Trinidad-portlets within different web apps. The problem is, that the key contains the webapp context! Here _uixJSL for example contains: /webapp-one/adf/jsLibs/Common1_0_10.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1910) portal: common.js is included serveral times
portal: common.js is included serveral times Key: TRINIDAD-1910 URL: https://issues.apache.org/jira/browse/TRINIDAD-1910 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.10-core Reporter: Daniel Niklas The commons.js is included several times, when you have more than one trinidad-porlet on your portal-site. In XhtmlUtils#writeLibImport there is a mechanism to prevent including javascript libs more than one time (portal environment). This mechanism is not working, when you have more than one Trinidad-portlets within different web apps. The problem is, that the key contains the webapp context! Here _uixJSL for example contains: /webapp-one/adf/jsLibs/Common1_0_10.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1910) portal: common.js is included serveral times
[ https://issues.apache.org/jira/browse/TRINIDAD-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908053#action_12908053 ] Daniel Niklas commented on TRINIDAD-1910: - Keep TRINIDAD-53 and TRINIDAD-1705 in mind, this would work, too. The solution for this issues is probably a lot of work... portal: common.js is included serveral times Key: TRINIDAD-1910 URL: https://issues.apache.org/jira/browse/TRINIDAD-1910 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.10-core Reporter: Daniel Niklas The commons.js is included several times, when you have more than one trinidad-porlet on your portal-site. In XhtmlUtils#writeLibImport there is a mechanism to prevent including javascript libs more than one time (portal environment). This mechanism is not working, when you have more than one Trinidad-portlets within different web apps. The problem is, that the key contains the webapp context! Here _uixJSL for example contains: /webapp-one/adf/jsLibs/Common1_0_10.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1910) portal: common.js is included serveral times
[ https://issues.apache.org/jira/browse/TRINIDAD-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Niklas updated TRINIDAD-1910: Status: Patch Available (was: Open) portal: common.js is included serveral times Key: TRINIDAD-1910 URL: https://issues.apache.org/jira/browse/TRINIDAD-1910 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.10-core Reporter: Daniel Niklas The commons.js is included several times, when you have more than one trinidad-porlet on your portal-site. In XhtmlUtils#writeLibImport there is a mechanism to prevent including javascript libs more than one time (portal environment). This mechanism is not working, when you have more than one Trinidad-portlets within different web apps. The problem is, that the key contains the webapp context! Here _uixJSL for example contains: /webapp-one/adf/jsLibs/Common1_0_10.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1910) portal: common.js is included serveral times
[ https://issues.apache.org/jira/browse/TRINIDAD-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12908056#action_12908056 ] Daniel Niklas commented on TRINIDAD-1910: - One comment to my patch: I could not find constants for adf/jsfLibs; Configuration seems to be outdated?! portal: common.js is included serveral times Key: TRINIDAD-1910 URL: https://issues.apache.org/jira/browse/TRINIDAD-1910 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 1.0.10-core Reporter: Daniel Niklas Attachments: XhtmlUtils-patch.txt The commons.js is included several times, when you have more than one trinidad-porlet on your portal-site. In XhtmlUtils#writeLibImport there is a mechanism to prevent including javascript libs more than one time (portal environment). This mechanism is not working, when you have more than one Trinidad-portlets within different web apps. The problem is, that the key contains the webapp context! Here _uixJSL for example contains: /webapp-one/adf/jsLibs/Common1_0_10.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1823) CapabilityMap#put() returns UnsupportedOperationException (instead of throws)
CapabilityMap#put() returns UnsupportedOperationException (instead of throws) - Key: TRINIDAD-1823 URL: https://issues.apache.org/jira/browse/TRINIDAD-1823 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.10-core Reporter: Daniel Niklas Priority: Trivial The method CapabilityMap#put(Object key, Object value) returns an UnsupportedOperationException instead of throwing one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1823) CapabilityMap#put() returns UnsupportedOperationException (instead of throws)
[ https://issues.apache.org/jira/browse/TRINIDAD-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876190#action_12876190 ] Daniel Niklas commented on TRINIDAD-1823: - I noticed that, when trying to extend PortletCapabilities (we have enalbed PPR in our PortletEnvironment). CapabilityMap#put() returns UnsupportedOperationException (instead of throws) - Key: TRINIDAD-1823 URL: https://issues.apache.org/jira/browse/TRINIDAD-1823 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.10-core Reporter: Daniel Niklas Priority: Trivial The method CapabilityMap#put(Object key, Object value) returns an UnsupportedOperationException instead of throwing one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1053) page blocking during request processing
[ https://issues.apache.org/jira/browse/TRINIDAD-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876192#action_12876192 ] Daniel Niklas commented on TRINIDAD-1053: - We have had al lot of problems here, too. We decided to overide the existing mechanism of trinidad. Therefor we're using the blockUI-plugin (jquery, http://jquery.malsup.com/block/). It is working like a charm! To be sure, that there are no concurrent requests, we are checking this on server side, too. There was one problem left: you could do concurrent requests in combination with PPR and tr:selectOneChoice, because you can't get the full control of HTML select-elements. Because of that, we have written our own Renderer for this component. After this enhancement, no more concurrent requests were noticed! page blocking during request processing --- Key: TRINIDAD-1053 URL: https://issues.apache.org/jira/browse/TRINIDAD-1053 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.0.8-core, 1.2.8-core Reporter: Gerhard Petracek it is possible to trigger multiple requests. there are more affected versions, but different behaviours - i just describe the details of 1.x.8-SNAPSHOT: with 1.x.8-SNAPSHOT the situation is a bit better. however, there are still several issues. these issues occur at least with ie and firefox, however, they behave differently. ppr request + ppr requests: after a ppr request is triggered and during it's server-side execution it is possible to trigger (at least) another ppr request (it depends on the browser). the next ppr request can be triggered before the previous one finished, but it gets executed after the previous one was finished. ppr request + conventional/none-ppr requests: a none-ppr request gets executed even though a ppr request is still in progress. if this is the desired behaviour, there should be at least a web.xml parameter for a strict mode. none-ppr request + none-ppr requests: with ie it is possible to trigger requests concurrently (concurrent execution on the server). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1822) partialTrigger to oneself causes warning NO_PPR_CAPABLE_ID_FOUND_FOR_COMPONENT
partialTrigger to oneself causes warning NO_PPR_CAPABLE_ID_FOUND_FOR_COMPONENT
--
Key: TRINIDAD-1822
URL: https://issues.apache.org/jira/browse/TRINIDAD-1822
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.0.10-core
Reporter: Daniel Niklas
Priority: Minor
When you define a partialTrigger to the id of the component oneself, a warning
is logged. Key of the message is NO_PPR_CAPABLE_ID_FOUND_FOR_COMPONENT.
This problem occurs only, when you put the component into a
tr:panelFormLayout! e.g:
tr:panelFormLayout maxCols=1
tr:inputDate id=testDate label=One date
value=#{dateInputBean.date} autoSubmit=true
partialTriggers=testDate
/tr:inputDate
tr:inputText id=inputText label=One Text value=test
autoSubmit=true partialTriggers=inputText/tr:inputText
/tr:panelFormLayout
(German message is:
Keine \'id\', die PPR unterstützt, für Elemente von
CoreInputText[UIXEditableFacesBeanImpl, id=inputText1] gefunden. Diese
Komponente hat kein \'id\'-Attribut herausgeschrieben
)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-790) datepicker selects wrong day
datepicker selects wrong day Key: TRINIDAD-790 URL: https://issues.apache.org/jira/browse/TRINIDAD-790 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.3-core Environment: Firefox 2.0.0.8 Internet Explorer 6.0.2800.1106 Trinidad 1.0.3 Reporter: Daniel Niklas The date-picker-popup of the inputDate-component sets the wrong day into the input-element. E.g.: Select October and click 26. Then 25.10.2007 is set into the input-element. This error occurs with the following months: - April - May - June - July - August - September - October You can reproduce this error here: http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx Best regards Daniel Niklas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
