Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request parameters in include]

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request parameters in include]

Brian Cook

Nothing has changed that I can see here.  The situation remains that you
need to have the parameters passed as hidden fields.  This will be true
of any file upload option.

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. Also
page fragments usually are not used as dynamic parts of forms unless
they are all standardized.  Or if they are they use simple options.

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


Andreas Schildbach wrote:

> Hallo Brian,
>
> did you see my post from Sunday on [hidden email]? May
> I politely ask if you know an answer? Sorry for emailing you directly,
> but maybe you just overlooked my clarification.
>
> Regards,
>
> Andreas
>
> -------- Original Message --------
> Subject: Re: [FileUpload] Issue with multipart/form-data and request
> parameters     in include
> Date: Sun, 28 Aug 2005 11:34:19 +0200
> From: Andreas Schildbach <[hidden email]>
> Reply-To: Jakarta Commons Users List <[hidden email]>
> Newsgroups: gmane.comp.jakarta.commons.user
> References: <dennni$opk$[hidden email]>
> <[hidden email]> <dep0se$ij3$[hidden email]>
> <[hidden email]>
>
> Hello Brian,
>
> I am sorry my last answer was a bit sloppy. For the sake of simplicity,
> please consider the following JSP 2.0 fragment:
>
> --- fragment.jsp ---
> ${param.p}
> --- end fragment.jsp ---
>
> This obviously outputs the parameter named p. Of course, my real
> fragment is much more complex than that, using an own controller and
> such (I was also using the words "plugin" and "portlet" because
> web-designers often use these. I was not talking about applets or
> embedded objects).
>
> Ok, now here is a JSP which is the target of a form (I am skipping
> taglib defs):
>
> --- target.jsp ---
> <c:import url="fragment.jsp?p=value1"/>
> hello world
> <c:import url="fragment.jsp?p=value2"/>
> --- end target.jsp ---
>
> --- form.jsp ---
> <form action="target.jsp" method="post" enctype="multipart/form-data">
>   [skipping form fields]
> </form>
> --- end form.jsp ---
>
> (and yes, I did get jsp:include and c:import mixed up in my last post)
>
> Now, here is what happens with the different methods for posting the form:
>
> 1. GET: "value1 hello world value2"
> 2. POST (default enctype): "value1 hello world value2"
> 3. POST enctype="multipart/form-data": "hello world"
>
> As I wrote, I am wondering why 2 works but I am very happy about it. It
> would be great if 3 worked as 2.
>
> I wonder what would be a reliable way to add parameters to included
> resources, that works regardless of the type of initial request.
>
> I am using FileUpload in a Spring (springframework.org) context, in a
> way that can be compared to a Servlet filter:
>
> <bean id="multipartResolver"
> class="org.springframework.web.multipart.commons.CommonsMultipartResolver"/>
>
>
> I hope I left no questions open this time. Sorry for that last
> inaccurate post.
>
> Regards,
>
> Andreas
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request parameters in include]

Andreas Schildbach
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request parameters in include]

Brian Cook

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Brian Cook
Digital Services Analyst
Print Time Inc.
[hidden email]
913.345.8900


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request parameters in include]

Brian Cook

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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

--
Brian Cook
Digital Services Analyst
Print Time Inc.
[hidden email]
913.345.8900


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request parameters in include]

Andreas Schildbach
Brian Cook wrote:
>
> I just realized if as you said you are using the for fragments  to fill
> in redundant parts of forms [...]

I did not say that.

I'm feeling we are talking at cross-purposes. Let's look at a more
concrete example:

I want to have an omni-present navigation bar on the left hand side of
the page. To implement this, I am including a fragment "navigation.do"
for the navigation bar on every page of my web application. Note that
this fragment actually consists of its own controller, model and view.

Now, I want that each page can indicate to the navigation bar an entry
that is highlighted, so that the currently opened part of the web page
is represented with a highlighted entry in the navigation (also, if the
highlighted entry is contained in a foldable sub-menu it could be
expanded). I implement this by feeding in a parameter named "page" from
every invocation of the fragment.

Thus, the include looks like the following (using JSTL):

<c:import url="navigation.do?page=forum"/>

or, alternatively

<c:import url="navigation.do"><c:param name="page"
value="forum"/></c:import>

Obviously, these tags would also be present in pages that have got forms
(to serve completely different purposes), but this does not matter in my
case.

What matters more, is that the fragment would also need to be included
in the _target_ page of any form. Like I said, I need to transmit the
full UTF range, this is why I am using POST and why I am using
enctype="multipart/form-data".

The controller of the navigation would read the parameter with the
statement:

request.getParameter("page")

Could you tell me exactly how to change the <c:import/> example above in
order for the parameter to actually arrive in the navigation fragment? I
still don't understand how you want me to transform the parameter into a
"hidden form parameter".

> 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.

I am starting to believe this, although it would make JSP technology
nearly unusable for modularization. How many parts of todays web
applications are really static? It is ridiculous to expect that
potentially very complex fragments like (foldable) navigation bars have
to be duplicated to each model, view and controller of the whole
application.

> So do not use <a> tags.  Just use forms.

Please don't get me wrong, but is this a joke? Are you really telling me
to replace each

<a href="action.do?param=value">link</a>

by something like

<form method="post" action="action.do">
   <input type="hidden" name="param" value="value"/>
   <input type="submit" value="link"/>
</form>

?

Regards,

Andreas


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request parameters in include]

Martin Cooper
On 9/2/05, Andreas Schildbach <[hidden email]> wrote:

>
> Brian Cook wrote:
> >
> > I just realized if as you said you are using the for fragments to fill
> > in redundant parts of forms [...]
>
> I did not say that.
>
> I'm feeling we are talking at cross-purposes. Let's look at a more
> concrete example:
>
> I want to have an omni-present navigation bar on the left hand side of
> the page. To implement this, I am including a fragment "navigation.do"
> for the navigation bar on every page of my web application. Note that
> this fragment actually consists of its own controller, model and view.
>
> Now, I want that each page can indicate to the navigation bar an entry
> that is highlighted, so that the currently opened part of the web page
> is represented with a highlighted entry in the navigation (also, if the
> highlighted entry is contained in a foldable sub-menu it could be
> expanded). I implement this by feeding in a parameter named "page" from
> every invocation of the fragment.
>
> Thus, the include looks like the following (using JSTL):
>
> <c:import url="navigation.do?page=forum"/>
>
> or, alternatively
>
> <c:import url="navigation.do"><c:param name="page"
> value="forum"/></c:import>


If you just change this to:

<c:set var="page" value="forum" />
<c:import url="navigation.do" />

and then in the controller use:

request.getAttribute("page");

your troubles will be over. :-)

--
Martin Cooper


Obviously, these tags would also be present in pages that have got forms

> (to serve completely different purposes), but this does not matter in my
> case.
>
> What matters more, is that the fragment would also need to be included
> in the _target_ page of any form. Like I said, I need to transmit the
> full UTF range, this is why I am using POST and why I am using
> enctype="multipart/form-data".
>
> The controller of the navigation would read the parameter with the
> statement:
>
> request.getParameter("page")
>
> Could you tell me exactly how to change the <c:import/> example above in
> order for the parameter to actually arrive in the navigation fragment? I
> still don't understand how you want me to transform the parameter into a
> "hidden form parameter".
>
> > 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.
>
> I am starting to believe this, although it would make JSP technology
> nearly unusable for modularization. How many parts of todays web
> applications are really static? It is ridiculous to expect that
> potentially very complex fragments like (foldable) navigation bars have
> to be duplicated to each model, view and controller of the whole
> application.
>
> > So do not use <a> tags. Just use forms.
>
> Please don't get me wrong, but is this a joke? Are you really telling me
> to replace each
>
> <a href="action.do?param=value">link</a>
>
> by something like
>
> <form method="post" action="action.do">
> <input type="hidden" name="param" value="value"/>
> <input type="submit" value="link"/>
> </form>
>
> ?
>
> Regards,
>
> Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: [FileUpload] Issue with multipart/form-data and request parameters in include]

Brian Cook
In reply to this post by Andreas Schildbach

This is a much better post and much closer to what should have been
posted originally.

Ok first the bottom line you are not going to be able to pass get
parameters to commons.fileupload using HTTP GET with an
enctype="multipart/form-data".  Any parameters
you want to pass using enctype="multipart/form-data" would have to be in
an HTML form.



 > What matters more, is that the fragment would also need to be included
 > in the _target_ page

Why do your page menus need to be include parameters in every POST/GET?
  This seems like a lot of unneeded work and complication.  Why re parse
your menu data on each page?  Is there a reason you can not use the
Session object for this?



 > Could you tell me exactly how to change the <c:import/>
 > example above in order for the parameter to actually
 > arrive in the navigation fragment?

Hard to say since we do not have much in the way of details about your
methodology, frame works etc to know what would work for you.  Since you
mentioned using MVC I am assuming you are adding all of the Parameters
passed to the session object as most MVC frame works do.  In that case
you can just call the value from the session object in your fragment.

Something like :

EL
${sessionScope.someParamName}

JSP
session.someParamName

<% String parameter = session.getAttribute("someParamName");  %>

<%=session.getAttribute("someParamName")  %>



 > I am starting to believe this, although it would make JSP technology
 > nearly unusable for modularization.

I should have been clearer on this point.  It is not that fragments can
not be used dynamically, but that it is a bad idea use them dynamically
with out standardizing what options they will use with each page, how
the page will pass that data to them, and how the page will layout what
the fragment returns.



 > Please don't get me wrong, but is this a joke? Are you really
 > telling me to replace each <a href="action.do?param=value">link</a>

No I am simply point out you have options.  You keep making statements
like the way you are doing it is the only possible way.  Like this quote

 >So this limitation (of not being able to standardize) comes from the
 >HTTP/HTML standard, not from my development practice.

Just because HTML gives you a lot of options for GET/POST does not mean
you have to use them all.  It is up to you to standardize on which ones
you want to use.  Doing this will save your self a lot of time in the
long run.  You may want to look at using Struts as it does a lot of the
standardizing for you.  Or so I am told.




Andreas Schildbach wrote:

> Brian Cook wrote:
>
>>
>> I just realized if as you said you are using the for fragments  to
>> fill in redundant parts of forms [...]
>
>
> I did not say that.
>
> I'm feeling we are talking at cross-purposes. Let's look at a more
> concrete example:
>
> I want to have an omni-present navigation bar on the left hand side of
> the page. To implement this, I am including a fragment "navigation.do"
> for the navigation bar on every page of my web application. Note that
> this fragment actually consists of its own controller, model and view.
>
> Now, I want that each page can indicate to the navigation bar an entry
> that is highlighted, so that the currently opened part of the web page
> is represented with a highlighted entry in the navigation (also, if the
> highlighted entry is contained in a foldable sub-menu it could be
> expanded). I implement this by feeding in a parameter named "page" from
> every invocation of the fragment.
>
> Thus, the include looks like the following (using JSTL):
>
> <c:import url="navigation.do?page=forum"/>
>
> or, alternatively
>
> <c:import url="navigation.do"><c:param name="page"
> value="forum"/></c:import>
>
> Obviously, these tags would also be present in pages that have got forms
> (to serve completely different purposes), but this does not matter in my
> case.
>
> What matters more, is that the fragment would also need to be included
> in the _target_ page of any form. Like I said, I need to transmit the
> full UTF range, this is why I am using POST and why I am using
> enctype="multipart/form-data".
>
> The controller of the navigation would read the parameter with the
> statement:
>
> request.getParameter("page")
>
> Could you tell me exactly how to change the <c:import/> example above in
> order for the parameter to actually arrive in the navigation fragment? I
> still don't understand how you want me to transform the parameter into a
> "hidden form parameter".
>
>> 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.
>
>
> I am starting to believe this, although it would make JSP technology
> nearly unusable for modularization. How many parts of todays web
> applications are really static? It is ridiculous to expect that
> potentially very complex fragments like (foldable) navigation bars have
> to be duplicated to each model, view and controller of the whole
> application.
>
>> So do not use <a> tags.  Just use forms.
>
>
> Please don't get me wrong, but is this a joke? Are you really telling me
> to replace each
>
> <a href="action.do?param=value">link</a>
>
> by something like
>
> <form method="post" action="action.do">
>   <input type="hidden" name="param" value="value"/>
>   <input type="submit" value="link"/>
> </form>
>
> ?
>
> Regards,
>
> Andreas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
Brian Cook
Digital Services Analyst
Print Time Inc.
[hidden email]
913.345.8900


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]