Sending VB data to another page in Javascript - asp.net

I'm creating a search form using an asp:button control with the urlpostback set to a results page. The problem is, the asp:button uses Visual Basic and the search results from Google require Javascript.
Is there a way to take the data from an asp: textbox in VB and then send it to another page that uses Javascript and use the data?

You can always save the search results into a hidden form field, and set the page's form option to post to your "destination" page. From there, you can use your typical JavaScript methods to pull the data out of the posted form.

I'm not sure if it helps you but its worth a try:
http://www.google.com/support/forum/p/AdSense/thread?tid=2a9b892b35120b56&hl=en

You could try
Response.Redirect - and redirect to google.com with the search query appended (as a test I just manupulated the string in my browser and it seems to work. Look at the querystring parameter "q"
Try the google search api

Related

aspx ashx mash-up

I'm retro-fitting a .aspx page with AJAX functionality (using VB, not C#). The codebehind populates the page with data pulled from a web-service. The page has two panels that are populted (with different data, of course) in this way. On a full page refresh, one or both panels might need to be populated. But populating Panel 2 can take a long time, and I need to be able to update panel 1 without refreshing Panel 2. Hence the need for AJAX (right?)
The solution I've come up with still has the old .aspx page with .aspx.vb codebehind, but introduces a Generic Handler (.ashx) page into the mix. Those first two components do the work on the user's first visit or on a full page refresh, but when AJAX is invoked, the request is handled by the .ashx page.
First question: Is this sound architecture? I haven't found a situation online quite like mine. Originally, I wanted to make the .aspx page into the AJAX handler by having the codebehind implement IHttpRequest, and then providing "ProcessRequest" and "IsReusable" methods, but I found I couldn't separate a regular visit to the page from an AJAX request, so my AJAX handlers took over even on the first visit to the page. Second question: Am I right to think that this approach (making the .aspx page do double-duty as the AJAX handler) will never work? Is it impossible to tell whether we're getting a full-page request or a partial-page (AJAX) request?
If the architecture is good, then I need to dynamically generate a lot of HTML in the .ashx file, right? If that is right, should I send HTML back to the client, or should I encode it in some way? I've heard of JSON encryption, but haven't figured out how to use it yet. So, Third question: Is "context.Response.Write" the only pipeline for sending data back to the client? And, if so, should I send back HTML or some kind of JSON-encoded objects?
Thanks in advance.
It sounds as if the page requires some AJAX functionality added to the UI.
Suggest using an UpdatePanel for each web form element that needs to have AJAXy refresh
functionality. That'll save you from having to refactor a bunch of code, and introduce a whole lot of HTML creation on your .ashx.
It'll be more maintainable over the long run, and require a shorter development cycle.
As pointed out by others, UpdatePanel would be a easier way - but you need to use multiple update panels with UpdateMode property set as conditional. Then you can trigger the update-panel refresh using any button on the page (see AsyncPostBackTrigger) or even using java-script (see this & this). On the server side, you may decide what has triggered the partial post-back and act accordingly by bypassing certain code if not needed.
You can also go with your approach - trick here is to capture the page output using HttpServerUtility.Execute in your ashx and write it back into the response (see this article where this trick has been used to capture user control output). Only limitation with this approach is that you can only simulate GET requests to your page and so you may have to change your page to accept parameters via query string. Personally, I will suggest that you create a user control that accept parameters via method/properties and will generate necessary output and then use the control on your page and in ashx (by dynmaically loading it in a temperory page - see this article).
EDIT: I am using jquery to illustrate how to do it from grid-row-view.
$(document).ready(function() {
$("tr.ajax-grid-row").click(function() {
$("#hidden-field-id").val($(this).find(".row-id").val()); // fill hidden filed
$("#hidden-button-id").click(); // simulate button click
});
});
You can place above script in the head element in markup - it is assuming that you have decorated each grid-row-view with css class "ajax-grid-row" and each row will have hidden field decorated with css class "row-id" to store row identifier or the value that you want to pass to server for that row. You can also use cell (but then you need to use innerHTML to get the value per row). "hidden-field-id" and "hidden-button-id" are client ids for hidden field and submit button - you should use Control.ClientID to get actual control ids if those are server controls.
JSON is not for that purpose, it is to pass objects serialized with a nice light weight notation, is you need to stream dinamically generated html using ashx, response.Write is what you have. You may want to take a look at MVC
Or you could use jquery if it's just html, the simpliest would be the load function, or you can look into Ajax with jquery. Since the ashx can be served as any resource it can be used in the load function.
I agree with #p.campbell and #R0MANARMY here. UpdatePanel could be the easiest approach here.
But then like me, if you don't want to go the UpdatePanel route, I don't see anything wrong with your approach. However, generating the html dynamically (entirely) at the back end is not a route I'll personally prefer (for the maintainence reasons). I'd rather prefer implementing a solution that will keep the design separate from the data.

Facebook like AutoSuggest texbox using jquery in asp.net

I need to implement Facebook like AutoSuggest texbox using jquery in my asp.net application.
I googled a lot about this but only found PHP links :(
Any pointer or suggestion will be really helpful. thanks
Go through this link and download the autosuggestion file(jquery.fcbkcomplete.min http://www.emposha.com/ of jQuery
You don't really need a specific example of the server-side code, do you? I'd guess that using this page as a starting point, and using something like Fiddler to intercept the traffic from the page you should be able to figure out what is required on the back end... (clue : autocomplete_ajax.cfm expects a query parameter called q with the text entered from the form, and returns data in the format
Match1Name|Match1Id
Match2Name|Match2Id
)

How to post a purely HTML form via ASP.NET

When posting a form in ASP.NET, it adds container information to the request form keys
For example if you have a Textbox field with an ID of: txtFullName
It could end up posting something like this: ctl00_ContentPlaceHolder1_txtFullName
This is fine if you control the page where you are posting to but if you are posting to someone else's page or API then the form keys have to be exact.
I'm looking for an example of how to post a pure HTML for via asp.net or via code in vb.net/c#
TIA
in ASP.Net 4 you have the ClientIDMode="Static" :)
but if you are still not on 4
you can use this solution:
http://www.west-wind.com/Weblog/posts/4605.aspx
but you have to be careful with it.
so just inherit the control you want like textbox and override this properties
and you should get the result you wanted.

Is it possible crawl ASP.NET pages?

Is there a way to crawl some ASP.NET pages that uses doPostBack as events calling?
Example:
Page1.aspx:
Contains 1 LinkButton that redirects to Page2.aspx
Code-behind for LinkButton Click event:
Response.Redirect("Page2.aspx")
In client side this code is generated on click event:
doPostBack(...
Is it possible crawl pages using only HttpWebRequest?
I know that use Response.Redirect is not a good idea in this case, but I don't have choice.
Yes, it's possible if the code follows a well predictable pattern. You would have to gather the form data from the page and simulate what the doPostBack function does (putting some values in some hidden fields), and send a POST request to the server. What you get back would be a redirection page, so you would have to parse that to get the url of the target page.
If you mean if search engines like Google will crawl the pages, then that is very unlikely. They might attempt to follow some common patterns of posting and script linking, but generally you need to use proper links between the pages to be sure that they are crawlable.

How to use jquery form plugin with asp.net?

in asp.net 2.0 (not mvc), the form's action is to itself. how can I use the forms plugin to send information to server?
I need to send data from the form (let's say name, email, comment) and to display the result on the client side.
Any ideas?
Thanks,
Dave
ms ajax? if i use update panel, i don't need jquery. i want to use jquery and the form plugin (plus the validation plugin) only. no microsoft ajax for me, thank you!
just look at the trafic they produce in firebug to understand why.
It depends on how much of asp.net you want to use during the form submit. I am using the forms plugin in this same way but you need to think in terms of a more classic web model.
The forms plugin does a 'submit' which does not include any viewstate information. That is to say, if you try to get a value like so
sName = txtName.text
the text for txtName will be blank. But if you use your request object you should be able to pull back the value provided your know the control's UniqueID
sName = Request.Form(txtName.UniqueID)
Then what I would do is use the form plugin's success: callback to run an ajax call that will pull back your results. You can use ms ajax WebMethods for this, and you can call the webmethods directly from jquery without the need for the ms script manager. In this case, the WebMethod is returning the html I want displayed on the page.
$(form).ajaxSubmit(function(){
success:function(ret){
$.ajax({
type: "POST",
contentType: "application/json; charset=utf-8",
dataType: "json",
data: "{}",
url: "SomePage.aspx/SomeWebMethod",
success: function(msg){
$('#somediv').html(msg);
}
}
});
More info on calling ms ajax with jquery here
Because of the way viewstate is tightly coupled to the form in ASP.NET, unless you set up a service to accept the request I'm not sure if this is going to be possible. If you don't want to use viewstate, then you could just use a normal HTML form on the aspx page and submit that to a service that returns your expected results.
When you submit an asp.net form to postback, it sends everything back through the page lifecycle, I don't think there really is anything for a jQuery ajax request to talk to. You could setup a WebMethod on the page, which essentially exposes a service and you could get the jQuery request to talk to that, but I'm not conviced that it would work.
However, you can do ASP.NET AJAX with the MS libraries without using UpdatePanels, see this article for a good rundown of what you can do with WebMethods and the ajax javascript libraries
I ran into this problem today and eventually solved it using the following combination of hacks:
Suppose you have a search page and a results page and you have a form on the search page that you want to post to the results page and load via ajax using the jquery forms plugin. You need to do the following:
Create a Search.aspx page and a Results.aspx page
ASP.NET webform pages have a single form on a page with and id of aspnetForm but the action will always be set to post to itself, so the first thing you need to do when you load the Search.aspx page is to change the action of the aspnetForm to be Results.aspx like this:
$('#aspnetForm').attr('action', 'Results.aspx');
You then need to deal with viewstate so that when you POST from Search.aspx to Results.aspx you don't get invalid viewstate errors. To do this just remove the viewstate variable from the page like this:
$('#__VIEWSTATE').remove();
then you should be able to set up the #aspnetForm to use the jquery forms plugin like so:
$('#aspnetForm').ajaxForm();
This then allows you to post to the Results.aspx webform. This is just a start to get you going in the right direction, but basically it comes down to needing to change the action that the aspnet form posts to and then removing viewstate.
I currently use a mix of asp.net and jquery and the way i solved the issues with the page life cycle and such is to simply not use the autopostbacks and asp.net buttons to submit the form.
I use either ajax calls attached to simple html buttons or, when i really want to submit the entire page i use the __doPostBack(eventTarget, eventArgument) javascript function.
These articles were useful to me:
Understanding the JavaScript __doPostBack Function
Calling __doPostBack in javascript
It doesn't seem VS08 works for you, but others may be interested:
I went to a MSDN Roadshow the other day that seemed to make it very easy.
Scott Gu's blog has this:
http://weblogs.asp.net/scottgu/archive/2008/11/21/jquery-intellisense-in-vs-2008.aspx
It doesn't work, as ASP.NET force you to put everything within a server form as long as you use server control (this is the way how it handles postback). The primary problem you would have is HTML does not allow nested form anyway, so you can't even use jQuery to find the form element (thats my experience with FF3)
The good answer (but hard to achieve)- throw away WebForm and use MVC.
The compromise workaround- I did a small plugin myself which converts a div into an ajax submit with the div abused with method="post" and action="url" dress up, then utilize jQuery Form Plugin to serialize, submit with a plugin pattern. It doesn't do File Upload though (as that requires IFrame, I think its still feasible, but take some more hack). The code is in my client's project so I still dont have permission to post it as a plugin. However I think this is not too hard to do it once you know the theory :)
Really, aim for the good answer (get rid of WebForm) next time. Its not just jQuery Form going to hurt you, there's a lot more pain you have to take if you decided to do jQuery + Web Form, if its not my client's requirement I would never take this path.

Resources