File uploading from within a custom form tag in Spring MVC

Context

Part of the administrator side of our application requires the user to edit various types of content, which involves using a rich text editor or using files to generate content that can be seen by the 'client side' users of the application. It's kind of a domain-specific CMS lite.

Because this 'content' can be used in various parts of the application, it is included as a seperate relation开发者_运维问答 in some of our domain entities. We decided to make our own tag library that defines some form fields that can be used to edit this content when an administrator edits an entity that includes a piece of content.

Question

What we'd like to be able to do is the following.

<form:form modelAttribute=...>
    <olo:content-editor path="content"/>
    <!-- Other form fields for this entity -->
    <form:.../>
    <form:.../>
</form:form>

The olo:content-editor tag then generates a number of form fields based on what type of content is needed. This means it may (or, depending on the type of content, may not!) generate the filebased-content tag which contains:

<input type="file" name="file/>

Which can be used to replace the file associated with the file based content.

The problem is that the Spring docs indicate that the file upload requires the form to have the enctype to define that it's sending multipart form data. As the file upload is part of the tag and not the form itself, we find this is undesirable. We would like to be able to use our olo:content-editor tag in forms without having to change the form enctype attribute. Is this possible?

Possible solutions

We can think of two client-side hacks that may resolve our problem, but both seem to be rather ugly solutions:

• Include a script in filebased content tag that changes the form enctype when it's loaded, so that it is always set to the appropriate type. (Very ugly.)
• Submit the file data as a regular hidden form field, of which the data is set by using the HTML5 File API (administrators use a compliant browser. This seems far less ugly but still not an optimal solution.)