Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
We probably have to point this out to the EG, since it is rather easy to fix this this should be fixed, after all to deal with those cases is what the name attribute in inputs exists for. It would be easy to have several viewState hidden fields one per form with formId:javax.faces.ViewState and the name javax.faces.ViewState... Werner Alexander Bell schrieb: Hi, in the past we did it in this way that we looking for the element only in the affected form. So in the form there is only one element with the id javax.faces.ViewState. It is also necessary that every form contains a hidden field with this id. So for JSF ok but it breaks the w3c standard and you can't use document.getElementById. We've got a appropriate code snippet in the j4fry code. 2009/4/19 Ganesh gan...@j4fry.org mailto:gan...@j4fry.org Hi Werner, 2 elements with the same id truely brake the HTML standard. And it's true, with Mojarra 2.0 and 2 forms on a page I get 2 identical input id=javax.faces.ViewState type=hidden value=j_id1:j_id2 name=javax.faces.ViewState/ elements! Still, I'm not able to find this in the specs, can you please point me to the section you are referring to? The spec says that an element with the identifier javax.faces.ViewState has to be added to every form if it does not exist within the update phase if viewState itself is responded! Best Regards, Ganesh -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org mailto:alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Hia... I sent a comment regarding this issue towards the given jcp-comments mail address. Lets see what happens. I think even if you can resolve those things on the javascript side this needs to be fixed, on the Spec side! After all the name attribute normally is there for what the spec and the RI tries to achieve by using multiple elements with the identifier javax.faces.ViewState! Werner Alexander Bell schrieb: Hi, in the past we did it in this way that we looking for the element only in the affected form. So in the form there is only one element with the id javax.faces.ViewState. It is also necessary that every form contains a hidden field with this id. So for JSF ok but it breaks the w3c standard and you can't use document.getElementById. We've got a appropriate code snippet in the j4fry code. 2009/4/19 Ganesh gan...@j4fry.org mailto:gan...@j4fry.org Hi Werner, 2 elements with the same id truely brake the HTML standard. And it's true, with Mojarra 2.0 and 2 forms on a page I get 2 identical input id=javax.faces.ViewState type=hidden value=j_id1:j_id2 name=javax.faces.ViewState/ elements! Still, I'm not able to find this in the specs, can you please point me to the section you are referring to? The spec says that an element with the identifier javax.faces.ViewState has to be added to every form if it does not exist within the update phase if viewState itself is responded! Best Regards, Ganesh -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org mailto:alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
On Mon, Apr 20, 2009 at 9:05 AM, Werner Punz werner.p...@gmail.com wrote: Hia... I sent a comment regarding this issue towards the given jcp-comments mail address. Lets see what happens. :-) /dev/null ? Another option is to have Martin (he is the ASF guy in the EG) bringing this to the EG. -Matthias I think even if you can resolve those things on the javascript side this needs to be fixed, on the Spec side! After all the name attribute normally is there for what the spec and the RI tries to achieve by using multiple elements with the identifier javax.faces.ViewState! Werner Alexander Bell schrieb: Hi, in the past we did it in this way that we looking for the element only in the affected form. So in the form there is only one element with the id javax.faces.ViewState. It is also necessary that every form contains a hidden field with this id. So for JSF ok but it breaks the w3c standard and you can't use document.getElementById. We've got a appropriate code snippet in the j4fry code. 2009/4/19 Ganesh gan...@j4fry.org mailto:gan...@j4fry.org Hi Werner, 2 elements with the same id truely brake the HTML standard. And it's true, with Mojarra 2.0 and 2 forms on a page I get 2 identical input id=javax.faces.ViewState type=hidden value=j_id1:j_id2 name=javax.faces.ViewState/ elements! Still, I'm not able to find this in the specs, can you please point me to the section you are referring to? The spec says that an element with the identifier javax.faces.ViewState has to be added to every form if it does not exist within the update phase if viewState itself is responded! Best Regards, Ganesh -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org mailto:alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Matthias Wessendorf schrieb: On Mon, Apr 20, 2009 at 9:05 AM, Werner Punz werner.p...@gmail.com wrote: Hia... I sent a comment regarding this issue towards the given jcp-comments mail address. Lets see what happens. :-) /dev/null ? That was mean :-) I will also talk to Martin about it as you said, btw... Another thing which really irks me generally. Since day zero about 90% of the problems of the end users revolve around the fact that there is no decent direct validation control for endusers within the spec. We have immediate, which does not work out for many cases, since it just shifts phases, we have since jsf1.2 the possibility of adding alternate lifecycles which is frankly spoken to complicated for many users and component sets add subforms which also is outside of the spec but work out best so far although they are still more complicated than a simple validation attribute! An attribute in the command links or buttons with validation=true/false would go a long way of removing a huge issue most users have with jsf. (the other one the component api thankfully has been resolved) I am glad Gerhard is adding something along those lines now to extVal, but I think in the long run a simple attribute in the button or command link which automatically turns off validation could help users tremendously. I am not sure why this still has not made it into the spec. Werner
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Hi Alexander/Ganesh there are two parts of the spec one being the PDF the other being the JavaDocs and JSDocs, you can find the issue in the JSDocs for jsf.ajax.response specifically in the section dealing with the updates in the responseXML! here is the section: If an update element is found in the response with the identifier javax.faces.ViewState: . snip other behavior if the form element does not contain an element with the identifier javax.faces.ViewState, create an input element of the type hidden, with the identifier javax.faces.ViewState, set its contents to the update element's CDATA contents, and add the input element as a child to the form element. note the term identifier here, which leaves no discussion that the id has to be used identifier == id in my opinion not the name which would be the proper way to resolve this in a html conform manner! Werner Alexander Bell schrieb: Hi, in the past we did it in this way that we looking for the element only in the affected form. So in the form there is only one element with the id javax.faces.ViewState. It is also necessary that every form contains a hidden field with this id. So for JSF ok but it breaks the w3c standard and you can't use document.getElementById. We've got a appropriate code snippet in the j4fry code. 2009/4/19 Ganesh gan...@j4fry.org mailto:gan...@j4fry.org Hi Werner, 2 elements with the same id truely brake the HTML standard. And it's true, with Mojarra 2.0 and 2 forms on a page I get 2 identical input id=javax.faces.ViewState type=hidden value=j_id1:j_id2 name=javax.faces.ViewState/ elements! Still, I'm not able to find this in the specs, can you please point me to the section you are referring to? The spec says that an element with the identifier javax.faces.ViewState has to be added to every form if it does not exist within the update phase if viewState itself is responded! Best Regards, Ganesh -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org mailto:alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml
[jira] Commented: (TRINIDAD-458) Allow users to control the starting date of date picker
[
https://issues.apache.org/jira/browse/TRINIDAD-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700690#action_12700690
]
Jacob Nordfalk commented on TRINIDAD-458:
-
It's a big annoyance that tr:chooseDate / can't be somehow made to get the
initial values of ist associated tr:inputDate/.
tr:inputDate chooseId=fromDate label=From date:
value=#{userchoice.fromDate} contentStyle=width: 80px immediate=true
f:convertDateTime timeZone=CET pattern=dd-MM-yy/
/tr:inputDate
tr:chooseDate id=fromDate /
tr:chooseDate always goes to the current date.
I have tried working around this issue with JavaScript
tr:document
onload=document.show.fromDateyear.selectedIndex=#{userchoice.fromDate.year-100};
document.show.fromDatemonth.selectedIndex=#{userchoice.fromDate.month};
but it doesent work too well, also not if I include
document.show.fromDateyear.onchange(); document.show.fromDatemonth.onchange();
I know this is not the right place but I couldnt fin *any* information about
how to get in contact with Trinidad developers.
Could someone please advice me, both on fixing the above, and how to get in
contact with Trinidad developers.?
Thanks
Jacob Nordfalk
Allow users to control the starting date of date picker
---
Key: TRINIDAD-458
URL: https://issues.apache.org/jira/browse/TRINIDAD-458
Project: MyFaces Trinidad
Issue Type: Improvement
Reporter: Simon Lessard
Priority: Minor
Attachments: trunk_patch90.patch
Currently, date picker init itself to the current date (unless there's a
DateTimeRangeValidator preventing it). This can be useful, but also
problematic when the date to be selected is decently old, like a birthdate
for instance. A decent workaround would be to add an attribute on the
component to fix the initial selected date of the date picker.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-458) Allow users to control the starting date of date picker
[ https://issues.apache.org/jira/browse/TRINIDAD-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700695#action_12700695 ] Matthias Weßendorf commented on TRINIDAD-458: - the right channel is the dev@myfaces.apache.org list. By using a subject that starts like [Trinidad] Looking at the code of the renderer (ChooseDateRenderer)'s encodeAll(), I see that it looks for the current date, here: ... long currTimeMillis = 0; Object currTimeValue = bean.getProperty (_currTimeKey); if (currTimeValue != null) currTimeMillis = ((Date) currTimeValue).getTime(); else currTimeMillis = System.currentTimeMillis(); ... generally the current behavior has pros and cons, I agree. Perhaps we can find a proper solution on the dev list for handing this... Allow users to control the starting date of date picker --- Key: TRINIDAD-458 URL: https://issues.apache.org/jira/browse/TRINIDAD-458 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Simon Lessard Priority: Minor Attachments: trunk_patch90.patch Currently, date picker init itself to the current date (unless there's a DateTimeRangeValidator preventing it). This can be useful, but also problematic when the date to be selected is decently old, like a birthdate for instance. A decent workaround would be to add an attribute on the component to fix the initial selected date of the date picker. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Trinidad] How to get tr:chooseDate/ to take the starting date of is't tr:inputDate/ ?
Dear Trinidad developers,
First, thanks for a great library.
I am using the following, probably very familiar, construct:
tr:inputDate chooseId=fromDate label=From date:
value=#{userchoice.fromDate}
f:convertDateTime timeZone=CET pattern=dd-MM-yy/
/tr:inputDate
tr:chooseDate id=fromDate /
It's a big annoyance for me that tr:chooseDate / can't be somehow made to
get the initial values of its associated tr:inputDate/.
tr:chooseDate always goes to the current date.
I have tried working around this issue with JavaScript
tr:document
onload=document.show.fromDateyear.selectedIndex=#{userchoice.fromDate.year-100};
document.show.fromDatemonth.selectedIndex=#{userchoice.fromDate.month};
but it doesent work too well, also not if I include
document.show.fromDateyear.onchange();
document.show.fromDatemonth.onchange();
Could someone please advice me on fixing the above?
As I'n not a Trinidad developer and the product is in production I am
looking for a Javascript workaround (rather than having to patch the
Trinidad code).
Thanks
Jacob Nordfalk
More info:
Currently, date picker init itself to the current date (unless there's a
DateTimeRangeValidator preventing it). This can be useful, but also
problematic when the date to be selected is decently old, like a birthdate
for instance. A decent workaround would be to add an attribute on the
component to fix the initial selected date of the date picker.
[
https://issues.apache.org/jira/browse/TRINIDAD-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700690#action_12700690]
--
Jacob Nordfalk
Venu al la plej granda kultura evento en esperantujo: Kultura
Esperanto-Festivalo - la 7a ĝis la 12a de julio 2009 - http://kef.saluton.dk
एस्पेरान्तो के हो? http://www.esperanto.org.np/.
Re: [Trinidad] How to get tr:chooseDate/ to take the starting date of is't tr:inputDate/ ?
On Mon, Apr 20, 2009 at 11:10 AM, Jacob Nordfalk
jacob.nordf...@gmail.com wrote:
Dear Trinidad developers,
First, thanks for a great library.
I am using the following, probably very familiar, construct:
tr:inputDate chooseId=fromDate label=From date:
value=#{userchoice.fromDate}
f:convertDateTime timeZone=CET pattern=dd-MM-yy/
/tr:inputDate
tr:chooseDate id=fromDate /
It's a big annoyance for me that tr:chooseDate / can't be somehow made to
get the initial values of its associated tr:inputDate/.
tr:chooseDate always goes to the current date.
I have tried working around this issue with JavaScript
tr:document onload=document.show.
fromDateyear.selectedIndex=#{userchoice.fromDate.year-100};
document.show.fromDatemonth.selectedIndex=#{userchoice.fromDate.month};
but it doesent work too well, also not if I include
document.show.fromDateyear.onchange();
document.show.fromDatemonth.onchange();
Could someone please advice me on fixing the above?
As I'n not a Trinidad developer and the product is in production I am
looking for a Javascript workaround (rather than having to patch the
Trinidad code).
I commented in the bug, where to take a look in the java code (the
actual renderer).
I think a fix there, for this enhancement, would be the right way to
fix the problem.
-M
Thanks
Jacob Nordfalk
More info:
Currently, date picker init itself to the current date (unless there's a
DateTimeRangeValidator preventing it). This can be useful, but also
problematic when the date to be selected is decently old, like a birthdate
for instance. A decent workaround would be to add an attribute on the
component to fix the initial selected date of the date picker.
[
https://issues.apache.org/jira/browse/TRINIDAD-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700690#action_12700690
]
--
Jacob Nordfalk
Venu al la plej granda kultura evento en esperantujo: Kultura
Esperanto-Festivalo - la 7a ĝis la 12a de julio 2009 - http://kef.saluton.dk
एस्पेरान्तो के हो? http://www.esperanto.org.np/.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: MyFaces 2.0 Ajax Java part
Hi, The class gets generated by a Maven plugin using _UISelectItems as a base. It works fine for me. Did you checkout also the mavin plugin projects? Regards, ~ Simon On Sun, Apr 19, 2009 at 4:30 PM, Ganesh gan...@j4fry.org wrote: Hi Simon, I have run mvn install. In the API javax.faces.component._SelectItemsIterator contains references to class UISelectItems which doesn't exists. There is a class named javax.faces.component._UISelectItems and if you wouldn't say it compiles fine for you I'd think it's a typo in javax.faces.component._SelectItemsIterator. Similar issues exist for UIMessage and UIMessages. Here's a link to the ViewVC of the 2_0_0 branch. I think it supports that there is _UISelectItems, but no UISelectItems and that _SelectItemsIterator references UISelectItems: http://svn.apache.org/viewvc/myfaces/core/branches/2_0_0/api/src/main/java/javax/faces/component/ Can you please check this again? Best Regards, Ganesh Simon Lessard schrieb: Hi Ganesh, I think you forgot to execute mvn install on the build maybe because it compiles fine for me. As for running the whole thing I don't think it would be working yet since some Lifecycle phases were already modified to use the new Ajax API on partial request, but there's no impl for that code yet. Once the partial context and writer as well as JSP VDL are implemented then I think a simpel test case will be runnable. Regards, ~ Simon
[jira] Issue Comment Edited: (MYFACES-2198) remaining FacesContext/FacesContextImpl TODOs.
[ https://issues.apache.org/jira/browse/MYFACES-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700791#action_12700791 ] Michael Concini edited comment on MYFACES-2198 at 4/20/09 6:45 AM: --- Patch includes the following: removed getFlash from FacesContext/FacesContextWrapper since it is not in the API per proposed final draft spec. Completed all methods in FacesConterxtImpl. Created PartialViewContextFactoryImpl and PartialViewContextImpl. All methods completed for PartialViewContextImpl except for processPartial, which will take some additional time and is outside the scope of what this issue was opened for. I reused getRequestParameterList from SImon's code that had been commented from the former internal PartialViewContextImpl class. was (Author: mconcini): Patch includes the following: removed getFlash from FacesContext/FacesContextWrapper since it is not in the API per proposed final draft spec. Completed all methods in FacesConterxtImpl. Created PartialViewContextFactoryImpl and PartialViewContextImpl. All methods completed for PartialViewContextImpl except for processPartial, which will take some additional time and is outside the scope of what this issue was opened for. remaining FacesContext/FacesContextImpl TODOs. -- Key: MYFACES-2198 URL: https://issues.apache.org/jira/browse/MYFACES-2198 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Concini Priority: Minor Attachments: MYFACES-2198.patch handle remaining todos in FacesContext and FacesContextImpl. Includes cleaning up of FacesContext TODO: IMPLEMENENT IMPL markers that have already been handled in the impl. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2198) remaining FacesContext/FacesContextImpl TODOs.
[ https://issues.apache.org/jira/browse/MYFACES-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Concini updated MYFACES-2198: - Status: Patch Available (was: Open) remaining FacesContext/FacesContextImpl TODOs. -- Key: MYFACES-2198 URL: https://issues.apache.org/jira/browse/MYFACES-2198 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Concini Priority: Minor Attachments: MYFACES-2198.patch handle remaining todos in FacesContext and FacesContextImpl. Includes cleaning up of FacesContext TODO: IMPLEMENENT IMPL markers that have already been handled in the impl. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
OT: Oracle buys Sun
Hello everyone I just read at the german Heise site that Oracle has bought Sun for 7.4 billion dollars. I wonder what the implications in the long run will be. My personal thought is that it might finally become possible that the RI and MyFaces can merge... Java: Probably business as usual but maybe it will become more open! OpenOffice will probably be maintained with the business as usual. Same goes for OpenSolaris/Solaris But I see a rather black future for Netbeans and MySQL... (I would be sad if Netbeans would go away the IDE is simply excellent) Also the proposed IceFaces merger as base for a future JSF-Sun component set might be now dead in the light of Oracle having already something in their portfolio! As for the Sun hardware division that is a big question, but I personally guess Oracle will try to keep it alive and make it a cash cow again!
Re: [VOTE] Release of Extensions Validator 1.1.2
+1 On Thu, Apr 16, 2009 at 8:27 AM, Cagatay Civici cagatay.civ...@gmail.comwrote: +1 On Thu, Apr 16, 2009 at 1:58 PM, Werner Punz werner.p...@gmail.comwrote: +1 Werner Hazem Saleh schrieb: ++1 Gerhard! It is really a nice extension that I enjoyed much! On Thu, Apr 16, 2009 at 10:19 AM, Matthias Wessendorf mat...@apache.orgmailto: mat...@apache.org wrote: +0 On Thu, Apr 16, 2009 at 10:15 AM, Gerald Müllan gerald.muel...@gmail.com mailto:gerald.muel...@gmail.com wrote: +1 cheers, Gerald On 4/16/09, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: +1 2009/4/16 Gerhard Petracek gpetra...@apache.org mailto:gpetra...@apache.org Hi, I was running the needed tasks to get the 1.1.2 release of Apache MyFaces Extensions Validator out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.1.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] http://people.apache.org/~gpetracek/myfaces/extval/release_candidate/1_1_2/http://people.apache.org/%7Egpetracek/myfaces/extval/release_candidate/1_1_2/ http://people.apache.org/%7Egpetracek/myfaces/extval/release_candidate/1_1_2/ http://people.apache.org/%7Egpetracek/myfaces/extval/release_candidate/1_1_2/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes -- 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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/tt/articles/article.tss?l=IntroductiontoGMaps4JSF
[ANNOUNCE] Release of Apache MyFaces Extensions Validator 1.1.2
The Apache MyFaces team is pleased to announce the release of Apache MyFaces Extensions Validator 1.1.2 (for JSF 1.1). Apache MyFaces Extensions Validator is an extensible framework to validate user input based on annotations. Apache MyFaces Extensions Validator is available in both binary and source distributions: http://myfaces.apache.org/extensions/validator/download.html Apache MyFaces Extensions Validator is available in the central Maven repository under Group ID org.apache.myfaces.extensions.validator.*. Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310821styleName=Htmlversion=12313873 Enjoy! Gerhard Petracek
[ANNOUNCE] Release of Apache MyFaces Extensions Validator 1.2.2
The Apache MyFaces team is pleased to announce the release of Apache MyFaces Extensions Validator 1.2.2 (for JSF 1.2). Apache MyFaces Extensions Validator is an extensible framework to validate user input based on annotations. Apache MyFaces Extensions Validator is available in both binary and source distributions: http://myfaces.apache.org/extensions/validator/download.html Apache MyFaces Extensions Validator is available in the central Maven repository under Group ID org.apache.myfaces.extensions.validator.*. Release Notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310821styleName=Htmlversion=12313874 Enjoy! Gerhard Petracek
Re: [VOTE] Release of Extensions Validator 1.2.2
+1 On Thu, Apr 16, 2009 at 8:27 AM, Cagatay Civici cagatay.civ...@gmail.comwrote: +1 On Thu, Apr 16, 2009 at 1:57 PM, Werner Punz werner.p...@gmail.comwrote: +1 Werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces Hazem Saleh schrieb: ++1 Gerhard! It is really a nice extension that I enjoyed much! On Thu, Apr 16, 2009 at 10:19 AM, Matthias Wessendorf mat...@apache.orgmailto: mat...@apache.org wrote: +0 On Thu, Apr 16, 2009 at 10:16 AM, Gerald Müllan gerald.muel...@gmail.com mailto:gerald.muel...@gmail.com wrote: +1 cheers, Gerald -- 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 -- Hazem Ahmed Saleh Ahmed Author of (The Definitive Guide to Apache MyFaces and Facelets): http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370 Web blog: http://www.jroller.com/page/HazemBlog [Web 2.0] Google Maps Integration with JSF: http://code.google.com/p/gmaps4jsf/ http://www.theserverside.com/tt/articles/article.tss?l=IntroductiontoGMaps4JSF
Re: Result (was: Re: [VOTE] Release of Extensions Validator 1.1.2)
even though the vote was closed an update: 5 binding +1 votes (pmc): - Cagatay Civici - Gerald Müllan - Gerhard Petracek - Werner Punz - Leonardo Uribe 1 non-binding +1 votes: - Hazem Saleh 1 +0 votes: - Matthias Wessendorf no -1 votes regards, gerhard 2009/4/19 Gerhard Petracek gpetra...@apache.org thank you for voting! 4 binding +1 votes (pmc): - Cagatay Civici - Gerald Müllan - Gerhard Petracek - Werner Punz 1 non-binding +1 votes: - Hazem Saleh 1 +0 votes: - Matthias Wessendorf no -1 votes regards, gerhard 2009/4/16 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 1.1.2 release of Apache MyFaces Extensions Validator out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.1.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] http://people.apache.org/~gpetracek/myfaces/extval/release_candidate/1_1_2/http://people.apache.org/%7Egpetracek/myfaces/extval/release_candidate/1_1_2/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: Result (was: Re: [VOTE] Release of Extensions Validator 1.2.2)
even though the vote was closed an update: 5 binding +1 votes (pmc): - Cagatay Civici - Gerald Müllan - Gerhard Petracek - Werner Punz - Leonardo Uribe 1 non-binding +1 votes: - Hazem Saleh 1 +0 votes: - Matthias Wessendorf no -1 votes regards, gerhard 2009/4/19 Gerhard Petracek gpetra...@apache.org thank you for voting! 4 binding +1 votes (pmc): - Cagatay Civici - Gerald Müllan - Gerhard Petracek - Werner Punz 1 non-binding +1 votes: - Hazem Saleh 1 +0 votes: - Matthias Wessendorf no -1 votes regards, gerhard 2009/4/16 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 1.2.2 release of Apache MyFaces Extensions Validator out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] http://people.apache.org/~gpetracek/myfaces/extval/release_candidate/1_2_2/http://people.apache.org/%7Egpetracek/myfaces/extval/release_candidate/1_2_2/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[Trinidad] How to control tr:chooseDate/'s starting date?
Dear Trinidad developers,
First, thanks for a great library.
I am using the following, probably very familiar, construct:
tr:inputDate chooseId=fromDate label=From date:
value=#{userchoice.fromDate}
f:convertDateTime timeZone=CET pattern=dd-MM-yy/
/tr:inputDate
tr:chooseDate id=fromDate /
It's a big annoyance for me that tr:chooseDate / can't be somehow made to
get the initial values of its associated tr:inputDate/.
tr:chooseDate always goes to the current date.
Could someone please advice me on fixing the above?
I'm not a Trinidad developer and the product is in production, so I am
looking for a Javascript workaround (rather than having to patch the
Trinidad code).
I have tried working around this issue with JavaScript
tr:document
onload=document.myForm.fromDateyear.selectedIndex=#{userchoice.fromDate.year-100};
document.myForm.fromDatemonth.selectedIndex=#{userchoice.fromDate.month};
but it doesent work too well, also not if I include
document.myForm.fromDateyear.onchange();
document.myForm.fromDatemonth.onchange();
Thanks
Jacob Nordfalk
More info:
Currently, date picker init itself to the current date (unless there's a
DateTimeRangeValidator preventing it). This can be useful, but also
problematic when the date to be selected is decently old, like a birthdate
for instance. A decent workaround would be to add an attribute on the
component to fix the initial selected date of the date picker.
[
https://issues.apache.org/jira/browse/TRINIDAD-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12700690#action_12700690]
--
Jacob Nordfalk
Venu al la plej granda kultura evento en esperantujo: Kultura
Esperanto-Festivalo - la 7a ĝis la 12a de julio 2009 - http://kef.saluton.dk
एस्पेरान्तो के हो? http://www.esperanto.org.np/.
Re: OT: Oracle buys Sun
I may be a little bad for some sun products, but in whole it would be great for java vs .net platformOracle is second largest software vendor. I am afraid this may cause other companies like IBM to move away from Java platform On Mon, Apr 20, 2009 at 7:01 AM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I just read at the german Heise site that Oracle has bought Sun for 7.4 billion dollars. I wonder what the implications in the long run will be. My personal thought is that it might finally become possible that the RI and MyFaces can merge... Java: Probably business as usual but maybe it will become more open! OpenOffice will probably be maintained with the business as usual. Same goes for OpenSolaris/Solaris But I see a rather black future for Netbeans and MySQL... (I would be sad if Netbeans would go away the IDE is simply excellent) Also the proposed IceFaces merger as base for a future JSF-Sun component set might be now dead in the light of Oracle having already something in their portfolio! As for the Sun hardware division that is a big question, but I personally guess Oracle will try to keep it alive and make it a cash cow again! -- Arash Rajaeeyan
Re: OT: Oracle buys Sun
What would IBM move to? Why would Java be any different with Oracle from IBM's perspective? -Alan via iPhone On Apr 20, 2009, at 10:25 AM, Arash Rajaeeyan arash.rajaee...@gmail.com wrote: I may be a little bad for some sun products, but in whole it would be great for java vs .net platform Oracle is second largest software vendor. I am afraid this may cause other companies like IBM to move away from Java platform On Mon, Apr 20, 2009 at 7:01 AM, Werner Punz werner.p...@gmail.com wrote: Hello everyone I just read at the german Heise site that Oracle has bought Sun for 7.4 billion dollars. I wonder what the implications in the long run will be. My personal thought is that it might finally become possible that the RI and MyFaces can merge... Java: Probably business as usual but maybe it will become more open! OpenOffice will probably be maintained with the business as usual. Same goes for OpenSolaris/Solaris But I see a rather black future for Netbeans and MySQL... (I would be sad if Netbeans would go away the IDE is simply excellent) Also the proposed IceFaces merger as base for a future JSF-Sun component set might be now dead in the light of Oracle having already something in their portfolio! As for the Sun hardware division that is a big question, but I personally guess Oracle will try to keep it alive and make it a cash cow again! -- Arash Rajaeeyan
Re: OT: Oracle buys Sun
Oracle is a bigger competitor for IBM, has a more aggressive strategy and much less committed to open source,for example they have promised to open source Oracle ADF RC for nearly two years, (Apache RCF) but you can't see any progress. now Oracle will have the most complete software stack even more complete than Microsoft! although MySQL was very popular but it was not a direct competitor of DB2 (But Oracle is) and Solaris and AIX had their own customers, Sparc and Power platform had their own market share two, but now with popularity of Oracle DB, Oracle can boost Sparc and Solaris sale, and get more market share from IBM. in software market because of Strong position of Oracle, they may need less commitment to open source and open standards. cheers Arash On Mon, Apr 20, 2009 at 8:59 AM, Alan Hancock suddenrush9...@gmail.comwrote: What would IBM move to? Why would Java be any different with Oracle from IBM's perspective? -Alan via iPhone On Apr 20, 2009, at 10:25 AM, Arash Rajaeeyan arash.rajaee...@gmail.com wrote: I may be a little bad for some sun products, but in whole it would be great for java vs .net platformOracle is second largest software vendor. I am afraid this may cause other companies like IBM to move away from Java platform On Mon, Apr 20, 2009 at 7:01 AM, Werner Punz werner.p...@gmail.com werner.p...@gmail.com wrote: Hello everyone I just read at the german Heise site that Oracle has bought Sun for 7.4 billion dollars. I wonder what the implications in the long run will be. My personal thought is that it might finally become possible that the RI and MyFaces can merge... Java: Probably business as usual but maybe it will become more open! OpenOffice will probably be maintained with the business as usual. Same goes for OpenSolaris/Solaris But I see a rather black future for Netbeans and MySQL... (I would be sad if Netbeans would go away the IDE is simply excellent) Also the proposed IceFaces merger as base for a future JSF-Sun component set might be now dead in the light of Oracle having already something in their portfolio! As for the Sun hardware division that is a big question, but I personally guess Oracle will try to keep it alive and make it a cash cow again! -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: OT: Oracle buys Sun
My two cents: http://zwadia.com/?p=91 Cheers, Zubin. On Mon, Apr 20, 2009 at 12:09 PM, Arash Rajaeeyan arash.rajaee...@gmail.com wrote: Oracle is a bigger competitor for IBM, has a more aggressive strategy and much less committed to open source,for example they have promised to open source Oracle ADF RC for nearly two years, (Apache RCF) but you can't see any progress. now Oracle will have the most complete software stack even more complete than Microsoft! although MySQL was very popular but it was not a direct competitor of DB2 (But Oracle is) and Solaris and AIX had their own customers, Sparc and Power platform had their own market share two, but now with popularity of Oracle DB, Oracle can boost Sparc and Solaris sale, and get more market share from IBM. in software market because of Strong position of Oracle, they may need less commitment to open source and open standards. cheers Arash On Mon, Apr 20, 2009 at 8:59 AM, Alan Hancock suddenrush9...@gmail.comwrote: What would IBM move to? Why would Java be any different with Oracle from IBM's perspective? -Alan via iPhone On Apr 20, 2009, at 10:25 AM, Arash Rajaeeyan arash.rajaee...@gmail.com wrote: I may be a little bad for some sun products, but in whole it would be great for java vs .net platformOracle is second largest software vendor. I am afraid this may cause other companies like IBM to move away from Java platform On Mon, Apr 20, 2009 at 7:01 AM, Werner Punz werner.p...@gmail.com werner.p...@gmail.com wrote: Hello everyone I just read at the german Heise site that Oracle has bought Sun for 7.4 billion dollars. I wonder what the implications in the long run will be. My personal thought is that it might finally become possible that the RI and MyFaces can merge... Java: Probably business as usual but maybe it will become more open! OpenOffice will probably be maintained with the business as usual. Same goes for OpenSolaris/Solaris But I see a rather black future for Netbeans and MySQL... (I would be sad if Netbeans would go away the IDE is simply excellent) Also the proposed IceFaces merger as base for a future JSF-Sun component set might be now dead in the light of Oracle having already something in their portfolio! As for the Sun hardware division that is a big question, but I personally guess Oracle will try to keep it alive and make it a cash cow again! -- Arash Rajaeeyan -- Arash Rajaeeyan
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Hi Matthias and Werner, The partial submit issue I posted to jsr-314-comme...@jcp.org received nearly instant response from Roger Kitain. Definitely not /dev/null, these guys really take their job serious. Werner, it would be great, if you forwarded your mail to the d...@myfaces list, so we can see what happens to it. Afaik the spec doesn't say anything about the view state issue apart from the JS docs (does anybody know any other places that talks about the id of the hidden view state inputs?). The Javascript shouldn't work based on the hidden inputs ids, but based on the hidden inputs names. Here's a proposal on how to change the JS docs. If you agree, I'll post it to jsr-314-comme...@jcp.org. Correct the jsdoc for static jsf.ajax.*response*(request, context) like this: If an |update| element is found in the response with the identifier |javax.faces.ViewState|: |update id=javax.faces.ViewState ![CDATA[...]] /update| Include this |state| in the document as follows: * Extract this |update| element's |CDATA| contents from the response. (remove thes following lines) * If the document contains an element with the identifier |javax.faces.ViewState| replace its contents with the |CDATA| contents. * For each |form| element in the document: o If the |form| element contains an |input| element with the identifier |javax.faces.ViewState|, replace the |input| element contents with the |update| element's |CDATA| contents. o If the |form| element does not contain an element with the identifier |javax.faces.ViewState|, create an |input| element of the type |hidden|, with the identifier |javax.faces.ViewState|, set its contents to the |update| element's |CDATA| contents, and add the |input| element as a child to the |form| element. === (add the following lines) * Set the value of all elements within the document with the name |javax.faces.ViewState |to the CDATA contents * For each |form| element in the document: o If the |form| element does not contain an element with the name |javax.faces.ViewState|, create an |input| element of the type |hidden|, with the name |javax.faces.ViewState|, set its value to the |update| element's |CDATA| contents, and add the |input| element as a child to the |form| element. Best Regards, Ganesh
Re: MyFaces 2.0 Ajax - Also question to the JSF2 EG Members!
Sent from my iPod. Am 21.04.2009 um 06:05 schrieb Ganesh gan...@j4fry.org: Hi Matthias and Werner, The partial submit issue I posted to jsr-314-comme...@jcp.org received nearly instant response from Roger Kitain. Definitely not / dev/null, these guys really take their job serious. That was a joke about the hidden discussions on almost all EGs. Werner, it would be great, if you forwarded your mail to the d...@myfaces list, so we can see what happens to it. CC to the original list would be good Afaik the spec doesn't say anything about the view state issue apart from the JS docs (does anybody know any other places that talks about the id of the hidden view state inputs?). The Javascript shouldn't work based on the hidden inputs ids, but based In trinidad we render no ID b/c of that ... on the hidden inputs names. Here's a proposal on how to change the JS docs. If you agree, I'll post it to jsr-314-comme...@jcp.org. +1 and a CC to this list? That would be great Thx Matthias Correct the jsdoc for static jsf.ajax.*response*(request, context) like this: If an |update| element is found in the response with the identifier | javax.faces.ViewState|: |update id=javax.faces.ViewState ![CDATA[...]] /update| Include this |state| in the document as follows: * Extract this |update| element's |CDATA| contents from the response. (remove thes following lines) * If the document contains an element with the identifier |javax.faces.ViewState| replace its contents with the |CDATA| contents. * For each |form| element in the document: o If the |form| element contains an |input| element with the identifier |javax.faces.ViewState|, replace the |input| element contents with the |update| element's |CDATA| contents. o If the |form| element does not contain an element with the identifier |javax.faces.ViewState|, create an |input| element of the type |hidden|, with the identifier |javax.faces.ViewState|, set its contents to the |update| element's |CDATA| contents, and add the |input| element as a child to the |form| element. === (add the following lines) * Set the value of all elements within the document with the name |javax.faces.ViewState |to the CDATA contents * For each |form| element in the document: o If the |form| element does not contain an element with the name |javax.faces.ViewState|, create an |input| element of the type |hidden|, with the name |javax.faces.ViewState|, set its value to the |update| element's |CDATA| contents, and add the |input| element as a child to the |form| element. Best Regards, Ganesh
[jira] Created: (MYFACES-2204) process javax.faces.ViewRoot in AJAX response
process javax.faces.ViewRoot in AJAX response - Key: MYFACES-2204 URL: https://issues.apache.org/jira/browse/MYFACES-2204 Project: MyFaces Core Issue Type: Sub-task Components: JSR-314 Affects Versions: 2.0.0-alpha Environment: Javascript Reporter: Ganesh Jung Priority: Minor Get the existing code to replace the entire page to run and enhance it to use contextualRange/adjacentHTML instead of innerHTML -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2204) process javax.faces.ViewRoot in AJAX response
[ https://issues.apache.org/jira/browse/MYFACES-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Jung updated MYFACES-2204: - Status: Patch Available (was: Open) process javax.faces.ViewRoot in AJAX response - Key: MYFACES-2204 URL: https://issues.apache.org/jira/browse/MYFACES-2204 Project: MyFaces Core Issue Type: Sub-task Components: JSR-314 Affects Versions: 2.0.0-alpha Environment: Javascript Reporter: Ganesh Jung Priority: Minor Attachments: patch-2204.patch Original Estimate: 48h Remaining Estimate: 48h Get the existing code to replace the entire page to run and enhance it to use contextualRange/adjacentHTML instead of innerHTML -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
