commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Cook <bc...@printtime.com>
Subject Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request parameters in include]
Date Thu, 01 Sep 2005 23:18:07 GMT

I just realized if as you said you are using the for fragments  to fill 
in redundant parts of forms then why is it so hard to add a hidden field 
to the page fragment?


Brian Cook wrote:
> 
> You answered your own question.
> 
>  > Why shouldn't they? Forms can have redundant parts that can be
>  > eliminated by using includes just as pages without forms.
> 
> Because as you said ...
> 
>  > 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).
> 
> Any time you start to make fragments dynamic you will start to run into 
> situations where they will work for some pages but not others.
> 
> 
>  > Believe me, I would really like to standardize on one POST/GET option.
>  > But neither can I switch <a href's/> .....
> 
> So do not use <a> tags.  Just use forms.
> 
> Bottom line what you are wanting to do is not going to work with any of 
> the file upload pages available.
> 
> 
> 
> Andreas Schildbach wrote:
> 
>> 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
>>
>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org


-- 
Brian Cook
Digital Services Analyst
Print Time Inc.
bcook@printtime.com
913.345.8900


Mime
View raw message