Re: JSF Client Side JS Framework Written on Top of Dojo Donation
zip it and send it to my address, I'd like to take a look over the weeknd! Do we have a place where we could store this, so that everybody interested can download it? I do not remember how we did it with the ADF donation. Manfred
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Ole, Good stuff. Let me know if you need a hosting location, we can get that sorted for you and get it out to the community en masse! Zubin. On 11/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: zip it and send it to my address, I'd like to take a look over the weeknd! Do we have a place where we could store this, so that everybody interested can download it? I do not remember how we did it with the ADF donation. Manfred
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
when he sent me, I'll put it to my apache account. so everybody has a chance to look at'! On 11/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: zip it and send it to my address, I'd like to take a look over the weeknd! Do we have a place where we could store this, so that everybody interested can download it? I do not remember how we did it with the ADF donation. Manfred -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
On 11/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: Sounds interesting. Do you think it's possible to integrate your components so deeply into the MyFaces framework, that a simple clientside=true for a single standard component or a all_clientside=true in the web.xml brings your components into the game? That would be awesome. Dojo/Ajax/Web2.0 gurus, what do you think? I think the all_clientside=true is somewhat dangerous, because when really every component in the page (outputText, outputLabel) requires a peer, it would slow down the page, since tons of javascript are needed on the client. a flag like attribute, name it clienSide or clientComponent would be better. and still I think there are some components which will always require a client side component; that can be handled by the renderer, for instance. -M Manfred On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Created: (TOMAHAWK-801) panelNavigation2 menu icon and label display issue
panelNavigation2 menu icon and label display issue -- Key: TOMAHAWK-801 URL: http://issues.apache.org/jira/browse/TOMAHAWK-801 Project: MyFaces Tomahawk Issue Type: Bug Components: Panel Navigation2 Affects Versions: 1.1.5-SNAPSHOT Reporter: chintan parekh I am using t:panelNavigation2 component for displaying Vertical Panel Navigation Menu. It uses NavigationMenuItems class to get menu items. The problem is, NavigationMenuItems is having constructor public NavigationMenuItem(String label, String action, String icon, boolean split). It is not displaying both icon and label on the menu page. Only icon is getting displayed. If I set icon as null then label is getting displayed. So at a time only one value is getting displayed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Manfred Geiler schrieb: Sounds interesting. Do you think it's possible to integrate your components so deeply into the MyFaces framework, that a simple clientside=true for a single standard component or a all_clientside=true in the web.xml brings your components into the game? That would be awesome. Dojo/Ajax/Web2.0 gurus, what do you think? Manfred Woha interesting stuff, I just have a minor issue with using yet another view handler. Let me look at the stuff first before giving a clear comment on it. Cheers Werner
Re: Commons Jsf Utils
I'd also like to see a jar for renderkit independent stuff, like converter/validators -M On 11/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Commons Jsf Utils
It seems a good idea to me. But should this commons lib be jsf version independent (I mean, same jar to be used in jsf 1.1 and jsf 1.2 or not). There are classes, like UIComponentTagUtils, which would have a different implementation for jsf 1.1 and 1.2, but there are other (many) classes that can work for 1.1 and 1.2 out of the box. I would say it would be better to have a unique implementation of myfaces-commons and it should be jsf version independent... Cheers, Bruno On 24/11/06, Manfred Geiler [EMAIL PROTECTED] wrote: Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred
Re: Commons Jsf Utils
Matthias Wessendorf schrieb: I'd also like to see a jar for renderkit independent stuff, like converter/validators One of the big issues we have is how we handle all the common javascript stuff. For now we have the dojo lib in tomahawk, but the Tobago guys want to start to use it as well. I cannot move dojo towards weblets for now until the resource loading issues are cleared up.
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Woha interesting stuff, I just have a minor issue with using yet another view handler. Let me look at the stuff first before giving a clear comment on it. that viewhandler is a js file, from what I see to have a proper mapping of client components to server side components -M Cheers Werner -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Commons Jsf Utils
Important hint, thanks! My feeling is, we should have only one jsf-commons project and resolve version issues in the way springframework does support both hibernate2.1 and hibernate3. They have separate packages and only optional maven dependencies. So we could start like this: org.apache.myfaces.commons-jsf org.apache.myfaces.commons-jsf-1-1 org.apache.myfaces.commons-jsf-1-2 and have org.apache.myfaces.commons-jsf-2-0 and so on later. Or alternatively: org.apache.myfaces.commons-jsf org.apache.myfaces.commons-jsf.jsf-1-1 org.apache.myfaces.commons-jsf.jsf-1-2 Or: org.apache.myfaces.commons-jsf.webapp org.apache.myfaces.commons-jsf.webapp.jsf-1-1 org.apache.myfaces.commons-jsf.webapp.jsf-1-2 org.apache.myfaces.commons-jsf.render.html org.apache.myfaces.commons-jsf.render.html.jsf-1-1 org.apache.myfaces.commons-jsf.render.html.jsf-1-2 WDYT? Manfred On 11/24/06, Bruno Aranda [EMAIL PROTECTED] wrote: It seems a good idea to me. But should this commons lib be jsf version independent (I mean, same jar to be used in jsf 1.1 and jsf 1.2 or not). There are classes, like UIComponentTagUtils, which would have a different implementation for jsf 1.1 and 1.2, but there are other (many) classes that can work for 1.1 and 1.2 out of the box. I would say it would be better to have a unique implementation of myfaces-commons and it should be jsf version independent... Cheers, Bruno On 24/11/06, Manfred Geiler [EMAIL PROTECTED] wrote: Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred
[jira] Commented: (TOBAGO-197) treestate setting marker was not able to display on the selectable leafs and expand the entire leafs node
[ http://issues.apache.org/jira/browse/TOBAGO-197?page=comments#action_12452413 ] Volker Weber commented on TOBAGO-197: - fix is commited. please try out the next nightly and give feetback. treestate setting marker was not able to display on the selectable leafs and expand the entire leafs node - Key: TOBAGO-197 URL: http://issues.apache.org/jira/browse/TOBAGO-197 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: JBoss 4.4 JDK 1.5 Reporter: Sam Wong Assigned To: Volker Weber I would like to display what the user has selected from the tree leafs when the user has saved the tree leafs onto the database and retrieve it back from your examples on TobagoDemoController.java tree = new DefaultMutableTreeNode( new Node(Root Node, root)); tree.insert(new DefaultMutableTreeNode(new Node(Sports, sports)), 0); tree.insert(new DefaultMutableTreeNode(new Node(Movies, movies)), 0); DefaultMutableTreeNode music = new DefaultMutableTreeNode( new Node(Music, music)); tree.insert(music, 0); tree.insert(new DefaultMutableTreeNode(new Node(Games, games)), 0); MutableTreeNode temp = new DefaultMutableTreeNode( new Node(Science, science)); temp.insert( new DefaultMutableTreeNode(new Node(Geography, geography)), 0); temp.insert( new DefaultMutableTreeNode(new Node(Mathematics, math)), 0); DefaultMutableTreeNode temp2 = new DefaultMutableTreeNode( new Node(Astronomy, astro)); temp2.insert(new DefaultMutableTreeNode(new Node(Education, edu)), 0); temp2.insert(new DefaultMutableTreeNode(new Node(Pictures, pic)), 0); temp.insert(temp2, 2); tree.insert(temp, 2); treeState = new TreeState(); treeState.addExpandState(tree); treeState.addSelection(temp2); treeState.setMarker(music); For examples Where I set the treeState.setMarker(temp2); When I expand the tree, I did not see the node leaf was being check? Also is there a way to expand a complete leafs node by default?? Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOMAHAWK-802) HtmlInputDate does not have methods to set onchange, onblur and other such attributes
HtmlInputDate does not have methods to set onchange, onblur and other such attributes - Key: TOMAHAWK-802 URL: http://issues.apache.org/jira/browse/TOMAHAWK-802 Project: MyFaces Tomahawk Issue Type: Bug Components: Date Affects Versions: 1.1.5-SNAPSHOT Reporter: Popcorn HtmlInputDate corresponding to the t:inputDate component does not have methods to set the following properties: onclick ondblclick onmousedown onmouseup onmouseover onmousemove onmouseout onkeypress onkeydown onkeyup onblur onfocus onchange onselect These attributes appear on the TLD document of tomahawk [1] but not on the javadocs of HtmlInputDate [2]. These should be supported for an HtmlInput component like all other. There is no way to submit the value of a dynamically created input date component onchange. [1] http://myfaces.apache.org/tomahawk/tlddoc/t/inputDate.html [2] http://myfaces.apache.org/tomahawk/apidocs/org/apache/myfaces/custom/date/HtmlInputDate.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Commons Jsf Utils
+1 for starting off with commons +1 for your first naming suggestion regards, Martin On 11/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: Important hint, thanks! My feeling is, we should have only one jsf-commons project and resolve version issues in the way springframework does support both hibernate2.1 and hibernate3. They have separate packages and only optional maven dependencies. So we could start like this: org.apache.myfaces.commons-jsf org.apache.myfaces.commons-jsf-1-1 org.apache.myfaces.commons-jsf-1-2 and have org.apache.myfaces.commons-jsf-2-0 and so on later. Or alternatively: org.apache.myfaces.commons-jsf org.apache.myfaces.commons-jsf.jsf-1-1 org.apache.myfaces.commons-jsf.jsf-1-2 Or: org.apache.myfaces.commons-jsf.webapp org.apache.myfaces.commons-jsf.webapp.jsf-1-1 org.apache.myfaces.commons-jsf.webapp.jsf-1-2 org.apache.myfaces.commons-jsf.render.html org.apache.myfaces.commons-jsf.render.html.jsf-1-1 org.apache.myfaces.commons-jsf.render.html.jsf-1-2 WDYT? Manfred On 11/24/06, Bruno Aranda [EMAIL PROTECTED] wrote: It seems a good idea to me. But should this commons lib be jsf version independent (I mean, same jar to be used in jsf 1.1 and jsf 1.2 or not). There are classes, like UIComponentTagUtils, which would have a different implementation for jsf 1.1 and 1.2, but there are other (many) classes that can work for 1.1 and 1.2 out of the box. I would say it would be better to have a unique implementation of myfaces-commons and it should be jsf version independent... Cheers, Bruno On 24/11/06, Manfred Geiler [EMAIL PROTECTED] wrote: Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[Validators] minor issue's with usage of getXXX() instead of _xxx
Hi, when you override a standard validator and provide a set/getMaximum() (for instance) and call inside validate() the super.validate() and only *decorate* the ExceptionHandling, you will notice that the the set value (here the maximum) will be ignored, since validate doesn't use getXXX() inside of validate. It uses _xxx directly. Should I change that ? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Commons Jsf Utils
Yes, having separate commons packages sounds good. Cagatay On 11/24/06, Martin Marinschek [EMAIL PROTECTED] wrote: +1 for starting off with commons +1 for your first naming suggestion regards, Martin On 11/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: Important hint, thanks! My feeling is, we should have only one jsf-commons project and resolve version issues in the way springframework does support both hibernate2.1 and hibernate3. They have separate packages and only optional maven dependencies. So we could start like this: org.apache.myfaces.commons-jsf org.apache.myfaces.commons-jsf-1-1 org.apache.myfaces.commons-jsf-1-2 and have org.apache.myfaces.commons-jsf-2-0 and so on later. Or alternatively: org.apache.myfaces.commons-jsf org.apache.myfaces.commons-jsf.jsf-1-1 org.apache.myfaces.commons-jsf.jsf-1-2 Or: org.apache.myfaces.commons-jsf.webapp org.apache.myfaces.commons-jsf.webapp.jsf-1-1 org.apache.myfaces.commons-jsf.webapp.jsf-1-2 org.apache.myfaces.commons-jsf.render.html org.apache.myfaces.commons-jsf.render.html.jsf-1-1 org.apache.myfaces.commons-jsf.render.html.jsf-1-2 WDYT? Manfred On 11/24/06, Bruno Aranda [EMAIL PROTECTED] wrote: It seems a good idea to me. But should this commons lib be jsf version independent (I mean, same jar to be used in jsf 1.1 and jsf 1.2 or not). There are classes, like UIComponentTagUtils, which would have a different implementation for jsf 1.1 and 1.2, but there are other (many) classes that can work for 1.1 and 1.2 out of the box. I would say it would be better to have a unique implementation of myfaces-commons and it should be jsf version independent... Cheers, Bruno On 24/11/06, Manfred Geiler [EMAIL PROTECTED] wrote: Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Interesting! Let's have a look. regards, Martin On 11/24/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Woha interesting stuff, I just have a minor issue with using yet another view handler. Let me look at the stuff first before giving a clear comment on it. that viewhandler is a js file, from what I see to have a proper mapping of client components to server side components -M Cheers Werner -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
RE: Commons Jsf Utils
Does it make sense to coordinate together with SUN... as you define the goal must not depend on a certain JSF implementation regards Alexander -Original Message- From: Manfred Geiler [mailto:[EMAIL PROTECTED] Sent: Friday, November 24, 2006 10:50 AM To: MyFaces Development Subject: Commons Jsf Utils Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred
Re: Commons Jsf Utils
I don't mind Bruno/Manfredo meant more myfaces-versions independent and independent from org.apache.myfaces.impl code (at least I got it that way) -M On 11/24/06, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: Does it make sense to coordinate together with SUN... as you define the goal must not depend on a certain JSF implementation regards Alexander -Original Message- From: Manfred Geiler [mailto:[EMAIL PROTECTED] Sent: Friday, November 24, 2006 10:50 AM To: MyFaces Development Subject: Commons Jsf Utils Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Commented: (TOBAGO-197) treestate setting marker was not able to display on the selectable leafs and expand the entire leafs node
[ http://issues.apache.org/jira/browse/TOBAGO-197?page=comments#action_12452436 ] Sam Wong commented on TOBAGO-197: - What about the expandstate? I would like to expand the entire tree when it display by default if I want it to? thanks. I will try out the next nightly build. thanks agian. treestate setting marker was not able to display on the selectable leafs and expand the entire leafs node - Key: TOBAGO-197 URL: http://issues.apache.org/jira/browse/TOBAGO-197 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.8 Environment: JBoss 4.4 JDK 1.5 Reporter: Sam Wong Assigned To: Volker Weber I would like to display what the user has selected from the tree leafs when the user has saved the tree leafs onto the database and retrieve it back from your examples on TobagoDemoController.java tree = new DefaultMutableTreeNode( new Node(Root Node, root)); tree.insert(new DefaultMutableTreeNode(new Node(Sports, sports)), 0); tree.insert(new DefaultMutableTreeNode(new Node(Movies, movies)), 0); DefaultMutableTreeNode music = new DefaultMutableTreeNode( new Node(Music, music)); tree.insert(music, 0); tree.insert(new DefaultMutableTreeNode(new Node(Games, games)), 0); MutableTreeNode temp = new DefaultMutableTreeNode( new Node(Science, science)); temp.insert( new DefaultMutableTreeNode(new Node(Geography, geography)), 0); temp.insert( new DefaultMutableTreeNode(new Node(Mathematics, math)), 0); DefaultMutableTreeNode temp2 = new DefaultMutableTreeNode( new Node(Astronomy, astro)); temp2.insert(new DefaultMutableTreeNode(new Node(Education, edu)), 0); temp2.insert(new DefaultMutableTreeNode(new Node(Pictures, pic)), 0); temp.insert(temp2, 2); tree.insert(temp, 2); treeState = new TreeState(); treeState.addExpandState(tree); treeState.addSelection(temp2); treeState.setMarker(music); For examples Where I set the treeState.setMarker(temp2); When I expand the tree, I did not see the node leaf was being check? Also is there a way to expand a complete leafs node by default?? Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TOBAGO-199) spell check in textarea
spell check in textarea --- Key: TOBAGO-199 URL: http://issues.apache.org/jira/browse/TOBAGO-199 Project: MyFaces Tobago Issue Type: New Feature Affects Versions: 1.0.8 Environment: JBOSS IE JDK1.5 Reporter: Sam Wong TextArea in tobargo, It would be nice if it has check spell on the text area box. At the mean time, is there a way to have spell check implement with tobago JSF? If it does, is there a website reference that I could view some examples? I really like the https://issues.apache.org/jira/secure/CreateIssue.jspa textarea box. When I submit comment on the textarea box, it has a check spell ability to underline in red for indicating check spell and when you use right click it allows you to choose a correct spelling of the word. Thanks. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Commons Jsf Utils
Yes, that was the intention: Independent of any other myfaces lib. Depending only on specified javax.faces.* classes, which means it is running on top of either myfaces-api or SUN's jsf-api. We are speaking of utils. No need to coordinate with SUN in my opinion. However, if an util class gets that popular we will claim acceptance for JSF 2.0 spec... ;-) Regards, Manfred On 11/24/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I don't mind Bruno/Manfredo meant more myfaces-versions independent and independent from org.apache.myfaces.impl code (at least I got it that way) -M On 11/24/06, Jesse Alexander (KSFD 121) [EMAIL PROTECTED] wrote: Does it make sense to coordinate together with SUN... as you define the goal must not depend on a certain JSF implementation regards Alexander -Original Message- From: Manfred Geiler [mailto:[EMAIL PROTECTED] Sent: Friday, November 24, 2006 10:50 AM To: MyFaces Development Subject: Commons Jsf Utils Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Commented: (TOMAHAWK-800) IinputHTML editor does not work for objectembed
[ http://issues.apache.org/jira/browse/TOMAHAWK-800?page=comments#action_12452456 ] Werner Punz commented on TOMAHAWK-800: -- Good question if this stuff is not a browser issue, the input html controls are to say it mildly very buggy and behave entirely different over various browsers. IinputHTML editor does not work for objectembed --- Key: TOMAHAWK-800 URL: http://issues.apache.org/jira/browse/TOMAHAWK-800 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Editor Affects Versions: 1.1.5-SNAPSHOT Environment: JBOSS, Windows XP Reporter: Dave Priority: Critical Fix For: 1.1.5-SNAPSHOT In html visual editing mode, no way to add code for playing a video file. in text editing mode, type in object block, the object block is lost on the way to server side binding variable. In text editing mode, the editor should keep all the valid code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-178) ASF Source Header and Copyright Notice Policy
[ http://issues.apache.org/jira/browse/TOBAGO-178?page=all ] Bernd Bohmann resolved TOBAGO-178. -- Resolution: Fixed ASF Source Header and Copyright Notice Policy - Key: TOBAGO-178 URL: http://issues.apache.org/jira/browse/TOBAGO-178 Project: MyFaces Tobago Issue Type: Task Reporter: Bernd Bohmann Assigned To: Bernd Bohmann Priority: Blocker Fix For: 1.0.9 All the ASF License headers in the source files need to be updated to remove the copyright notice as per the new policy: http://www.apache.org/legal/src-headers.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-195) Digester in Tobago should use ContextClassloader
[ http://issues.apache.org/jira/browse/TOBAGO-195?page=all ] Bernd Bohmann resolved TOBAGO-195. -- Resolution: Fixed Digester in Tobago should use ContextClassloader Key: TOBAGO-195 URL: http://issues.apache.org/jira/browse/TOBAGO-195 Project: MyFaces Tobago Issue Type: Improvement Components: Core Affects Versions: 1.0.8 Reporter: Bernd Bohmann Assigned To: Bernd Bohmann Fix For: 1.0.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-198) Support for a standard required css class for UIInput Renderer like readonly required disabled..
[ http://issues.apache.org/jira/browse/TOBAGO-198?page=all ] Bernd Bohmann resolved TOBAGO-198. -- Resolution: Fixed Support for a standard required css class for UIInput Renderer like readonly required disabled.. Key: TOBAGO-198 URL: http://issues.apache.org/jira/browse/TOBAGO-198 Project: MyFaces Tobago Issue Type: Improvement Components: Themes Affects Versions: 1.0.8 Reporter: Bernd Bohmann Assigned To: Bernd Bohmann Priority: Minor Fix For: 1.0.9 HtmlRendererUtil.updateClassAttribute should support required css class -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-140) Generate faces-config from annotations
[ http://issues.apache.org/jira/browse/TOBAGO-140?page=all ] Bernd Bohmann resolved TOBAGO-140. -- Resolution: Fixed Generate faces-config from annotations -- Key: TOBAGO-140 URL: http://issues.apache.org/jira/browse/TOBAGO-140 Project: MyFaces Tobago Issue Type: Improvement Components: Build Reporter: Bernd Bohmann Assigned To: Bernd Bohmann Priority: Minor Fix For: 1.0.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-196) getExternalContext().encodeActionURL should called for actionUrl
[ http://issues.apache.org/jira/browse/TOBAGO-196?page=all ] Bernd Bohmann resolved TOBAGO-196. -- Resolution: Fixed getExternalContext().encodeActionURL should called for actionUrl Key: TOBAGO-196 URL: http://issues.apache.org/jira/browse/TOBAGO-196 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.8 Reporter: Bernd Bohmann Assigned To: Bernd Bohmann Fix For: 1.0.9 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TOBAGO-183) tc:out / tc:in support right-aligned numbers
[ http://issues.apache.org/jira/browse/TOBAGO-183?page=all ] Bernd Bohmann resolved TOBAGO-183. -- Resolution: Fixed tc:out / tc:in support right-aligned numbers Key: TOBAGO-183 URL: http://issues.apache.org/jira/browse/TOBAGO-183 Project: MyFaces Tobago Issue Type: New Feature Components: Core Affects Versions: 1.0.8 Environment: all Reporter: Rainer Rohloff Assigned To: Bernd Bohmann Fix For: 1.0.9 in many business applications users are used to right aligned numbers -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Validators] minor issue's with usage of getXXX() instead of _xxx
Yes, academically seen, whenever there is a non-final getter, all methods within a class should use the getter instead of directly accessing the field. Or expressed the other way round: Whenever a class accesses a field directly the corresponding (public or protected) getter method should be defined as final. Sounds logical, but nobody adheres this - including me! ;-) To your question: Yes, change direct field access to getter access, please. Manfred On 11/24/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, when you override a standard validator and provide a set/getMaximum() (for instance) and call inside validate() the super.validate() and only *decorate* the ExceptionHandling, you will notice that the the set value (here the maximum) will be ignored, since validate doesn't use getXXX() inside of validate. It uses _xxx directly. Should I change that ? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Validators] minor issue's with usage of getXXX() instead of _xxx
yeah, I was just wondering, what you guys think about that ... Since I ran into that *issue* :) well, I am fine with keeping the current state :) since that looks *cleaner* to me ... -M On 11/24/06, Manfred Geiler [EMAIL PROTECTED] wrote: Yes, academically seen, whenever there is a non-final getter, all methods within a class should use the getter instead of directly accessing the field. Or expressed the other way round: Whenever a class accesses a field directly the corresponding (public or protected) getter method should be defined as final. Sounds logical, but nobody adheres this - including me! ;-) To your question: Yes, change direct field access to getter access, please. Manfred On 11/24/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, when you override a standard validator and provide a set/getMaximum() (for instance) and call inside validate() the super.validate() and only *decorate* the ExceptionHandling, you will notice that the the set value (here the maximum) will be ignored, since validate doesn't use getXXX() inside of validate. It uses _xxx directly. Should I change that ? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Created: (TOMAHAWK-803) SelectOneLanguage validator never called
SelectOneLanguage validator never called
Key: TOMAHAWK-803
URL: http://issues.apache.org/jira/browse/TOMAHAWK-803
Project: MyFaces Tomahawk
Issue Type: Bug
Components: SelectOneCountry
Affects Versions: 1.1.5-SNAPSHOT
Environment: Myfaces-Jar's are 1.1.5-snapshot of 2006-20-11:
myfaces-impl, myfaces-api, tomahawk, tomahawk-sandbox
Reporter: Bruno Marti
t:selectOneLanguage never calls the custom validator #{myBean.validateField},
which is defined on attribute validator=
sample:
t:selectOneLanguage id=customerLanguage
emptySelection=my empty message
required=true|false
validator=#{myBean.validateField}
value=#{myBean.language}
/
on the other side, the validator of an inputText field works fine:
t:inputTextid=customername
required=true|false
validator=#{myBean.validateField}
value=#{myBean.name}
/
Problem was previousely reported under MYFACES-491
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TOMAHAWK-803) SelectOneLanguage validator never called
[
http://issues.apache.org/jira/browse/TOMAHAWK-803?page=comments#action_12452496
]
Matthias Weßendorf commented on TOMAHAWK-803:
-
looks like nested validators are also ignored
see: SelectOneLanguage.validateValue(...)
SelectOneLanguage validator never called
Key: TOMAHAWK-803
URL: http://issues.apache.org/jira/browse/TOMAHAWK-803
Project: MyFaces Tomahawk
Issue Type: Bug
Components: SelectOneCountry
Affects Versions: 1.1.5-SNAPSHOT
Environment: Myfaces-Jar's are 1.1.5-snapshot of 2006-20-11:
myfaces-impl, myfaces-api, tomahawk, tomahawk-sandbox
Reporter: Bruno Marti
Assigned To: Cagatay Civici
t:selectOneLanguage never calls the custom validator #{myBean.validateField},
which is defined on attribute validator=
sample:
t:selectOneLanguage id=customerLanguage
emptySelection=my empty message
required=true|false
validator=#{myBean.validateField}
value=#{myBean.language}
/
on the other side, the validator of an inputText field works fine:
t:inputTextid=customername
required=true|false
validator=#{myBean.validateField}
value=#{myBean.name}
/
Problem was previousely reported under MYFACES-491
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
[EMAIL PROTECTED] On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Matthias, I just sent it. First attempt got rejected as Spam, so I just gave it another shot. I rebuilt the dojo button widget example using the Dojo.presentation (That's what I called it, but we can rename it...) So now it works just like an JSF Component with the Renderer and the Component being separate, and with support for listeners, validators, and converters. The ViewHandler supports custom tags, so that someone could write validator with a specific namespace, and just hook it up in a template xml like fashion. See the src/main/test/render/test_visualButton.html for the example. Cheers, - Ole --- Matthias Wessendorf [EMAIL PROTECTED] wrote: sounds interesting, I like having a client side API. When you look at Trinidad for instance we already have Converters and Validators for instance. TrDateTimeConverter.prototype.getAsString(..) TrDateTimeRangeValidator.prototype.validate(..) We don't have *client side components* in Trinidad. Does your example contain examples etc ? zip it and send it to my address, I'd like to take a look over the weeknd! -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
OK - Just sent it. --- Matthias Wessendorf [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Matthias, I just sent it. First attempt got rejected as Spam, so I just gave it another shot. I rebuilt the dojo button widget example using the Dojo.presentation (That's what I called it, but we can rename it...) So now it works just like an JSF Component with the Renderer and the Component being separate, and with support for listeners, validators, and converters. The ViewHandler supports custom tags, so that someone could write validator with a specific namespace, and just hook it up in a template xml like fashion. See the src/main/test/render/test_visualButton.html for the example. Cheers, - Ole --- Matthias Wessendorf [EMAIL PROTECTED] wrote: sounds interesting, I like having a client side API. When you look at Trinidad for instance we already have Converters and Validators for instance. TrDateTimeConverter.prototype.getAsString(..) TrDateTimeRangeValidator.prototype.validate(..) We don't have *client side components* in Trinidad. Does your example contain examples etc ? zip it and send it to my address, I'd like to take a look over the weeknd! -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
worked (I upload in 1h) thx On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: OK - Just sent it. --- Matthias Wessendorf [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Matthias, I just sent it. First attempt got rejected as Spam, so I just gave it another shot. I rebuilt the dojo button widget example using the Dojo.presentation (That's what I called it, but we can rename it...) So now it works just like an JSF Component with the Renderer and the Component being separate, and with support for listeners, validators, and converters. The ViewHandler supports custom tags, so that someone could write validator with a specific namespace, and just hook it up in a template xml like fashion. See the src/main/test/render/test_visualButton.html for the example. Cheers, - Ole --- Matthias Wessendorf [EMAIL PROTECTED] wrote: sounds interesting, I like having a client side API. When you look at Trinidad for instance we already have Converters and Validators for instance. TrDateTimeConverter.prototype.getAsString(..) TrDateTimeRangeValidator.prototype.validate(..) We don't have *client side components* in Trinidad. Does your example contain examples etc ? zip it and send it to my address, I'd like to take a look over the weeknd! -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: HostedQA Selenium tests for the Tomahawk components
Wendy, I would like to setup some Selenium test, in part so I know if I break something. Based on the email, we can use HostedQA to run the Selenium tests. If this is still true, will you setup an account for me on the server. Paul Spencer I would like Selenium Wendy Smoak wrote: At this point I have the popup and tree2nonav tests running at HostedQA, on Tomcat, in both IE and Firefox. You can see the results here: * https://myfaces.hostedqa.com/project/54/session/suite/list (Follow the links to see the log file and screen shots of every step of the tests.) These are the same tests that you can run locally using this info: * http://myfaces.apache.org/tomahawk/testing/selenium.html I haven't figured out how to automatically update the app at HostedQA, right now I have to go log in and upload a new version. I'll set up an account at myfaces.hostedqa.com for any committer, just ask!
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Manfred, Sure - I think that should be easy to do. In addition I suspect that the Implementation could just check whether Javascript is enabled, and serve the Javascript components if it is (With Perhaps some Javascript version support checking). I've tried to mirror the JSF Spec as much as possible in the code base, so that developing with the framework becomes easy for JSF developers. I also wrote the JSUnit tests so that deducing the ViewHandler approach should be as simple as possible, and there is documentation in the src/maven/apt/ folder. So the general Idea is that the Renderer for the JSF Components would just render the custom dojo.presentation tag...the ViewHandler supports custom namespaces... Then the ViewHandler compiles this tag on the client creating the visual representation of the component. The component can then pull additional content using XMLRequest... Components can also be created in Raw Javascript ...giving gui developers the option to develop web interfaces in a SWING or SWT like fashion. Matthias has the code now hopefully, so perhaps he can check it into Subversion for us. I already have a CLA on file for the directory project , and I think that covers all of apache. Cheers, - Ole --- Manfred Geiler [EMAIL PROTECTED] wrote: Sounds interesting. Do you think it's possible to integrate your components so deeply into the MyFaces framework, that a simple clientside=true for a single standard component or a all_clientside=true in the web.xml brings your components into the game? That would be awesome. Dojo/Ajax/Web2.0 gurus, what do you think? Manfred On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Cool - Thanks --- Matthias Wessendorf [EMAIL PROTECTED] wrote: worked (I upload in 1h) thx On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: OK - Just sent it. --- Matthias Wessendorf [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Matthias, I just sent it. First attempt got rejected as Spam, so I just gave it another shot. I rebuilt the dojo button widget example using the Dojo.presentation (That's what I called it, but we can rename it...) So now it works just like an JSF Component with the Renderer and the Component being separate, and with support for listeners, validators, and converters. The ViewHandler supports custom tags, so that someone could write validator with a specific namespace, and just hook it up in a template xml like fashion. See the src/main/test/render/test_visualButton.html for the example. Cheers, - Ole --- Matthias Wessendorf [EMAIL PROTECTED] wrote: sounds interesting, I like having a client side API. When you look at Trinidad for instance we already have Converters and Validators for instance. TrDateTimeConverter.prototype.getAsString(..) TrDateTimeRangeValidator.prototype.validate(..) We don't have *client side components* in Trinidad. Does your example contain examples etc ? zip it and send it to my address, I'd like to take a look over the weeknd! -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited
Re: HostedQA Selenium tests for the Tomahawk components
On 11/24/06, Paul Spencer [EMAIL PROTECTED] wrote: I would like to setup some Selenium test, in part so I know if I break something. Based on the email, we can use HostedQA to run the Selenium tests. If this is still true, will you setup an account for me on the server. Done. You should have gotten an email... let me know if not. See this page for information on configuration: http://myfaces.apache.org/tomahawk/testing/hostedqa.html You can also run the Selenium tests locally: http://myfaces.apache.org/tomahawk/testing/selenium.html The tests are currently only configured to run under Firefox at HostedQA, so there's not really much to be gained by executing them remotely. (The tests that use xpath expressions tend to fail in IE. My guess is that the components render themselves differently in different browsers.) -- Wendy
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
I won't commit it now. First everybody should look at it ;) -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Cool - Thanks --- Matthias Wessendorf [EMAIL PROTECTED] wrote: worked (I upload in 1h) thx On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: OK - Just sent it. --- Matthias Wessendorf [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Matthias, I just sent it. First attempt got rejected as Spam, so I just gave it another shot. I rebuilt the dojo button widget example using the Dojo.presentation (That's what I called it, but we can rename it...) So now it works just like an JSF Component with the Renderer and the Component being separate, and with support for listeners, validators, and converters. The ViewHandler supports custom tags, so that someone could write validator with a specific namespace, and just hook it up in a template xml like fashion. See the src/main/test/render/test_visualButton.html for the example. Cheers, - Ole --- Matthias Wessendorf [EMAIL PROTECTED] wrote: sounds interesting, I like having a client side API. When you look at Trinidad for instance we already have Converters and Validators for instance. TrDateTimeConverter.prototype.getAsString(..) TrDateTimeRangeValidator.prototype.validate(..) We don't have *client side components* in Trinidad. Does your example contain examples etc ? zip it and send it to my address, I'd like to take a look over the weeknd! -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
[jira] Commented: (TOMAHAWK-803) SelectOneLanguage validator never called
[
http://issues.apache.org/jira/browse/TOMAHAWK-803?page=comments#action_12452500
]
Cagatay Civici commented on TOMAHAWK-803:
-
Yes, calling parent's validation first will solve the issue.
SelectOneLanguage validator never called
Key: TOMAHAWK-803
URL: http://issues.apache.org/jira/browse/TOMAHAWK-803
Project: MyFaces Tomahawk
Issue Type: Bug
Components: SelectOneCountry
Affects Versions: 1.1.5-SNAPSHOT
Environment: Myfaces-Jar's are 1.1.5-snapshot of 2006-20-11:
myfaces-impl, myfaces-api, tomahawk, tomahawk-sandbox
Reporter: Bruno Marti
Assigned To: Cagatay Civici
t:selectOneLanguage never calls the custom validator #{myBean.validateField},
which is defined on attribute validator=
sample:
t:selectOneLanguage id=customerLanguage
emptySelection=my empty message
required=true|false
validator=#{myBean.validateField}
value=#{myBean.language}
/
on the other side, the validator of an inputText field works fine:
t:inputTextid=customername
required=true|false
validator=#{myBean.validateField}
value=#{myBean.name}
/
Problem was previousely reported under MYFACES-491
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
It is up http://people.apache.org/~matzew/dojo.presentation.zip thx ole On 11/24/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I won't commit it now. First everybody should look at it ;) -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Cool - Thanks --- Matthias Wessendorf [EMAIL PROTECTED] wrote: worked (I upload in 1h) thx On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: OK - Just sent it. --- Matthias Wessendorf [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Matthias, I just sent it. First attempt got rejected as Spam, so I just gave it another shot. I rebuilt the dojo button widget example using the Dojo.presentation (That's what I called it, but we can rename it...) So now it works just like an JSF Component with the Renderer and the Component being separate, and with support for listeners, validators, and converters. The ViewHandler supports custom tags, so that someone could write validator with a specific namespace, and just hook it up in a template xml like fashion. See the src/main/test/render/test_visualButton.html for the example. Cheers, - Ole --- Matthias Wessendorf [EMAIL PROTECTED] wrote: sounds interesting, I like having a client side API. When you look at Trinidad for instance we already have Converters and Validators for instance. TrDateTimeConverter.prototype.getAsString(..) TrDateTimeRangeValidator.prototype.validate(..) We don't have *client side components* in Trinidad. Does your example contain examples etc ? zip it and send it to my address, I'd like to take a look over the weeknd! -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Yahoo! Music Unlimited Access over 1 million songs. http://music.yahoo.com/unlimited -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Good thinking :-) --- Matthias Wessendorf [EMAIL PROTECTED] wrote: I won't commit it now. First everybody should look at it ;) -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Cool - Thanks --- Matthias Wessendorf [EMAIL PROTECTED] wrote: worked (I upload in 1h) thx On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: OK - Just sent it. --- Matthias Wessendorf [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Matthias, I just sent it. First attempt got rejected as Spam, so I just gave it another shot. I rebuilt the dojo button widget example using the Dojo.presentation (That's what I called it, but we can rename it...) So now it works just like an JSF Component with the Renderer and the Component being separate, and with support for listeners, validators, and converters. The ViewHandler supports custom tags, so that someone could write validator with a specific namespace, and just hook it up in a template xml like fashion. See the src/main/test/render/test_visualButton.html for the example. Cheers, - Ole --- Matthias Wessendorf [EMAIL PROTECTED] wrote: sounds interesting, I like having a client side API. When you look at Trinidad for instance we already have Converters and Validators for instance. TrDateTimeConverter.prototype.getAsString(..) TrDateTimeRangeValidator.prototype.validate(..) We don't have *client side components* in Trinidad. Does your example contain examples etc ? zip it and send it to my address, I'd like to take a look over the weeknd! -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com === message truncated === Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: Commons Jsf Utils
Sounds really useful. Especially for classes like the ones John Fallows and Jonas Jacobi developed in their book to support resource loading, etc. --- Manfred Geiler [EMAIL PROTECTED] wrote: Hi *, Anyone remembering the old idea of having a separate commons jsf utils project? Mission: - provide utilities for JSF component developers as well as JSF application developers - provide a stable API - must not depend on a certain JSF implementation - own release schedule independent of core and tomahawk. Maybe propelled by a sister project of course... ;-) One perfect example of a jsf-commons class I just stumbled across is UIComponentTagUtils. It's the class where all those boring set*Property methods are implemented, that do the if value-binding then... else... things. Proposal: - Initiate a new MyFaces sub-project called commons-jsf (Yes! There did exist a commons in ancient times. It was the forerunner for our current shared project and the reason we renamed commons to shared was, that we planned to create a REAL commons project later. Remember?) - We start with those obvious common jsf utils (like UIComponentTagUtils) - Each (new) util class must be carefully designed to be able to provide a robust API Thoughts? Manfred Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
Re: HostedQA Selenium tests for the Tomahawk components
Wendy, The email has not yet come through. Paul Spencer Wendy Smoak wrote: On 11/24/06, Paul Spencer [EMAIL PROTECTED] wrote: I would like to setup some Selenium test, in part so I know if I break something. Based on the email, we can use HostedQA to run the Selenium tests. If this is still true, will you setup an account for me on the server. Done. You should have gotten an email... let me know if not. See this page for information on configuration: http://myfaces.apache.org/tomahawk/testing/hostedqa.html You can also run the Selenium tests locally: http://myfaces.apache.org/tomahawk/testing/selenium.html The tests are currently only configured to run under Firefox at HostedQA, so there's not really much to be gained by executing them remotely. (The tests that use xpath expressions tend to fail in IE. My guess is that the components render themselves differently in different browsers.)
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Cool - Hope it's helpful :-) Thanks, - Ole --- Matthias Wessendorf [EMAIL PROTECTED] wrote: It is up http://people.apache.org/~matzew/dojo.presentation.zip thx ole On 11/24/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: I won't commit it now. First everybody should look at it ;) -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Cool - Thanks --- Matthias Wessendorf [EMAIL PROTECTED] wrote: worked (I upload in 1h) thx On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: OK - Just sent it. --- Matthias Wessendorf [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Matthias, I just sent it. First attempt got rejected as Spam, so I just gave it another shot. I rebuilt the dojo button widget example using the Dojo.presentation (That's what I called it, but we can rename it...) So now it works just like an JSF Component with the Renderer and the Component being separate, and with support for listeners, validators, and converters. The ViewHandler supports custom tags, so that someone could write validator with a specific namespace, and just hook it up in a template xml like fashion. See the src/main/test/render/test_visualButton.html for the example. Cheers, - Ole --- Matthias Wessendorf [EMAIL PROTECTED] wrote: sounds interesting, I like having a client side API. When you look at Trinidad for instance we already have Converters and Validators for instance. TrDateTimeConverter.prototype.getAsString(..) TrDateTimeRangeValidator.prototype.validate(..) We don't have *client side components* in Trinidad. Does your example contain examples etc ? zip it and send it to my address, I'd like to take a look over the weeknd! -M On 11/24/06, Ole Ersoy [EMAIL PROTECTED] wrote: Hi, I've created a framework for working with Javascript on the client side that uses components similar to those used in JSF. Initially I was just trying to fix a bug in Dojo, but then I ended up writing a new client side view handler, etc. My original motivation can be found here. http://trac.dojotoolkit.org/ticket/1378 I would like to donate it to myfaces if there is interest? When I did the rewrite I wanted to Dojo Widgets to support converters, validators, listeners like JSF does so I built this into the ViewHandler... Anyways if anyone on the myfaces team wants a look, I'll be happy to zip it up and mail it. Cheers, - Ole Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com === message truncated === Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index
Re: JSF Client Side JS Framework Written on Top of Dojo Donation
Yes - Precisely - So compiling client side custom tags into JS components that live in the client JS Container... So the server side component renderer just needs to emit one of these tags, and the rest is handled on the client. --- Matthias Wessendorf [EMAIL PROTECTED] wrote: Woha interesting stuff, I just have a minor issue with using yet another view handler. Let me look at the stuff first before giving a clear comment on it. that viewhandler is a js file, from what I see to have a proper mapping of client components to server side components -M Cheers Werner -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com
Re: svn commit: r478888 - /myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
good catch. Thanks!
regards,
Martin
On 11/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: cagatay
Date: Fri Nov 24 06:13:41 2006
New Revision: 47
URL: http://svn.apache.org/viewvc?view=revrev=47
Log:
Updated client state params to javax.faces.ViewState
Modified:
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
Modified:
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js?view=diffrev=47r1=478887r2=47
==
---
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
(original)
+++
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
Fri Nov 24 06:13:41 2006
@@ -14,16 +14,12 @@
}
this.isClientStateSaving = function() {
-return dojo.byId(jsf_state) || dojo.byId(jsf_state_64);
+return dojo.byId(javax.faces.ViewState);
}
this.addJsfState = function(request) {
request.content = request.content || {};
-this.addInputValue(request.content, jsf_state);
-this.addInputValue(request.content, jsf_state_64);
-this.addInputValue(request.content, jsf_tree);
-this.addInputValue(request.content, jsf_tree_64);
-this.addInputValue(request.content, jsf_viewid);
+this.addInputValue(request.content, javax.faces.ViewState);
}
this.addInputValue = function (content, inputName) {
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: svn commit: r478888 - /myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
:)
look the email archive ...
On 11/24/06, Martin Marinschek [EMAIL PROTECTED] wrote:
good catch. Thanks!
regards,
Martin
On 11/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: cagatay
Date: Fri Nov 24 06:13:41 2006
New Revision: 47
URL: http://svn.apache.org/viewvc?view=revrev=47
Log:
Updated client state params to javax.faces.ViewState
Modified:
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
Modified:
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
URL:
http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js?view=diffrev=47r1=478887r2=47
==
---
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
(original)
+++
myfaces/tomahawk/trunk/core/src/main/resources/org/apache/myfaces/custom/dojoextensions/resource/FacesIO.js
Fri Nov 24 06:13:41 2006
@@ -14,16 +14,12 @@
}
this.isClientStateSaving = function() {
-return dojo.byId(jsf_state) || dojo.byId(jsf_state_64);
+return dojo.byId(javax.faces.ViewState);
}
this.addJsfState = function(request) {
request.content = request.content || {};
-this.addInputValue(request.content, jsf_state);
-this.addInputValue(request.content, jsf_state_64);
-this.addInputValue(request.content, jsf_tree);
-this.addInputValue(request.content, jsf_tree_64);
-this.addInputValue(request.content, jsf_viewid);
+this.addInputValue(request.content, javax.faces.ViewState);
}
this.addInputValue = function (content, inputName) {
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
[jira] Resolved: (TOMAHAWK-803) SelectOneLanguage validator never called
[ http://issues.apache.org/jira/browse/TOMAHAWK-803?page=all ]
Cagatay Civici resolved TOMAHAWK-803.
-
Fix Version/s: 1.1.4-SNAPSHOT
1.1.5-SNAPSHOT
Resolution: Fixed
Fixed both in trunk and 1.1.4 branch.
SelectOneLanguage validator never called
Key: TOMAHAWK-803
URL: http://issues.apache.org/jira/browse/TOMAHAWK-803
Project: MyFaces Tomahawk
Issue Type: Bug
Components: SelectOneCountry
Affects Versions: 1.1.5-SNAPSHOT, 1.1.4-SNAPSHOT
Environment: Myfaces-Jar's are 1.1.5-snapshot of 2006-20-11:
myfaces-impl, myfaces-api, tomahawk, tomahawk-sandbox
Reporter: Bruno Marti
Assigned To: Cagatay Civici
Fix For: 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT
t:selectOneLanguage never calls the custom validator #{myBean.validateField},
which is defined on attribute validator=
sample:
t:selectOneLanguage id=customerLanguage
emptySelection=my empty message
required=true|false
validator=#{myBean.validateField}
value=#{myBean.language}
/
on the other side, the validator of an inputText field works fine:
t:inputTextid=customername
required=true|false
validator=#{myBean.validateField}
value=#{myBean.name}
/
Problem was previousely reported under MYFACES-491
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
