Fixed IE7 alignment issue for fileEntry by removing overflow:hidden styling from the themes. Then noticed that rime style class was "rime", instead of "ice-skin-rime", as it was in other files, and modified it to match.

Subversion 22961

IE8 was getting a javascript exception, since it added support for some of the DOM features that Firefox and WebKit support, and was going down the non-IE code path, which didn't work because it still didn't support some other features. Added more precise feature detecting.

Subversion 22960

Re-opened due to IE8 JS error issue, and IE7 styling issue.

Added @Component tlddoc.

Subversion 22720

Outstanding features are:

• Disabled styling
• Handle required property
• Handle singleSubmit property
• Add validator, validatorMessage properties
• Progress: HTML 4
• Multi-file: HTML 4 user interface and PhaseListener
• Multi-file: HTML 5 user interface
• Callback support

Not doing:

Progress via HTML 5 : This turned out to be a non-feature, since the progress is not on the input element, but just in XmlHttpRequest, and right now we're not supporting HTML XmlHttpRequest. So, we're only doing HTML 4 (and above) progress.

ARIA support : There is no ARIA input type=file widget. There is no role. We could in theory still fulfill the basic roletype requirements. Also, when we add the interface for multiple files, those elements could have ARIA support.

Added disabled, tabindex, style, styleClass pass-through attributes. Made some utility methods for concatenating the styleClasses. Renamed FileEntryInfo and the info property to FileEntryResults and the results property. Better documented results and maxFileCount. Added testing code for the new properties. Updated the rime and sam skins to describe the disabled style as ice-file-entry-disabled, but the renderer is not outputting that, as we're waiting for a pan sparkle naming strategy for disabled styling.

Subversion 22692

Small tweak to the @Component and @ResourceDependencies annotations in FileEntryMeta.

Subversion 22693

Did the rename process of inputFiles -> fileEntry, which involved repackaging, renaming classes, renaming javascript and CSS files, and renaming CSS selectors. IDE refactoring helped a lot, but still had to follow up with directory searches of "inputfiles" (case insensitive) to fully rename everything.

Subversion 22660
Subversion 22667

The InputFilesMeta should follow the dateTimeEntry pattern:

@Component(tagName = "dateTimeEntry",
       componentClass = "org.icefaces.component.datetimeentry.DateTimeEntry",
       rendererClass = "org.icefaces.component.datetimeentry.DateTimeEntryRenderer",
       componentFamily = "org.icefaces.Input",
       componentType = "org.icefaces.DateTimeEntry",
       rendererType = "org.icefaces.DateTimeEntry",
       extendsClass = "javax.faces.component.UIInput",
       generatedClass = "org.icefaces.component.datetimeentry.DateTimeEntryBase"
)

The binding property is now auto-inherited.

fileEntry component has the following noted outstanding tasks/issues:

Component Name:

• Rename/repackage component to "FileEntry", incl. comp. name, tag name ("fileEntry"), all classnames, componentFamily, etc.

Attributes:

• Following attributes are missing:
• validator
• validatorMessage
• tabIndex
• disabled
• binding

• Following attribute names should be changed:
• info (too general), suggest uploadStatus or uploadInfo
• inputFilesListener -> uploadListener (aligns with uploadStatus)

Documentation:

• Component level descriptive doc missing from TLD/taglib doc. This can be brief summation with link to the Wiki doc page.
• The following attributes have insufficient doc:
• info (more detail required)
• maxFileCount (more context - max for a single upload operation)

• Wiki user doc:
• No user-doc page at all yet.
• Should mimic the general contents and compleness from http://developer.yahoo.com/yui/autocomplete/, for example.
• General config and usage should be covered, typical use-cases illustrated and described.

Wrapped the input type=file element with a div tag, for the styling to act upon. As well, when we support multi-file, then all the markup will go within that root div.

Subversion 22505

Added form14 test cases for ice:inputFiles to sparkle component showcase application, demonstrating localised faces messages.

Subversion 22503

Finished the support for localised FacesMessage to display depending on the results of the file upload attempt. The ice:inputFiles component will first see if the maxTotalSizeMessage, maxFileSizeMessage, maxFileCountMessage, requiredMessage properties are specified, and if not, will then see if the application has registered itw own ResourceBundle, and has specified resources for the success or error message, and failing that, will fall back to using the built-in resource bundle that comes with the sparkle components jar.

Added MessageUtils, which is derived from compat, but re-made, to facilitate adding FacesMessage(s) derived from resource bundles, and ones from custom MessageFormat patterns.

Future support has been laid for custom InputFilesStatus implementors to give their own custom localised FacesMessage objects.

From testing, noticed that maxFileCount had not been implemented, most likely because multi-file has not been implemented. Finished that, so could test the messages for it. Also fixed whichever glitches I came across when testing.

Subversion 22502

Augmented the testing to cover having inputFiles components inside of dataTables, with both the info property being maintained by the component, and with a ValueExpression being maintained by the bean. Also, added some test code for faces messages.

Subversion 22423

The previous ice:inputFile component did not participate in form submission. It could optionally cause the side effect of submitting the form, before or after the file was uploaded. The new ice:inputFiles component does participate in form submission by default. If you use an h:commandButton to do a full form submit, then the file will upload along with the form contents. If you use an explicitly ajax form submit, like an ice:commandButton which calls javascript ice.submit, or an f:ajax h:commandButton, which calls JSF's ajax javascript, then the file will not be uploaded as the form contents are submitted. There might be a point to having a flag for the ice:commandButton to allow it to do a full form submit, so that it can upload the file.

As well, there's on mode missing. We opt in to the form by default, and we can opt out of uploading the file by using ajax submit, but we can't currently upload the file and opt out of processing the rest of the form. As such we lack some equivalent to singleSubmit for the ice:inputFiles component. Since there is no built-in submit button on the ice:inputFiles component, it's not obvious how that could be accomplished, beyond putting the ice:inputFiles component in its own form. One use case might be the auto-upload, in which case there would be a trigger for the ice:inputFiles component to be initiating the form submission, and thus be able to direct the process to only execute the inputFiles component. Alternatively, since the InputFilesPhaseListener is responsible for setting up the whole lifecycle, the ice:inputFiles component could have some hidden input field, that would set a singleSubmit flag, which the InputFilesPhaseListener could find, and then setup the lifecycle to then only execute the ice:inputFiles component.

There's also the issue of enabling some kind of singleSubmit/partialSubmit behaviour.

Must-haves for release are (in order of priority):

• Make info property iteration aware
• Change hard-coded FacesMessage strings to use proper localisations
• Augment InputFilesStatuses to work with localised strings
• Skin support (Rime + Sam)
• Handle required property
• ARIA support

Next highest:

• Progress: HTML 5
• Progress: HTML 4

Finally:

• Multi-file: HTML 5
• Multi-file: HTML 4
• Callback support

Added more documentation for the inputFiles properties.
Subversion 21850

I missed a support file in glimmer, CoreUtils, which is derived from the similarly named class in compat.

Subversion 21830

Committed my test page, which runs through 12 or so scenarios of using the inputFiles component.
Subversion 21821

Committed sparkle code for base functionality of inputFiles component.
Subversion 21820

TODO:

• Change hard-coded FacesMessage strings to use proper localisations
• Augment InputFilesStatuses to work with localised strings
• Handle required property
• Make info property iteration aware
• ContentType / file extension filtering
• Progress: HTML 5
• Progress: HTML 4
• Multi-file: HTML 5
• Multi-file: HTML 4
• Callback support

From Deryk Sinotte:
We generally have had to call setId() specifically in these PostAddToView events because the internally tracked id of the component leads to this issue.
So the FormScriptWriter is using writeAttribute() but this doesn't help with the internal id which is why setId needs to be called also/instead (not sure which).

Changed FormScriptWriter so that it will always set an id on itself. If none is specified, use a generated id.

Subversion 21459
glimmer\core\src\main\java\org\icefaces\event\FormScriptWriter.java

Committed glimmer code that sparkle depends on.
Subversion 21455
Subversion 21456

Committed sparkle inputFiles first draft.
Subversion 21457

Commited sparkle test app changes to include inputFiles
Subversion 21458

Putting code in the Filter has one major drawback: In Servlet 2.5, JARs can't have web.xml snippets, only WARs, so it would be up to applications to configure the Filter. I'd prefer a more automatic approach. So, I've been investigating using the pre-RestoreView PhaseListener to do everything that was planned for the Filter.

The first step is to fake out the Faces-Request HTTP header, so that PartialViewContext.isAjaxRequest() will return true, on our fake-AJAX file upload POSTs. I've made the fake HttpServletRequest fake the header, so that ExternalContext will return the appropriate header, but it appears that PartialViewContext.isAjaxRequest() is caching a previous evaluation. Searching the JSF code for all direct and indirect invocations of that method show that one invocation is happening earlier than I'm intercepting it. FacesContextFactoryImpl.getFacesContext calls ExceptionHandlerFactoryImpl.getExceptionHandler() calls PartialViewContext.isAjaxRequest(). My initial solution to this was to override the ExceptionHandlerFactory, to return an ExceptionHandlerWrapper that lazily evaluates constructing the ExceptionHandler, since it's only used at the end of each Phase anyway. But, I'd still be vulnerable from any other code, over time, that could call isAjaxRequest() first. Ted told me that we override the PartialViewContextFactory, and have our own DOMPartialViewContext, where I can just add my own method to reset the isAjaxRequest() caching. This is used on ICEfaces views, and stock JSF views with delegating. So, even when testing in stock JSF, I can use it.

Need to research this to see what's feasible using just Ajax/xHTML.

For now, the link for inputFile component has been disabled.

requires addition of commons-fileupload.jar (currently isn't in compat/lib folder)

direction is to use new jsf2.0 resource handling api for fileupload--changing the iframe HTML so it posts back to a ResourceHandler looking for a multipart file upload . Mircea indicates that a custom ResrouceHandler may be required.

Also for state saving:-
com.icesoft.faces.component.inputfile.InputFile has (old)references to facesContext.getViewNumber() from 1.8.x, which are no longer available in ICEfaces 2.0. Ted suggests that this must be referenced from the ViewState of jsf2.0 so that fileupload is associated with the correct component tree.
There is also a reference to (old) DOMResponseWriter.getSavedNode() which no longer exists. Greg suggests that this is no longer required as jsf2.0 maintains the saved state.