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 Fri, 02 Sep 2005 17:00:19 GMT

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