Return-Path: Delivered-To: apmail-myfaces-users-archive@www.apache.org Received: (qmail 40541 invoked from network); 13 Jul 2009 21:51:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Jul 2009 21:51:55 -0000 Received: (qmail 66600 invoked by uid 500); 13 Jul 2009 21:52:03 -0000 Delivered-To: apmail-myfaces-users-archive@myfaces.apache.org Received: (qmail 66519 invoked by uid 500); 13 Jul 2009 21:52:03 -0000 Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Discussion" Delivered-To: mailing list users@myfaces.apache.org Received: (qmail 66511 invoked by uid 99); 13 Jul 2009 21:52:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Jul 2009 21:52:03 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of anuj.argusoft@gmail.com designates 209.85.217.227 as permitted sender) Received: from [209.85.217.227] (HELO mail-gx0-f227.google.com) (209.85.217.227) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Jul 2009 21:51:54 +0000 Received: by gxk27 with SMTP id 27so3949638gxk.12 for ; Mon, 13 Jul 2009 14:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=YutgqO094dlRCwufqdIpxXPu2VRPRcx0bY3chzCDn0c=; b=D011cGTv/4zDJw2FEdQi42RRj5HTr08SS1PRQCz/1xqVhgoIl84eHIreULrydz/I/e zlBj6NWNP+mb0qAk2H9LK9iVpdmiZhMnkNdQxgsaVwgPD414WT3TLs/T3hOQSqfk6Z1+ jrDpUnNBYVoCs/+DmUW41bhVt/NhVimY/1PPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=HNABS0tbgWFHZ5FoonP0Cc27SaTWUBmCy6CRAE4hR6sjExK2/rQl3CnLQd29jbmaEM FAS3UbmS9xJqjC8JXdwYuTfnJ2RanVRPDVXq5Q8RpUVwE1HK4fEMZrp5NQGuyzmTS4xq QDVPqrLRBaZ91GikW/YoMwm1NWtoL/XBIUdW8= MIME-Version: 1.0 Received: by 10.151.38.12 with SMTP id q12mr9071217ybj.166.1247521893879; Mon, 13 Jul 2009 14:51:33 -0700 (PDT) In-Reply-To: References: <4A495D4A.2080008@oracle.com> Date: Mon, 13 Jul 2009 14:51:33 -0700 Message-ID: Subject: Re: tr:inputFile with panelGroupLayout From: Anuj Patel To: MyFaces Discussion Content-Type: multipart/mixed; boundary=001517511032558ff1046e9d5317 X-Virus-Checked: Checked by ClamAV on apache.org --001517511032558ff1046e9d5317 Content-Type: multipart/alternative; boundary=001517511032558fe0046e9d5315 --001517511032558fe0046e9d5315 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Matt, Attached is the page I created to reproduce this problem. I haven't used any other component library nor is there any custom HTML on the page. Yet, the problem is easily reproduced. If you find something fishy in the code, then please feel free to point it out. -Anuj On Tue, Jul 7, 2009 at 9:57 AM, Matt Cooper wrote: > The behavior described sounds like there might be some invalid HTML on the > page. If you have any other component libraries or any custom HTML in this > page, I would recommend trying to remove them temporarily to isolate the > problem. If certain pieces of the page are not showing up but their content > is present in the raw page source, this is typically caused by mismatching > start/end elements. > > Regards, > Matt > > > On Wed, Jul 1, 2009 at 2:46 PM, Anuj Patel wrote: > >> It looks like the panelGroupLayout is the culprit here. Because, even >> after I provided an id for the panelGroupLayout, the span remained >> unaltered. i.e. *<**span** id**=**"uploadPhoto:inputFileImg::msg" ** >> class**=**"OraInlineErrorText"**>** * * >> * >> *Could someone confirm if this is a bug and if so can we create a JIRA >> issue for the same?* >> >> *-Anuj >> * >> >> On Mon, Jun 29, 2009 at 6:21 PM, Anuj Patel wrote: >> >>> The span *<**span** id**=**"uploadPhoto:inputFileImg::msg" **class**=** >>> "OraInlineErrorText"**>** * >>> already indicates who the message is for. Besides, if this would have >>> been a problem, then my code wouldn't have worked in the scenario where I do >>> not have anything in the panelGroupLayout. >>> >>> One of my other apps, also have similar functionality built with which I >>> am able to see the message when I try to upload file greater than allowable >>> size >>> >>> Thanks, >>> Anuj >>> >>> On Mon, Jun 29, 2009 at 5:33 PM, Mamallan Uthaman < >>> mamallan.uthaman@oracle.com> wrote: >>> >>>> Hi Anuj, >>>> >>>> Could you please try using to display any error message in >>>> the FacesContext? If you refer to Trinidad issue (Trinidad-607) that >>>> resolved this problem, the last comment states that the error message is >>>> stored in the FacesContext. >>>> >>>> Thanks >>>> Mamallan >>>> >>>> >>>> Anuj Patel wrote: >>>> >>>>> Hi All, >>>>> I am using Trinidad-api and trinidad-impl version 1.2.10. When using >>>>> tr:inputFile with in tr:panelGroupLayout, if the file size is too large then >>>>> the message that should be displayed for informing the user is not getting >>>>> displayed. Following is the generated source; >>>>>

>>>> class="af_panelGroupLayout">>>>> id="uploadPhoto:inputFileImg__xc_" class="af_inputFile" cellpadding="0" >>>>> cellspacing="0" border="0" summary="">
>>>> nowrap>>>>> class="AFContentCell">>>>> name="uploadPhoto:inputFileImg" onchange="checkImageExtension(this);" >>>>> class="af_inputFile_content" type="file">
>>>> class="AFComponentMessageCell">>>>> class="OraInlineErrorText">
>>>>> As one may see in the above generated text, the span that should >>>>> display the message is turning out to have no value in it. Also, the icon >>>>> "X" does not show up on the screen for some reason. >>>>> Following is my code snippet that is generating the above mentioned >>>>> view source when trying to upload a file bigger than allowable size; >>>>> / >>>>> >>>> id="inputFileImg" onchange="validateFile(this);" >>>>> partialTriggers="uploadImgBtn deleteBtn" value="#{backingBean.imageFile}" >>>>> rendered="#{backingBean.imageFile==null}"/> >>>>> / Is this a bug or >>>>> am I missing something? FYI, I get the same behaviour even with version >>>>> 1.2.9. Although, in version 1.2.9 there is an exception reported in the >>>>> server log where as in 1.2.10 the exception does not get logged in server >>>>> log. >>>>> -Anuj >>>>> >>>> >>> >> > --001517511032558fe0046e9d5315 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Matt,
Attached is the page I created to reproduce this problem.=A0 I = haven't used any other component library nor is there any custom HTML o= n the page.=A0 Yet, the problem is easily reproduced.
If you find someth= ing fishy in the code, then please feel free to point it out.

-Anuj


On Tue, Jul 7, 2009 at 9:57= AM, Matt Cooper <mcooper@apache.org> wrote:
The behavior described sounds like there might be some invalid HTML on the = page.=A0 If you have any other component libraries or any custom HTML in th= is page, I would recommend trying to remove them temporarily to isolate the= problem.=A0 If certain pieces of the page are not showing up but their con= tent is present in the raw page source, this is typically caused by mismatc= hing start/end elements.

Regards,
Matt


On Wed, Jul 1, 2009 at 2:46 PM= , Anuj Patel <anuj.argusoft@gmail.com> wrote:
It looks like the panelGroupLayout is the culprit here. =A0Because, even af= ter I provided an id for the panelGroupLayout, the span remained unaltered.= =A0i.e.=A0=A0<span=A0id=3D"uploadPhoto:inputFileImg::msg"=A0<= /span>class=3D"OraInlineErrorText"></span>=A0

Could someone confi= rm if this is a bug and if so can we create a JIRA issue for the same?

-Anuj

On Mon, Jun 29, 2009 at 6:21 PM, Anuj Patel &= lt;anuj.arguso= ft@gmail.com> wrote:
The span=A0<= span style=3D"font-size: 12pt; font-family: "Times New Roman",&qu= ot;serif";">span id=3D"uploadPhoto:inputFileImg::msg" clas= s=3D= "OraInlineErrorText"></span>=A0
already indica= tes who the message is for. =A0Besides, if this would have been a problem, = then my code wouldn't have worked in the scenario where I do not have a= nything in the panelGroupLayout. =A0

One of my other apps, also have similar functionality b= uilt with which I am able to see the message when I try to upload file grea= ter than allowable size

Thanks,
Anuj

On Mon, Jun 29, 2009 at 5:33 PM, Mamall= an Uthaman <mamallan.uthaman@oracle.com> wrote:
Hi Anuj,

Could you please try using <tr:messages> to display any error message= in the FacesContext? If you refer to Trinidad issue (Trinidad-607) that re= solved this problem, the last comment states that the error message is stor= ed in the FacesContext.

Thanks
Mamallan


Anuj Patel wrote:
Hi All,
I am using Trinidad-api and trinidad-impl version 1.2.10. =A0When using tr:= inputFile with in tr:panelGroupLayout, if the file size is too large then t= he message that should be displayed for informing the user is not getting d= isplayed. =A0Following is the generated source;
=A0=A0<br><br><span id=3D"uploadPhoto:j_id141" cla= ss=3D"af_panelGroupLayout"><script type=3D"text/javasc= ript">var _locale=3D'en';var _tLocale=3D'en';</s= cript><script type=3D"text/javascript" src=3D"/adf/jsL= ibs/resources/LocaleElements_en1_2_10.js?loc=3Den"></script>&= lt;table id=3D"uploadPhoto:inputFileImg__xc_" class=3D"af_in= putFile" cellpadding=3D"0" cellspacing=3D"0" borde= r=3D"0" summary=3D""><tr><td class=3D"= af_inputFile_label" nowrap><span id=3D"uploadPhoto:inputFil= eImg::icon" style=3D"display:none;"><a name=3D"_m= sgAnc_uploadPhoto:inputFileImg" title=3D"Error" class=3D&quo= t;AFErrorIconStyle">X</a></span></td><td valig= n=3D"top" nowrap class=3D"AFContentCell"><input i= d=3D"uploadPhoto:inputFileImg" name=3D"uploadPhoto:inputFile= Img" onchange=3D"checkImageExtension(this);" class=3D"a= f_inputFile_content" type=3D"file"></td></tr>= <tr><td></td><td class=3D"AFComponentMessageCell&= quot;><span id=3D"uploadPhoto:inputFileImg::msg" class=3D&q= uot;OraInlineErrorText"></span></td></tr></tab= le>
As one may see in the above generated text, the span that should display th= e message is turning out to have no value in it. =A0Also, the icon "X&= quot; does not show up on the screen for some reason.
=A0Following is my code snippet that is generating the above mentioned view= source when trying to upload a file bigger than allowable size;
=A0/<tr:panelGroupLayout partialTriggers=3D"uploadImgBtn deleteBtn&= quot;>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0<tr:inputFile id=3D"inputFileImg&quo= t; onchange=3D"validateFile(this);" partialTriggers=3D"uploa= dImgBtn deleteBtn" value=3D"#{backingBean.imageFile}" render= ed=3D"#{backingBean.imageFile=3D=3Dnull}"/>
/ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Is this a bug or am I missing something? =A0= FYI, I get the same behaviour even with version 1.2.9. =A0Although, in vers= ion 1.2.9 there is an exception reported in the server log where as in 1.2.= 10 the exception does not get logged in server log.
-Anuj




--001517511032558fe0046e9d5315-- --001517511032558ff1046e9d5317 Content-Type: application/xhtml+xml; name="imageUpload.xhtml" Content-Disposition: attachment; filename="imageUpload.xhtml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fx3qbgnr0 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjwhRE9DVFlQRSBodG1sIFBV QkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFN0cmljdC8vRU4iICJodHRwOi8vd3d3LnczLm9y Zy9UUi94aHRtbDEvRFREL3hodG1sMS1zdHJpY3QuZHRkIj4NCjxodG1sIHhtbG5zPSJodHRwOi8v d3d3LnczLm9yZy8xOTk5L3hodG1sIg0KICAgICAgeG1sbnM6dWk9Imh0dHA6Ly9qYXZhLnN1bi5j b20vanNmL2ZhY2VsZXRzIg0KICAgICAgeG1sbnM6aD0iaHR0cDovL2phdmEuc3VuLmNvbS9qc2Yv aHRtbCINCiAgICAgIHhtbG5zOmY9Imh0dHA6Ly9qYXZhLnN1bi5jb20vanNmL2NvcmUiDQogICAg ICB4bWxuczp0cj0iaHR0cDovL215ZmFjZXMuYXBhY2hlLm9yZy90cmluaWRhZCI+DQogICAgICAN CiAgICA8dWk6Y29tcG9zaXRpb24gdGVtcGxhdGU9Ii9XRUItSU5GL2xheW91dC9pbWFnZVVwbG9h ZExheW91dC54aHRtbCIgPg0KDQogICAgICAgIDx1aTpkZWZpbmUgbmFtZT0idGl0bGUiPlVwbG9h ZCBJbWFnZTwvdWk6ZGVmaW5lPg0KICAgICAgICA8dWk6ZGVmaW5lIG5hbWU9ImNvbnRlbnQiPg0K DQogICAgICAgICAgICA8dHI6Zm9ybSBpZD0icGFydHlDb250YWN0Rm9ybSIgdXNlc1VwbG9hZD0i dHJ1ZSI+DQogICAgICAgICAgICAgICAgPHRyOnBhbmVsR3JvdXBMYXlvdXQgaWQ9InBhbmVsR3Jv dXBGaWxlVXBsb2FkIiBwYXJ0aWFsVHJpZ2dlcnM9InVwbG9hZEltZ0J0biBkZWxldGVCdG4iPg0K ICAgICAgICAgICAgICAgICAgICA8dHI6aW5wdXRUZXh0IGxhYmVsPSJOYW1lIiB2YWx1ZT0iI3tp bWFnZVVwbG9hZEJlYW4ucGVyc29uTmFtZX0iLz4NCiAgICAgICAgICAgICAgICAgICAgPHRyOmlu cHV0RmlsZSBpZD0iaW5wdXRGaWxlSW1nIiBsYWJlbD0iSW1hZ2UiIHZhbHVlPSIje2ltYWdlVXBs b2FkQmVhbi5maWxlfSIgcmVuZGVyZWQ9IiN7aW1hZ2VVcGxvYWRCZWFuLmZpbGU9PW51bGx9Ii8+ DQogICAgICAgICAgICAgICAgICAgIDx0cjppbnB1dFRleHQgaWQ9ImZpbGVOYW1lVGV4dCIgbGFi ZWw9IkltYWdlIiByZWFkT25seT0idHJ1ZSIgcmVxdWlyZWQ9InRydWUiIHZhbHVlPSIje2ltYWdl VXBsb2FkQmVhbi5maWxlLmZpbGVuYW1lfSIgcmVuZGVyZWQ9IiN7aW1hZ2VVcGxvYWRCZWFuLmZp bGUhPW51bGx9Ii8+DQoNCiAgICAgICAgICAgICAgICAgICAgPHRyOmltYWdlIGlkPSJibGFua0lt ZyIgc291cmNlPSIvaW1hZ2V1cGxvYWQvaW1hZ2UiIGlubGluZVN0eWxlPSJoZWlnaHQ6IDEwMHB4 OyIvPg0KDQogICAgICAgICAgICAgICAgICAgIDx0cjpjb21tYW5kQnV0dG9uIGlkPSJkZWxldGVC dG4iIHBhcnRpYWxUcmlnZ2Vycz0idXBsb2FkSW1nQnRuIGRlbGV0ZUJ0biIgcGFydGlhbFN1Ym1p dD0idHJ1ZSIgdGV4dD0iRGVsZXRlIiByZW5kZXJlZD0iI3tpbWFnZVVwbG9hZEJlYW4uZmlsZSE9 bnVsbH0iIGFjdGlvbj0iI3tpbWFnZVVwbG9hZEJlYW4uZG9EZWxldGV9Ii8+DQogICAgICAgICAg ICAgICAgICAgIDx0cjpjb21tYW5kQnV0dG9uIGlkPSJ1cGxvYWRJbWdCdG4iIHBhcnRpYWxTdWJt aXQ9InRydWUiIHBhcnRpYWxUcmlnZ2Vycz0idXBsb2FkSW1nQnRuIGRlbGV0ZUJ0biIgdGV4dD0i VXBsb2FkIEltYWdlIiBhY3Rpb249IiN7aW1hZ2VVcGxvYWRCZWFuLmRvVXBsb2FkfSIgcmVuZGVy ZWQ9IiN7aW1hZ2VVcGxvYWRCZWFuLmZpbGU9PW51bGx9IiAvPg0KICAgICAgICAgICAgICAgICAg ICA8dHI6Y29tbWFuZEJ1dHRvbiBpZD0ic2F2ZUJ0biIgdGV4dD0iU2F2ZSIgYWN0aW9uPSIje2lt YWdlVXBsb2FkQmVhbi5zYXZlfSIgLz4NCiAgICAgICAgICAgICAgICA8L3RyOnBhbmVsR3JvdXBM YXlvdXQ+DQogICAgICAgICAgICA8L3RyOmZvcm0+DQogICAgICAgIDwvdWk6ZGVmaW5lPg0KICAg IDwvdWk6Y29tcG9zaXRpb24+DQo8L2h0bWw+DQo= --001517511032558ff1046e9d5317--