RE: valueChangeListener + JSF lifecycle
Madhav Bhargava schrieb:
Hi All,
I was under the impression that Value change listeners will be called
only when there is no validation exception on the page. However on my
page if there is a validation failure and a message is displayed to the
user. Now if the user changes a value say in a drop down and a value
change listener is attached to it then it gets called.
Following is the code for the drop down:
t:panelGrid columns=2
s:selectOneRow id=radioLayerOne groupName=selection
value=#{ppmdController.selectedRow}
disabled=#{ppmdController.selectedValue ||
benefitController.disableScreenElements ||
templateOverviewController.disableScreenElements }
valueChangeListener=#{ppmdController.checkForErrors}
f:selectItem itemValue=ABC
itemLabel= id=rad/f:selectItem
a4j:support event=onclick id=ajaxOne
reRender=Rx_Quantity,id_minQty,id_minDaySupply,Days_Supply,id_strtrDose,id_strtrDoseBypassDays,id_strtrDoseMaintBypassDays,id_maxRetailDays,txtNoMoreThanFills,menuAlwdPerOptn,calStrtDate,chkboxDeductible,chkboxOutOfPkt,chkboxMaxBft,menuMailSrvc,id_CmpQty,selectedProvider,selectedNetwork,selectedClaims,myPpmdfloater
actionListener=#{ppmdController.fetchLayerTwo}
oncomplete=Richfaces.hideModalPanel('ajaxLoadingModalBox');enableMaxRxQtyDysSplyPPMD();
/a4j:support
/s:selectOneRow
/t:panelGrid
Should the value change listener be called when there is a validation
exception?
Simon wrote:
The spec is clear that a ValueChangeEvent should only occur if
validation passes. I've got a copy of the JSF2.0 early draft handy, and
in section 3.2.6.3:
quote
EditableValueHolder is a source of ValueChangeEvent events, which are
emitted when the validate() processing of the Process Validations phase
of the request processing lifecycle determines that the previous value
of this component differs from the current value, and all validation
checks have passed (i.e. the valid property of this component is still
true).
/quote
However before you report a bug, please check whether this still happens
in a plain MyFaces environment. I see you are using tomahawk + sandbox +
a4j all together here, which is a complex combination.
And when you have questions, you should always specify what version of
MyFaces and what version of Java you are using. Neither of those
critical pieces of information are in your original email.
Regards,
Simon
Apologies for not mentioning the JSF version. Here are the details:
Sun JSF RI 1.1_02
Tomahawk 1.1.7
Tomahawk-sandbox 1.1.7
Richfaces - 3.1.6
I will create a simple JSF project and will try out the same thing and if I
find the same behavior I will post a bug.
Thanks for your response.
Regards,
Madhav
--
-- Emails in mixed posting style will be ignored
-- (http://en.wikipedia.org/wiki/Posting_style)
CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are
not
to copy, disclose, or distribute this e-mail or its contents to any other
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has
taken
every reasonable precaution to minimize this risk, but is not liable for any
damage
you may sustain as a result of any virus in this e-mail. You should carry out
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***
Re: Tomahawk - Compatible version for MyFaces 1.2.5
Thanks for your help. I've managed to get MyFaces 1.2.5 working together with Tomahawk12-1.1.8, Trinidad 1.2.11 and RichFaces 3.3.0. Most of the pages are looking good, however, i still have one problem: Some of the links do not work correctly, but i can't see any difference. If i click on some of the links (mostly MyFaces or Tomahawk commandLinks), I'm always getting the same error: /pages/xlist.jsp No saved view state could be found for the view identifier: /pages/xlist.jsp Any ideas what this means? The session is not expired... Simon Kitching wrote: You are reading the tabel wrong (I agree it's not an easy table to read). The dashes mean no information. So the table says that myfaces 1.2.3 is definitely NOT compatible with Tomahawk 1.1.6, but otherwise there is no information at all here about recent myfaces + recent tomahawk. This table is a user-community-maintained resource (on the wiki). The user community obviously isn't bothering to maintain it. The page says clearly that the myfaces developers will not keep this table up-to-date. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style) -- View this message in context: http://www.nabble.com/Tomahawk---Compatible-version-for-MyFaces-1.2.5-tp22311695p22347553.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: Tomahawk - Compatible version for MyFaces 1.2.5
Hmm. I presume you are using server-side state-saving here. Are you using multiple browser windows at the same time? Myfaces keeps a cache of the last N views in the session. Therefore if you perform N+1 submits using one window, then try to use the other window you will get this problem. Unfortunately there is no easy solution for this. Note that the value N is configurable; I think it defaults to 20. Otherwise, I suggest using the firefox live http headers plugin or similar to see what is actually being submitted to the server. There should be one field named jsf_view_id or similar; this contains the key to look up the saved viewstate. If this is missing for some reason (eg because of some custom javascript you have in your page) then that would cause this problem. I can't think of any other likely cause at the moment... Regards, Simon andi303 schrieb: Thanks for your help. I've managed to get MyFaces 1.2.5 working together with Tomahawk12-1.1.8, Trinidad 1.2.11 and RichFaces 3.3.0. Most of the pages are looking good, however, i still have one problem: Some of the links do not work correctly, but i can't see any difference. If i click on some of the links (mostly MyFaces or Tomahawk commandLinks), I'm always getting the same error: /pages/xlist.jsp No saved view state could be found for the view identifier: /pages/xlist.jsp Any ideas what this means? The session is not expired... Simon Kitching wrote: You are reading the tabel wrong (I agree it's not an easy table to read). The dashes mean no information. So the table says that myfaces 1.2.3 is definitely NOT compatible with Tomahawk 1.1.6, but otherwise there is no information at all here about recent myfaces + recent tomahawk. This table is a user-community-maintained resource (on the wiki). The user community obviously isn't bothering to maintain it. The page says clearly that the myfaces developers will not keep this table up-to-date. Regards, Simon -- -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
Check if anything has been changed on the form
Hi All, We are trying to fine tune the DAO layer where we are using Hibernate as our ORM. Since we have too many detached objects, every time we go and save which is quite often (because of implicit save) too many queries get fired and the application responds slowly. This happens even if nothing is changed by the user on the UI. I was hoping to find a dirty flag setter in JSF where it can be checked first and only if the form has been changed will the call to other layers is made. There are a couple of options that we considered: 1. Using JS we iterate all the elements on the page and check if something has changed. However the JS gives an error if there are just too many elements on the page. Most of our pages are long and complex - don't ask me why - just a client requirement :( 2. Attach value change listeners for every component that can be modified. What if nothing gets changed and therefore no ValueChangeEvent is queued. How will this be checked? 3. Hack model update phase and try and set a dirty flag if anything is updated during that phase. Do not know how to do that either? The solution needs to be light on performance. Any pointer would be really appreciated. Thanks Regards, Madhav CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS***
Re: Check if anything has been changed on the form
Madhav Bhargava schrieb: Hi All, We are trying to fine tune the DAO layer where we are using Hibernate as our ORM. Since we have too many detached objects, every time we go and save which is quite often (because of implicit save) too many queries get fired and the application responds slowly. This happens even if nothing is changed by the user on the UI. I was hoping to find a dirty flag setter in JSF where it can be checked first and only if the form has been changed will the call to other layers is made. There are a couple of options that we considered: 1. Using JS we iterate all the elements on the page and check if something has changed. However the JS gives an error if there are just too many elements on the page. Most of our pages are long and complex – don’t ask me why – just a client requirement L 2. Attach value change listeners for every component that can be modified. What if nothing gets changed and therefore no ValueChangeEvent is queued. How will this be checked? 3. Hack model update phase and try and set a dirty flag if anything is updated during that phase. Do not know how to do that either? The solution needs to be light on performance. Any pointer would be really appreciated. So what you really need is to know whether a ValueChangeEvent has been queued for any component, right? One way to do that would be to use a custom ViewHandler in order to return a custom UIViewRoot object that wraps the real one. Then you could override the UIViewRoot.queueEvent method, and check in there whether the event being queued is a ValueChangeEvent. If at the start of the update-model phase, one or more ValueChangeEvents has been queued during the request then you have a real change to the model. You could store this flag as a request-scope property or similar. Note that each input component is responsible for detecting that the model property it is bound to has a different value, and queueing a ValueChangeEvent on itself. But queuing an event on itself just causes the call to bubble up the component tree until it reaches the UIViewRoot, where the event is stuck on a global queue. So UIViewRoot.queueEvent is eventually called for all events. Possibly the original queued event gets wrapped on the way up (eg tables create a wrapper so they can restore the correct row when the event is executed), but I would expect that any wrapper for a ValueChangeEvent would also be a subclass of ValueChangeEvent. This seems generally useful; maybe such a patch would even be accepted into the MyFaces UIViewRoot impl (though of course if you want your app to run on Mojarra too then you'd need a separate implementation anyway). I don't quite understand your point (2) above : if nothing gets changed, and no ValueChangeEvent is triggered, isn't that ok? In this case your model isn't changed and that is what you wanted to know. By the way, I believe that JSF2.0 will state that during the update-model phase, setters are only called on model properties where the property value *has* changed, ie where a ValueChangeEvent has been queued for that component because calling the property getter returned a different value than the component contains internally. However the JSF1.1 spec didn't say this, and both Sun and MyFaces currently call property setters for all input components, regardless of whether the value has changed or not. Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style)
Orchestra Core 1.3.1 Released
The Apache MyFaces Orchestra team is pleased to announce the release of Apache MyFaces Orchestra Core 1.3.1 This is a bugfix release that fixes a small number of issues with release 1.3. There is no need to upgrade if you are not experiencing any of the issues listed in the release notes. Get a full overview at Orchestra's homepage [1]. The release notes for 1.3.1 can be found here: * http://svn.apache.org/repos/asf/myfaces/orchestra/tags/core-1_3_1/RELEASE-NOTES.txt The distribution is available at * http://myfaces.apache.org/orchestra/download.html Apache MyFaces Orchestra is available in the central Maven repository under Group ID org.apache.myfaces.orchestra. Regards, Simon [1] http://myfaces.apache.org/orchestra
RE: Orchestra Core 1.3.1 Released
YAH ! :-) -Original Message- From: Simon Kitching [mailto:skitch...@apache.org] Sent: Thursday, March 05, 2009 3:44 PM To: MyFaces Discussion Subject: Orchestra Core 1.3.1 Released The Apache MyFaces Orchestra team is pleased to announce the release of Apache MyFaces Orchestra Core 1.3.1 This is a bugfix release that fixes a small number of issues with release 1.3. There is no need to upgrade if you are not experiencing any of the issues listed in the release notes. Get a full overview at Orchestra's homepage [1]. The release notes for 1.3.1 can be found here: * http://svn.apache.org/repos/asf/myfaces/orchestra/tags/core- 1_3_1/RELEASE-NOTES.txt The distribution is available at * http://myfaces.apache.org/orchestra/download.html Apache MyFaces Orchestra is available in the central Maven repository under Group ID org.apache.myfaces.orchestra. Regards, Simon [1] http://myfaces.apache.org/orchestra
Re: How to access session scope attributes via JSF EL
Unless you set #{sessionScope.someBooleanProperty} to true it will return
null, and null is the same as false in terms of the disabled attribute.
-Andrew
On Wed, Mar 4, 2009 at 11:54 PM, Madhav Bhargava
madhav_bharg...@infosys.com wrote:
Hi All,
In a JSP I need to disable a component based on an attribute’s value in
HttpSession.
http://developers.sun.com/docs/jscreator/help/jsp-jsfel/jsf_expression_language_intro.html
The above link mentions that session scope can be accessed using an
implicit object – sessionScope
I tried to use session scope as follows:
t:inputText id=”someID” value=”#{someBean.someProperty} disabled
=”#{sessionScope.someBooleanProperty}”/
The session attribute gets set properly but
#{sessionScope.someBooleanProperty} always returns “false”.
I am assuming I am doing something wrong here. What would be the correct
way to use session attributes?
Thanks Regards,
Madhav
CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are
not
to copy, disclose, or distribute this e-mail or its contents to any other
person and
any such actions are unlawful. This e-mail may contain viruses. Infosys has
taken
every reasonable precaution to minimize this risk, but is not liable for any
damage
you may sustain as a result of any virus in this e-mail. You should carry out
your
own virus checks before opening the e-mail or attachment. Infosys reserves the
right to monitor and review the content of all messages sent to or from this
e-mail
address. Messages sent to or from this e-mail address may be stored on the
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***
