From adffaces-user-return-1878-apmail-incubator-adffaces-user-archive=incubator.apache.org@incubator.apache.org Wed Jan 17 02:08:52 2007 Return-Path: Delivered-To: apmail-incubator-adffaces-user-archive@locus.apache.org Received: (qmail 6385 invoked from network); 17 Jan 2007 02:08:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Jan 2007 02:08:52 -0000 Received: (qmail 31206 invoked by uid 500); 17 Jan 2007 02:08:58 -0000 Delivered-To: apmail-incubator-adffaces-user-archive@incubator.apache.org Received: (qmail 31194 invoked by uid 500); 17 Jan 2007 02:08:58 -0000 Mailing-List: contact adffaces-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-user@incubator.apache.org Delivered-To: mailing list adffaces-user@incubator.apache.org Received: (qmail 31185 invoked by uid 99); 17 Jan 2007 02:08:58 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Jan 2007 18:08:58 -0800 X-ASF-Spam-Status: No, hits=3.5 required=10.0 tests=HTML_MESSAGE,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (herse.apache.org: transitioning domain of g.steyn@cqu.edu.au does not designate 138.77.5.11 as permitted sender) Received: from [138.77.5.11] (HELO mx.cqu.edu.au) (138.77.5.11) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Jan 2007 18:08:48 -0800 Received: from [127.0.0.1] (helo=falcon.cqu.edu.au) by mx.cqu.edu.au with esmtp (Exim 4.63) (envelope-from ) id 1H70Dw-0002Pr-OY for adffaces-user@incubator.apache.org; Wed, 17 Jan 2007 12:08:24 +1000 Received: from tsurani.cqu.edu.au (tsurani.cqu.edu.au [138.77.5.123]) by falcon.cqu.edu.au (8.13.8/8.13.8) with ESMTP id l0H28NtU009255 for ; Wed, 17 Jan 2007 12:08:24 +1000 (EST) (envelope-from g.steyn@cqu.edu.au) Received: from remus.staff.ad.cqu.edu.au ([138.77.34.93] helo=UNIMAIL.staff.ad.cqu.edu.au) by tsurani.cqu.edu.au with esmtp (Exim 4.44) id 1H70Da-0003NE-5s for adffaces-user@incubator.apache.org; Wed, 17 Jan 2007 12:08:02 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C739DB.DCDC0018" Subject: Trinidad/Facelets problem with html elements being rendered repeatedly if there is a validation error - faces-1_2-070102 branch. Date: Wed, 17 Jan 2007 12:04:46 +1000 Message-ID: <1AE19A80523D5F40BE0044A1447A53FF0396EF2E@UNIMAIL.staff.ad.cqu.edu.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trinidad/Facelets problem with html elements being rendered repeatedly if there is a validation error - faces-1_2-070102 branch. Thread-Index: Acc5239rR9GuYoA1RmKRLsT2WHUBzw== From: "Graeme Steyn" To: X-Virus-Checked: Checked by ClamAV on apache.org ------_=_NextPart_001_01C739DB.DCDC0018 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Good Morning again, =20 I have a another question related to the use of Trinidad and a problem that I am experiencing. I have basically got a mix of tomahawk, facelets 1.1.11, Trinidad face-1_2-070102 branch, the reference JSF implementation and Glassfish SJSAS 9_01 patch 1. For the page in question, I have surrounded the fields in a fieldset. I have also used the tr:form component, with a normal . When I submit the page with an error that gets detected on the server side, it renders a response with a blank fieldset for each of the fieldsets defined in the page. So for the original page in question there are 3 fieldsets. The page gets re-rendered with 3 empty fieldsets followed by the originals. If you submit a second time with the same validation error, it gets rendered with 6 empty fieldsets followed by the originals. And so the pattern continues. =20 Original Page =20 =20 Rerendered Page - first submission error =20
=20 Rerendered Page - second submission error =20
=20 I have experienced a similar problem with the use of trh:body, where the body contents get re-rendered multiple times. Could anyone point me in the right direction? Is there an overview document that may deal with some of the basic rules of using Trinidad that I could read. For example, covering things like the fact that Trinidad renders IDs differently to the reference version of JSF. =20 The original page code appears below. =20 Thank you. Graeme Steyn =20 quickDetails.xhtml =20 Quick Details #{bundle.formQuickDetails} #{bundle.formQuickDetails} =20 =20
=20 =20 =20 =20 =20 =20 =20 =20
=20 =20 =20 =20 =20
Facelets Template: =20 <ui:insert name=3D"pageTitle">Default = Title</ui:insert> =20 = =20
=20

No page content has been provided.

=20
=20 =20
=20 =20 =20 =20
=20 nextAction code: =20 public boolean isPreferredChannelDataOk(FacesContext facesContext) { =20 ContactType preferredChannel =3D getVisit().getCandidate() .getContacts().getPreferredContactType(); String contactVal =3D getVisit().getCandidate().getContact( preferredChannel); =20 if (contactVal =3D=3D null || contactVal.equals("")) { FacesMessage message =3D new FacesMessage( FacesMessage.SEVERITY_ERROR, "A value must be entered.", null); =20 // Note that to be able to display the error message with the // correct field, a client ID is required. This means that in // the xhtml, the ID for the fields must match the toString() // values returned by the enumeration type. Note that Trinidad // does not appear to prepend the field ID with the form ID // as done in the JSF standard. If using the core Html tags (h) // you need to prepend the field ID with form ID. facesContext.addMessage(preferredChannel.toString(), message); return false; } =20 return true; } ------_=_NextPart_001_01C739DB.DCDC0018--