AddTrigger method

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AddTrigger method

Guest-45
Dean,

I've noticed that in the lastest development build of NeatUpload, you've marked the AddTrigger method as obsolete, and instead wish for us to the AddNonUploadButton Method.  I'm not exactly sure what the reasoning behind this was, but I think it'd be wise to keep the AddTrigger event.

The reason is that to me it makes more sense to have a single AddTrigger statement, rather than a potentially large number of AddNonUploadButton statements. 

In fact, in some cases, it becomes very difficult to account for all the AddNonUploadButtons. For example, I have implemented your wonderful control in a .ascx User Control, residing on a parent .aspx page which has two additional .ascx user controls, such as our header.  The problem is that the header user control has a button that I have to mark as a NonUploadButton, but since my progress bar does not reside on this header control, it then become rather troublesome to mark it as a NonUploadButton.

I think it'd be much much much simpler to call the AddTrigger method on my page where the progress bar resides, and not have to worry about the many other controls on this page and other child controls that cause Postbacks to start the progress bar.

Also, imagine the trouble it would cause to add nonuploadbuttons in a datagrid which contains many different rows and different TemplateColumns with postback controls.  I know you can simply mark the entire datagrid as a nonuploadbutton, but in my case, my NeatUpload InputFile control is IN the datagrid, and would therefore render it useless.  So instead i'd have to cycle through every row, and mark the other controls as NonUploadButtons.

Anyway, just a thought.  I still love the control.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Guest-45
Dean,

After playing around a little more, I see the benefit of having the AddNonUploadButton method, because it appears to clear the Input file control before the designated nonuploadbuttons post back.

So now I don't know what to do, because that is obviously a very useful thing, and would not want to be without it, but I still can't mark some of the buttons on other user controls as NonUploadButtons.

Any ideas on how to reap the benefits of both of these methods?  Maybe always clearing the InputFile unless the postback is initiated by a Trigger button?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Dean Brettle
Administrator
> Maybe always clearing the InputFile unless the postback is initiated by a Trigger button?

I tried to do that initially and couldn't find a way to make it work.  However, thanks to your feedback I decided to give it another try and I think I have it working.  Please try NeatUpload-trunk.113.zip.  With that you should just be able to use the AddTrigger() method (or the new Triggers property) and not need to use NonUploadButtons unless you have controls other than submit buttons and links which cause the form to submit.

Thanks for the feedback.  NeatUpload is better because of it.

--Dean
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Guest-45
Any time Dean...

You've got a wonderful control here and I am forever indebted to you  :).  Now, if we somehow implemented the Additional Upload Data I mentioned in the "Feature Requests", this will be truly the best thing since, well, this control.

-Amir
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Larry Brindise

I agree that the AddNonUploadButton method is necessary for all controls that postback before you are ready to commence the upload.  The way this currently seems to be working is javascript clears the text field in the FileUpload control when an included control gains focus.  This accomplishes the desired result, except it's a bit heavy-handed because now the user has to re-enter the file name they want to upload.

I was wondering if it might be possible to embed a hidden boolean field within the FileUpload control that would signify whether the file name contained in the control's text box should be uploaded or not during a postback.  Any control added via AddNonUploadButton would turn the hidden boolean field on, meaning DON'T upload (instead of clearing the text box), and the controls that have not been added to this collection could turn the boolean field "off" (or leave it off).  During postback, the FileUpload control can check this field, and if it is off, commence the upload.  If it is on, just "pretend" the text box is empty and don't upload.

This would allow easy specification of which controls allow an upload and which don't, without clearing the text field and making the user re-select the upload file.

Now, after all this, I am wondering the purpose of the "AddTrigger" method because it seems like all postback controls cause an upload to occur unless they are added to the nonupload collection via AddNonUploadButton.  Currently, the documentation is a little confusing on this.

Thanks!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Dean Brettle
Administrator
I agree that the current approach is rather heavy-handed, but unfortunately browser security dictates that only the user (not javascript and not the server) can set the filename.  That means there is no way to restore the filename after postback.  FYI, I have to jump through hoops just to clear the filename before the postback.  I literally have to delete the original <input type="file"> element and create a new one in it's place.

Regarding the purpose of triggers and non-upload buttons, for many (most?) forms you will only need to specify one or more triggers (either via AddTrigger() or the Triggers property).  If you specify at least one trigger, all other submit buttons and links are automatically considered non-upload buttons (ie clicking on them clears the filename).  So, you only need to explicitly specify non-upload buttons if for some reason you chose not to specify any triggers, or if you have postback controls other than submit buttons and links.  For the page you sent me you have a couple drop-downs that postback, so you need to specify those as non-upload buttons, either with AddNonUploadButton() or the NonUploadButtons property.  I have a couple ideas for how to change NeatUpload so you won't have to specify any postback controls as non-upload buttons, but I haven't had a chance to try them out yet.

--Dean



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Guest-45

"If you specify at least one trigger, all other submit buttons and links are automatically considered non-upload buttons (ie clicking on them clears the filename"

 

Dean, have you implemented this yet? I tried specifying a trigger (on the Page load) with the latest trunk version (.127), and it didn't seem to specify everything else as non-upload buttons, meaning that other postback controls on the page started the progress bar.

And yes, even though its inconvenient, having the inputfile.filename property as read-only is extremely important for security reasons.

Let me know thanks.

-Amir

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Dean Brettle
Administrator
Yes, this should be implemented in trunk.127.  Do the progress bars start if you click the Cancel buttons on the Demo.aspx page in the trunk.127 release?  What browser/version are you using?

--Dean
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Amir

 Dean,

Ok, after further testing, it appears that only the controls in my datagrid template columns are starting the progress bar on the post back.  All other controls seems to be behaving as intended.  Take a look at this picture and I'll show you where the problem lies:

http://www.amir777.com/pics/neat2.jpg

If you look at the datagrid, the dropdowns in section 1 post back.  These are the ones causing the progress bar to start up.  All other controls such as those on the top tabs (Place Order, Shopping Cart, etc.) clear the input field before posting back. So maybe its just the datagrid.  For now, I just went ahead and cycled through the datagrid and set those dropdowns as non-uploadbuttons, which pretty much gets everything the way I want it to.  I do remember reading somewhere where you mentioned mixing AddTrigger and AddNonUploadButtons may result in unexpected behavior.  Is this still the case?  I seem to be doing ok so far.

While we're at it, I know there was another thread regarding client-side validation, but how about server-side?  As you see, I deal with multiple uploads at a time, and I have server side validation which checks to make sure that if the user selected "Upload Files" that they did in fact choose a file using the inputfile.hasfile method.

However, as you can guess, as long as one of the inputfile fields is populated, the progress bar begins the stream before it does the validation.  I know there probably are javascript methods to do this, but Im a big server-side fan, so if you can think of anything, I'd appreciate it.

btw, I'm using PC Internet Explorer 6 on XP SP2 if that helps with the datagrid issue.  Thanks again for everything.

-Amir

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Dean Brettle
Administrator
The behavior you are seeing is expected.  Per earlier messages in this thread drop-downs don't qualify as "submit buttons or links" and thus are not automatically considered non-upload buttons.  In your particular case, do you really need a postback to occur at all (ie even without an upload) when the dropdown selection changes?  If not, I recommend just setting the AutoPostBack property of the dropdowns to false.  Then you won't even have to worry about making them non-upload buttons.  Note that even if you make them non-upload buttons, if they are postback controls you're going to get nasty behavior where the user selects "Upload files", picks a file, and then when they selects "Upload files" in another dropdown, the file they just picked gets cleared by NeatUpload.

Also, it is now OK to mix triggers and non-upload buttons.  If a control happens to be listed as both, it will act like a trigger.

As for server-side validation, the server can't validate what it hasn't yet received, so it can't start validation until the entire request has been received.  That means the user has to wait for the files to be uploaded for the server to validate.

--Dean
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Larry Brindise

What a great discussion...

I think either the AddTrigger - OR - the AddNonUploadButton should be available, but not both.  They seem redundant.

I also think that any control that can do a postback should automatically be marked as non-upload (not just submit and cancel buttons), which makes me favor the AddTrigger method instead of the AddNonUploadButton.  Because I think in most cases, there will be one button (or one button per column in a datagrid) that I will want to cause the start of the upload.  I can't think of a case where a drop-down selection should begin an upload.

I think that submit and cancel buttons should not be treated any differently than any other control since any submission back to the server will potentially start an upload if the text field of the FileUpload control is populated.

Assuming you're inheriting from the standard FileUpload control, is it impossible to extend it with a hidden field that would allow you to have the controls indicate whether the text field should be ignored (and thus an upload not continue) instead of clearing the text field as I outlined in my prior post?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Amir

Larry,

A hidden field would not help, because the filename property of any fileupload control is read-only, for security reasons.  On any postback event, the upload field will clear after the postback is complete. So, the only way in theory to not lose the text field would be to set the filename property to whatever value it was prior to the postback.  Since the filename property is read-only, this is not possible.

I think this is just one of those accepted behaviors, becuase the potential security risks of allowing the filename to be set is far greater than the inconvenience it provides for having to reselect the file.

Could you imagine if someone set the filename property to "C:\Documents and Settings\user\Local Settings\Application Data\Microsoft\Outlook\Outlook.pst", the default path and filename for the outlook data file?  or any other file?

-Amir

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Larry Brindise

Thank you for that lucid explanation!  You've convinced me to give up on my request.

However, I'm still standing by my proposition that AddTrigger is redundant...unless there is something I'm misinformed on that too.

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Amir

Larry,

Well, its only redundant if you use AddTrigger to specify the trigger button AND use AddNonUploadButton to specify ALL of the buttons that you don't want to start the progress bar with.

In most cases, you'll only need to specify AddTrigger once per progress bar, and there is no need to use the "AddNonUploadButton" method at all.

In my case, one simple "progressBarId.AddTrigger(btnSubmit)" is all that's necessary to get the whole page functioning correctly.  Otherwise, I'd had to use the AddNonUploadButton over 15-20 times to declare every single control on the page that may cause postbacks.

I still do, of course, for the dropdowns, but its much simpler than declaring every link button that posts back. Obviously, my situation may be extreme, and in most cases, there won't be that many controls that post back, but nevertheless, the current solution seems to be very good. Obviously, if we included AutoPostBack=True dropdowns and other controls to also clear the inputfile control, it would even be better, but I won't push my luck :).

-----

Dean,

Unfortunately, I can't take the AutoPostBack off of the dropdowns, because there is a lot that happens when the selection is changed in the codebehind.  For example, there is the obvious hiding of the "InputFile" control when the selection is anything but "Upload Files", but also other controls that become visible when other selections are selected.  If the page wasn't so dynamic, it might be possible to do these with Javascript easily, but again, I don't like to use javascript when I dont have to.

As you see in the previous pic, that datagrid can contain as many rows as the items the customer has in their cart, so keeping track of all those inputfile controls and dropdowns via javascript is a nightmare.

Regardless, I am so amazed at your ability to work with us so well on these issues, which makes me believe that you agree with us and don't see us a bunch of demanding, think-we-know-it-all users.  I truly appreciate this; its nice to see someone stand behind their product and have the desire to constantly improve it. Thanks for everything

-Amir

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Dean Brettle
Administrator
Hi Amir,

First, I suspect that Larry meant to say that AddNonUploadButtons was redundant since that is basically what he said a couple message earlier.  I agree and I'm almost finished changing the implementation to automatically treat all postback controls as non-upload controls.

I see what you are saying about your use of AutoPostBack on your form.  However, you understand that even with my latest implmentation you will still get the nasty behavior I described earlier, right?  The best I can suggest for avoiding that would be to move the InputFile controls onto a new page that is displayed when the user clicks continue or into a separate window that pops up when the user selects "Upload Files" from the drop-down.  Just ideas...

--Dean

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Larry Brindise

Yes, the AddNonUploadButtons is redundant if you require that I only specify each control that I want to cause an upload via the AddTrigger method, and if you automatically default every postback control to be non-upload (unless identified in an AddTrigger).

This certainly seems like the most straightforward approach that will make unintended uploads impossible because the developer has to identify which will cause an upload.  The number of controls that would cause an upload would almost certainly be less than the total population of postback controls.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Dean Brettle
Administrator
OK.  I think it's working.  As of NeatUpload-trunk.131.zip you should no longer need to specify non-upload buttons.  Let me know if you run into problems.

Thanks for all the feedback!

--Dean
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Larry Brindise

Works great.  All I did was AddTrigger(mySubmitButton) and it detected all of my postback objects (go-back button and several autopostback drop-downs) and did not do the upload when those posted back.  It appears you also fixed the text box from shrinking, which you also must have noticed while testing.

I will let you know if I run into anything else.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Dean Brettle
Administrator
Thanks for testing.  I hadn't observed any problems with shrinking text boxes.  Which text box are you referring to?  The one that contains the filename or some other text box on your form?  When was it shrinking?

--Dean
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: AddTrigger method

Larry Brindise

I think this was in .127.  When it was being cleared (so the upload would not occur), it would also shrink its width.  It no longer does this in .131.

12
Loading...