We've been using IScriptControl to tie javascript objects to our UserControls and ServerControls, and it's worked fine.
The problem is that ASP.NET seems to provide no method to tie a javascript object to a Page. Up to now, we've been putting plain functions in the global namespace, but I am developing a serious allergy to that practice.
It'd be easy enough to wrap our functions into a javascript class, and to include the javascript file on the page, but how to instantiate the object, how to reference it from callback events, and how to pass data to it from the code-behind, I haven't figured out.
Or rather, the methods we've been using up to now (hidden fields, emitted javascript strings, etc.), really bug me.
Anyone have better ideas?
There isn't any association between the JS file and the page, unless you build it. With script controls, the common practice to store state is hidden fields (the ACT uses this approach). The only other ways to communicate with the server is through a web service call, form posted data, or by invoking a __doPostBack (but that isn't AJAX).
You can create some base architecture to link the two together. With script controls, the server renders a $create statement to pass properties and event handlers from the server to the client; data being posted back to the server is stored in hidden variables and processed on the client (with most script libraries), so script controls and ACT hide a lot of this for you, and you would have to build some of this if you wanted to automate this. It may help to study the client-server interaction to give you ideas of what to do if you wanted to customize this.
Funny, I was thinking of the same thing for my Nucleo project (a third party library of mine) on codeplex, but I haven't yet gotten around to it.
Related
I've developed an ASP.NET user control, instances of which may appear several times on a single page. Without getting into too much application detail, when the value of any one of the instances changes, all of the other instances need to be refreshed. Currently, in order to accomplish this, I'm requiring that the consuming page implement a couple of methods which iterate through each control on the form, find all the instances of my user control, and call a Refresh method in each one.
Functionally, it's working perfectly. However, I'd like to force the developer of the consuming page to implement these two methods exactly as per my requirements. I could have them implement an interface, but that doesn't provide the functionality in each method. Or I could have them extend an abstract class, but in either case (interface or abstract class) how can I force them to inherit? I need something that will trigger a compiler error if the necessary abstract class is not extended by the consuming page. Any ideas?
Thanks.
You can enforce implementation by using 'abstract methods' in C# or using the 'MustInherit' keyword in VB.NET.
In your particular case, you're expecting the developer to essentially implement 'your' code to force the refreshing and this is something I wouldn't want delegate. Without knowing too many details I would be tempted to utilise the 'Observer' design pattern or possibly the 'Mediator' using either a separate object as a controller or even applying the controlling / publishing code to the webpage. Here's a practical example of the 'Observer' in ASP.NET.
HTH
Folks,
I have some personalized properties on an ASP.Net Web Part that I would like to set via Ajax (for example, the size to which the user has expanded the WebPart using the jQuery Resizable plugin.)
I've read this question and answer, but I don't think it will work. Personalized properties are instance properties. (If they were static, they couldn't be user-scoped, could they?) A WebMethod, which must be static, can't access them.
You might be thinking that I could just use a hidden field and send my values back that way, but that assumes that a postback is done at least once after the values are set. In this case I can't guarantee that: the page in question displays a lot of data but doesn't take any user input other than for configuration.
I seem to recall that some Ajax techniques involve remotely instantiating a page on the server and going through at least part of the page life cycle, but the last time I messed with that was 2006 and I never could get it to work very well. I have the impression that modern Ajax techniques, even for ASP.Net, work in other ways.
So, does anybody have an idea of how this could be managed?
Thanks very much,
Ann L.
Webmethods only have to be static when they are page-based. Create a webservice in your project and stick non-static webmethods in there. You can even enable session state.
Is it my understanding that Helper methods are really the place where you can do the hard core logic that we would have done in lets say custom controls in ASP.NET? For instance I work for a .com which uses classic ASP.NET. The nature of our site is VERY complex, so we reuse and render different forms for thousands of products. Every product could have a different configuration form. We have a very complext RenderForm.cs custom server control that performs all the logic. Based on some configuration settings from a table in the DB, it says ok, for Product 1123 it reads the setup (that our users confugure form our internal admin system) and takes that and spits out the dynamic form (using literal controls and what not) to the p age.
So I'm thinking MVC now. Yea yea, it's all done in the View. Well partially. You're still going to have a need to have some custom logic in some .cs where it's not all embeded in your view. That would be foolish to think you're not going to have some class that will spit out some HTML..like some very hard core extensive helper methods.
So my question is, are helper methods or class where you now do your custom server control type of logic? it's basically kind of the same concept in that you need a place to put your "hard core" HTML rendering logic in some class other than a controller. Your controller is not responsible for rendering. So helper methods I guess are the so-called custom server controls in a way that I have in classic ASP.NET, figuratively speaking. I just need a yes or now on is the consensus that helper methods is the place to do all my hard core reusable logic that spits out html to the page and where I can embed custom controls into my view? Looks like it.
"Helpers are essentially static classes, designed to contain the UI logic that otherwise clutters up your UI. Think of these as UI utilities." link text
Yes, that is right on. If you do it right, you will start with the HTML helpers that MVC gives you, and you will gradually build up your own set of helpers that do even more and more for your specific project. You can get to the point where your view has only a few lines of code, which say something like, "Render entire view for Product 1123". The helpers will become your own "language" of renderers specific to your project, and you will be applying configuration, validation and everything else in a very DRY (Don-t Repeat Yourself) manner. It's phenomenal.
Update: Of course, only presentation stuff should go in your helpers. The goal is to stay DRY in your views. You still need to be careful to put into your ViewModels the things that belong in the ViewModels.
I would say "no"... or rather "only where you have to". More often than not, you can instead do the logic in the Controller (or a Service) and end up passing all the data required back to the View in ViewData. Somtimes this will mean multiple Views from one ControllerAction, less often it will mean logic in your View, and occasionally it means HtmlHelpers.
When you decide to use Helpers, it should be with the consideration that this means generated markup that won't be... well, in your markup. If you have (or later hire) a designer, that can be a problem. Or if you need to make a minor change to your layout, where do you go first? Your View or your Helpers?
[Edit] Also should ask yourself this: where is my code more easily unit tested? In a Service class which is just handing back View Data, or in a class that builds entire chunks of HTML and returns them as a String? If you're using TagBuilder, as you probably should be, then any change in the implementation of TagBuilder (even a change of whitespace handling) will break tests on a Helper without your code changing.
I'm not saying "don't use Helpers", I'm saying "don't abuse Helpers".
Based on my understanding, both of them essentially do the same thing (lets us execute a server side method from JS). Are there any differences?
Also, Ajax Page Methods can be implemented either using JQuery or using ScriptManager. Which one is preferred and why??
**BOUNTY: Adding a bounty to get clear explanation of the question. Thanks **
Fundamentally, Client Callbacks and Ajax Page Methods are doing the same thing. They use an XMLHttpRequest object to send a request (usually asynchronous) to some URL, get the results of that request, then execute a callback method you've provided (callback with a lowercase c), passing the results of the request to your method.
Having said that, there is one big difference between the two approaches:
Page Methods are implemented as static methods on your page. Your page class is just a convenient container for these methods, which could really be hosted anywhere (a web service, a custom HttpHandler, etc.). Since no instance is ever going to be constructed, the client doesn't have to send ViewState data and Asp.Net doesn't have to run through the Page's lifecycle. The flip side is that you don't have access to to your Page class's instance methods and properties. However, in many cases you can work around this by refactoring instance methods into static methods. (See this article for more information.)
Client Callbacks are implemented as instance methods on your page.
They have access to other instance methods on your page, including stuff stored in ViewState. This is convenient, but comes at a price: in order to build the Page instance, the client has to send a relatively large amount of data to the server and has to run through a fair chunk of the page lifecycle. (This article has a nice diagram showing which parts.)
Apart from that, the cost of setting them up varies quite a bit and clients use them differently:
Client Callbacks require a fair amount of idiosyncratic scaffolding
code that is intimately coupled to Asp.Net (as shown in the link above). Given
the much easier alternatives we have now, I'm tempted to say that this technology is obsolete (for new development).
Calling page methods using
ScriptManager requires less setup than Client Callbacks: you just have
to pop a ScriptManager onto your
page, set EnablePageMethods = true,
then access your page methods through the proxy the PageMethods proxy.
Calling page methods using jQuery only requires you to link the jQuery library (and familiarity with jQuery, of course).
I prefer to use jQuery to access page methods because it's independent of the server framework and exposes just the right amount of implementation details, but it's really just a matter of taste. If you go with ScriptManager, its proxy makes the page method calls a little easier on the eyes, which some might consider more important.
I would say there are differences, but would tend to say do it the way you feel more comfortable with.
I have used both approaches, and having jQuery calls from the page is generally faster. I write an ashx handler that does the job the jquery call needs (query the database, process something, etc.) and call it from the page. I wouldn't use an aspx page for a jQuery call, because you're sending a lot of info that you won't need at all. The difference/ benefit of using an Ajax.Net call is that you don't need to build another page to process things, you can use the same page events to do it.
For example, if you need to fill a second drop down list using the selected value on a first one, you could use Ajax.Net to call the SelectedIndexChanged in the page code behind and when it fires go Page_Load, SelectedIndexChanged, Page_PreRender and so on. In the event method you'd query the db and fill the second ddl.
With jQuery that could be a bit different. You make your call to an ashx handler, the handler is just a server method that do the magic and return data in the form you want to have (json, array of strings, xml, etc) and fill the second ddl using javascript.
As I told you before, some people doesn't feel too mcuh comfortable with Client code and tend to do it in the server, but I always say that you need to use the correct tool for the right job, so know your tools and apply them wisely.
If you want to know more about ASP.Net, ASHX handlers and jQuery, you can read a post that I wrote about it.
Hope it helps.-
They are essentially the same. Both:
Setup a webservice for you that the javascript for the control can call.
Provide asynchronous response without involving the page lifecycle.
They are different:
Page Methods simply require that you decorate a static method with an attribute and you are done. The rest of the magic is handled by HTTP Handlers and Modules. Callbacks require you implement a few interfaces and handle the async event handlers yourself. I find them to be a little more of a pain.
Callbacks only work with certain controls. Calling page methods allows you to affect any control through custom javascript. Callbacks have a slight advantage here in that the client-side behavior is already written and fixed. With page methods you have more flexibility, though (the behavior on the client side is determined by you).
There are a few other differences, but these are the basics. My understanding is that client callbacks tend to perform as well as Page methods, but are not used as much becuase they are only available in certain situations, whereas a Page Method is always a valid avenue.
As for the ScriptManager vs. JQuery question, my feeling here is it's about taste more than anything. I like JQuery's syntax and I feel like it performs better, but in the grand scheme of things the most expensive thing is the XmlHttpRequest... after that the execution of the javascript is likely to be insignificant in difference next to that.
I have to integrate an existing, simple asp.net web forms app including postbacks etc. into another external site with a jQuery load() call., an app that was intended to be integrated through an iframe. I doubt that's possible without a rewrite of the app.
The app is a basic questionnaire that leads the user to a product suggestion at the end.
Does anyone have any pointers to how I could solve this? I guess I will probably have to rewrite the app with web services and dynamic calls to RenderUserControls, I will also need access to the page that calls the load() and write additional jQuery methods to handle the user input... I will probably have to remove all of asp.net's postback calls and rewrite the handling of the user input?
First of all you should note that the load() function, like all ajax, can only work on the same domain. So if the 'external site' is on another domain ajax is the wrong choice.
It does sounds like a lot of hard work, depending on the complexity of the page. Postbacks can occur in many places - image clicks, combo selects, etc. Also, there are hidden fields to worry about, like the View State and Event handler - those have the same names on both pages. You'll have an easier time if the external site has no state and postbacks.
If the pages are relatively simple this can probably be done. It's been my experience that forms don't work well in other forms, so you'll have to remove one of them (probably the loaded page's form), or place them one after the other. As you've mentioned, you'll have to rewrite postbacks, you'll want to serialize the data. You may be able to change this string to fit the names on the original page (if you've changed the name of the viewstate, etc, it's easier to change it back on the serialized string than to mess with IDs), post it to the original page, and load again.
Personally, as much as I like jQuery, and as much as this project sounds interesting (and it is), I'd probably go for a server-side solution. It sounds much easier to create a user control (that may use ajax itself), or to the expose the page's functionality using web services or better, generic handlers.