Return-Path: 
 <commons-user-return-13515-apmail-jakarta-commons-user-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-user-archive@www.apache.org
Received: (qmail 8788 invoked from network); 1 Sep 2005 22:08:23 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 1 Sep 2005 22:08:23 -0000
Received: (qmail 24571 invoked by uid 500); 1 Sep 2005 22:08:16 -0000
Delivered-To: apmail-jakarta-commons-user-archive@jakarta.apache.org
Received: (qmail 24529 invoked by uid 500); 1 Sep 2005 22:08:15 -0000
Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-user-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-user-help@jakarta.apache.org>
List-Post: <mailto:commons-user@jakarta.apache.org>
List-Id: "Jakarta Commons Users List" <commons-user.jakarta.apache.org>
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Delivered-To: mailing list commons-user@jakarta.apache.org
Received: (qmail 24516 invoked by uid 99); 1 Sep 2005 22:08:15 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2005 15:08:15 -0700
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of gcjcu-commons-user@m.gmane.org
 designates 80.91.229.2 as permitted sender)
Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Sep 2005 15:08:29 -0700
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1EAx5D-0002Eb-H7
	for commons-user@jakarta.apache.org; Thu, 01 Sep 2005 23:58:55 +0200
Received: from e181017009.adsl.alicedsl.de ([85.181.17.9])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <commons-user@jakarta.apache.org>; Thu, 01 Sep 2005 23:58:55 +0200
Received: from andreas by e181017009.adsl.alicedsl.de with local (Gmexim 0.1
 (Debian))
        id 1AlnuQ-0007hv-00
        for <commons-user@jakarta.apache.org>; Thu, 01 Sep 2005 23:58:55 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: commons-user@jakarta.apache.org
From: Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request
   parameters     in include]
Date: Thu, 01 Sep 2005 23:56:35 +0200
Lines: 46
Message-ID: <df7tek$l6p$1@sea.gmane.org>
References: <431709D7.3090208@schildbach.de> <431755FE.9000708@printtime.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
X-Gmane-NNTP-Posting-Host: e181017009.adsl.alicedsl.de
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050727)
X-Accept-Language: en-us, en
In-Reply-To: <431755FE.9000708@printtime.com>
Sender: news <news@sea.gmane.org>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Hello Brian,

> It also looks like you need standardize your development practices.  Why 
> are you supporting 3 or more http POST/Get options? You will help your 
> self in the long run if you simplify this and use just one or two.

Believe me, I would really like to standardize on one POST/GET option. 
But neither can I switch <a href's/> to use POST nor can I tell forms to 
use GET _and_ transport the full UTF charset at the same time. So this 
limitation (of not being able to standardize) comes from the HTTP/HTML 
standard, not from my development practice.

> Also 
> page fragments usually are not used as dynamic parts of forms unless 
> they are all standardized.

Why shouldn't they? Forms can have redundant parts that can be 
eliminated by using includes just as pages without forms.

In my case, the fragments are not even part of the form itself, but are 
included on the target page of the form. The target page can be target 
of many different operations and has not got a clue how it will be 
requested (POST/GET, see above).

 > The situation remains that you
 > need to have the parameters passed as hidden fields. This will be true
 > of any file upload option.

How can I pass in a hidden field into an include? How can I even POST to 
an include? IMHO this is not possible. AFAIK, using URL parameters is 
the official way to pass parameters to an include. That's why 
<c:import..><c:param.../></c:import> was invented. As I said in my last 
post, POSTs with default encoding somehow manage to get the parameters 
transmitted into includes, however POSTs with 
enctype="multipart/form-data" do not.

> Last point you want to have all replys to the tread go to the list not 
> the individual person responding.

I'm sorry, I had posted to the list, and I told you in my introduction. 
I was mailing to you directly because I was under the impression that 
you missed my post.

Regards,

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org