AsyncFileUpload *VERY* broken in the AjaxControlToolkit - asp.net

I've just downloaded the new AjaxControlToolkit from codeplex to give the much anticipated AsyncFileUpload control a go, but unfortunately it has fallen at the first hurdle...
I have put it on a fairly simple page called uploadFile.aspx which takes a url argument:
uploadFile.aspx?myDbId=1
In the page load, it's doing stuff with Request["myDbId"].
When selecting a file using the new control, it posts it back straight away, but it hits a 500 error with the Request["myDbId"] line because it has stripped ALL url arguments and replaced them for it's own:
uploadFile.aspx?AsyncFileUploadID=ctl00_BodyPlaceHolder_ctl00&rnd=08382490910589695
This to me is a massive problem, and one I haven't been able to get around. Any solutions?

Here's an alternate solution if that one doesn't work out. This solution has been around for a year or two, and it is his second version. It includes a progress bar that doesn't require a flash dependency, and can handle very large files without problems.
ASP.Net File Upload Module v2
http://darrenjohnstone.net/aspnet-file-uploaddownload-module-v2-documentation/

Can you use a Session variable to manage myDbId?

You could encode the id in the filename, so just append "--" + myDbId to the filename. The fact that it comes after the extension could make it easier to know that this was added.

Put the AsyncFileUpload control in an iframe on the page, which will post back to just that section.

Related

Saving contents of <pre> tag to file on server

I have searched here and googled for this, and I've probably come across an answer, but I guess I don't understand asp.net enough to get it working. As the title says, I'm trying to save the contents of a tag to a file on the server. I'm specifically using asp.net because I'm developing for a website on a WHS box and I'd like to use the already existing FBA.
Using javascript, I can successfully get the contents, but I am unable to work with it from there. From what I've read, it sounds like I need to POST the contents, either a postback or to another page, to save the file. That's what I'm having problems getting working. I can get a StreamWriter created and working, but I am unable to pass what I need to it.
Thanks for any help, and I can post some of the code I have now if needed. JR
You need to use Javascript to send an AJAX request to an ASHX handler with the text as the POST body.
You can then read the POST in the ASHX handler from the Request object and write it to disk.

How do I submit a form with a large file upload and send ajax requests?

This works in other browsers but not in chrome. I am trying to allow users to upload large files and have an ajax call to update them on the progress of the file upload.
So a unique ID is generated on the client side and added to the action of the form before sending. Then the form is submitted (form only contains a file upload input) and an ajax call is made to get the progress of the upload.
The ajax call goes to another page and uses the ID to lookup the upload.
I am using JQuery 1.5.1. Debugging this and putting something on the error function give me nothing other than "error". Not very helpful. I used Chrome's debugger and it just says failed to load resource xxxx.aspx. xxx.aspx is the URL i needed. Turns out that there seems to be some sort of conflict between the form and the ajax call.
Is there some way to get around this?
you should really look at SWFupload, a great flash based uploader, with concurrent upload and progressbar support. Also it makes it really easy to use server-side, you dont need to implement upload percentage view as it client-side based.
not exactly an answer to your question, but a link to a tool that can really help you drill down and find good error messages, step through javascript code and such would be firebug for Chrome, I got the IE and Chrome versions working and use it very regularly, it has been a life saver and greatly has decreased debugging time:
http://getfirebug.com/releases/lite/chrome/
I would suggest making firebug a common tool in your debugging arsenal.
Use SlickUpload
It is a server control and module that does exactly what you are looking for and takes less than 10 minutes to setup.
Documentation: http://krystalware.com/Products/SlickUpload/Documentation/overview/

asp.net url concealment?

In my asp.net 2005 app, I would like conceal the app structure from the user. Currently, the end user can learn intimate details of my web app as they navigate and watch the url change. I don't want the end user to know about my application structure. I would like the browser url to not change if possible. Please advise.
thanks
E.A.
URL rewriting is the only one that can provide any kind of real concealment.
Just moving the requests to AJAX or to frames, means anyone (well, more advanced users) can still see those requests being fired, just not in the address bar.
Simplest solution is to use frames - a single frame that holds your application and is 100% * 100%. The URL will not change though the underlying URL can still be seen via "View Frame info", however only advanced users will even figure that out.
In your pages, make sure that they are contained inside the holding frame.
A couple of possibilities.
1) use AJAX to power everything. This will mean that the user never leaves the home page
2) use postbacks to power everything. In this, you'd have all those pages be user controls which you progrmattically hide or show.
3) URL rewriting (especially if this is asp.net 3.0 or later)
My site uses url parameters to dynamically load ascx files into a single main aspx. So if I get 'page_id=123' on the query string, I load the corresponding ascx. The url changes, but only the query string - the domain part remains the same.
If you want the url to remain precisely the same at all times, then frames (per Oded) or ajax (per Stephen) are probably the only ways to do it.
Short answer: use URL encryption
A simple & straight article: http://devcity.net/PrintArticle.aspx?ArticleID=47
and another article: https://web.archive.org/web/20210610035204/http://aspnet.4guysfromrolla.com/articles/083105-1.aspx
HTH

iframed ASP actions trouble

This is actually a follow up on my previous question (link)
I've created the HttpHandler and it works fine for now, I'll add flexibility by using the querystring and session to point the post I'm making in the right direction.
The next question is as follows.
Now that I have the old page iframed as it should be, there's still the trouble of handling the postbacks (or actions) these pages trigger.
Every button action (asp form post) refers to a page that is not there (it's on the other server from which I am importing functionality).
I've tried using a url mapping to the other server but I get an error that tells me the external link is not a valid virtual directory. Hence I discarded this option.
I there anyway to keep functionality going inside the iframe?
please do ask clarification if you need it.
I got a solution from a colleague.
before passing the response string to the Iframe from the handler I use a string.replace to adjust the urls in the old site. This way they point to the old site and everything works again :)

Parsing PlainText Emails from HTML Content (ASP.NET)

Right, in short we basically already have a system in place where the HTML content for emails is generated. It's not perfect, but it works.
From this, we need to be able to derive a plaintext alternative for the email. I was thinking of instantly jumping on and creating a RegEx to strip the <*> tags from the message - but then I realised this would be no good because we do need some of the formatting information (paragraphs, line breaks, images etc).
NOTE: I am OK with actually sending the mail and setting up alternative views etc, this is only about getting plaintext from HTML.
So, I am pondering some ideas. Will post one as an answer to see what you guys think, but thought I would open it up to the floor. :)
If you need any more clarification then please shout.
Many thanks,
Rob
My Solution
OK, so here it is! I thought up a solution to my problem and it works like a charm!
Now, here are some of the goals I wanted to set out:
All the content for the emails should remain in the ASPX pages (as the HTML content currently does).
I didn't want the client code to do anything more other than say "SendMail("PageX.aspx")".
I didn't want to write too much code.
I wanted to keep the code as semantically correct as possible (no REALLY crazy-ass hacks!).
The Process
So, this is what I ended up doing:
Go to the master page for the email messages. Create an ASP.NET MultiView Control. This control would have two views - HTML and PlainText.
Within each view, I added content placeholders for the actual content.
I then grabbed all the existing ASPX code (such as header and footer) and stuck it in the HTML View. All of it, DocType and everything. This does cause VS to whinge a little bit. Ignore It.
I then of course added new content to the PlainText view to best replicate the HTML view in a PlainText environment.
I then added some code to the Master Page_Load, checking for the QueryString parameter "type" which could be either "html" or "text". It falls over to "text" if none present. Dependant on the value, it switches the view.
I then go to the content pages and add new placeholders for the PlainText equivalents and add text as required.
To make my life easier, I then overloaded my SendMail method to get the response for the required page, passing "type=html" and "type=text" and creating AlternateView's as appropriate.
In Summary
So, in short:
The Views seperate the actual "views" of the content (HTML and Text).
A master page auto switches the view based on a QueryString.
Content pages are responsible for how their views look.
Job done!
If any of this is unclear then please shout. I would like to create blog post on this at some point in more detail.
My Idea
Create a page based on the HTML content and traverse the control tree. You can then pick the text from the controls and handle different controls as required (e.g. use ALT text for images, "_____" for HR etc).
You could ensure the HTML mail is in XHTML format so you can parse it easily using the standard XML tools, then create your own DOM serialiser that outputs plain text. It'd still be a lot of work to cover general XHTML, but for a limited subset you plan to use in e-mail it could work.
Alternatively, if you don't mind shelling out to another program, you could just use the -dump switch to the lynx web browser.

Resources