Re: Tutorial: MyFaces 2 on Google App Engine
Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Tutorial: MyFaces 2 on Google App Engine
Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.orgwrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Tutorial: MyFaces 2 on Google App Engine
Yeah, very cool Ali! Thanks Have you also tried to use IntelliJ for your project? I never use IntelliJ, but never used GAE. Don't know if any specific plugin is required for GAE? /JK 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.orgwrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Tutorial: MyFaces 2 on Google App Engine
great! (i would prefer a wiki page.) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.orgwrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Tutorial: MyFaces 2 on Google App Engine
On Mon, Mar 29, 2010 at 9:21 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: great! (i would prefer a wiki page.) real doc get's more visibility.. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.org wrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Tutorial: MyFaces 2 on Google App Engine
Have you also tried to use IntelliJ for your project? I never use IntelliJ, but never used GAE. Don't know if any specific plugin is required for GAE? I've never used IntelliJ either, but it seems there is a GAE plugin herehttp://blogs.jetbrains.com/idea/2009/05/google-app-engine-support/ . I will try it, and let the community know. Regards, Ali On Mon, Mar 29, 2010 at 10:21 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: great! (i would prefer a wiki page.) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.orgwrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: Tutorial: MyFaces 2 on Google App Engine
imo we should move much more to the wiki... it's easier for users to participate. furthermore, we can link important wiki pages within our site... so we would have the same visibility. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org On Mon, Mar 29, 2010 at 9:21 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: great! (i would prefer a wiki page.) real doc get's more visibility.. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.org wrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Tutorial: MyFaces 2 on Google App Engine
well, with the new cwiki, that should be more easy. We should perhaps clean-up the outdated stuff from the homepage, anyways. -M On Mon, Mar 29, 2010 at 10:10 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: imo we should move much more to the wiki... it's easier for users to participate. furthermore, we can link important wiki pages within our site... so we would have the same visibility. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org On Mon, Mar 29, 2010 at 9:21 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: great! (i would prefer a wiki page.) real doc get's more visibility.. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.org wrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Tutorial: MyFaces 2 on Google App Engine
We should perhaps clean-up the outdated stuff from the homepage, anyways. I agree that. For example, I noticed yesterday that Irian link at Getting started page http://myfaces.apache.org/core20/gettingstarted.html is not working. On Mon, Mar 29, 2010 at 11:14 AM, Matthias Wessendorf mat...@apache.orgwrote: well, with the new cwiki, that should be more easy. We should perhaps clean-up the outdated stuff from the homepage, anyways. -M On Mon, Mar 29, 2010 at 10:10 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: imo we should move much more to the wiki... it's easier for users to participate. furthermore, we can link important wiki pages within our site... so we would have the same visibility. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org On Mon, Mar 29, 2010 at 9:21 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: great! (i would prefer a wiki page.) real doc get's more visibility.. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.org wrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: myfaces wiki
ok - i propose that we do it step by step. let's start to move the wiki of codi and extval to confluence. is that ok for everyone? @matthias: [1] describes the steps to request a cwiki space. regards, gerhard [1] http://cwiki.apache.org/confluence/display/CWIKI/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/24 Gabrielle Crawford gabrielle.crawf...@oracle.com +1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto: mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2629) Accept abstract FaceletContext, do not force AbstractFaceletContext
[ https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850832#action_12850832 ] Jakob Korherr commented on MYFACES-2629: Hi Lewis, We cast to the AbstractFaceletContext first, because our AbstractFaceletContext defines more methods than FaceletContext from the api, which we need internally. However if this is a big problem here, which it seems to me that it is, I'll take a look at those methods and maybe find another place to put them in order to not have to cast to AbstractFaceletContext. Accept abstract FaceletContext, do not force AbstractFaceletContext --- Key: MYFACES-2629 URL: https://issues.apache.org/jira/browse/MYFACES-2629 Project: MyFaces Core Issue Type: Improvement Components: General, JSR-314 Affects Versions: 2.0.0-beta-3 Environment: Tomcat 6.0+, MyFaces 2.0.0-beta3 API/Impl. Reporter: Lewis Gass I am the main coder on the Gracelets project (http://gracelets.sourceforge.net/) and have recently began integration of Groovy with JSF 2.0. In order for Gracelets to harness the already existing Facelets libraries it needs access to the TagLibrary class and the actual libraries loaded by the JSF 2.0 implementation. Since that library is not part of the JSF 2.0 public API, I have to write an extension for each different JSF 2.0 implementation in order to load them. I have been able to successfully integrate with the SUN RI with minimal code. However, in MyFaces Core implementation this code appears on line 135 of the org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate: AbstractFaceletContext actx = (AbstractFaceletContext) ctx; Gracelets has its own FaceletContext (which is part of the public API) in order to mimimize integration between different JSF 2.0 implementations. Since in MyFaces this is forced to be a particular sub class here, it breaks portability. Is there anyway this can be avoided? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2631) javax.faces.Messages.zh lacks two properties.
[
https://issues.apache.org/jira/browse/MYFACES-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850834#action_12850834
]
Jakob Korherr commented on MYFACES-2631:
Thanks, Mark!
I'll add them asap.
javax.faces.Messages.zh lacks two properties.
-
Key: MYFACES-2631
URL: https://issues.apache.org/jira/browse/MYFACES-2631
Project: MyFaces Core
Issue Type: Bug
Reporter: Mark Li
Original Estimate: 0.08h
Remaining Estimate: 0.08h
should add
javax.faces.validator.DoubleRangeValidator.NOT_IN_RANGE = 该值不在允许的 {0} 至 {1}
包围内.
javax.faces.validator.LongRangeValidator.NOT_IN_RANGE = 该值不在允许的 {0} 至 {1} 包围内.
to
javax.faces.Messages.zh.properties
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Tutorial: MyFaces 2 on Google App Engine
A big +1 on site clean up from me :) 2010/3/29 Ali Ok al...@aliok.com.tr We should perhaps clean-up the outdated stuff from the homepage, anyways. I agree that. For example, I noticed yesterday that Irian link at Getting started page http://myfaces.apache.org/core20/gettingstarted.html is not working. On Mon, Mar 29, 2010 at 11:14 AM, Matthias Wessendorf mat...@apache.orgwrote: well, with the new cwiki, that should be more easy. We should perhaps clean-up the outdated stuff from the homepage, anyways. -M On Mon, Mar 29, 2010 at 10:10 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: imo we should move much more to the wiki... it's easier for users to participate. furthermore, we can link important wiki pages within our site... so we would have the same visibility. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org On Mon, Mar 29, 2010 at 9:21 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: great! (i would prefer a wiki page.) real doc get's more visibility.. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.org wrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: myfaces wiki
Yes, great idea Gerhard! 2010/3/29 Gerhard Petracek gerhard.petra...@gmail.com ok - i propose that we do it step by step. let's start to move the wiki of codi and extval to confluence. is that ok for everyone? @matthias: [1] describes the steps to request a cwiki space. regards, gerhard [1] http://cwiki.apache.org/confluence/display/CWIKI/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/24 Gabrielle Crawford gabrielle.crawf...@oracle.com +1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto: mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Tutorial: MyFaces 2 on Google App Engine
@leonardo: can you please remove the broken link. once we have cwiki we should list all examples. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Ali Ok al...@aliok.com.tr We should perhaps clean-up the outdated stuff from the homepage, anyways. I agree that. For example, I noticed yesterday that Irian link at Getting started page http://myfaces.apache.org/core20/gettingstarted.html is not working. On Mon, Mar 29, 2010 at 11:14 AM, Matthias Wessendorf mat...@apache.orgwrote: well, with the new cwiki, that should be more easy. We should perhaps clean-up the outdated stuff from the homepage, anyways. -M On Mon, Mar 29, 2010 at 10:10 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: imo we should move much more to the wiki... it's easier for users to participate. furthermore, we can link important wiki pages within our site... so we would have the same visibility. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org On Mon, Mar 29, 2010 at 9:21 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: great! (i would prefer a wiki page.) real doc get's more visibility.. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.org wrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
Re: GSoC
Ok, I created a new ticket for this: https://issues.apache.org/jira/browse/MYFACES-2632 -Matthias On Thu, Mar 25, 2010 at 2:23 PM, Matthias Wessendorf mat...@apache.org wrote: http://markmail.org/message/mk6th4uj7o6fpqic based on that, I will overhaul the JIRA issue and make it neutral. Ali still can use his wiki page, to collect data, for his application. -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: myfaces wiki
hi, yes - i'll help with the admin tasks... @space-key: +1 for myfaces regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Matthias Wessendorf mat...@apache.org # Include the cwiki account name of a PMC member (preferably the PMC chair) who will help administer the space. Gerhard, do you want to help to administer the space? For the next weeks I have not much to time for that... # Also specify the key name for the Space. The key name cannot be changed. = myfaces ? :) .Matthias On Mon, Mar 29, 2010 at 10:25 AM, Gerhard Petracek gerhard.petra...@gmail.com wrote: ok - i propose that we do it step by step. let's start to move the wiki of codi and extval to confluence. is that ok for everyone? @matthias: [1] describes the steps to request a cwiki space. regards, gerhard [1] http://cwiki.apache.org/confluence/display/CWIKI/Index http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/24 Gabrielle Crawford gabrielle.crawf...@oracle.com +1 confluence is so much better Jakob Korherr wrote: +1 from me :) Frankly I don't really like the current wiki.. Regards, Jakob 2010/3/24 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org +1 I don't remember the outcome of the old discussion, wasn't there one? Anyways I am +1 on confluence... -Matthias On Wed, Mar 24, 2010 at 11:30 AM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: hi @ all, what do you think about moving our wiki to confluence[1]? regards, gerhard [1] http://cwiki.apache.org/confluence/ http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2618) Don't warn if there is no submitted value in the current request for every EditableValueHolder
[ https://issues.apache.org/jira/browse/MYFACES-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850845#action_12850845 ] Jakob Korherr commented on MYFACES-2618: Hi Martin, Ooh, ok - frankly, I did not think of that. So I just asked the user, who brought that up on the mailing list, to describe his scenario in more detail here or even to add a small test webapp. I hope this will help us figure out what to do. Regards, Jakob Don't warn if there is no submitted value in the current request for every EditableValueHolder -- Key: MYFACES-2618 URL: https://issues.apache.org/jira/browse/MYFACES-2618 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Minor Attachments: MYFACES-2618.patch Take a look at HtmlRendererUtils.decodeUIInput(): There we do a check for paramMap.containsKey(clientId) and if this returns false (meaning that there is no submitted value for the given component in the request parameter map) we add a warning message to the log. I think we should get rid of this warning, because as a reason of AJAX it is on my opinion normal to not submit all values of a form in every request. Furthermore it has no impact on the lifecycle, because if the submitted value is null it just isn't processed any further. See also the related thread on the mailing list: http://www.mail-archive.com/us...@myfaces.apache.org/msg55238.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Tutorial: MyFaces 2 on Google App Engine
Hi! Latest IntelliJ IDEAs come with GAE support and it works fine! I have used it already in the past and I didn't have any problem with it. It can be found in Tools Upload App Engine Application. In order for that to work you have to define a Google App Engine facet (IntelliJ will auto-detect it if you have the appengine.xml file in your sources) and you are set! Cheers, Bruno On 29 March 2010 16:19, Jan-Kees van Andel jankeesvanan...@gmail.comwrote: Yeah, very cool Ali! Thanks Have you also tried to use IntelliJ for your project? I never use IntelliJ, but never used GAE. Don't know if any specific plugin is required for GAE? /JK 2010/3/29 Ali Ok al...@aliok.com.tr Do you mind to put this tutorial to our side as well? OK, it would be great :) I will convert it to APT format and send a patch (probably next week). Greetings, Ali On Mon, Mar 29, 2010 at 9:49 AM, Matthias Wessendorf mat...@apache.orgwrote: Very cool! thx, Ali! Do you mind to put this tutorial to our side as well? -Matthias On Sat, Mar 27, 2010 at 11:54 PM, Ali Ok al...@aliok.com.tr wrote: Since MyFaces 2 Beta-3 (includes Google App Engine support) is released, I post a tutorial on my blog: MyFaces 2 on Google App Engine : Tutorial with Eclipse http://blog.aliok.com.tr/2010/03/myfaces-2-on-google-app-engine-how-to.html Regards, Ali -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- My Blog: http://blog.aliok.com.tr Twitter: http://twitter.com/aliok_tr
[jira] Created: (TRINIDAD-1766) Train look and feel improvement
Train look and feel improvement --- Key: TRINIDAD-1766 URL: https://issues.apache.org/jira/browse/TRINIDAD-1766 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.2.14-core , 2.0.0.3-core Reporter: Cosmin Martinconi Priority: Minor The train demo needs a visual look and feel improvement, numbering and maybe a line link between stations. See the attached screenshot. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2631) javax.faces.Messages.zh lacks two properties.
[
https://issues.apache.org/jira/browse/MYFACES-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850853#action_12850853
]
Jakob Korherr commented on MYFACES-2631:
I added your proposed messages as _detail and set the normal message to the
standard validation error message used in the whole properties file.
javax.faces.Messages.zh lacks two properties.
-
Key: MYFACES-2631
URL: https://issues.apache.org/jira/browse/MYFACES-2631
Project: MyFaces Core
Issue Type: Bug
Reporter: Mark Li
Original Estimate: 0.08h
Remaining Estimate: 0.08h
should add
javax.faces.validator.DoubleRangeValidator.NOT_IN_RANGE = 该值不在允许的 {0} 至 {1}
包围内.
javax.faces.validator.LongRangeValidator.NOT_IN_RANGE = 该值不在允许的 {0} 至 {1} 包围内.
to
javax.faces.Messages.zh.properties
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2631) javax.faces.Messages.zh lacks two properties.
[
https://issues.apache.org/jira/browse/MYFACES-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr resolved MYFACES-2631.
Resolution: Fixed
Fix Version/s: 2.0.0-beta-4
Assignee: Jakob Korherr
javax.faces.Messages.zh lacks two properties.
-
Key: MYFACES-2631
URL: https://issues.apache.org/jira/browse/MYFACES-2631
Project: MyFaces Core
Issue Type: Bug
Reporter: Mark Li
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-4
Original Estimate: 0.08h
Remaining Estimate: 0.08h
should add
javax.faces.validator.DoubleRangeValidator.NOT_IN_RANGE = 该值不在允许的 {0} 至 {1}
包围内.
javax.faces.validator.LongRangeValidator.NOT_IN_RANGE = 该值不在允许的 {0} 至 {1} 包围内.
to
javax.faces.Messages.zh.properties
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-865) Simplify AJAX component handling
Simplify AJAX component handling Key: TOBAGO-865 URL: https://issues.apache.org/jira/browse/TOBAGO-865 Project: MyFaces Tobago Issue Type: Task Components: Core, Themes Reporter: Udo Schnurpfeil Assignee: Bernd Bohmann Remove AjaxComponent and AjaxRenderer classes (which was used internally). In the DOM the elements are replaced instead of the innerHtml -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (EXTVAL-88) Allow case insensitive comparison for String in the Equals and NotEquals validations
[
https://issues.apache.org/jira/browse/EXTVAL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850880#action_12850880
]
Rudy De Busscher commented on EXTVAL-88:
Usage example with v2 of Gerhard becomes
@NotEquals(value = { firstName }, parameters = { CaseInsensitive.class })
Allow case insensitive comparison for String in the Equals and NotEquals
validations
Key: EXTVAL-88
URL: https://issues.apache.org/jira/browse/EXTVAL-88
Project: MyFaces Extensions Validator
Issue Type: New Feature
Components: Property Validation
Affects Versions: 1.2.3, 2.0.3, 1.1.3
Reporter: Rudy De Busscher
Priority: Minor
Attachments: EXTVAL-88.patch, EXTVAL-88_unittests.patch,
EXTVAL-88_v2.patch
Created a new ValidationParameter to indicate case sensitive (the default, as
before) or case insensitive.
The EqualsStrategy is adjusted to take this parameter into account.
Usage example:
@NotEquals(value = { firstName }, parameters = {
CaseComparator.CaseInsensitive.class })
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2621) BeanValidation does not work with Unified EL 2.2
[ https://issues.apache.org/jira/browse/MYFACES-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850895#action_12850895 ] Jakob Korherr commented on MYFACES-2621: Looking at all the different ValueExpression wrappers I figured out the following: TagValueExpression - needed for bean validation: created TagValueExpressionUEL LocationValueExpression - needed for bean validation: created LocationValueExpressionUEL ValueBindingToValueExpression - not needed: only used in ApplicationImpl to create a component with a binding MappedValueExpression, IndexedValueExpression, IteratedValueExpression - not needed: only used for c:forEach and bean validation does not work with properties of Map, List, array... because they can't be annotated LiteralValueExpression - not needed: bean validation only works for real properties of a class So I'll commit the solution with TagValueExpressionUEL and LocationValueExpressionUEL. BeanValidation does not work with Unified EL 2.2 Key: MYFACES-2621 URL: https://issues.apache.org/jira/browse/MYFACES-2621 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Environment: bean validation 1.0.0.GA, unified el 2.2 Reporter: Jakob Korherr Assignee: Jakob Korherr When using the new Unified EL 2.2, BeanValidation does not work, because _BeanValidatorUELUtils.getUELValueReferenceWrapper() always returns null. See also the related thread on the mailing list: http://www.mail-archive.com/us...@myfaces.apache.org/msg55250.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2621) BeanValidation does not work with Unified EL 2.2
[ https://issues.apache.org/jira/browse/MYFACES-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850899#action_12850899 ] Jakob Korherr commented on MYFACES-2621: So this works now perfectly :) The only thing which I really don't like now is that we are calling ExternalSpecifications.isUnifiedELAvailable() very often (for every ValueExpression in TagAttributeImpl at least once) and this method is synchronized. And frankly, I really don't understand why this one has to be synchronized. It is null at first and then it changes to Boolean.TRUE or Boolean.FALSE and is never changed again, as Leonardo wrote before. When we're removing synchronized the only thing which can happen is that more than one thread sets it from null to true or false, but this really is no problem, because every thread will come up with the same result here! So removing synchronized should not cause any problems here or am I missing something? What were your concerns, Jan-Kees? BeanValidation does not work with Unified EL 2.2 Key: MYFACES-2621 URL: https://issues.apache.org/jira/browse/MYFACES-2621 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Environment: bean validation 1.0.0.GA, unified el 2.2 Reporter: Jakob Korherr Assignee: Jakob Korherr When using the new Unified EL 2.2, BeanValidation does not work, because _BeanValidatorUELUtils.getUELValueReferenceWrapper() always returns null. See also the related thread on the mailing list: http://www.mail-archive.com/us...@myfaces.apache.org/msg55250.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2621) BeanValidation does not work with Unified EL 2.2
[ https://issues.apache.org/jira/browse/MYFACES-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850902#action_12850902 ] Martin Marinschek commented on MYFACES-2621: Sounds like a totally sure case for removing synchronized ;) best regards, Martin BeanValidation does not work with Unified EL 2.2 Key: MYFACES-2621 URL: https://issues.apache.org/jira/browse/MYFACES-2621 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Environment: bean validation 1.0.0.GA, unified el 2.2 Reporter: Jakob Korherr Assignee: Jakob Korherr When using the new Unified EL 2.2, BeanValidation does not work, because _BeanValidatorUELUtils.getUELValueReferenceWrapper() always returns null. See also the related thread on the mailing list: http://www.mail-archive.com/us...@myfaces.apache.org/msg55250.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-866) Add capabilities and update browsers in UserAgent class
Add capabilities and update browsers in UserAgent class --- Key: TOBAGO-866 URL: https://issues.apache.org/jira/browse/TOBAGO-866 Project: MyFaces Tobago Issue Type: Improvement Components: Core, Themes Reporter: Udo Schnurpfeil Assignee: Bernd Bohmann The UserAgent should say, e. g. it supports placeholder. Also updating the browser list. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTSCRIPT-109) Improve the test coverage of the system
Improve the test coverage of the system --- Key: EXTSCRIPT-109 URL: https://issues.apache.org/jira/browse/EXTSCRIPT-109 Project: MyFaces Extensions Scripting Issue Type: Bug Components: Core Affects Versions: Beta-1 Reporter: Werner Punz Assignee: Werner Punz Priority: Minor -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2618) Don't warn if there is no submitted value in the current request for every EditableValueHolder
[ https://issues.apache.org/jira/browse/MYFACES-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850929#action_12850929 ] Dave commented on MYFACES-2618: --- This is our use case. We made an ajax-enabled JSF component. When user changes select value of the component, an ajax request with the new select value will be sent to the server side. We use the component decode() method to process the ajax request. The ajax request parameters: var formSubmitParam = select.form.id + _SUBMIT; // why need this? var url = serverURL + ajax=1sid= + Math.random() + + formSubmitParam + =1 + + clientId + = + selectValue; the serverURL contains view_state for restoring view. If we do not add the formSubmitParam, the component decode() method will not be called. The url above works well for processing ajax request in the decode method. But we got the warning. The warning is not prefered. If there is a way to keep it silent, it would be great, for example, adding a parameter. Don't warn if there is no submitted value in the current request for every EditableValueHolder -- Key: MYFACES-2618 URL: https://issues.apache.org/jira/browse/MYFACES-2618 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Minor Attachments: MYFACES-2618.patch Take a look at HtmlRendererUtils.decodeUIInput(): There we do a check for paramMap.containsKey(clientId) and if this returns false (meaning that there is no submitted value for the given component in the request parameter map) we add a warning message to the log. I think we should get rid of this warning, because as a reason of AJAX it is on my opinion normal to not submit all values of a form in every request. Furthermore it has no impact on the lifecycle, because if the submitted value is null it just isn't processed any further. See also the related thread on the mailing list: http://www.mail-archive.com/us...@myfaces.apache.org/msg55238.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-137) TCK: Missing Lifecycle test web app
TCK: Missing Lifecycle test web app --- Key: PORTLETBRIDGE-137 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-137 Project: MyFaces Portlet Bridge Issue Type: Bug Components: General Reporter: Alistair Wilson TCK requires a web application to test lifecycle id handling in section 3.2 of the bridge specification: LIFECYCLE_ID is a String valued configuration parameter that describes the ID of the Lifecycle the bridge uses when executing Faces requests. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-867) Ajax is always possible in Tobago (can't be deactivated)
Ajax is always possible in Tobago (can't be deactivated) Key: TOBAGO-867 URL: https://issues.apache.org/jira/browse/TOBAGO-867 Project: MyFaces Tobago Issue Type: Task Components: Core Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor The ajax-enabled tag is deprecated in tobago-config.xml now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOBAGO-867) Ajax is always possible in Tobago (can't be deactivated)
[ https://issues.apache.org/jira/browse/TOBAGO-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-867. Resolution: Fixed Fix Version/s: 1.5.0 1.5.0-alpha-2 Ajax is always possible in Tobago (can't be deactivated) Key: TOBAGO-867 URL: https://issues.apache.org/jira/browse/TOBAGO-867 Project: MyFaces Tobago Issue Type: Task Components: Core Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor Fix For: 1.5.0-alpha-2, 1.5.0 The ajax-enabled tag is deprecated in tobago-config.xml now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2629) Accept abstract FaceletContext, do not force AbstractFaceletContext
[ https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850996#action_12850996 ] Lewis Gass commented on MYFACES-2629: - I imagined that you probably have additional functionality via the Abstract implementation, but could you use the wrapper pattern instead of casting? AbstractFaceletContext actx = new SomeASFFaceletContext(ctx); And then pass on the calls to the original where possible and also allowing more functionality? Accept abstract FaceletContext, do not force AbstractFaceletContext --- Key: MYFACES-2629 URL: https://issues.apache.org/jira/browse/MYFACES-2629 Project: MyFaces Core Issue Type: Improvement Components: General, JSR-314 Affects Versions: 2.0.0-beta-3 Environment: Tomcat 6.0+, MyFaces 2.0.0-beta3 API/Impl. Reporter: Lewis Gass I am the main coder on the Gracelets project (http://gracelets.sourceforge.net/) and have recently began integration of Groovy with JSF 2.0. In order for Gracelets to harness the already existing Facelets libraries it needs access to the TagLibrary class and the actual libraries loaded by the JSF 2.0 implementation. Since that library is not part of the JSF 2.0 public API, I have to write an extension for each different JSF 2.0 implementation in order to load them. I have been able to successfully integrate with the SUN RI with minimal code. However, in MyFaces Core implementation this code appears on line 135 of the org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate: AbstractFaceletContext actx = (AbstractFaceletContext) ctx; Gracelets has its own FaceletContext (which is part of the public API) in order to mimimize integration between different JSF 2.0 implementations. Since in MyFaces this is forced to be a particular sub class here, it breaks portability. Is there anyway this can be avoided? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2629) Accept abstract FaceletContext, do not force AbstractFaceletContext
[ https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850996#action_12850996 ] Lewis Gass edited comment on MYFACES-2629 at 3/29/10 4:51 PM: -- I imagined that you probably have additional functionality via the Abstract implementation, but could you use the wrapper pattern instead of casting? AbstractFaceletContext actx = new SomeASFFaceletContext(ctx); or AbstractFaceletContext actx = ctx instanceof AbstractFaceletContext ? (AbstractFaceletContext) ctx : new WrapperContext(ctx); And then pass on the calls to the original where possible and also allowing more functionality? was (Author: elponderador): I imagined that you probably have additional functionality via the Abstract implementation, but could you use the wrapper pattern instead of casting? AbstractFaceletContext actx = new SomeASFFaceletContext(ctx); And then pass on the calls to the original where possible and also allowing more functionality? Accept abstract FaceletContext, do not force AbstractFaceletContext --- Key: MYFACES-2629 URL: https://issues.apache.org/jira/browse/MYFACES-2629 Project: MyFaces Core Issue Type: Improvement Components: General, JSR-314 Affects Versions: 2.0.0-beta-3 Environment: Tomcat 6.0+, MyFaces 2.0.0-beta3 API/Impl. Reporter: Lewis Gass I am the main coder on the Gracelets project (http://gracelets.sourceforge.net/) and have recently began integration of Groovy with JSF 2.0. In order for Gracelets to harness the already existing Facelets libraries it needs access to the TagLibrary class and the actual libraries loaded by the JSF 2.0 implementation. Since that library is not part of the JSF 2.0 public API, I have to write an extension for each different JSF 2.0 implementation in order to load them. I have been able to successfully integrate with the SUN RI with minimal code. However, in MyFaces Core implementation this code appears on line 135 of the org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate: AbstractFaceletContext actx = (AbstractFaceletContext) ctx; Gracelets has its own FaceletContext (which is part of the public API) in order to mimimize integration between different JSF 2.0 implementations. Since in MyFaces this is forced to be a particular sub class here, it breaks portability. Is there anyway this can be avoided? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2629) Accept abstract FaceletContext, do not force AbstractFaceletContext
[ https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851011#action_12851011 ] Leonardo Uribe commented on MYFACES-2629: - I never thought see one case like this. In theory, it is not expected to have a wrapper for FaceletContext. Probe of this fact are: - There is no FaceletContextFactory or something similar. - There is no documentation about when and where instance of this class are created. - The reason why FaceletContext is on the spec is to expose some methods required by FaceletHandler implementations. The reason why AbstractFaceletContext exists is provide a class that exposes some inner methods required by facelets implementation. This includes: - Handle TemplateClient class (used by ui components). - Composite component cases. - Partial State Saving methods. - Bean Validation cases. All those methods depends in one way or another of the state stored in DefaultFaceletContext. Obviously it is possible to move this to some place (an object stored on FacesContext or something similar), but I'm not very sure about that. If gracelets needs some specific code per impl to work, why don't create a wrapper there that extends from myfaces AbstractFaceletContext and delegate correctly, or even better, why don't we update myfaces code to expose in some way what gracelets needs. I think the right place to put that code is on that integration module. Other option is create a CustomFaceletContextFactory and do on myfaces what is missing on the spec (like in LifecycleProviderFactory to allow integration with web containers). In that place we can do something to wrap FaceletContext object in a standard way. Accept abstract FaceletContext, do not force AbstractFaceletContext --- Key: MYFACES-2629 URL: https://issues.apache.org/jira/browse/MYFACES-2629 Project: MyFaces Core Issue Type: Improvement Components: General, JSR-314 Affects Versions: 2.0.0-beta-3 Environment: Tomcat 6.0+, MyFaces 2.0.0-beta3 API/Impl. Reporter: Lewis Gass I am the main coder on the Gracelets project (http://gracelets.sourceforge.net/) and have recently began integration of Groovy with JSF 2.0. In order for Gracelets to harness the already existing Facelets libraries it needs access to the TagLibrary class and the actual libraries loaded by the JSF 2.0 implementation. Since that library is not part of the JSF 2.0 public API, I have to write an extension for each different JSF 2.0 implementation in order to load them. I have been able to successfully integrate with the SUN RI with minimal code. However, in MyFaces Core implementation this code appears on line 135 of the org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate: AbstractFaceletContext actx = (AbstractFaceletContext) ctx; Gracelets has its own FaceletContext (which is part of the public API) in order to mimimize integration between different JSF 2.0 implementations. Since in MyFaces this is forced to be a particular sub class here, it breaks portability. Is there anyway this can be avoided? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2629) Accept abstract FaceletContext, do not force AbstractFaceletContext
[ https://issues.apache.org/jira/browse/MYFACES-2629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851019#action_12851019 ] Leonardo Uribe commented on MYFACES-2629: - Maybe we need an alternative interface called MyfacesFaceletContext with the required methods, and cast to that interface instead of AbstractFaceletContext (really in that case AbstractFaceletContext should implement MyfacesFaceletContext), so in gracelets you can create a wrapper that extends from your custom FaceletContext wrapper and implement that interface, delegating all required methods. I'm just giving some ideas to make what looks better in this case. Accept abstract FaceletContext, do not force AbstractFaceletContext --- Key: MYFACES-2629 URL: https://issues.apache.org/jira/browse/MYFACES-2629 Project: MyFaces Core Issue Type: Improvement Components: General, JSR-314 Affects Versions: 2.0.0-beta-3 Environment: Tomcat 6.0+, MyFaces 2.0.0-beta3 API/Impl. Reporter: Lewis Gass I am the main coder on the Gracelets project (http://gracelets.sourceforge.net/) and have recently began integration of Groovy with JSF 2.0. In order for Gracelets to harness the already existing Facelets libraries it needs access to the TagLibrary class and the actual libraries loaded by the JSF 2.0 implementation. Since that library is not part of the JSF 2.0 public API, I have to write an extension for each different JSF 2.0 implementation in order to load them. I have been able to successfully integrate with the SUN RI with minimal code. However, in MyFaces Core implementation this code appears on line 135 of the org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate: AbstractFaceletContext actx = (AbstractFaceletContext) ctx; Gracelets has its own FaceletContext (which is part of the public API) in order to mimimize integration between different JSF 2.0 implementations. Since in MyFaces this is forced to be a particular sub class here, it breaks portability. Is there anyway this can be avoided? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1680) Introduce include-property in CSS
[ https://issues.apache.org/jira/browse/TRINIDAD-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851027#action_12851027 ] Jeanne Waldman commented on TRINIDAD-1680: -- Hi, The coding style is Code Style: JDeveloper Classic, Indentation Size/Tab Size 2, no tabs. Put the arguments of a method on their own line, indented from the start of the file. When I applied your patch, I saw a lot of differences in styling. I was expecting only differences in the lines of code you changed. For example, in the original file, the parameters are like this static public StyleSheetEntry parseCSSSource( ParseContext context, NameResolver resolver, StringsourceName, Class? expectedType) throws IOException and in yours it is like: static public StyleSheetEntry parseCSSSource(ParseContext context, NameResolver resolver, String sourceName, Class? expectedType) throws IOException I also saw some of the imports reordered. We like to have them in alphabetical order. I see import org.apache.myfaces.trinidadinternal.style.util.CSSUtils; import org.apache.myfaces.trinidadinternal.style.util.StyleUtils; have been moved before style.xml to after. - Jeanne I wonder if you selected 'Reformat' to reformat the file? Introduce include-property in CSS - Key: TRINIDAD-1680 URL: https://issues.apache.org/jira/browse/TRINIDAD-1680 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Marius Petoi Priority: Minor Attachments: includeProperty.patch, includeProperty.patch, includeProperty.patch, patchIncludeProperty.patch The include-property feature is present in the XSS, but it is not supported in the CSS. With this, we are one step closer to eliminating the old XSS files and replacing them with CSS. In the XSS files, the syntax of includeProperty is: !-- AFVeryDarkForeground is the darkest foreground color in the core (green) color ramp -- style name=AFVeryDarkForeground includeProperty name=AFVeryDarkBackground propertyName=background-color localPropertyName=color/ /style This should be ported to CSS also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1680) Introduce include-property in CSS
[
https://issues.apache.org/jira/browse/TRINIDAD-1680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851033#action_12851033
]
Jeanne Waldman commented on TRINIDAD-1680:
--
More comments:
1. In the skinning.xml file, can you explain why this would be useful to
someone?
2. In purpleSkin.css, can you add more properties to the selectors to make sure
they still get included?
/* test the new include property functionality */
.AFTestForegroundColor:alias {color: Red; font-style:bold;}
.AFTestBackgroundColor:alias {-tr-include-property:
property(selector=.AFTestForegroundColor:alias,propertyName=color,
localPropertyName=background-color); padding: 2px; margin:5px;}
af|commandButton
{
background-color: purple;
-tr-include-property:
property(selector=.AFTestBackgroundColor:alias,propertyName=background-color,localPropertyName=background-color);
min-width: 100px;
}
Introduce include-property in CSS
-
Key: TRINIDAD-1680
URL: https://issues.apache.org/jira/browse/TRINIDAD-1680
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Skinning
Reporter: Marius Petoi
Priority: Minor
Attachments: includeProperty.patch, includeProperty.patch,
includeProperty.patch, patchIncludeProperty.patch
The include-property feature is present in the XSS, but it is not supported
in the CSS. With this, we are one step closer to eliminating the old XSS
files and replacing them with CSS. In the XSS files, the syntax of
includeProperty is:
!-- AFVeryDarkForeground is the darkest foreground color in the core (green)
color ramp --
style name=AFVeryDarkForeground
includeProperty name=AFVeryDarkBackground
propertyName=background-color
localPropertyName=color/
/style
This should be ported to CSS also.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1171) A failing client-side validator while using PPR causes a page hang with hourglass in IE when clicking in a empty spot on the page
[
https://issues.apache.org/jira/browse/TRINIDAD-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851034#action_12851034
]
komarios commented on TRINIDAD-1171:
Hello Markus,
For our organization it is an important issue and easily reproducible, though
we were not able to pinpoint the exact conditions on which it occurs. Some pcs
do it, some don't.
I would appreciate it if you could fix this bug once again in the current
version, or at least provide a workaround.
Thanks a lot for the good job you are doing.
A failing client-side validator while using PPR causes a page hang with
hourglass in IE when clicking in a empty spot on the page
-
Key: TRINIDAD-1171
URL: https://issues.apache.org/jira/browse/TRINIDAD-1171
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.7-core, 1.0.8-core, 1.0.9-core
Environment: Windows IE6 and IE7
Reporter: Mark van den Boomen
Attachments: Trinidad-1.0.8_revert_TRINIDAD-952,
TrinidadJira1171Validation.war
Code to reproduce:
tr:form id=testValidationForm
tr:inputDate value=#{test.myDate} id=myDate
partialTriggers=validate
tr:convertDateTime pattern=dd-MM- /
/tr:inputDate
tr:commandButton text=Validate partialSubmit=true id=validate /
/tr:form
Steps to reproduce:
1. fill in something in the date field so the (date) validation will fail
(eg. hello)
2. press Validate
3. Now click on a spot on the page (but within the body area)
Now the hourglass shows in IE. The only way to get rid of it is to click
outside the body of the page of on the toolbar of IE.
I traced the problem back to bug TRINIDAD-952 whose fix is causing the
problem, after reverting the change everything works ok in 1.0.8 .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2633) Cannot set properties on custom composite component class when are implemented on getter/setter
Cannot set properties on custom composite component class when are implemented on getter/setter --- Key: MYFACES-2633 URL: https://issues.apache.org/jira/browse/MYFACES-2633 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Implementing a custom composite component class with some properties in the old way (getter/setter), so there is no attribute map on the middle, I found a bug when I try to set them. The stack trace is this: javax.faces.FacesException: java.lang.IllegalArgumentException: argument type mismatch at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:222) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:389) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:865) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520) Caused by: java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at javax.faces.component._ComponentAttributesMap.setComponentProperty(_ComponentAttributesMap.java:450) at javax.faces.component._ComponentAttributesMap.put(_ComponentAttributesMap.java:345) at javax.faces.component._ComponentAttributesMap.put(_ComponentAttributesMap.java:58) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentRule$ValueExpressionMetadata.applyMetadata(CompositeComponentRule.java:83) at org.apache.myfaces.view.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:45) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.setAttributes(CompositeComponentResourceTagHandler.java:269) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:200) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:54) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:51) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:59) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:255) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:54) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:51) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:59) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:255) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:54) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:51) at
[jira] Resolved: (MYFACES-2633) Cannot set properties on custom composite component class when are implemented on getter/setter
[ https://issues.apache.org/jira/browse/MYFACES-2633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2633. - Resolution: Fixed Fix Version/s: 2.0.0-beta-4 Cannot set properties on custom composite component class when are implemented on getter/setter --- Key: MYFACES-2633 URL: https://issues.apache.org/jira/browse/MYFACES-2633 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-4 Implementing a custom composite component class with some properties in the old way (getter/setter), so there is no attribute map on the middle, I found a bug when I try to set them. The stack trace is this: javax.faces.FacesException: java.lang.IllegalArgumentException: argument type mismatch at org.apache.myfaces.context.ExceptionHandlerImpl.wrap(ExceptionHandlerImpl.java:241) at org.apache.myfaces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:156) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:222) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:191) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:389) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:324) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:535) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:865) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:539) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520) Caused by: java.lang.IllegalArgumentException: argument type mismatch at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at javax.faces.component._ComponentAttributesMap.setComponentProperty(_ComponentAttributesMap.java:450) at javax.faces.component._ComponentAttributesMap.put(_ComponentAttributesMap.java:345) at javax.faces.component._ComponentAttributesMap.put(_ComponentAttributesMap.java:58) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentRule$ValueExpressionMetadata.applyMetadata(CompositeComponentRule.java:83) at org.apache.myfaces.view.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:45) at org.apache.myfaces.view.facelets.tag.composite.CompositeComponentResourceTagHandler.setAttributes(CompositeComponentResourceTagHandler.java:269) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:200) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:54) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:51) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:59) at org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply(ComponentTagHandlerDelegate.java:255) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:54) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:51) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:59) at
[jira] Reopened: (TRINIDAD-744) Update translated message files
[ https://issues.apache.org/jira/browse/TRINIDAD-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bud Osterberg reopened TRINIDAD-744: New translation drop for 1.2.12.2 Update translated message files --- Key: TRINIDAD-744 URL: https://issues.apache.org/jira/browse/TRINIDAD-744 Project: MyFaces Trinidad Issue Type: Bug Reporter: Bud Osterberg Assignee: Matthias Weßendorf Fix For: 1.0.8-core, 1.2.8-core, 1.2.12-core, 1.2.13-core Attachments: trinidad-translations.xml, trinslations-090917.tar.gz, trinslations080326.zip, trinslations080326.zip.md5, trinslations080326.zip.sha1, trinslations080702.zip, trinslations090825.tar.gz, trinslations_090112.jar, trinslations_090421.tar.gz, trinslations_090701.jar, trinslations_1.2.12.1_091009.tar.gz, trinslations_1.2.12.1_091207.tar.gz, trinslations_1.2.12.2_091009.tar.gz, trinslations_1.2.12.2_091022.tar.gz, trinslations_1.2.12.2_100329.zip Latest versions of the message files (LoggerBundle, MessageBundle, and CoreBundle) need translations. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1767) throw an IllegalStateException on SkinFactory.addSkin for duplicate skins.
throw an IllegalStateException on SkinFactory.addSkin for duplicate skins. -- Key: TRINIDAD-1767 URL: https://issues.apache.org/jira/browse/TRINIDAD-1767 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.2.13-core Reporter: Jeanne Waldman hrow an IllegalStateException from Trinidad's SkinFactory.addSkin() method if a skin id that already exists is added again. This will not change the method signature since IllegalStateException is an unchecked exception. This will keep a duplicate skin from overriding an existing one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Ideas for GSoC
Hey Guys, the deadline for students to sign up for the GSoC program is coming and I thought it would be really cool to get the chance to participate and contribute to MyFaces. I co-organized/attended a talk by Matthias Wessendorf and Bernd Bohmann on JSF 2.0 / MyFaces 2.0 in January and I'm hooked since then. Long story short, there are only two MyFaces tickets in the GSoC JIRA and I just wanted to ask you guys if you have some more ideas for which I could apply. Cheers, Tobias
Re: Ideas for GSoC
hi tobias, are you interested in client-side validation based on bean-validation (jsr 303) constraints? regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Tobias Ullrich li...@dump.netvanced.eu Hey Guys, the deadline for students to sign up for the GSoC program is coming and I thought it would be really cool to get the chance to participate and contribute to MyFaces. I co-organized/attended a talk by Matthias Wessendorf and Bernd Bohmann on JSF 2.0 / MyFaces 2.0 in January and I'm hooked since then. Long story short, there are only two MyFaces tickets in the GSoC JIRA and I just wanted to ask you guys if you have some more ideas for which I could apply. Cheers, Tobias
[jira] Updated: (PORTLETBRIDGE-137) TCK: Missing Lifecycle test web app
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alistair Wilson updated PORTLETBRIDGE-137: -- Status: Patch Available (was: Open) TCK: Missing Lifecycle test web app --- Key: PORTLETBRIDGE-137 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-137 Project: MyFaces Portlet Bridge Issue Type: Bug Components: General Reporter: Alistair Wilson TCK requires a web application to test lifecycle id handling in section 3.2 of the bridge specification: LIFECYCLE_ID is a String valued configuration parameter that describes the ID of the Lifecycle the bridge uses when executing Faces requests. Patch to follow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2632) HTML 5 renderkit for MyFaces
[ https://issues.apache.org/jira/browse/MYFACES-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851143#action_12851143 ] Ali Ok commented on MYFACES-2632: - Here is a detailed outline: http://wiki.apache.org/myfaces/GSoC2010_HTML5 HTML 5 renderkit for MyFaces Key: MYFACES-2632 URL: https://issues.apache.org/jira/browse/MYFACES-2632 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf running into this document: http://diveintohtml5.org/forms.html I started playing with some of the new widgets in my Chromium browser (I wasn't aware that spinbox/sliders are part of HTML5). What about trying to find someone for a GSoC project, to add a (raw) HTML 5 renderkit? Bernd and I talked about a potential renderkit last time we saw each other, but now there is actually some (raw) support on it inside of some browsers... Why not introducing an hx:*** namespace that could contain stuff as the following: -hx:inputRangeSlider -hx:inputColor -hx:whatEverNewWidgetIsPartOfHTML5 / And/or some more functional stuff, like drag-and-drop: -fx:dragAndDrop... (could be done as a behavior) etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2632) HTML 5 renderkit for MyFaces
[ https://issues.apache.org/jira/browse/MYFACES-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851144#action_12851144 ] Ali Ok commented on MYFACES-2632: - I've been digging in and discussing this idea with the MyFaces community since January. Here is a detailed outline and my proposal at Apache MyFaces wiki: http://wiki.apache.org/myfaces/GSoC2010_HTML5 HTML 5 renderkit for MyFaces Key: MYFACES-2632 URL: https://issues.apache.org/jira/browse/MYFACES-2632 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf running into this document: http://diveintohtml5.org/forms.html I started playing with some of the new widgets in my Chromium browser (I wasn't aware that spinbox/sliders are part of HTML5). What about trying to find someone for a GSoC project, to add a (raw) HTML 5 renderkit? Bernd and I talked about a potential renderkit last time we saw each other, but now there is actually some (raw) support on it inside of some browsers... Why not introducing an hx:*** namespace that could contain stuff as the following: -hx:inputRangeSlider -hx:inputColor -hx:whatEverNewWidgetIsPartOfHTML5 / And/or some more functional stuff, like drag-and-drop: -fx:dragAndDrop... (could be done as a behavior) etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2632) HTML 5 renderkit for MyFaces
[ https://issues.apache.org/jira/browse/MYFACES-2632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851146#action_12851146 ] Ali Ok commented on MYFACES-2632: - My GSoC application can be found at http://socghop.appspot.com/gsoc/student_proposal/show/google/gsoc2010/ali_ok/t126990106550 Since viewing the GSoC application requires a Google account, I synchronized the wiki page[1] and the application at the GSOC system to make it easy to view the application. [1] : http://wiki.apache.org/myfaces/GSoC2010_HTML5 HTML 5 renderkit for MyFaces Key: MYFACES-2632 URL: https://issues.apache.org/jira/browse/MYFACES-2632 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Reporter: Matthias Weßendorf Assignee: Matthias Weßendorf running into this document: http://diveintohtml5.org/forms.html I started playing with some of the new widgets in my Chromium browser (I wasn't aware that spinbox/sliders are part of HTML5). What about trying to find someone for a GSoC project, to add a (raw) HTML 5 renderkit? Bernd and I talked about a potential renderkit last time we saw each other, but now there is actually some (raw) support on it inside of some browsers... Why not introducing an hx:*** namespace that could contain stuff as the following: -hx:inputRangeSlider -hx:inputColor -hx:whatEverNewWidgetIsPartOfHTML5 / And/or some more functional stuff, like drag-and-drop: -fx:dragAndDrop... (could be done as a behavior) etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1747) zip page state to reduce live memory
[ https://issues.apache.org/jira/browse/TRINIDAD-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851176#action_12851176 ] Martin Marinschek commented on TRINIDAD-1747: - A few questions to this (sorry, I am a bit late): - 100Megs of page state - for one user? This is incredibly high! I guess you are talking about multiple users? - why do you have a page-state independent of the implementation´s page state? I don´t understand this. best regards, Martin zip page state to reduce live memory Key: TRINIDAD-1747 URL: https://issues.apache.org/jira/browse/TRINIDAD-1747 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Gabrielle Crawford Attachments: 1.2.12.1_compressviewstate.patch, 1.2.12.2_compressviewstate.patch, trunk_compressviewstate.patch PageState Objects tend to pin a lot of live memory. These objects are heavy in live memory and can use a couple of MB per object. This is very big overhead and becomes much bigger issue in clustering when session replication happens. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jsr-314-open] PostAddToViewEvent publishing conditions
Now, the instants of time where PostAddToViewEvent is published are: - With Partial State Saving enabled * When the view is build at first time. * In a postback when the view is build but before the state of the component is restored. - With Partial State Saving disabled * When the view is build at first time. * In a postback when the view is refreshed, because all component nodes are detached and attached to the tree. In other words, on render response phase, vdl.buildView is called and in this case facelets algorithm add all transient components (usually all html markup not saved), and to do that, it detach and attach all components to be in right order. This also has some other implications, like c:if tag depends on this to work correctly. This sounds ugly. You are sure that this is the behaviour in both MyFaces and Mojarra. Here my 2cents: - Partial state saving should not make any difference at all (also in partial state saving, the template should be reapplied before rendering, see my other mail) - PostAddToViewEvent should be called always after a component has been added to the view fully, and all its state has been restored best regards, Martin
[jira] Created: (MYFACES-2634) MyFaces 2.0 performance improvements
MyFaces 2.0 performance improvements Key: MYFACES-2634 URL: https://issues.apache.org/jira/browse/MYFACES-2634 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Reporter: Martin Marinschek Assignee: Martin Marinschek JSF 2.0 introduced a partial state saving option: state of the page will not completely, but only partially state-saved. This partial state saving reduces the page-state memory to around 20% of the value under the JSF 1.2 full state saving option, as preliminary measurements show - this is a relevant reduction. However, I believe we can reduce this number even more, if we carefully take a look on what really needs to be saved and how. This project would need to provide: 1) a setup to measure the numbers and provide comparisons 2) measurements of the current state 3) several steps which lead to a reduction of the state Further research topics could be: - partial state-saving in tables - currently, this is not implemented at all - if no c:if, c:forEach, or ui:include is present on the page, we could get rid of the second application of the template before rendering automatically. best regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Ideas for GSoC
Hi guys, I have just added one more proposal from me. https://issues.apache.org/jira/browse/MYFACES-2634 @Gerhard: hurry up with adding your proposal! best regards, Martin On Mon, Mar 29, 2010 at 11:11 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: hi tobias, are you interested in client-side validation based on bean-validation (jsr 303) constraints? regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/3/29 Tobias Ullrich li...@dump.netvanced.eu Hey Guys, the deadline for students to sign up for the GSoC program is coming and I thought it would be really cool to get the chance to participate and contribute to MyFaces. I co-organized/attended a talk by Matthias Wessendorf and Bernd Bohmann on JSF 2.0 / MyFaces 2.0 in January and I'm hooked since then. Long story short, there are only two MyFaces tickets in the GSoC JIRA and I just wanted to ask you guys if you have some more ideas for which I could apply. Cheers, Tobias -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Google SoC
Hi Jakob, you could also take part as a student, if you´d rather do that. But you can certainly be a mentor for this, every committer may. best regards, Martin On Thu, Mar 11, 2010 at 4:05 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi Martin, If it's ok with everyone, I would also like to be a mentor! Regards, Jakob 2010/3/11, Martin Marinschek mmarinsc...@apache.org: Based on the outcome of this discussion, I will add a few issues to our issue tracker which amount to these proposals. Matthias, did you already sign up to be a mentor? Did anyone else do so already? Who wants to mentor? best regards, Martin On 3/11/10, Martin Marinschek mmarinsc...@apache.org wrote: - Extend Orchestra use Conversations based on the JSF 2.0 custom scope API, Extend Orchestra to work with Spring Conversations, to do File-New Window Handling I was thinking based on a suggestion done on JSFDays to take advantage on trinidad pageFlowScope code (like we did with flash scope on myfaces 2.0), and refactor that code to allow orchestra conversation scope work without spring (using the new JSF 2.0 custom scope). [Mario Ivankovits] Orchestra without Spring, that surely would be great. One thing to keep in mind is that we need AOP or at least proxying to inject the current conversation into the bean. Not too complicated, though. ok, sure - this could be part of the project. But what does this have to do with trinidad's pageFlowScope? If there is common utiltiy methods we can re-use (for example for file--new window detection in IE with JavaScript the generation of this JavaScript), we can and should certainly reuse it. If we leave the EntityManager thing out of line, we just need a JSF 2.0 scope impl and the proxying/interception stuff which is handled by Spring currently. perfect - let's do a proposal for this. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TRINIDAD-1747) zip page state to reduce live memory
[ https://issues.apache.org/jira/browse/TRINIDAD-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851185#action_12851185 ] Gabrielle Crawford commented on TRINIDAD-1747: -- - 100Megs of page state - for one user? This is incredibly high! I guess you are talking about multiple users? Sorry, should have said, 200 users - why do you have a page-state independent of the implementation´s page state? I don´t understand this. we do some things in our statemanager like cache the view root of the last view you looked at, which means we don't even have to restore the state, we just return the old tree. zip page state to reduce live memory Key: TRINIDAD-1747 URL: https://issues.apache.org/jira/browse/TRINIDAD-1747 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Gabrielle Crawford Attachments: 1.2.12.1_compressviewstate.patch, 1.2.12.2_compressviewstate.patch, trunk_compressviewstate.patch PageState Objects tend to pin a lot of live memory. These objects are heavy in live memory and can use a couple of MB per object. This is very big overhead and becomes much bigger issue in clustering when session replication happens. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1747) zip page state to reduce live memory
[ https://issues.apache.org/jira/browse/TRINIDAD-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851191#action_12851191 ] Martin Marinschek commented on TRINIDAD-1747: - That sounds reasonable. Question: do you anyways save the state, or only cache? what do you do if the user spawns a new window for the same view? best regards, Martin zip page state to reduce live memory Key: TRINIDAD-1747 URL: https://issues.apache.org/jira/browse/TRINIDAD-1747 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Gabrielle Crawford Attachments: 1.2.12.1_compressviewstate.patch, 1.2.12.2_compressviewstate.patch, trunk_compressviewstate.patch PageState Objects tend to pin a lot of live memory. These objects are heavy in live memory and can use a couple of MB per object. This is very big overhead and becomes much bigger issue in clustering when session replication happens. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jsr-314-open] PostAddToViewEvent publishing conditions
2010/3/29 Martin Marinschek mmarinsc...@apache.org Now, the instants of time where PostAddToViewEvent is published are: - With Partial State Saving enabled * When the view is build at first time. * In a postback when the view is build but before the state of the component is restored. - With Partial State Saving disabled * When the view is build at first time. * In a postback when the view is refreshed, because all component nodes are detached and attached to the tree. In other words, on render response phase, vdl.buildView is called and in this case facelets algorithm add all transient components (usually all html markup not saved), and to do that, it detach and attach all components to be in right order. This also has some other implications, like c:if tag depends on this to work correctly. This sounds ugly. You are sure that this is the behaviour in both MyFaces and Mojarra. Here my 2cents: I'm 100% sure this is the current behavior. If the issue with c:if and partial state saving was solved on mojarra, PSS = true should trigger PostAddToViewEvent like PSS = false - Partial state saving should not make any difference at all (also in partial state saving, the template should be reapplied before rendering, see my other mail) - PostAddToViewEvent should be called always after a component has been added to the view fully, and all its state has been restored I totally agree. Really it is necessary to add an event for relocate components on the tree when the view is build. In myfaces, when we started to integrate facelets it was detected, so right now there exists a class called PostBuildComponentTreeOnRestoreViewEvent. The problem to use this one is it is inside myfaces impl jar, so if anyone wants to create a component that requires relocation it will not be compatible with myfaces, so right now we are using the standard PostAddToView for this case. I'll be more detailed about the conclusion I proposed on the first email. What I want to be added on the spec is this: - Create a new event (let's call it PostBuildViewEvent for the moment), that is propagated every time the view is build (when it is created, restored or refreshed before render response). h:outputScript, h:outputStylesheet, cc:insertChildren and cc:insertFacet should add a listener for this event and handle all relocation code at response of this event. - Fix PostAddToViewEvent/PreRemoveFromViewEvent publishing conditions. In my opinion this ones should not be called when the view is refreshed. Martin suggestion about the publishing conditions are reasonable. I have to remember this topic here: [jsr-314-open] add component resources depending on the owner component state If exists an event like PostBuildViewEvent, that event could solve this one too (we could have PostRefreshViewEvent extends PostBuildViewEvent). with best regards, Leonardo Uribe
Re: [jsr-314-open] Use a Renderer on a composite component
Hi Leonardo, Myfaces already has this behavior implemented. We use a param called org.apache.myfaces.CLEAN_TRANSIENT_BUILD_ON_RESTORE, that is set from c:forEach, ui:include, c:if or c:choose tag handlers to indicate that the current view should be refreshed. This behavior is activated throught set org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS param to auto. Maybe the auto mode should be the default. perfect, that sounds good. I am cc´ing our dev list cause this is of course relevant for MyFaces as well. If that ends up in the API, it should be on FacesContext. If we do it in MyFaces only, it should be in a MyFacesContext - we should have something like this anyways. MyFacesContext.getCurrentInstance() should deliver an instance of it. best regards, Martin best regards, Martin On Tue, Mar 30, 2010 at 3:53 AM, Leonardo Uribe lu4...@gmail.com wrote: 2010/3/29 Andy Schwartz andy.schwa...@oracle.com On 3/29/10 5:10 PM, Martin Marinschek wrote: Hi Leonardo, Ok, if I have a composite component the first thought is use c:if tag, but remember that with partial state saving enabled this tag is evaluated when the view is build, not when it is rendered. Other alternative is use a component that allows to render one just to get this straight, cause I seemed to read this (IMHO, wrong assertion) several times from you already: c:if, c:forEach and ui:include _should_ be evaluated before rendering again. This is in Mojarra as of 2.0.3 (Ed, Ryan, correct me if I am wrong) and it should be in MyFaces as well, right? Haven't had a chance to review this entire thread (or any other recent threads - sorry!), but just wanted to jump in to say that, yes, Ryan has implemented an initial fix for this as part of this issue: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1313 Would be good to do some additional testing with our various test cases just to make sure that all is well. Ok, that's great!. That means we need to make myfaces evaluate c:if, c:forEach and ui:include as default, not as an option activated by a param, like in myfaces right now. Thanks for the tip. regards, Leonardo Uribe Andy Anyway I support your basic motion: it would generally be good to be able to exchange the renderer as well. best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
