Zend Framework

An error occurred in my problem description.

The Zend_Form_Decorator_File is not actually using the helper set on $helper on Zend_Form_Element_File and rather uses directly the helper formFile...

So, basically to change the helper used instead of formFile we need to extend both Zend_Form_Element_File and Zend_Form_Decorator_File...

Why would you want to use another helper?

Note that the file element would then no longer work... same applies for the decorator. There were already several issues being written because people did erase the decorator and the file element did not work anymore.

The purpose if for adding advanced facilities for add/edit of uploaded files.

Let's suppose we have a form for adding/editing a product. I am not talking about advanced upload facilities, as for http://www.swfupload.org/ but for some basic ones into a normal situation.

Case 1: We are a new product. The user is adding one file for upload, but forgets to fill other field.

The current way: The user gets again the add form, with all the valid values filled in, but of course, he lost the uploaded file, he should re-upload again the file...

Normal behavior: the uploaded field has a link to the uploaded file (or a thumbnail of the image, if that's an image). If the user wants to upload a different file then he just pick other file.

Case 2: We are editing a product.

The current way: the user is invited to upload new file without to actually see if there are currently uploaded files and which files

The new way: use is able to see what files are uploaded and to decide if he wants to add more.

Of course, the problem can be extended to be able to "remove" existing uploaded files.

I just tried to how you that if we are limiting the File element to a standard behavior is very difficult for developers to put up some otherwise not quite unusual facilities...

In my case, i had to rework lot of files to get such behavior (File Element, Decorator, aso)...

Case 1 does not work:
Temporary uploaded files are erased by PHP. And you can't set a path on the element itself as you can not set a value on file elements due to HTML/Browser restrictions. So you always MUST upload a file completly.

Same for Case2.

The problem is not the limitation of the file element, the problem is that HTML/Browser does not allow to do this.

When you need a behaviour feel free to propose it.

Generally the file element does not work 100% identical to the other elements due to the previous mentioned restrictions. When we would change this, then we would have much problems we can not solve.

Case 1:
"Temporary uploaded files are erased by PHP. "

Is possibly to save the file on a form derived isValid.

Case 2:

Similar.

I am not trying to propose a way to do uploads other than imposed by htm/browser. I am trying to say we should keep the File element open to be extended by developers to do more advanced ways to work with files.

If you think we should not be able to extend the File element easier then you are saying we should actually do raw PHP and forget about using ZF...

There is no reason to be ridiculous just because someone wants to discuss an issue in detail before coming to an conclusion.

I just want to know a usecase for eliminating the binding between Zend_File and it's helper.

Saving the temporary file and providing it later will as mentioned by you will cause an "attacker exception" from PHP itself.

The standard way to work with File element (and generally with the way browsers/html are doing this) is simply too annoying to use more than for demo scripts, for learning ZF. Is not ZF fault of course.

But any kind of serious application needs to go beyond this very basic functionality, and i think would be easier for developer to go further based on existing File element by extending his functionality:

• than getting rid of File element and developing from scratch
• or by still using File element but making lot of workarounds to make it work the way it wants...

Closing as non issue

*) The file form element provides the helper parameter
*) The render method of it is not hardcoded to file but to parent
*) The file decorator works identical to errors, fieldset, image and label which were the 4 decorators I used as reference

As the file element and it's decorator works identical to several other element regarding it's call and usage of view and view helpers this issue is closed as non-issue.

When you think that there is a generic problem on Zend_Form itself then please open a new issue. Because in my opinion the file element behaves correct (as all other elements)

Thanks Thomas.

If is like you said that "As the file element and it's decorator works identical to several other element regarding it's call and usage of view and view helpers" so applies for other form elements then is a real problem in many cases and i will file a new issue on JIRA.