[jira] Commented: (TRINIDAD-946) tr:panelPopup incorrect placement in IE7 and IE6 with long pages
[ https://issues.apache.org/jira/browse/TRINIDAD-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920885#action_12920885 ] Tobias Eisenträger commented on TRINIDAD-946: - This Bug still seems to exist. not workign correctly on Trinidad 1.2.13 Please reopen. tr:panelPopup incorrect placement in IE7 and IE6 with long pages Key: TRINIDAD-946 URL: https://issues.apache.org/jira/browse/TRINIDAD-946 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.5-core, 1.0.6-core Environment: Server: Windows 2003, Tomcat 5.5.25, JDK 1.5.0_14, Myfaces 1.1.5, Trinidad 1.0.6, Trinidad 1.0.5 Client: IE7, IE6, Firefox 2.0.0.12 Reporter: Jed Smallwood In IE7 and IE6 the placement of a relative positioned popup is always within the initial visible page section of the browser window as opposed to anywhere on the page. For example, my table has 50 rows. On the initial page load 12 rows are visible with my browser size. My observation is that the popup will not render below the 12th row even when the page has been scrolled down to row 50. Clicking on the popup trigger in the 50th row will render the correct popup on top of the 12th row as opposed to the 50th row. Viewing the same page in Firefox 2.0.0.12, all popups are rendered in the correct positions. After posting this to the myfaces user mailing list, Andrew Robinson responded with the following: I haven't had the time to look into some positioning problems with the popup, but there are many bugs in IE with regards to component location calculations. Open a bug We will need to come up with a solution where there is IE and Firefox specific JS code using bounding box code instead of attempting to use the w3c implementations which are not properly implemented by most browsers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-673) tr:panelPopup positions itself with regards to the document body, not the offset parent
[ https://issues.apache.org/jira/browse/TRINIDAD-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920886#action_12920886 ] Tobias Eisenträger commented on TRINIDAD-673: - This Bug still seems to exist. Not working correctly on Trinidad 1.2.13 Please reopen or advice. Thanks! tr:panelPopup positions itself with regards to the document body, not the offset parent --- Key: TRINIDAD-673 URL: https://issues.apache.org/jira/browse/TRINIDAD-673 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.2-core Reporter: Andrew Robinson Assignee: Andrew Robinson Fix For: 1.0.3-core Attachments: popup.js I have been working for a large part of the day on my own renderer of the tr:panelPopup as the core one unfortunately doesn't work for my needs. The problem is that the PanelPopup.js assumes that the panel's offsetParent is the document.body/window. With CSS styling, this is very rarely the case. As a result a tr:panelPopup inside of a relative or absolute HTML element will not be rendered in the correct location on the screen. Furthermore, the panel is often not visible if the parent's overflow is hidden. Proposed solution: The best way to ensure that the popup is positioned correctly is to have all measurements made using absolute (page) co-ordinates. Also, it is imperative to have the popup inside a container that is not cropped or scrolling in any way to ensure the dialog stays visible. Steps: 1) When the popup is shown, move it to the parent FORM element (use the form to ensure that form elements inside the popup do not break) 2) if the popup is not in a form, then relocate the popup to the document.body 3) have event listeners on the popup and the trigger. 4) in the mouse out, check to see if the events X and Y co-ordinates fall in the page X and page Y co-ordinates of either the trigger or the popup. If the event is outside both sets of co-ordinates, hide the popup 5) when hiding the popup, move it back to it's original parent Technical notes: - to determine absolute co-ordinates relative to the page, one must loop through all the parent nodes, checking offsetTop and offsetLeft until the offsetParent is null -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TRINIDAD-946) tr:panelPopup incorrect placement in IE7 and IE6 with long pages
[ https://issues.apache.org/jira/browse/TRINIDAD-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf reopened TRINIDAD-946: - tr:panelPopup incorrect placement in IE7 and IE6 with long pages Key: TRINIDAD-946 URL: https://issues.apache.org/jira/browse/TRINIDAD-946 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.5-core, 1.0.6-core Environment: Server: Windows 2003, Tomcat 5.5.25, JDK 1.5.0_14, Myfaces 1.1.5, Trinidad 1.0.6, Trinidad 1.0.5 Client: IE7, IE6, Firefox 2.0.0.12 Reporter: Jed Smallwood In IE7 and IE6 the placement of a relative positioned popup is always within the initial visible page section of the browser window as opposed to anywhere on the page. For example, my table has 50 rows. On the initial page load 12 rows are visible with my browser size. My observation is that the popup will not render below the 12th row even when the page has been scrolled down to row 50. Clicking on the popup trigger in the 50th row will render the correct popup on top of the 12th row as opposed to the 50th row. Viewing the same page in Firefox 2.0.0.12, all popups are rendered in the correct positions. After posting this to the myfaces user mailing list, Andrew Robinson responded with the following: I haven't had the time to look into some positioning problems with the popup, but there are many bugs in IE with regards to component location calculations. Open a bug We will need to come up with a solution where there is IE and Firefox specific JS code using bounding box code instead of attempting to use the w3c implementations which are not properly implemented by most browsers -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1551) f:ajax doesn't work in t:selectOneRadio layout=spread
[
https://issues.apache.org/jira/browse/TOMAHAWK-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920932#action_12920932
]
Werner Punz commented on TOMAHAWK-1551:
---
Ok this seems to be a bug, but just for the sake of quickly posting a
workaround, you always can use a direct jsf.ajax.request call on the javascript
side itself to work around this problem.
f:ajax doesn't work in t:selectOneRadio layout=spread
---
Key: TOMAHAWK-1551
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1551
Project: MyFaces Tomahawk
Issue Type: Bug
Components: selectOneRadio / radio
Affects Versions: 1.1.10
Environment: Mojarra 2.0.3, Tomcat 6.0.29, Eclipse 3.6, Windows XP
Reporter: Bauke Scholtz
The f:ajax doesn't work in t:selectOneRadio layout=spread. Judging the HTML
source, it incorrectly obtains the client ID of t:selectOneRadio instead of
the one of the t:radio (or just this) as first argument of the ajax
function. This is been used in document.getElementById() which in turns
returns null/undefinied and breaks the ajax function.
XHTML source:
t:selectOneRadio id=item value=#{bean.item} layout=spread
f:selectItems value=#{bean.items} /
f:ajax event=click /
/t:selectOneRadio
t:radio for=item index=0 /
t:radio for=item index=1 /
Generated HTML source (labels omitted):
input id=form:item:0 type=radio name=form:item value=item1
onclick=mojarra.ab('form:item',event,'click',0,0) /
input id=form:item:1 type=radio name=form:item value=item2
onclick=mojarra.ab('form:item',event,'click',0,0) /
Expected HTML source (labels omitted):
input id=form:item:0 type=radio name=form:item value=item1
onclick=mojarra.ab('form:item:0',event,'click',0,0) /
input id=form:item:1 type=radio name=form:item value=item2
onclick=mojarra.ab('form:item:1',event,'click',0,0) /
OR
input id=form:item:0 type=radio name=form:item value=item1
onclick=mojarra.ab(this,event,'click',0,0) /
input id=form:item:1 type=radio name=form:item value=item2
onclick=mojarra.ab(this,event,'click',0,0) /
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
JBoss and MyFaces ....
Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone
Re: JBoss and MyFaces ....
Am 14.10.10 22:32, schrieb Matthias Wessendorf: Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone Oha... this is big news... Werner
Re: JBoss and MyFaces ....
Congrats to everyone involved - you did great work to make this happen! all the best, Martin On 10/14/10, Werner Punz werner.p...@gmail.com wrote: Am 14.10.10 22:32, schrieb Matthias Wessendorf: Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone Oha... this is big news... Werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (TRINIDAD-1940) Problems with the tr:forEach
Problems with the tr:forEach
Key: TRINIDAD-1940
URL: https://issues.apache.org/jira/browse/TRINIDAD-1940
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0.3-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
The tr:forEach tag has issues when trying to use component references and
trying to keep the component state in sync with the items in a list. It also
does not support Maps like the c:forEach tag does.
I seek to improve the forEach tag in Trinidad, and propose that JSF/JSTL does
something similar so that user's can really use the for each tag without
issues. Some of the for each problems are described in my blog:
http://drewdev.blogspot.com/2008/08/cforeach-with-jsf-could-ruin-your-day.html
I propose to address each of the issues with the JSP tag.
First, reliable component references:
tr:forEach var=item items=#{myBean.items}
tr:panelGroupLayout id=pgl1 layout=horizontal
tr:inputText id=it1 label=Enter value: value=#{item.text}
autoSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.text}
partialTriggers=it1 /
/tr:panelGroupLayout
/tr:forEach
The problem is that the author intended the output text component to partially
updated by the sibling input text when it changed value, but that is not the
result. Instead, the partial triggers is always it1, but the generated input
text components are ot1, ot1j_id_1 and ot1j_id_2. The result is that the
output text components all partially update only when the first input text is
changed.
Another problem is that the indexed value expressions and the var status map
that is put into the variable mapper by the for each loop is static. Take the
following example:
tr:panelGroupLayout id=pgl1 layout=scroll
tr:forEach var=item items=#{myBean.items} varStatus=vs
tr:outputText id=ot1 value=This is the last item in the list:
#{vs.last}. Item #{item.text}. /
/tr:forEach
/tr:panelGroupLayout
Say during the first pass, the items in the list are A, B and C and the page
would look like this:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
Now, consider what the output would be if someone added an object D to the end
of the list during invoke application:
This is the last item in the list: false. Item A.
This is the last item in the list: false. Item B.
This is the last item in the list: true. Item C.
This is the last item in the list: true. Item D.
Notice that both C and D think they are the last. The reason is that the
UIComponentClassicTagBase will find the components generated for A, B and C
during the findComponent call. It will only create a new component for D. When
D is created, it will pick up the new variable status map created by the for
each tag in its value expressions. Because when three earlier components were
build, C was the last item, and the variable status map in their value
expressions did not reflect any changes. D gets the correct values since it was
just created.
-
I propose to reduce any work required by page developers to implement the for
each loop with re-ordering support (avoid having to use immediate EL in the ID
attribute) and fix the issues above.
The proposal is that Trinidad Tag based components (those components created by
UIXComponentELTag) will be able to have key-based IDs automatically generated
as a result of being in a for each tag. So consider this example:
tr:forEach var=item items=#{bean.items} varStatus=vs
tr:inputText id=it1 value=#{item.value} partialSubmit=true /
tr:outputText id=ot1 value=Value is: #{item.value}
partialTriggers=it1_${vs.key} /
/tr:forEach
In this code, the IDs of the components would automatically pick up the item
key. The item key would be stored on the var status. For List this key would
simply be the index, for Map it would be the map key and CollectionModel would
use the row key. UIXComponentELTag could check to see if a parent tag desires
to alter the component IDs, which in this case, the for each would. With that
set, the tags would alter the component IDs to append the key. For example, _
+ key would be appended to each component ID (it1 would become it1_A if the key
were A).
The for each tag would set the key into the variable mapper so that, instead of
indexes, the key would be used to evaluate the EL with the limitation that the
key would be the index for List, in which the current behavior would be
retained of the component state staying with the index rather than with the
object.
Due to the fact that the JSP does not perform any component reordering, the
org.apache.myfaces.trinidad.change.ReorderChildrenComponentChange component
change class can be use to alter the component order and also notify the
component change manager
[Trinidad 2] For each fixes proposal
I have created a JIRA on the problems with using tr:forEach and a proposed fix: https://issues.apache.org/jira/browse/TRINIDAD-1940 Just sending a heads up for any feedback. Thanks, Andrew
[jira] Created: (TRINIDAD-1941) Required field message on af:selectonechoice component incorrect
Required field message on af:selectonechoice component incorrect -- Key: TRINIDAD-1941 URL: https://issues.apache.org/jira/browse/TRINIDAD-1941 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Priority: Trivial If you have af:selectOneChoice that is marked as being required and the user doesn't enter any value, the message thrown is: A selection is required. You must make at least one selection.. Instead the message should be: A selection is required. You must make a selection. The difference is the at least one part of the message. The fix is to update trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/MessageBundle.xrts with resource key=org.apache.myfaces.trinidad.UIXSelectOne.REQUIRED_detailYou must make a selection./resource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1941) Required field message on af:selectonechoice component incorrect
[ https://issues.apache.org/jira/browse/TRINIDAD-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-1941: Status: Patch Available (was: Open) Required field message on af:selectonechoice component incorrect -- Key: TRINIDAD-1941 URL: https://issues.apache.org/jira/browse/TRINIDAD-1941 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Priority: Trivial If you have af:selectOneChoice that is marked as being required and the user doesn't enter any value, the message thrown is: A selection is required. You must make at least one selection.. Instead the message should be: A selection is required. You must make a selection. The difference is the at least one part of the message. The fix is to update trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/MessageBundle.xrts with resource key=org.apache.myfaces.trinidad.UIXSelectOne.REQUIRED_detailYou must make a selection./resource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1941) Required field message on af:selectonechoice component incorrect
[ https://issues.apache.org/jira/browse/TRINIDAD-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-1941: Status: Open (was: Patch Available) Required field message on af:selectonechoice component incorrect -- Key: TRINIDAD-1941 URL: https://issues.apache.org/jira/browse/TRINIDAD-1941 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Priority: Trivial If you have af:selectOneChoice that is marked as being required and the user doesn't enter any value, the message thrown is: A selection is required. You must make at least one selection.. Instead the message should be: A selection is required. You must make a selection. The difference is the at least one part of the message. The fix is to update trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/MessageBundle.xrts with resource key=org.apache.myfaces.trinidad.UIXSelectOne.REQUIRED_detailYou must make a selection./resource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1941) Required field message on af:selectonechoice component incorrect
[ https://issues.apache.org/jira/browse/TRINIDAD-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kentaro Kinebuchi updated TRINIDAD-1941: Status: Patch Available (was: Open) Required field message on af:selectonechoice component incorrect -- Key: TRINIDAD-1941 URL: https://issues.apache.org/jira/browse/TRINIDAD-1941 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0.3-core Environment: Linux x86 Reporter: Kentaro Kinebuchi Priority: Trivial Attachments: bug10117191.patch If you have af:selectOneChoice that is marked as being required and the user doesn't enter any value, the message thrown is: A selection is required. You must make at least one selection.. Instead the message should be: A selection is required. You must make a selection. The difference is the at least one part of the message. The fix is to update trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/MessageBundle.xrts with resource key=org.apache.myfaces.trinidad.UIXSelectOne.REQUIRED_detailYou must make a selection./resource -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JBoss and MyFaces ....
Yes, the goal is to allow any version and any implementation of JSF. That's why you will see Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] Just to be clear, it's AS6 SNAPSHOT, not AS5. The AS6 CR1 release will be out in a few weeks but you can get a nightly build if you want to try it now: https://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x/lastSuccessfulBuild/artifact/JBossAS_6_0/build/target/ I'd love to get feedback. See the short JSF on JBoss doc to see how to do things like assign a JSF impl to a particular WAR. Also, I don't think it's in the doc, but changing the default impl from Mojarra to MyFaces is just a matter of changing one value in an XML file. The doc is here: http://www.jboss.org/jbossas/docs/6-x/Component-Documentation/jsf.html Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. Stan Quoting Matthias Wessendorf mat...@apache.org: Matthias Wessendorf (@mwessendorf) has shared a Tweet with you: lincolnthree: MyFaces 2 is now included in JBoss AS 5 SNAPSHOT!! -Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] --http://www.twitter.com/lincolnthree/status/27372071638 sent from my Android phone
Re: JBoss and MyFaces ....
Hi 2010/10/14 ssilv...@redhat.com Yes, the goal is to allow any version and any implementation of JSF. That's why you will see Initialized 3 JSF configurations: [Mojarra-1.2, MyFaces-2.0, Mojarra-2.0] Just to be clear, it's AS6 SNAPSHOT, not AS5. The AS6 CR1 release will be out in a few weeks but you can get a nightly build if you want to try it now: https://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x/lastSuccessfulBuild/artifact/JBossAS_6_0/build/target/ I'd love to get feedback. See the short JSF on JBoss doc to see how to do things like assign a JSF impl to a particular WAR. Also, I don't think it's in the doc, but changing the default impl from Mojarra to MyFaces is just a matter of changing one value in an XML file. The doc is here: http://www.jboss.org/jbossas/docs/6-x/Component-Documentation/jsf.html Right now it has MyFaces 2.0.1, but I'm soon planning to do the full integration of 2.0.2 as per Leonardo's changes. That will make MyFaces a little more efficient on JBoss AS. Great! It makes me happy :-). I'll keep an eye on this one. As soon as we have feedback about if the integration points are ok, I can make another release. Leonardo Uribe
