I use this approach to decide if an dialog should be closed or keeped open (to show validation errors).

form that holds the max Severity:
<h:form id="severityForm" style="display:none;">
<h:inputHidden id="maximumSeverity" value="#{facesContext.maximumSeverity.ordinal}"/>
</h:form>

In my js callbacks i use this function to decide:
function requestContainsErrors()
{
return document.getElementById('severityForm:maximumSeverity').value >= '2';
}

Its a bit complicated because you must rerender the hidden field on ajax requests too. If you use richfaces you can put the hidden field in an <a4j:outputPanel> to avoid manual rerender. This works but i agree there should be an convenient way to check for error messages (or validation errors) in the js callbacks.

Regards,
Luca



Jakob Korherr wrote:
Hi Mark and Werner,

You could also add a h:messages component to the page and re-render this one
in any ajax-request. If the dom-update for this component is not empty, then
you know that there are FacesMessages.

Regards,
Jakob

2010/6/13 Werner Punz <werner.p...@gmail.com>

Am 13.06.10 07:11, schrieb Mark Li:

 when i use jsf.ajax, i cant find out any information about facesmessage.
I have looked into "Event Object", but find nothing.

My situation is,

jsf.ajax.request(this, event,{
       onerror:function(data){alert('nothing happened!')},
       onevent:function(data){
       //if there is message do something. will do like keep dialog.
       //if there is no message do otherthings. will do like close dialog;
       }
} );


Can anyone help?

 Hi there is no direct handling of faces-messages in the protocol, if you
do a standard ajax request you will get something back like
<update id="bbb">html code to update </update>

so what you can do is to check the response for updated message fields.
The protocol unfortunately does not deal with messages directly all it does
is to deal with dom nodes which get updated.

The protocol allows following tags but only update is used due to a spec
limitation which hopefully will be lifted on 2.1
(on component level)

<update>
<insert>
<delete>
<attributes>
<eval>
<extension> afair with extension being a place for specific extensions.

So currently both impls do not use extension but if you need direct access
to the faces messages you could add a custom mechanism (responsewriter,
maybe an event handler ), which drags them directly in and use the
extensions tag for this purpose, but then you have to parse them out also
via an event handler.


Werner






--
Technical Consulting

------------------------------------------------------

Inxmail GmbH
Wentzingerstr. 17, 79106 Freiburg, Germany
Tel: +49 761 296979-404, Fax: -9
luca.g...@inxmail.de, www.inxmail.de

Handelsregister Freiburg, HRB 5870
USt.-ID: DE198371679
Geschäftsleitung: Martin Bucher, Peter Ziras
------------------------------------------------------

Inxmail Professional kostenlos testen:
http://www.inxmail.de/jetzt-testen

Tipps und Tricks für E-Mail-Marketers:
http://www.inxmail.de/newsletter

Inxmail kompakt in 140 Zeichen:
http://www.twitter.com/inxmail_gmbh

Reply via email to