Could one of the guys who found this problem create a JIRA issue so we don't loose track.
On 8/6/07, Danny Robinson <[EMAIL PROTECTED]> wrote: > > Good question. Did a quick test and it's the style, but it's not that > easy looking at the code!!! The MessageRenderer isn't the simplest piece of > code. Really hard to understand just what gets rendered when. Before you > discovered it's the style, I did a quick refactor that seemed to fix the IE > problem. > > As the inline validation is now the default it seems to make sense to have > it output div's for each message section (help, message, inline-message). > Prior to this, it was pushing out span-br-span or span-br-span-br-span > depending on the scenario. We should try and keep things consistent for > successful skinning - as it stands now, changes to OraInlineInfoText would > unintentionally appear in OraInlineErrorText. > I've attached a patch file - see what you think. There's definate further > improvements that could be made. > > D. > > On 8/6/07, Adam Winer <[EMAIL PROTECTED]> wrote: > > > Is it the span, or the OraInlineInfoText style that's to blame? > > > > -- Adam > > > > > > On 8/6/07, Danny Robinson <[EMAIL PROTECTED]> wrote: > > > I can see it also. Not tracked this down in the renderer, but just > > saved > > > the output html and played with it. > > > Would seem to be related to the outer SPAN inside the DIV that renders > > under > > > each input field. > > > > > > <DIV class=af_panelFormLayout_message-cell style="DISPLAY: > > > none"><!--Start: > > > org.apache.myfaces.trinidad.Input["_idJsp3"]--><SPAN > > > class=OraInlineInfoText><SPAN class=OraInlineErrorText > > > id=_idJsp1:_idJsp3::msg > > > style="DISPLAY: none"></SPAN></SPAN></DIV> > > > > > > With the SPAN removed it seems to behave. > > > > > > > > > > > > On 8/6/07, Butash, Bob < [EMAIL PROTECTED]> wrote: > > > > Adam, > > > > > > > > I'm testing with IE 6. Here is the simple.jsp page that I created: > > > > > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" > > > > " http://www.w3.org/TR/html4/loose.dtd";> > > > > <%@ page contentType="text/html;charset=windows-1252"%> > > > > <%@ taglib uri="http://java.sun.com/jsf/html " prefix="h"%> > > > > <%@ taglib uri="http://java.sun.com/jsf/core " prefix="f"%> > > > > <%@ taglib uri=" > > > http://myfaces.apache.org/trinidad"; > > > prefix="tr"%> > > > > <f:view> > > > > <tr:document> > > > > <h:form> > > > > <tr:panelFormLayout> > > > > <tr:inputText label="Label 1" required="true"/> > > > > <tr:inputText label="Label 2" required="true"/> > > > > <tr:commandButton action="/jsp/simple.jspx"/> > > > > </tr:panelFormLayout> > > > > </h:form> > > > > </tr:document> > > > > > > > > </f:view> > > > > > > > > I enter a value in the first field and then click on the button....I > > get > > > > whitespace below the first field and I properly get the error > > message > > > > under the second field. If the Trinidad <client-validation> is set > > to > > > > DISABLED the weird spacing goes away, but then this takes away the > > > > client side validation. Obviously if it is set to ALERT, the > > JavaScript > > > > alert box is shown. We were hoping to get a consistent look and > > feel > > > > with the messages that need to come from the server and the ones > > that > > > > could be checked on the client. > > > > > > > > I have attached some screen shots, not sure if they will make it to > > the > > > > distribution list. > > > > > > > > Thanks, > > > > > > > > Bob > > > > > > > > > > > > -----Original Message----- > > > > From: Adam Winer [mailto: [EMAIL PROTECTED] > > > > Sent: Monday, August 06, 2007 2:03 PM > > > > To: MyFaces Discussion > > > > Subject: Re: Trinidad Migration to 1.0.1 > > > > > > > > I've just tested with the current Trinidad 1.0.2 code and IE 7, and > > > > don't see a problem. Are you seeing problems with IE 6 or IE 7? If > > IE > > > > 7, could you post the simplest page you can think of that shows a > > > > problem? > > > > > > > > -- Adam > > > > > > > > > > > > On 8/6/07, Perkins, Nate-P63196 <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > I have this issue as well. I have not found a solution to it yet. > > > > > > > > > > > > > > > > > Nate Perkins > > > > > 480-441-3667 > > > > > [EMAIL PROTECTED] > > > > > > > > > > This email message is for the sole use of the intended > > recipient(s) > > > > > and may contain GDC4S confidential or privileged information. Any > > > > > unauthorized review, use, disclosure or distribution is > > prohibited. > > > > > If you are not an intended recipient, please contact the sender by > > > > > > > reply email and destroy all copies of the original message. > > > > > > > > > > > > > > > ________________________________ > > > > > From: Butash, Bob [mailto: [EMAIL PROTECTED] ] > > > > > Sent: Monday, August 06, 2007 10:42 AM > > > > > To: [email protected] > > > > > Subject: Trinidad Migration to 1.0.1 > > > > > > > > > > > > > > > > > > > > > > > > > Hello - > > > > > > > > > > I'm migrating from a Snapshot build of Trinidad to version 1.0.1and > > > > > I'm noticing differences between Firefox and Internet Explorer > > when > > > > > I'm using the required attribute on a form field. The issue that > > I'm > > > > > having is that when I submit the page with Internet Explore I see > > a > > > > > flash of the screen with the input fields expanded as if there was > > > > > > > room for the error messages to be displayed between the > > fields. If I > > > > > submit the form with a missing required field, I get the error > > message > > > > > > > > > properly but once again all of the other fields have been spaced > > for > > > > > error messages. These pages look fine with Firefox. > > > > > > > > > > Has anyone else seen this behavior? I'm assuming that it has > > > > > something to do with the new AJAX validation instead of the > > javascript > > > > > > > > > validation, but I did not think that it would cause all of the > > screen > > > > > flashes and spacing issues. > > > > > > > > > > Thanks, > > > > > > > > > > Bob > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Chordiant Software Inc. > > > www.chordiant.com > > > > > > -- > Chordiant Software Inc. > www.chordiant.com > > -- Chordiant Software Inc. www.chordiant.com
