jijo-paulose / gwtupload

Automatically exported from code.google.com/p/gwtupload
Other
0 stars 0 forks source link

MultipleFileUploader - nested widgets removed after upload #81

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.Create a MultipleFileUploader and nested other form fields within it by 
calling .add()
2.Perform an upload, and the nested form fields will be removed after the 
successful upload of a file

What is the expected output? What do you see instead?
The nested form fields should not be removed because removing the fields 
prevents the ability from a static set of form fields to be embedded in each 
POST (upload) from the client.  Having to inject the form fields back in after 
ever upload is DOM/client intensive and not ideal.

What version of the product are you using? On what operating system?
6.1

Please provide any additional information below.

This was reported as a comment on 
http://code.google.com/p/gwtupload/issues/detail?id=8 however that issue has 
been flag as fixed.

Original issue reported on code.google.com by ShieldsJ...@gmail.com on 24 Nov 2010 at 4:07

GoogleCodeExporter commented 9 years ago
A new form is created for each new Uploader unless you provide an instance of 
FormPanel, then Uploader adds the FileInput to this form.

MultiUploader does not have the option of providing customized forms, it 
creates a new Form for each upload and removes the previous one when finishes. 
Not sure what implies to change the behaviour. Nevertheless a workaround right 
now is to add a statusChanged handler to the Multiuploader instance:
Final Widget w = new ...;
public void onStatusChanged( IUploader uploader ) {
  if ( uploader.getStatus() == Status.CHANGED ) {
       uploader.add(w);
  }
}

Another option which is simpler is to add extra parameters to the query string 
sent when uploading uploading.setServletPath("uploadServlet.gupld?id=whatever") 
and get
this parameter in server side with request.getParameter("id").

Let me know if you have a patch for this feature, if not I'll schedule this for 
a future release.

Original comment by manuel.carrasco.m on 29 Dec 2010 at 7:36

GoogleCodeExporter commented 9 years ago

Original comment by manuel.carrasco.m on 29 Dec 2010 at 3:29

GoogleCodeExporter commented 9 years ago
Was there a strategic reason MultiUploader doesn't allow for the specification 
of a FormPanel via the constructor?  That seems like a logical/useful fix for 
it.

Original comment by ShieldsJ...@gmail.com on 29 Dec 2010 at 8:36

GoogleCodeExporter commented 9 years ago
The only one is the layout, when I created the widget I saw easier to add new 
uploaders to the vertical panel.
Using the same FormPanel it should be necessary to detach and reattach it each 
time.

Original comment by manuel.carrasco.m on 30 Dec 2010 at 6:45

GoogleCodeExporter commented 9 years ago
This issue was closed by revision r873.

Original comment by manuel.carrasco.m on 22 Mar 2011 at 9:27

GoogleCodeExporter commented 9 years ago
Reusing the form panel is a bit difficult since we need the panel for the 
current upload, so as new ones can not use it until the submit has finished.

The solution I have selected, is to maintain a list with the widgets added, and 
add all those widgets when the new form is submitted and before the old form is 
removed.

Hidden field values are recalculated if their value match the input name 
prefix. It is useful for php apc progress mechanism. 

Nevertheless it is still possible to add/remove widgets in onStatusChanged if 
the user wanted a different behavior. 

Thank you for reporting

- Manolo

Original comment by man...@talkwheel.com on 22 Mar 2011 at 10:25