Return-Path: 
 <dev-return-60256-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 20533 invoked from network); 29 Apr 2004 18:55:05 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 29 Apr 2004 18:55:05 -0000
Received: (qmail 4319 invoked by uid 500); 29 Apr 2004 18:54:11 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 4262 invoked by uid 500); 29 Apr 2004 18:54:11 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 4244 invoked from network); 29 Apr 2004 18:54:11 -0000
Received: from unknown (HELO mail.wrinkledog.com) (65.243.176.122)
  by daedalus.apache.org with SMTP; 29 Apr 2004 18:54:11 -0000
Received: (qmail 5056 invoked from network); 29 Apr 2004 18:57:02 -0000
Received: from c-67-170-169-150.client.comcast.net (HELO ?192.168.0.3?)
 (ml@67.170.169.150)
  by mail.wrinkledog.com with SMTP; 29 Apr 2004 18:57:02 -0000
Mime-Version: 1.0 (Apple Message framework v609)
To: dev@cocoon.apache.org
Message-Id: <90260443-9A0E-11D8-AF6B-000A95908E0E@wrinkledog.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-3--269064096
From: Mark Lundquist <ml@wrinkledog.com>
Subject: [cforms] upload widget styling
Date: Thu, 29 Apr 2004 11:53:54 -0700
X-Mailer: Apple Mail (2.609)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N


--Apple-Mail-3--269064096
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

(I'm posting this on the dev list because I may end up filing something 
on Bugzilla, but I wanted to talk it over first...)

Anyway.... I'm not getting the idea of what forms-field-styling.xsl is 
trying to do with <fi:upload>... all I know is that it's not what I 
need! :-)

   <xsl:template match="fi:upload">
     <xsl:choose>
       <xsl:when test="fi:value">
         <!-- Has a value (filename): display it with a change button -->
         <span title="{fi:hint}">
           [<xsl:value-of select="fi:value"/>] <input type="submit" 
id="{@id}" name="{@id}" value="..."/>
         </span>
       </xsl:when>
       <xsl:otherwise>
         <input type="file" id="{@id}" name="{@id}" title="{fi:hint}" 
accept="{@mime-types}"/>
       </xsl:otherwise>
     </xsl:choose>
     <xsl:apply-templates select="." mode="common"/>
   </xsl:template>

My form has an action widget whose handler cares about the value of the 
upload widget (this handler does the upload).  So when the form is 
redisplayed, I no longer get an <input type="file">, instead I get a 
submit button (!).

This handling of fi:upload was obviously designed to support some 
scenario, but it's undocumented and (a)  obvious to me what that might 
be, and (b) as I mentioned, it doesn't fit what I'm trying to do.

I tried to defeat this behavior by doing this immediately before 
exiting my action widget handler:

	wid.logoFile.value = null;

...but that loses: "value of <fd:upload> widget cannot be manually 
set", or something to that effect.

I would petition that the default handling of <fi:upload> should always 
just generate an <input type="file">, and let the special handling that 
is the current default be selected using an <fi:styling> attribute.

Or, that it  be allowed to set the value of an upload widget to null 
(fine with me if setting it to a non-null value were disallowed).

WDYT?
mark


--Apple-Mail-3--269064096
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

(I'm posting this on the dev list because I may end up filing
something on Bugzilla, but I wanted to talk it over first...)


Anyway.... I'm not getting the idea of what forms-field-styling.xsl is
trying to do with <<fi:upload>... all I know is that it's not what I
need! :-)  


<fontfamily><param>Courier</param>  <<xsl:template match="fi:upload">

    <<xsl:choose>

      <<xsl:when test="fi:value">

        <<!-- Has a value (filename): display it with a change button
-->

        <<span title="{fi:hint}">

          [<<xsl:value-of select="fi:value"/>] <<input type="submit"
id="{@id}" name="{@id}" value="..."/>

        <</span>

      <</xsl:when>

      <<xsl:otherwise>

        <<input type="file" id="{@id}" name="{@id}" title="{fi:hint}"
accept="{@mime-types}"/>

      <</xsl:otherwise>

    <</xsl:choose>

    <<xsl:apply-templates select="." mode="common"/>

  <</xsl:template>

</fontfamily>

My form has an action widget whose handler cares about the value of
the upload widget (this handler does the upload).  So when the form is
redisplayed, I no longer get an <<input type="file">, instead I get a
submit button (!).


This handling of fi:upload was obviously designed to support some
scenario, but it's undocumented and (a)  obvious to me what that might
be, and (b) as I mentioned, it doesn't fit what I'm trying to do.


I tried to defeat this behavior by doing this immediately before
exiting my action widget handler:


	wid.logoFile.value = null;


...but that loses: "value of <<fd:upload> widget cannot be manually
set", or something to that effect.


I would petition that the default handling of <<fi:upload> should
always just generate an <<input type="file">, and let the special
handling that is the current default be selected using an
<<fi:styling> attribute.


Or, that it  be allowed to set the value of an upload widget to null
(fine with me if setting it to a non-null value were disallowed).


WDYT?

mark



--Apple-Mail-3--269064096--