Re: html5 lib
Maybe MFHTML5 like we did in MyFaces commons (--> MFCOMMONS). Regards, Jakob Am Donnerstag, 20. Januar 2011 schrieb Matthias Wessendorf : > the issue is, something like MYFACES-HTML5 does not work (because of -) > :-) > > On Thu, Jan 20, 2011 at 8:18 AM, Gerhard wrote: >> +1 for a new jira project >> regards, >> gerhard >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >> >> >> 2011/1/20 Matthias Wessendorf >>> >>> Question: >>> >>> Should we add a new JIRA project (MYFACESHTML5) >>> Or is it enough to have a HTML5 component ? >>> >>> I personally don't mind having a new project for it.. >>> >>> -M >>> >>> On Thu, Jan 20, 2011 at 6:06 AM, Matthias Wessendorf >>> wrote: >>> > Nope >>> > >>> > On Wednesday, January 19, 2011, Ali Ok wrote: >>> >> Hi, >>> >> >>> >> totally - let's create a jira instance for myfaces-html5 ?Do we need >>> >> voting for this? >>> >> >>> >> Cheers,Ali >>> >> On Tue, Jan 18, 2011 at 3:50 PM, Ali Ok wrote: >>> >> >>> >> Hi, >>> >> For example, for the hx:video component there is a "fallback" facet. >>> >> But I can't say we're able cope with this problem (yet). So far, I've >>> >> experimented Html5, CSS and other Javascript APIs; created some >>> >> components, >>> >> behaviors and etc. >>> >> >>> >> >>> >> Providing fallbacks automatically is not that easy and for some >>> >> features, it is impossible. Of course, we would have allow users to plug >>> >> in >>> >> their fallbacks.That would be an important part of this project. >>> >> >>> >> >>> >> >>> >> >>> >> How do others cope with this situation? Is there an established pattern >>> >> for this case? If so, then we should add it to our WIKI.There is a >>> >> Javascript library called "Modernizr" [1] which can detect the support >>> >> for >>> >> features. AFAIK, people use that to use Html5 features or fallback to old >>> >> stuff. >>> >> >>> >> Furthermore, Html side of the Html5 (Html + JS APIs + CSS3) mostly >>> >> designed in a way that old browsers will just ignore the component, but >>> >> not >>> >> it's children elements. So, that is another way of providing fallbacks, >>> >> as >>> >> nested elements, since new browsers will consider the Html5 elements, but >>> >> ignore it's non-applicable children. >>> >> >>> >> >>> >> [1] https://github.com/Modernizr/Modernizr >>> >> Greetings,Ali >>> >> >>> >> On Tue, Jan 18, 2011 at 3:31 PM, Mark Struberg >>> >> wrote: >>> >> Please allow me a question (I'm a complete noob on this topic), just >>> >> for getting the 'big picture': >>> >> >>> >> The html5 components are obviously only for html-5 compatible browsers. >>> >> >>> >> Is there a strategy to also serve older (xhtml-4 only) browsers? Or do >>> >> we just show them a 'not available for your old browser' page in this >>> >> case? >>> >> How do others cope with this situation? Is there an established pattern >>> >> for this case? If so, then we should add it to our WIKI. >>> >> >>> >> LieGrue, >>> >> strub >>> >> >>> >> --- On Tue, 1/18/11, Matthias Wessendorf wrote: >>> >> >>> >>> From: Matthias Wessendorf <-- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Which one should be used : Mojarra vs. MyFaces
Hi, We are also using myfaces for JSF 1.2 reference implementation in our UI framwork project. Now we have a push that we should replace it with Mojarra project implementaion. What do you suggest about these two implemenations w.r.t. JSF 2.0. thanks, Agam
Re: html5 lib
+1 let me use that... On Thu, Jan 20, 2011 at 12:16 PM, Jakob Korherr wrote: > Maybe MFHTML5 like we did in MyFaces commons (--> MFCOMMONS). > > Regards, > Jakob > > Am Donnerstag, 20. Januar 2011 schrieb Matthias Wessendorf > : >> the issue is, something like MYFACES-HTML5 does not work (because of -) >> :-) >> >> On Thu, Jan 20, 2011 at 8:18 AM, Gerhard wrote: >>> +1 for a new jira project >>> regards, >>> gerhard >>> >>> http://www.irian.at >>> >>> Your JSF powerhouse - >>> JSF Consulting, Development and >>> Courses in English and German >>> >>> Professional Support for Apache MyFaces >>> >>> >>> >>> 2011/1/20 Matthias Wessendorf Question: Should we add a new JIRA project (MYFACESHTML5) Or is it enough to have a HTML5 component ? I personally don't mind having a new project for it.. -M On Thu, Jan 20, 2011 at 6:06 AM, Matthias Wessendorf wrote: > Nope > > On Wednesday, January 19, 2011, Ali Ok wrote: >> Hi, >> >> totally - let's create a jira instance for myfaces-html5 ?Do we need >> voting for this? >> >> Cheers,Ali >> On Tue, Jan 18, 2011 at 3:50 PM, Ali Ok wrote: >> >> Hi, >> For example, for the hx:video component there is a "fallback" facet. >> But I can't say we're able cope with this problem (yet). So far, I've >> experimented Html5, CSS and other Javascript APIs; created some >> components, >> behaviors and etc. >> >> >> Providing fallbacks automatically is not that easy and for some >> features, it is impossible. Of course, we would have allow users to >> plug in >> their fallbacks.That would be an important part of this project. >> >> >> >> >> How do others cope with this situation? Is there an established pattern >> for this case? If so, then we should add it to our WIKI.There is a >> Javascript library called "Modernizr" [1] which can detect the support >> for >> features. AFAIK, people use that to use Html5 features or fallback to >> old >> stuff. >> >> Furthermore, Html side of the Html5 (Html + JS APIs + CSS3) mostly >> designed in a way that old browsers will just ignore the component, but >> not >> it's children elements. So, that is another way of providing fallbacks, >> as >> nested elements, since new browsers will consider the Html5 elements, >> but >> ignore it's non-applicable children. >> >> >> [1] https://github.com/Modernizr/Modernizr >> Greetings,Ali >> >> On Tue, Jan 18, 2011 at 3:31 PM, Mark Struberg >> wrote: >> Please allow me a question (I'm a complete noob on this topic), just >> for getting the 'big picture': >> >> The html5 components are obviously only for html-5 compatible browsers. >> >> Is there a strategy to also serve older (xhtml-4 only) browsers? Or do >> we just show them a 'not available for your old browser' page in this >> case? >> How do others cope with this situation? Is there an established pattern >> for this case? If so, then we should add it to our WIKI. >> >> LieGrue, >> strub >> >> --- On Tue, 1/18/11, Matthias Wessendorf wrote: >> >>> From: Matthias Wessendorf <-- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Which one should be used : Mojarra vs. MyFaces
Am 20.01.11 12:14, schrieb Agam Dass: Hi, We are also using myfaces for JSF 1.2 reference implementation in our UI framwork project. Now we have a push that we should replace it with Mojarra project implementaion. What do you suggest about these two implemenations w.r.t. JSF 2.0. Best bet is to make your ui framework work on both impls and if you run into bugs where one thing works while the thing on the other does not then please immediately post a bugreport so that we can fix it. That way you can switch over to one impl or the other as the need arises (which is often imposed by management not by quality criteria) The implementors on both impls work hard to deliver a solid experience, so it is hard to tell which implementation is the better, of course I am biased in favor of myfaces naturally, but you will get the answer towards Mojarra in a mojarra centric forum. I personally think that both implementations of JSF 2.0 are by now pretty mature so it is really hard to give an preferences here for one of those. just my 2c Werner
[ProjectStage] Enhancing the ProjectStage to contain "DesignTime" ?
Hi, opening a ADF/Trinidad application in JDeveloper's I am seeing a "warning" like this: WARNING: Your environment is configured as production and Apache Trinidad is running with debug javascript. See the "org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT" parameter in /WEB-INF/web.xml The WARNING itself is fine, since the web.xml doesn't have any ProjectStage setting, but it contains a flag to not obfuscate our JavaScript (to make it readable)... However, in DT (DesignTime) mode this can be pretty annoying.. Therefore I was wondering if the standard ProjectStage ([1]) should contain a "DesingTime" value? In a similar fashion like the java.beans.Beans class does have a isDesignTime() method ([2]). Not sure if that has been already discussed when specifying the new ProjectStage contract. Greetings, Matthias [1] http://myfaces.apache.org/core20/myfaces-api/xref/javax/faces/application/ProjectStage.html [2] http://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/beans/src/main/java/java/beans/Beans.java -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Which one should be used : Mojarra vs. MyFaces
+1 doesn't hurt to have our app/framework working with both (see [1]). Actually even if you prefer one over the other, different containers may ship different JSF implementations. Would be kinda odd if your tool does only support one. Once our are able to use both, I'd suggest to collect some (perf) stats, to measure/test your needs. -Matthias [1] http://markmail.org/message/2ts6xjrkw3x4mhdm On Thu, Jan 20, 2011 at 12:40 PM, Werner Punz wrote: > Am 20.01.11 12:14, schrieb Agam Dass: >> >> Hi, >> We are also using myfaces for JSF 1.2 reference implementation in our UI >> framwork project. Now we have a push that we should replace it with >> Mojarra project implementaion. What do you suggest about these two >> implemenations w.r.t. JSF 2.0. > > Best bet is to make your ui framework work on both impls and if you run into > bugs where one thing works while the thing on the other does not > then please immediately post a bugreport so that we can fix it. > That way you can switch over to one impl or the other as the need arises > (which is often imposed by management not by quality criteria) > > The implementors on both impls work hard to deliver a solid experience, so > it is hard to tell which implementation is the better, of course I am biased > in favor of myfaces naturally, but you will get the answer towards Mojarra > in a mojarra centric forum. > > I personally think that both implementations of JSF 2.0 are by now pretty > mature so it is really hard to give an preferences here for one of those. > > > just my 2c > > Werner > > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Result - Re: [VOTE] Release Apache MyFaces checktyle-rules-2
Thanks for voting, We got n votes, all +7: -Matthias Wessendorf -Mark Struberg -Leonardo Uribe -Werner Punz -Jakob Korherr -Grant smith -Gerhard Petracek I will proceed to release these maven bits. Greetings, Matthias On Mon, Jan 17, 2011 at 12:22 PM, Matthias Wessendorf wrote: > Hi, > > I've created a checktyle-rules-2 release candidate, with the following > artifacts > up for a vote: > > SVN source tag (r1059870): > http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/tags/checkstyle-rules-2/ > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemyfaces-038 > > Source release: > https://repository.apache.org/content/repositories/orgapachemyfaces-038/org/apache/myfaces/buildtools/checkstyle-rules/2/checkstyle-rules-2-source-release.zip > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > > -- > 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: [VOTE] Trinidad plugins: 2.0.4
Thanks for voting, We got n votes, all +6: -Matthias Wessendorf -Mark Struberg -Scott O'bryan -Blake Sullivan -Max Starets -Grant smith I will proceed to release these maven bits. Greetings, Matthias On Mon, Jan 17, 2011 at 9:12 AM, Matthias Wessendorf wrote: > Hi, > > I've created a 2.0.4 release candidate, with the following artifacts > up for a vote: > > SVN source tag (r1059776): > http://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.4/ > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemyfaces-034/ > > Source release: > https://repository.apache.org/content/repositories/orgapachemyfaces-034/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.4/maven-plugin-parent-2.0.4-source-release.zip > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > > -- > 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
result - Re: [VOTE] Trinidad plugins: 1.2.13
Thanks for voting, We got n votes, all +3: -Matthias Wessendorf -Mark Struberg -Jakob Korherr I will proceed to release these maven bits. Greetings, Matthias On Mon, Jan 17, 2011 at 9:13 AM, Matthias Wessendorf wrote: > Hi, > > I've created a 1.2.13 release candidate, with the following artifacts > up for a vote: > > SVN source tag (r1059787): > http://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-1.2.13/ > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemyfaces-036/ > > Source release: > https://repository.apache.org/content/repositories/orgapachemyfaces-036/org/apache/myfaces/trinidadbuild/maven-plugin-parent/1.2.13/maven-plugin-parent-1.2.13-source-release.zip > > Vote will be open for 72 hours. > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > -- > 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] Created: (MYFACES-3018) f:ajax - render @this in render and execute as ClientBehaviorContext.getSourceId()
f:ajax - render @this in render and execute as ClientBehaviorContext.getSourceId() -- Key: MYFACES-3018 URL: https://issues.apache.org/jira/browse/MYFACES-3018 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.4-SNAPSHOT Environment: myfaces code 2.0.4 trunk rev. 1061168 Reporter: Martin Kočí Myfaces HtmlAjaxBehaviorRenderer renders marker "@this" in as pass thru value This will not work with complex component, please see this thread "[core] ajax @this with non trivial component": http://www.mail-archive.com/dev@myfaces.apache.org/msg50884.html and javadoc for ClientBehaviorContext.getSourceId() for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-3019) Output a warning if VisitContext.getIdsToVisit() contains id(s) of nonexistent component
Output a warning if VisitContext.getIdsToVisit() contains id(s) of nonexistent component Key: MYFACES-3019 URL: https://issues.apache.org/jira/browse/MYFACES-3019 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.4-SNAPSHOT Environment: myfaces code 2.0.4 trunk rev. 1061168 Reporter: Martin Kočí Priority: Minor If VisitContext.getIdsToVisit() contains "nonexistentId" of component, myfaces say nothing. It would be useful output a warning (in development stage). I noticed this problem with MYFACES-3018, because of that request contains javax.faces.partial.execute = "nonexistentId" and execution silently fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Apache MyFaces POM-10
Hi, I've created a MyFaces-10 pom release candidate, with the following artifacts up for a vote: SVN source tag (r1061273): https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/tags/myfaces-10/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemyfaces-056/ [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Apache MyFaces POM-10
+1 On Thu, Jan 20, 2011 at 1:53 PM, Matthias Wessendorf wrote: > Hi, > > I've created a MyFaces-10 pom release candidate, with the following artifacts > up for a vote: > > SVN source tag (r1061273): > https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/tags/myfaces-10/ > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemyfaces-056/ > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Thanks, > 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: [core] ajax @this with non trivial component
Hi Andy, thank you for explanation. Myfaces do only the first part: (1) "This value will (or, well, should) be passed in as thefirst argument to jsf.ajax.request()" but the second (2) "and used as the replacement for "@this" targets." in not implemented yet: https://issues.apache.org/jira/browse/MYFACES-3018 Also if that situation occurs problem is not easy to find: https://issues.apache.org/jira/browse/MYFACES-3019 Regards, Martin Andy Schwartz píše v St 19. 01. 2011 v 08:56 -0500: > Hi Martin - > > I was worried about this case as well when we were working on the > Ajax/ClientBehavior APIs. Many Trinidad/ADF Faces components use > similar markup to what you describe. > > To support this case, we added the ClientBehaviorContext.getSourceId() API: > > http://download.oracle.com/javaee/6/api/javax/faces/component/behavior/ClientBehaviorContext.html#getSourceId() > > This allows renderers that attach client behaviors to non-root DOM > elements to explicitly specify the id that corresponds to the > component. This value will (or, well, should) be passed in as the > first argument to jsf.ajax.request() and used as the replacement for > "@this" targets. > > Andy >
Re: Which one should be used : Mojarra vs. MyFaces
Quoting Matthias Wessendorf : +1 doesn't hurt to have our app/framework working with both (see [1]). I totally agree. You should make sure your app always runs with either JSF impl so that you can switch based on which impl runs your final app better. Actually even if you prefer one over the other, different containers may ship different JSF implementations. I have to pipe up and toot my own horn here. JBoss AS6 now ships with three JSF implementations. Changing to a different impl is just a matter of changing a single param in your web.xml or a single param in the main JBossWeb configuration file. http://jsfunit.blogspot.com/2010/12/jsf-on-jboss-as6-final.html Would be kinda odd if your tool does only support one. Once our are able to use both, I'd suggest to collect some (perf) stats, to measure/test your needs. -Matthias [1] http://markmail.org/message/2ts6xjrkw3x4mhdm On Thu, Jan 20, 2011 at 12:40 PM, Werner Punz wrote: Am 20.01.11 12:14, schrieb Agam Dass: Hi, We are also using myfaces for JSF 1.2 reference implementation in our UI framwork project. Now we have a push that we should replace it with Mojarra project implementaion. What do you suggest about these two implemenations w.r.t. JSF 2.0. Best bet is to make your ui framework work on both impls and if you run into bugs where one thing works while the thing on the other does not then please immediately post a bugreport so that we can fix it. That way you can switch over to one impl or the other as the need arises (which is often imposed by management not by quality criteria) The implementors on both impls work hard to deliver a solid experience, so it is hard to tell which implementation is the better, of course I am biased in favor of myfaces naturally, but you will get the answer towards Mojarra in a mojarra centric forum. I personally think that both implementations of JSF 2.0 are by now pretty mature so it is really hard to give an preferences here for one of those. just my 2c Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: result - Re: [VOTE] Trinidad plugins: 1.2.13
hi, we need 3 binding votes... -> +1 (based on a quick check) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/1/20 Matthias Wessendorf > Thanks for voting, > > We got n votes, all +3: > -Matthias Wessendorf > -Mark Struberg > -Jakob Korherr > > I will proceed to release these maven bits. > > Greetings, > Matthias > > On Mon, Jan 17, 2011 at 9:13 AM, Matthias Wessendorf > wrote: > > Hi, > > > > I've created a 1.2.13 release candidate, with the following artifacts > > up for a vote: > > > > SVN source tag (r1059787): > > > http://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-1.2.13/ > > > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapachemyfaces-036/ > > > > Source release: > > > https://repository.apache.org/content/repositories/orgapachemyfaces-036/org/apache/myfaces/trinidadbuild/maven-plugin-parent/1.2.13/maven-plugin-parent-1.2.13-source-release.zip > > > > Vote will be open for 72 hours. > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > > > -- > > 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: result - Re: [VOTE] Trinidad plugins: 1.2.13
Thanks for voting; I though as an ASF member his vote is binding. Now, with yours, we do have 3 binding +1 votes. Too bad nobody else did vote :-( -Matthias On Thu, Jan 20, 2011 at 2:29 PM, Gerhard wrote: > hi, > we need 3 binding votes... > -> +1 (based on a quick check) > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > 2011/1/20 Matthias Wessendorf >> >> Thanks for voting, >> >> We got n votes, all +3: >> -Matthias Wessendorf >> -Mark Struberg >> -Jakob Korherr >> >> I will proceed to release these maven bits. >> >> Greetings, >> Matthias >> >> On Mon, Jan 17, 2011 at 9:13 AM, Matthias Wessendorf >> wrote: >> > Hi, >> > >> > I've created a 1.2.13 release candidate, with the following artifacts >> > up for a vote: >> > >> > SVN source tag (r1059787): >> > >> > http://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-1.2.13/ >> > >> > Maven staging repo: >> > https://repository.apache.org/content/repositories/orgapachemyfaces-036/ >> > >> > Source release: >> > >> > https://repository.apache.org/content/repositories/orgapachemyfaces-036/org/apache/myfaces/trinidadbuild/maven-plugin-parent/1.2.13/maven-plugin-parent-1.2.13-source-release.zip >> > >> > Vote will be open for 72 hours. >> > >> > [ ] +1 approve >> > [ ] +0 no opinion >> > [ ] -1 disapprove (and reason why) >> > >> > -- >> > 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 > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Apache MyFaces POM-10
yippie, looks good this time ;) +1 LieGrue, strub --- On Thu, 1/20/11, Matthias Wessendorf wrote: > From: Matthias Wessendorf > Subject: [VOTE] Apache MyFaces POM-10 > To: "MyFaces Development" > Date: Thursday, January 20, 2011, 12:53 PM > Hi, > > I've created a MyFaces-10 pom release candidate, with the > following artifacts > up for a vote: > > SVN source tag (r1061273): > https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/tags/myfaces-10/ > > Maven staging repo: > https://repository.apache.org/content/repositories/orgapachemyfaces-056/ > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Thanks, > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf >
Re: [VOTE] Apache MyFaces POM-10
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/1/20 Mark Struberg > yippie, looks good this time ;) > > +1 > > LieGrue, > strub > > --- On Thu, 1/20/11, Matthias Wessendorf wrote: > > > From: Matthias Wessendorf > > Subject: [VOTE] Apache MyFaces POM-10 > > To: "MyFaces Development" > > Date: Thursday, January 20, 2011, 12:53 PM > > Hi, > > > > I've created a MyFaces-10 pom release candidate, with the > > following artifacts > > up for a vote: > > > > SVN source tag (r1061273): > > > https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/tags/myfaces-10/ > > > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapachemyfaces-056/ > > > > [ ] +1 approve > > [ ] +0 no opinion > > [ ] -1 disapprove (and reason why) > > > > Thanks, > > Matthias > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > >
Re: [VOTE] Apache MyFaces POM-10
+1 2011/1/20 Gerhard > +1 > > regards, > gerhard > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > 2011/1/20 Mark Struberg > > yippie, looks good this time ;) >> >> +1 >> >> LieGrue, >> strub >> >> --- On Thu, 1/20/11, Matthias Wessendorf wrote: >> >> > From: Matthias Wessendorf >> > Subject: [VOTE] Apache MyFaces POM-10 >> > To: "MyFaces Development" >> > Date: Thursday, January 20, 2011, 12:53 PM >> > Hi, >> > >> > I've created a MyFaces-10 pom release candidate, with the >> > following artifacts >> > up for a vote: >> > >> > SVN source tag (r1061273): >> > >> https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/tags/myfaces-10/ >> > >> > Maven staging repo: >> > >> https://repository.apache.org/content/repositories/orgapachemyfaces-056/ >> > >> > [ ] +1 approve >> > [ ] +0 no opinion >> > [ ] -1 disapprove (and reason why) >> > >> > Thanks, >> > Matthias >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> > >> >> >> >> >
[jira] Commented: (MYFACES-2958) Improve handling of AJAX response if source element is deleted
[ https://issues.apache.org/jira/browse/MYFACES-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984384#action_12984384 ] Werner Punz commented on MYFACES-2958: -- Hi Martin seems like a regression bug has slipped in, I will recheck your usecase tomorrow and will fix it. > Improve handling of AJAX response if source element is deleted > -- > > Key: MYFACES-2958 > URL: https://issues.apache.org/jira/browse/MYFACES-2958 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.3-SNAPSHOT > Environment: myfaces trunk >Reporter: Martin Kočí > Fix For: 2.0.3 > > Attachments: MYFACES-2958.patch > > > If ajax response removes HTML form with source element, .js stops processing > of others HTML forms (specially it does not update ViewState elements). -- 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-2958) Improve handling of AJAX response if source element is deleted
[ https://issues.apache.org/jira/browse/MYFACES-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984384#action_12984384 ] Werner Punz edited comment on MYFACES-2958 at 1/20/11 3:38 PM: --- Hi Martin seems like a regression bug has slipped in, I will recheck your usecase tomorrow and will fix it. I am just a little bit puzzled of your description because normally this parameter you set should force the impl to iterate over all given forms and set the viewstate field. I have been using this mechanism this week successfully myself in a testing app. Either way I will debug into it. was (Author: werpu): Hi Martin seems like a regression bug has slipped in, I will recheck your usecase tomorrow and will fix it. > Improve handling of AJAX response if source element is deleted > -- > > Key: MYFACES-2958 > URL: https://issues.apache.org/jira/browse/MYFACES-2958 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.3-SNAPSHOT > Environment: myfaces trunk >Reporter: Martin Kočí > Fix For: 2.0.3 > > Attachments: MYFACES-2958.patch > > > If ajax response removes HTML form with source element, .js stops processing > of others HTML forms (specially it does not update ViewState elements). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2958) Improve handling of AJAX response if source element is deleted
[ https://issues.apache.org/jira/browse/MYFACES-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984391#action_12984391 ] Werner Punz commented on MYFACES-2958: -- Ok the bug is reproducable, the viewstate elements are really lost, it is a combination of renderAll and a bug in our viewstate fix I assume. The response correctly delivers the entire page and then delivers a separate viewState element, at that time the fix should kick in and should apply new viewState elements because the new content does not have them and this seems to fail one way or the other. A fix is on the way and will be committed tomorrow. > Improve handling of AJAX response if source element is deleted > -- > > Key: MYFACES-2958 > URL: https://issues.apache.org/jira/browse/MYFACES-2958 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.3-SNAPSHOT > Environment: myfaces trunk >Reporter: Martin Kočí > Fix For: 2.0.3 > > Attachments: MYFACES-2958.patch > > > If ajax response removes HTML form with source element, .js stops processing > of others HTML forms (specially it does not update ViewState elements). -- 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-2958) Improve handling of AJAX response if source element is deleted
[ https://issues.apache.org/jira/browse/MYFACES-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984391#action_12984391 ] Werner Punz edited comment on MYFACES-2958 at 1/20/11 4:11 PM: --- Ok found the bug the bag was in an incorrect error termination of the response processing due to the form issuing the request not being found anymore (the ids had changed) I fixed that on my code and things look good now. was (Author: werpu): Ok the bug is reproducable, the viewstate elements are really lost, it is a combination of renderAll and a bug in our viewstate fix I assume. The response correctly delivers the entire page and then delivers a separate viewState element, at that time the fix should kick in and should apply new viewState elements because the new content does not have them and this seems to fail one way or the other. A fix is on the way and will be committed tomorrow. > Improve handling of AJAX response if source element is deleted > -- > > Key: MYFACES-2958 > URL: https://issues.apache.org/jira/browse/MYFACES-2958 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.3-SNAPSHOT > Environment: myfaces trunk >Reporter: Martin Kočí > Fix For: 2.0.3 > > Attachments: MYFACES-2958.patch > > > If ajax response removes HTML form with source element, .js stops processing > of others HTML forms (specially it does not update ViewState elements). -- 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-2958) Improve handling of AJAX response if source element is deleted
[ https://issues.apache.org/jira/browse/MYFACES-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984391#action_12984391 ] Werner Punz edited comment on MYFACES-2958 at 1/20/11 4:14 PM: --- Ok found the bug the bag was in an incorrect error termination of the response processing due to the form issuing the request not being found anymore (the ids had changed) I fixed that on my code and things look good now. Only render="@all" or render could trigger this bug was (Author: werpu): Ok found the bug the bag was in an incorrect error termination of the response processing due to the form issuing the request not being found anymore (the ids had changed) I fixed that on my code and things look good now. > Improve handling of AJAX response if source element is deleted > -- > > Key: MYFACES-2958 > URL: https://issues.apache.org/jira/browse/MYFACES-2958 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.3-SNAPSHOT > Environment: myfaces trunk >Reporter: Martin Kočí > Fix For: 2.0.3 > > Attachments: MYFACES-2958.patch > > > If ajax response removes HTML form with source element, .js stops processing > of others HTML forms (specially it does not update ViewState elements). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2958) Improve handling of AJAX response if source element is deleted
[ https://issues.apache.org/jira/browse/MYFACES-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-2958. -- Resolution: Fixed Fix Version/s: (was: 2.0.3) 2.0.4-SNAPSHOT fixed > Improve handling of AJAX response if source element is deleted > -- > > Key: MYFACES-2958 > URL: https://issues.apache.org/jira/browse/MYFACES-2958 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-314 >Affects Versions: 2.0.3-SNAPSHOT > Environment: myfaces trunk >Reporter: Martin Kočí > Fix For: 2.0.4-SNAPSHOT > > Attachments: MYFACES-2958.patch > > > If ajax response removes HTML form with source element, .js stops processing > of others HTML forms (specially it does not update ViewState elements). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-3020) jsf.js dutch i18n translations
jsf.js dutch i18n translations -- Key: MYFACES-3020 URL: https://issues.apache.org/jira/browse/MYFACES-3020 Project: MyFaces Core Issue Type: Improvement Reporter: Werner Punz Rudy de Buscher has provided the dutch jsf.js client side error message translations, thanks rudy for providing them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-3020) jsf.js dutch i18n translations
[ https://issues.apache.org/jira/browse/MYFACES-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3020. -- Resolution: Fixed Fix Version/s: 2.0.4-SNAPSHOT > jsf.js dutch i18n translations > -- > > Key: MYFACES-3020 > URL: https://issues.apache.org/jira/browse/MYFACES-3020 > Project: MyFaces Core > Issue Type: Improvement >Reporter: Werner Punz > Fix For: 2.0.4-SNAPSHOT > > > Rudy de Buscher has provided the dutch jsf.js client side error message > translations, > thanks rudy for providing them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Apache MyFaces POM-10
+1 Regards, Jakob 2011/1/20 Leonardo Uribe : > +1 > > 2011/1/20 Gerhard >> >> +1 >> regards, >> gerhard >> >> http://www.irian.at >> >> Your JSF powerhouse - >> JSF Consulting, Development and >> Courses in English and German >> >> Professional Support for Apache MyFaces >> >> >> 2011/1/20 Mark Struberg >>> >>> yippie, looks good this time ;) >>> >>> +1 >>> >>> LieGrue, >>> strub >>> >>> --- On Thu, 1/20/11, Matthias Wessendorf wrote: >>> >>> > From: Matthias Wessendorf >>> > Subject: [VOTE] Apache MyFaces POM-10 >>> > To: "MyFaces Development" >>> > Date: Thursday, January 20, 2011, 12:53 PM >>> > Hi, >>> > >>> > I've created a MyFaces-10 pom release candidate, with the >>> > following artifacts >>> > up for a vote: >>> > >>> > SVN source tag (r1061273): >>> > >>> > https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/tags/myfaces-10/ >>> > >>> > Maven staging repo: >>> > >>> > https://repository.apache.org/content/repositories/orgapachemyfaces-056/ >>> > >>> > [ ] +1 approve >>> > [ ] +0 no opinion >>> > [ ] -1 disapprove (and reason why) >>> > >>> > Thanks, >>> > Matthias >>> > >>> > -- >>> > Matthias Wessendorf >>> > >>> > blog: http://matthiaswessendorf.wordpress.com/ >>> > sessions: http://www.slideshare.net/mwessendorf >>> > twitter: http://twitter.com/mwessendorf >>> > >>> >>> >>> >> > > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
[jira] Created: (MYFACES-3021) javax.faces.view.facelets.ComponentHandler initializes TagHandlerDelegate on startup, but it should be on demand
javax.faces.view.facelets.ComponentHandler initializes TagHandlerDelegate on startup, but it should be on demand Key: MYFACES-3021 URL: https://issues.apache.org/jira/browse/MYFACES-3021 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.3 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Call TagHandlerDelegateFactory.createComponentHandlerDelegate on ComponentHandler constructor is not a good idea. The reason is we are creating over and over unnecessary instances of ComponentHandler through the factory that in the end they could never be used. It also causes a problem when it is required to wrap a ComponentHandler instance for a composite component (using TagHandlerDelegateFactory) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-3009) Flash scope looses values on redirect
[ https://issues.apache.org/jira/browse/MYFACES-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3009: Resolution: Fixed Assignee: Leonardo Uribe (was: Jakob Korherr) Status: Resolved (was: Patch Available) > Flash scope looses values on redirect > - > > Key: MYFACES-3009 > URL: https://issues.apache.org/jira/browse/MYFACES-3009 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.3 >Reporter: Jakob Korherr >Assignee: Leonardo Uribe > Attachments: MYFACES-3009-1.patch > > > Example as follows: > 1) A facelet called Entry.xhtml > > > >First Name: > > > > > >Last Name: > > > > >/> > > and the confirmation.xhtml: > > >First Name: > > > > > >Last Name: > > > > > > > /> > > But when the confirmation page is loaded, the firstName and lastName I > submitted > is missing. Why? I am using flash.keep. According to what I read it should > keep the values more than a PRG cycle. > It works if I use Mojarra. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-3021) javax.faces.view.facelets.ComponentHandler initializes TagHandlerDelegate on startup, but it should be on demand
[ https://issues.apache.org/jira/browse/MYFACES-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3021. - Resolution: Fixed Fix Version/s: 2.0.4-SNAPSHOT > javax.faces.view.facelets.ComponentHandler initializes TagHandlerDelegate on > startup, but it should be on demand > > > Key: MYFACES-3021 > URL: https://issues.apache.org/jira/browse/MYFACES-3021 > Project: MyFaces Core > Issue Type: Bug > Components: JSR-314 >Affects Versions: 2.0.3 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.0.4-SNAPSHOT > > > Call TagHandlerDelegateFactory.createComponentHandlerDelegate on > ComponentHandler constructor is not a good idea. The reason is we are > creating over and over unnecessary instances of ComponentHandler through the > factory that in the end they could never be used. > It also causes a problem when it is required to wrap a ComponentHandler > instance for a composite component (using TagHandlerDelegateFactory) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [ProjectStage] Enhancing the ProjectStage to contain "DesignTime" ?
The ApplicationImpl's getProjectStage() would immediately return "ProjectStage.DesignTime", if Beans.isDesignTime() is true. -Matthias On Thu, Jan 20, 2011 at 1:00 PM, Matthias Wessendorf wrote: > Hi, > > opening a ADF/Trinidad application in JDeveloper's I am seeing a > "warning" like this: > > WARNING: Your environment is configured as production and Apache > Trinidad is running with debug javascript. See the > "org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT" parameter in > /WEB-INF/web.xml > > The WARNING itself is fine, since the web.xml doesn't have any > ProjectStage setting, but it contains a flag to not obfuscate our > JavaScript (to make it readable)... > > However, in DT (DesignTime) mode this can be pretty annoying.. > Therefore I was wondering if the standard ProjectStage ([1]) should > contain a "DesingTime" value? > In a similar fashion like the java.beans.Beans class does have a > isDesignTime() method ([2]). > > Not sure if that has been already discussed when specifying the new > ProjectStage contract. > > Greetings, > Matthias > > [1] > http://myfaces.apache.org/core20/myfaces-api/xref/javax/faces/application/ProjectStage.html > [2] > http://svn.apache.org/repos/asf/harmony/enhanced/java/trunk/classlib/modules/beans/src/main/java/java/beans/Beans.java > > -- > 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
