Trouble upgrading from 1.1.2 to 1.1.7
Hello, I am experiencing quite a lot of trouble while upgrading from MyFaces 1.1.2 to 1.1.7. My application uses IceFaces 1.8.2, Spring 2.5.2 and Hibernate 3.4.0. The only thing that I changed in my Maven 2 build is the version of MyFaces. This had an impact on the following jars: Added: myfaces-api-1.1.7.jar myfaces-impl-1.1.7.jar commons-digester-1.8.jar commons-beanutils-1.8.0.jar Removed: myfaces-api-1.1.2.jar myfaces-impl-1.1.2.jar commons-digester-1.6.jar commons-beanutils-1.7.0.jar commons-codec-1.3.jar When I build and deploy my application in Weblogic 9.2.3, the deploy goes fine, but the actions in the app do not work anymore. More precisely: as soon as I try to use JSF components like if I submit a form, then nothing happens. This behaviour can be observed with several browsers. I tried to find some upgrading guide but didn't find any guide related to these versions. And since the version change is minor, I expected my application to run fine with the new jars. I tried also tried to override some jar versions, putting back the Digester to version 1.6, and the BeanUtils to version 1.7.0, but this didn't change anything. At this point, the only thing that had changed in my EAR were the two MyFaces jars. Another attempt to find the problem was to upgrade the version gradually. I switched to MyFaces 1.1.4, and everything worked fine. That's when I switched to MyFaces 1.1.5 that the problem appeared. However, I haven't seen anything in the changes from 1.1.4 to 1.1.5[1] that seems suspect. Is there some configuration changes that I might have missed? Or some known compatibility problems regarding this upgrade? Again, I couldn't find anything precisely related to these versions up to now, but I'm still looking. Any help would be highly appreciated! :-) Best regards, Sébastien [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10600fixfor=12312310sorter/field=summarysorter/order=ASCsorter/field=resolutionsorter/order=ASCsorter/field=statussorter/order=ASCsorter/field=prioritysorter/order=DESC Sébastien Pennec Lombard Odier Darier Hentsch Cie T +41 22 709 2601 - F +41 22 709 3782 www.lombardodier.com DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Cie or any of its branches or affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. *
RE: [TOMAHAWK] t:columns usage backbean example
Hi thanks for the snippets. Can i ask you to post also the NotenErfassenStandardRow snippet? I am trying to figure out the minimal code needed to implement a base skeleton. Thank you anyay for you help. This is much appreciated. Regards. Andrea. _ Tutto lo spazio che ti serve, lo trovi su Hotmail http://www.windowslive.it/hotmail/SpazioDisponibile.aspx
Re: [TOMAHAWK] t:columns usage backbean example
You're welcome!
Of course, here's the snippet:
public class NotenErfassenStandardRow implements Serializable,
NotenErfassenRow{
private Schueler schueler;
private MapGegenstand,GueltigeNoten noten;
public NotenErfassenStandardRow(Schueler schueler,
MapGegenstand,GueltigeNoten noten) {
super();
this.schueler = schueler;
this.noten = noten;
}
public GueltigeNoten getColumnValue(Gegenstand geg){
return this.noten.get(geg);
}
// cut for clarity
}
Hope this helps!
Regards,
Jakob
2010/3/1 Andrea Paternesi patto...@hotmail.it
Hi thanks for the snippets.
Can i ask you to post also the NotenErfassenStandardRow snippet?
I am trying to figure out the minimal code needed to implement a base
skeleton.
Thank you anyay for you help.
This is much appreciated.
Regards.
Andrea.
_
Tutto lo spazio che ti serve, lo trovi su Hotmail
http://www.windowslive.it/hotmail/SpazioDisponibile.aspx
Re: Trouble upgrading from 1.1.2 to 1.1.7
Hi, Maybe there's a problem with the javascript that submits the form. I saw However this is just a shot in the blue... Regards, Jakob 2010/3/1 s.pen...@lombardodier.com Hello, I am experiencing quite a lot of trouble while upgrading from MyFaces 1.1.2 to 1.1.7. My application uses IceFaces 1.8.2, Spring 2.5.2 and Hibernate 3.4.0. The only thing that I changed in my Maven 2 build is the version of MyFaces. This had an impact on the following jars: Added: myfaces-api-1.1.7.jar myfaces-impl-1.1.7.jar commons-digester-1.8.jar commons-beanutils-1.8.0.jar Removed: myfaces-api-1.1.2.jar myfaces-impl-1.1.2.jar commons-digester-1.6.jar commons-beanutils-1.7.0.jar commons-codec-1.3.jar When I build and deploy my application in Weblogic 9.2.3, the deploy goes fine, but the actions in the app do not work anymore. More precisely: as soon as I try to use JSF components like if I submit a form, then nothing happens. This behaviour can be observed with several browsers. I tried to find some upgrading guide but didn't find any guide related to these versions. And since the version change is minor, I expected my application to run fine with the new jars. I tried also tried to override some jar versions, putting back the Digester to version 1.6, and the BeanUtils to version 1.7.0, but this didn't change anything. At this point, the only thing that had changed in my EAR were the two MyFaces jars. Another attempt to find the problem was to upgrade the version gradually. I switched to MyFaces 1.1.4, and everything worked fine. That's when I switched to MyFaces 1.1.5 that the problem appeared. However, I haven't seen anything in the changes from 1.1.4 to 1.1.5[1] that seems suspect. Is there some configuration changes that I might have missed? Or some known compatibility problems regarding this upgrade? Again, I couldn't find anything precisely related to these versions up to now, but I'm still looking. Any help would be highly appreciated! :-) Best regards, Sébastien [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10600fixfor=12312310sorter/field=summarysorter/order=ASCsorter/field=resolutionsorter/order=ASCsorter/field=statussorter/order=ASCsorter/field=prioritysorter/order=DESC Sébastien Pennec Lombard Odier Darier Hentsch Cie T +41 22 709 2601 - F +41 22 709 3782 www.lombardodier.com DISCLAIMER This message is intended only for use by the person to whom it is addressed. It may contain information that is privileged and confidential. Its content does not constitute a formal commitment by Lombard Odier Darier Hentsch Cie or any of its branches or affiliates. If you are not the intended recipient of this message, kindly notify the sender immediately and destroy this message. Thank You. *
[Trinidad] Tiles
Hi, I have a problem to using apache tiles in trinidad i want to know is that possible ? and which way is better to config it ?
Re: [Trinidad] Tiles
I'd strongly recommend to go with Facelets. Also the next Facelets version is part of JSF2, so you already learn future technologies today. -M On Mon, Mar 1, 2010 at 2:53 PM, omid p vermind...@gmail.com wrote: Hi, I have a problem to using apache tiles in trinidad i want to know is that possible ? and which way is better to config it ? -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
How to obtain posLeft and posTop for a t:panelGrid
Hi!
I need to obtain a t:panelGrid position.
I try to use
document.getElementById('contentLvl:Layer5').style.posLeft
document.getElementById('contentLvl:Layer5').style.posTop
but I receive 0.
Thanks in advance for any suggestions.
Cheers, Valentina
--
View this message in context:
http://old.nabble.com/How-to-obtain-posLeft-and-posTop-for-a-t%3ApanelGrid-tp27744419p27744419.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Trouble upgrading from 1.1.2 to 1.1.7
Hello,
My guess is that the problem is more general than just a javascript issue.
In my previous message, I gave the form submit situation only as an
example. The problem actually touches more than just this: I cannot sort
my table content by clicking on one column header, I cannot switch from a
StackPanel to another, etc...
By searching a little bit further, I found out that the values that I used
in combo boxes to show a greater or smaller choice (for example, age
greater or smaller than 30) are not bound to their java counterpart
anymore. For example:
ice:selectOneMenu value=#{someController.filter.ageOperator} id=
ageOperator
f:selectItem itemValue=1 itemLabel=#{msg.search_filter_greater} /
f:selectItem itemValue=-1 itemLabel=#{msg.search_filter_less} /
/ice:selectOneMenu
This menu was bound to a Java integer as follows:
private int ageOperator;
With 1.1.7, the value is not bound anymore. I needed to change the type of
the attribute in my Java class to String for the binding to work again. Is
there a special converter that I should add, which was not needed in 1.1.2
? I can assure you that this runs fine with 1.1.2 :-)
I am fairly new to MyFaces. Is there something I should do to make the
upgrade easier?
Thanks a lot for your help :-)
Sébastien
Jakob Korherr jakob.korh...@gmail.com
Sent by: sethfromaust...@gmail.com
01.03.2010 12:25
Please respond to
MyFaces Discussion users@myfaces.apache.org
To
MyFaces Discussion users@myfaces.apache.org
cc
Subject
Re: Trouble upgrading from 1.1.2 to 1.1.7
Hi,
Maybe there's a problem with the javascript that submits the form. I saw
However this is just a shot in the blue...
Regards,
Jakob
2010/3/1 s.pen...@lombardodier.com
Hello,
I am experiencing quite a lot of trouble while upgrading from MyFaces
1.1.2 to 1.1.7.
My application uses IceFaces 1.8.2, Spring 2.5.2 and Hibernate 3.4.0.
The only thing that I changed in my Maven 2 build is the version of
MyFaces.
This had an impact on the following jars:
Added:
myfaces-api-1.1.7.jar
myfaces-impl-1.1.7.jar
commons-digester-1.8.jar
commons-beanutils-1.8.0.jar
Removed:
myfaces-api-1.1.2.jar
myfaces-impl-1.1.2.jar
commons-digester-1.6.jar
commons-beanutils-1.7.0.jar
commons-codec-1.3.jar
When I build and deploy my application in Weblogic 9.2.3, the deploy
goes
fine, but the actions in the app do not work anymore.
More precisely: as soon as I try to use JSF components like if I submit
a
form, then nothing happens. This behaviour can be observed with several
browsers.
I tried to find some upgrading guide but didn't find any guide related
to
these versions. And since the version change is minor, I expected my
application to run fine with the new jars.
I tried also tried to override some jar versions, putting back the
Digester to version 1.6, and the BeanUtils to version 1.7.0, but this
didn't change anything. At this point, the only thing that had changed
in
my EAR were the two MyFaces jars.
Another attempt to find the problem was to upgrade the version
gradually.
I switched to MyFaces 1.1.4, and everything worked fine. That's when I
switched to MyFaces 1.1.5 that the problem appeared. However, I haven't
seen anything in the changes from 1.1.4 to 1.1.5[1] that seems suspect.
Is there some configuration changes that I might have missed? Or some
known compatibility problems regarding this upgrade? Again, I couldn't
find anything precisely related to these versions up to now, but I'm
still
looking.
Any help would be highly appreciated! :-)
Best regards,
Sébastien
[1]
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10600fixfor=12312310sorter/field=summarysorter/order=ASCsorter/field=resolutionsorter/order=ASCsorter/field=statussorter/order=ASCsorter/field=prioritysorter/order=DESC
DISCLAIMER
This message is intended only for use by the person to
whom it is addressed. It may contain information that is
privileged and confidential. Its content does not
constitute a formal commitment by Lombard Odier
Darier Hentsch Cie or any of its branches or affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*
DISCLAIMER
This message is intended only for use by the person to
whom it is addressed. It may contain information that is
privileged and confidential. Its content does not
constitute a formal commitment by Lombard Odier
Darier Hentsch Cie or any of its branches or affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*
[Trinidad] resource not available (404) at popup of tr:inputDate
Hi, When one uses extension mapping and Facelets, the popup dialog of a basic tr:inputDate does not work, it causes the error message The requested resource (/CONTEXT/__ADFv__) is not available. This is known since July 2007: https://issues.apache.org/jira/browse/TRINIDAD-119 A patch exists since July 2008, revised in July 2009. (But I don't want to wait until July 2010 for the next activity. :-) The problem still exists for MyFaces 1.2.8, Trinidad 1.2.12, and Facelets 1.1.14. (I don't know if it's relevant that I use Facelets, other bug commenters seem to have used JSP, too.) Is somebody in the know here who can tell me about the state of this bug? Is the patch OK? If the patch is not the Right Way To Do It, maybe one can add the filter as a workaround to the distribution? Or add some hint to the Wiki? It needed some time to analyze and find the issue, I'd be willing to do it and save others the same work if I get a go-ahead from project members. Any input or reaction to this issue would be welcome. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jsch...@acm.org Roedermark, Germany
Re: Trouble upgrading from 1.1.2 to 1.1.7
Can you provide some generated HTML (not JSP!!), which includes components
that do not work. This could be a great help!
Regards,
Jakob
2010/3/1 s.pen...@lombardodier.com
Hello,
My guess is that the problem is more general than just a javascript issue.
In my previous message, I gave the form submit situation only as an
example. The problem actually touches more than just this: I cannot sort
my table content by clicking on one column header, I cannot switch from a
StackPanel to another, etc...
By searching a little bit further, I found out that the values that I used
in combo boxes to show a greater or smaller choice (for example, age
greater or smaller than 30) are not bound to their java counterpart
anymore. For example:
ice:selectOneMenu value=#{someController.filter.ageOperator} id=
ageOperator
f:selectItem itemValue=1 itemLabel=#{msg.search_filter_greater} /
f:selectItem itemValue=-1 itemLabel=#{msg.search_filter_less} /
/ice:selectOneMenu
This menu was bound to a Java integer as follows:
private int ageOperator;
With 1.1.7, the value is not bound anymore. I needed to change the type of
the attribute in my Java class to String for the binding to work again. Is
there a special converter that I should add, which was not needed in 1.1.2
? I can assure you that this runs fine with 1.1.2 :-)
I am fairly new to MyFaces. Is there something I should do to make the
upgrade easier?
Thanks a lot for your help :-)
Sébastien
Jakob Korherr jakob.korh...@gmail.com
Sent by: sethfromaust...@gmail.com
01.03.2010 12:25
Please respond to
MyFaces Discussion users@myfaces.apache.org
To
MyFaces Discussion users@myfaces.apache.org
cc
Subject
Re: Trouble upgrading from 1.1.2 to 1.1.7
Hi,
Maybe there's a problem with the javascript that submits the form. I saw
However this is just a shot in the blue...
Regards,
Jakob
2010/3/1 s.pen...@lombardodier.com
Hello,
I am experiencing quite a lot of trouble while upgrading from MyFaces
1.1.2 to 1.1.7.
My application uses IceFaces 1.8.2, Spring 2.5.2 and Hibernate 3.4.0.
The only thing that I changed in my Maven 2 build is the version of
MyFaces.
This had an impact on the following jars:
Added:
myfaces-api-1.1.7.jar
myfaces-impl-1.1.7.jar
commons-digester-1.8.jar
commons-beanutils-1.8.0.jar
Removed:
myfaces-api-1.1.2.jar
myfaces-impl-1.1.2.jar
commons-digester-1.6.jar
commons-beanutils-1.7.0.jar
commons-codec-1.3.jar
When I build and deploy my application in Weblogic 9.2.3, the deploy
goes
fine, but the actions in the app do not work anymore.
More precisely: as soon as I try to use JSF components like if I submit
a
form, then nothing happens. This behaviour can be observed with several
browsers.
I tried to find some upgrading guide but didn't find any guide related
to
these versions. And since the version change is minor, I expected my
application to run fine with the new jars.
I tried also tried to override some jar versions, putting back the
Digester to version 1.6, and the BeanUtils to version 1.7.0, but this
didn't change anything. At this point, the only thing that had changed
in
my EAR were the two MyFaces jars.
Another attempt to find the problem was to upgrade the version
gradually.
I switched to MyFaces 1.1.4, and everything worked fine. That's when I
switched to MyFaces 1.1.5 that the problem appeared. However, I haven't
seen anything in the changes from 1.1.4 to 1.1.5[1] that seems suspect.
Is there some configuration changes that I might have missed? Or some
known compatibility problems regarding this upgrade? Again, I couldn't
find anything precisely related to these versions up to now, but I'm
still
looking.
Any help would be highly appreciated! :-)
Best regards,
Sébastien
[1]
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=10600fixfor=12312310sorter/field=summarysorter/order=ASCsorter/field=resolutionsorter/order=ASCsorter/field=statussorter/order=ASCsorter/field=prioritysorter/order=DESC
DISCLAIMER
This message is intended only for use by the person to
whom it is addressed. It may contain information that is
privileged and confidential. Its content does not
constitute a formal commitment by Lombard Odier
Darier Hentsch Cie or any of its branches or affiliates.
If you are not the intended recipient of this message,
kindly notify the sender immediately and destroy this
message. Thank You.
*
DISCLAIMER
This message is intended only for use by the person to
whom it is addressed. It may contain information that is
privileged and confidential. Its content does not
constitute a formal commitment by Lombard Odier
Darier Hentsch Cie or any of its branches
Re: [Trinidad] resource not available (404) at popup of tr:inputDate
Joachim -- On Mon, Mar 1, 2010 at 11:11 AM, Joachim Schrod jsch...@acm.org wrote: Hi, When one uses extension mapping and Facelets, the popup dialog of a basic tr:inputDate does not work, it causes the error message The requested resource (/CONTEXT/__ADFv__) is not available. This is known since July 2007: https://issues.apache.org/jira/browse/TRINIDAD-119 A patch exists since July 2008, revised in July 2009. (But I don't want to wait until July 2010 for the next activity. :-) The problem still exists for MyFaces 1.2.8, Trinidad 1.2.12, and Facelets 1.1.14. (I don't know if it's relevant that I use Facelets, other bug commenters seem to have used JSP, too.) Is somebody in the know here who can tell me about the state of this bug? Is the patch OK? If the patch is not the Right Way To Do It, maybe one can add the filter as a workaround to the distribution? Or add some hint to the Wiki? It needed some time to analyze and find the issue, I'd be willing to do it and save others the same work if I get a go-ahead from project members. Any input or reaction to this issue would be welcome. Joachim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jsch...@acm.org Roedermark, Germany I just did a servlet mapping like this: servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern/__ADFv__*/url-pattern url-pattern/faces/*/url-pattern /servlet-mapping Ugly, but it seems to work fine under Tomcat. Good luck! DJ
Re: [Trinidad] resource not available (404) at popup of tr:inputDate
Donn Aiken wrote: On Mon, Mar 1, 2010 at 11:11 AM, Joachim Schrodjsch...@acm.org wrote: Donn, thanks, but that doesn't quite cover my situation. When one uses extension mapping and Facelets, the popup dialog of a basic tr:inputDate does not work, it causes the error message The requested resource (/CONTEXT/__ADFv__) is not available. This is known since July 2007: https://issues.apache.org/jira/browse/TRINIDAD-119 A patch exists since July 2008, revised in July 2009. (But I don't want to wait until July 2010 for the next activity. :-) I just did a servlet mapping like this: servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern/__ADFv__*/url-pattern url-pattern/faces/*/url-pattern /servlet-mapping Ugly, but it seems to work fine under Tomcat. As I wrote above, I use extension mapping, i.e., my URIs have an extension .jsf and not a prefix /faces/. And sadly servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern/__ADFv__*/url-pattern url-pattern*.jsf/url-pattern /servlet-mapping doesn't work, the popup request still returns a 404 response. (It's an interesting question why not, as this request is passed to the MyFaces Servlet, but somehow Trinidad doesn't get a hold on it, while it succeeds when using the filter. Really strange.) So, my questions remain: What's on here? Is info in the Wiki wanted? I can also supply a minimal demo project if somebody needs this for analysis. Joachim PS: In the meantime, I upgraded to Trinidad 1.2.13. No change. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jsch...@acm.org Roedermark, Germany
Re: [Trinidad] resource not available (404) at popup of tr:inputDate
Joachim -- On Mon, Mar 1, 2010 at 1:09 PM, Joachim Schrod jsch...@acm.org wrote: Donn Aiken wrote: On Mon, Mar 1, 2010 at 11:11 AM, Joachim Schrodjsch...@acm.org wrote: Donn, thanks, but that doesn't quite cover my situation. When one uses extension mapping and Facelets, the popup dialog of a basic tr:inputDate does not work, it causes the error message The requested resource (/CONTEXT/__ADFv__) is not available. This is known since July 2007: https://issues.apache.org/jira/browse/TRINIDAD-119 A patch exists since July 2008, revised in July 2009. (But I don't want to wait until July 2010 for the next activity. :-) I just did a servlet mapping like this: servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern/__ADFv__*/url-pattern url-pattern/faces/*/url-pattern /servlet-mapping Ugly, but it seems to work fine under Tomcat. As I wrote above, I use extension mapping, i.e., my URIs have an extension .jsf and not a prefix /faces/. And sadly servlet-mapping servlet-nameFaces Servlet/servlet-name url-pattern/__ADFv__*/url-pattern url-pattern*.jsf/url-pattern /servlet-mapping doesn't work, the popup request still returns a 404 response. (It's an interesting question why not, as this request is passed to the MyFaces Servlet, but somehow Trinidad doesn't get a hold on it, while it succeeds when using the filter. Really strange.) So, my questions remain: What's on here? Is info in the Wiki wanted? I can also supply a minimal demo project if somebody needs this for analysis. Joachim PS: In the meantime, I upgraded to Trinidad 1.2.13. No change. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Joachim Schrod Email: jsch...@acm.org Roedermark, Germany Is it a problem to have both *.jsf and /faces configured? Another approach I have used successfully is to fix it up with a servlet filter. But I did use a sendRedirect to /faces/__ADFv__ url pattern rather than /__ADFv__ DJ
[GSOC] HTML5 Renderkit Start-up
Hi, I've started working on HTML5 renderkit, which I will apply GSOC this year. I haven't done much, just created the project, configured the builder (modified Tomahawk's building procedure). Now I am trying to determine what to implement and how people will use it after we are done. So I am writing some example component codes to get your ideas. The project is hosted on Google Code: http://code.google.com/p/myfaces-html5-starter/ I will appreciate some review on pages at: http://code.google.com/p/myfaces-html5-starter/source/browse/#svn/trunk/src/test/resources/tag-interface Please note that, components are not implemented yet. Code on xhtml pages are just trials. If anybody is interested, please feel free to send me your feedback :) Thanks, Ali Sorry for duplicate post :( -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[Trinidad] IE specific bug in tr:table ? javaScript error with tr:table with rowSelection=multiple upon clicking Select None or Select All after other
Hello folks,
I suspect I found a bug in tr:table
For a tr:tree with 'rowSelection=multiple', when Select None or
Select All is clicked right after the other one (for example clicking
'Select None', then clicking 'Select All'), in IE 7, we get javaScript
error of;
'undefined' is null or not an object
And hence, the selectionListener method never gets called in the managed
bean.
However if
1) In FireFox exact same things works ok.
2) In IE 7, if I click one of the rows in between Select None and Select
All, it is OK.
I captured the generated code and point where it is complaining
CollectionComponent.prototype._selectedKey=a13;
CollectionComponent.prototype._selectedModeKey=a14;
CollectionComponent.prototype.getLength=function(){
var a16=this._getBoxes(); // Error happens at this line
return a16.length;
};
..
where above _getBoxes() function seems to be defined as;
CollectionComponent.prototype._getBoxes=function(){
var a16=this.getFormElement(this._selectedKey);
if(a16.length==(void 0))
{
var a20=new Array(1);
a20[0]=a16;
a16=a20;
}
return a16;
};
I'm using Trinidad 1.2.10
The related xhtml code is;
tr:panelGroupLayout layout=vertical
tr:table value=#{bfeIbdsDialog.ibds} var=row
selectionListener=
#{bfeIbdsDialog.ibdSelectionListener}
autoSubmit=true
immediate=true
id=ibdsTableId
rendered=true
width=100%
rowSelection=multiple
rows=10
rowBandingInterval=1
emptyText=Nothing to show
summary=BFEs matching the Search Criteria
tr:column headerText=IBD #
tr:outputText value=#{row.ibdNum} /
/tr:column
tr:column headerText=IBD Name
tr:outputText value=#{row.ibdName} /
/tr:column
/tr:table
/tr:panelGroupLayout
The selectionListener method in Managed Bean is;
public void ibdSelectionListener(SelectionEvent _se){
logger.info(--BEF ibdSelectionListener(.) );
}
Any idea what to do ?
Regards,
-- ilker
Information Classification: Public
Information Classification: Public
**
IMPORTANT: Any information contained in this communication is intended for the
use of the named individual or entity. All information contained in this
communication is not intended or construed as an offer, solicitation, or a
recommendation to purchase any security. Advice, suggestions or views presented
in this communication are not necessarily those of Pershing LLC nor do they
warrant a complete or accurate statement.
If you are not an intended party to this communication, please notify the
sender and delete/destroy any and all copies of this communication. Unintended
recipients shall not review, reproduce, disseminate nor disclose any
information contained in this communication. Pershing LLC reserves the right to
monitor and retain all incoming and outgoing communications as permitted by
applicable law.
Email communications may contain viruses or other defects. Pershing LLC does
not accept liability nor does it warrant that email communications are virus or
defect free.
**
