Christian Haul wrote:
Tony Collen wrote:
Kai Benndorf wrote:
Hi Tony,
if there really is no way to get the encoded request parameter, although it's not very smart, we still have the possibility to encode the parameter anew. Is there already an existing function to encode the parameter somewhere?
Regards
Kai
Well, if we can't solve the problem correctly, the quick and dirty solution is to manually re-encode the value inside the inputmodule using java.net.URLEncoder.encode().
Still working on it.. must have patience! :)
If you do this, please bear in mind that I made this module for a purpose: to get at the uploaded data.
The Request.getParameter() method unfortunately converts them to java.lang.String which effectively
prevents this. So, if you change this module, please check that the object is a String before re-encoding
it. And check that the upload sample in the databases block works with the modification.
If it turns out that the un-decoded (raw) parameter really should never be returned from the Request, then it makes more sense to introduce a "url-encode" input module which would encode a given string, including the output of another module for use as a valid url in the sitemap. IIRC there have been users with valid use cases for this with no way to automatically come up with the value.
I'm fine with any solution that tries to maintain current behaviour as much as possible. Indeed, there
is a necessity to access the undecoded parameters or at least easily access re-encoded parameters.
Mind you, though, that you might need to encode the parameter name as well! E.g "parameter[1]=foo++bar"
is not useful either.
So my interest here is to keep the way open for accessing uploads. Depending on a check for instanceof String
might be enough. A "meta" module probably cleaner.
Chris.
