Good question. What you are really asking is "what does the <html:file> tag
do?".

Struts will generate an <input type="file" ... > tag, where the value of the
'name' attribute is taken from the 'property' attribute of your <html:file>
tag. It will also generate a 'value' attribute. Looking at the source code,
it seems that the valueof the 'value' attribute will be the result of
calling toString() on the FormFile object. Since that object doesn't
override toString(), the result will be nothing useful. On the other hand,
browsers usually ignore the 'value' attribute anyway.

At this point, the original uploaded file is still on the disk, and will
remain there until the form is resubmitted. Then it will be deleted as a
part of setting up for parsing the new multipart data.

Hope this helps.

--
Martin Cooper


----- Original Message -----
From: "Jonathan Asbell" <[EMAIL PROTECTED]>
To: "Martin Cooper" <[EMAIL PROTECTED]>
Sent: Sunday, June 10, 2001 5:47 AM
Subject: Re: uploading file requires immediate serialization location?


> Great explanation Martin. Thank you.  So what you really have said is that
> the stream contents gets turned into a FormFile object.  Ok.  Now the big
> question.  You know when a form is not valid it gets sent beack to the
> client as strings which pre-populate the form fields.  How will this occur
> in the case of a file input?
>
>
> ----- Original Message -----
> From: "Martin Cooper" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Jonathan Asbell"
<[EMAIL PROTECTED]>
> Sent: Sunday, June 10, 2001 12:20 AM
> Subject: Re: uploading file requires immediate serialization location?
>
>
> > Let me see if I can describe the process.
> >
> > 1. Check to see if the request should be treated as multipart (i.e.
> content
> > type is multipart/form-data and method is POST). If not, carry on as
> normal.
> > 2. Find the multipart handler or instantiate one, set it on the form
bean,
> > and call it to handle the request.
> > 2a. Iterate over the fields (parts) in the request.
> > 2a1. If the current part is not a file, store it as a String.
> > 2a2. If the current part is a file (according to the Content-Disposition
> > header), create a new file in the temp directory, stream the content of
> the
> > part to that file, create a new object which implements FormFile, and
> store
> > the file data in it.
> > 2b. Turn the set of fields into something that looks like regular
request
> > parameters.
> > 3. Populate the ActionForm instance from the set of request parameters.
> > Here, the value of a file parameter has type FormFile, so it matches a
> > setter on the form bean that takes a FormFile as a parameter.
> >
> > That's the gist of it, although there are some other nitty gritty
details.
> > Almost all of this happens inside the code that populates the form bean
> from
> > request parameters.
> >
> > It appears (from my reading of the source, anyway) that the temporary
> files
> > will not be automatically deleted until another request comes in that
uses
> > the same form bean instance, or until the form bean instance goes away.
> > Given that, I would recommend calling setMultipartRequestHandler(null)
> from
> > your form bean's reset() method if you keep your beans in session scope.
> >
> > The part you are interested in, I believe, is 2a2 above. Unfortunately,
> that
> > code is buried inside an iterator class, so you can't override just that
> > piece. I assume what you would want is that the data is kept in memory
> > instead of to a file. Interestingly, I believe the original
implementation
> > did this, but it was changed to use files because of potential memory
> > problems with large uploads.
> >
> > Hope this helps.
> >
> > --
> > Martin Cooper
> >
> >
> > ----- Original Message -----
> > From: "Jonathan Asbell" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Saturday, June 09, 2001 8:11 PM
> > Subject: Re: uploading file requires immediate serialization location?
> >
> >
> > > Hello Martin.  So is it POSSIBLE to save binary data in a bean?  What
> does
> > > struts do?  These are my real questions.  If I have a form which
besides
> > > fields, has an uploaded file, how does the bean actually handle the
> file?
> > > Is there a conceptual step by step you can give me.  How does the
> > ActionForm
> > > save (and validate) the binary data sent via input type "file".
> > >
> > >
> > > ----- Original Message -----
> > > From: "Martin Cooper" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>; "Jonathan Asbell"
> > <[EMAIL PROTECTED]>
> > > Sent: Saturday, June 09, 2001 10:55 PM
> > > Subject: Re: uploading file requires immediate serialization location?
> > >
> > >
> > > > Internally to Struts, multipart handling is provided through an
> > interface,
> > > > MultipartRequestHandler. In Struts 1.0, the only supplied
> implementation
> > > of
> > > > this interface is DiskMultipartRequestHandler, which, as you might
> > expect,
> > > > writes "file" parts to disk as it encounters them.
> > > >
> > > > Struts does allow you to configure the multipart handler to use, by
> > > > specifying the class name in the multipartClass init-param for your
> web
> > > app.
> > > > This allows you to provide your own implementation if you want to
> > > (although
> > > > this is no small task).
> > > >
> > > > --
> > > > Martin Cooper
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "Jonathan Asbell" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Saturday, June 09, 2001 6:39 AM
> > > > Subject: uploading file requires immediate serialization location?
> > > >
> > > >
> > > > Hello all.
> > > > I am just trying to understand an aspect of a multipart request.
When
> > > > you submit after using an input of type "file", do you have to
provide
> > > > an immediate location for the file to be serialized to, or can you
> store
> > > > it in a java object (in a bean's field) as a binary object until you
> are
> > > > ready to serialize it.  The reason is that I want to hold a jpeg in
a
> > > > bean until the person completes the last page of the form, and THEN
> > > > serialize it.
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
>


Reply via email to