Here's the current bug entry for this issue that inputFile has been
side-stepped
https://javaserverfaces-spec-public.dev.java.net/issues/
show_bug.cgi?id=107
The response is curious
<quote>
------- Additional comments from edburns Fri Mar 3 17:05:42 +0000
2006 -------
Now that JavaStudio Creator and the Sun Blueprints Solutions Catalog
both have a
file upload component, this can safely be moved to JSF 2.0.
</quote>
The upload component seems to create another form via javascript and
submit it it, the upload is done in a filter.
The syntax of the upload tag seems to have little resemblance to the
normal tags. ui:BigTitleCasedTag .. The FileUploadTag isn't bad in
itself, its acceptance that this lets 1.2 off the hook in finally
defining h:inputFile that is bad (the word "unacceptable" was the
first that spang to mind). As has been found in jsp generally things
dont need to go very far to become tag-soup.
Ideally things would look like this
<h:form>
<h:inputFile value="#{mybean.upload}" />
the "safe" alternative is messy unless you wanted to use an ajax
solution using the dojo javascript and to boot the progress bar is
shoe horned into the html rather than creating it in javascript..
Very cool, but no thanks, i want a simple input type="file" and for
my backing bean to have the mapped property to be populate, just as
it should/needs to be. If I want bigger uploads to be managed
leveraging xmlhttprequest, i'll do just that.
So what's the "safe" tag doing under the bonnet.. My guess is it
works around faces completely.. It must do something of the kind as
the RI doesn't seem to allow any multipart requests at all..
Now I'm sure there's a very smart intelligent answer to all this,
"processing multipart requests causes potential security issues"
"decoding the form state is gonna be a cow to implement, especially
saving state on the client" etc etc.. But multipart requests are part
of http and html, life hurts. There was talk of inputFile being added
between 1.1 and 1.2.
Even if 2.0 addresses this its already too late, if faces blocks
multipart requests its game over. EVen if i write my own component
i'm doing more hoop-jumping than I should be. Now as a "user" i have
to fish around in the source code, run the code in a debugger just to
work out what on earth is going on with my "standards compliant" use
of the enctype attribute on the form tag..
Mark
On 1 Apr 2007, at 10:01, Mark Lowe wrote:
> Hello
>
> Yet again h:inputFile has been ignored, it should have been in the
> spec from the start even if it would mean more hassles writing
> implementations to support it.
>
> Accepting this lack of support even in jsf 1.2, and not wanting to
> hack it with ajax and servlet filters I started to write a
> component. But what happened? As soon as I change the form's
> enctype to multipart i cant get passed the RESTORE_VIEW phase.
>
> I've narrowed things down to that faces thinks that the request is
> a postback.. Does anyone know how I can fix this? With no ajax or
> filters.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: users-
> help_at_javaserverfaces.dev.java.net
>