I have a Mate project with a WebService tag instance in the EventMap (which I'm using within various event handlers). I'd quite like to be able to set the wsdl property of the WebService via flashvars, but I'm not entirely sure where or how I could do that.
I know I can access flashvars via the Application.application.parameters collection, but I don't seem to have access to the Application instance during the load event of the WebService...
I suspect there's either something subtle or something blatantly obvious that I'm managing to overlook :(
Partly this was due to me not putting the parameter in the correct section of index.template.html (if everything's fine, it's the SECOND section that gets called, not the first), and partly it was my misunderstanding the behaviour of the Application and WebService classes (why oh why does it not cache the wsdl?)
I ended up adding a bindable public variable on the event map instance, then setting that variable in the creationComplete handler of the main application. I could probably have done this entirely within the event map, but it would have been a little more convoluted.
Related
Recently, I discovered that using: someControl.Attributes.Add("customAttr", "customVal") is not compatible with all web browsers. The recommended registration for custom attributes is:
Page.ClientScript.RegisterExpandoAttribute(someControl.ClientID, "customAttr", "customVal")
Okay, here's the problem. I am using a ListView to generate a custom control. In certain scenarios, the ListView must be refreshed/recreated. When this happens, and a ListView item attempts the register (in this case, re-register) the expando attribute, the page throws the following error:
An entry with the same key already exists.
Obviously RegisterExpandoAttribute() does not behave like the Page.Cache object where if a key already exists, the current value is overwritten. I can easily hack my way past this problem but I wonder if there is a more elegant solution to this. For example, there is no method like: Page.ClientScript.IsExpandoAttributeRegistered(...)
Any ideas?
If you're creating a custom control, try doing the RegisterExpandoAttribute call during the control PreRender. I was having issues with the attribute still being registered if the control had been removed and doing that fixed my issue. I would imagine that if you're calling RegisterExpandoAttribute in the PreRender for the control then it shouldn't be called more than once per page load.
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.
I'm looking for a way to intercept the ASP.NET processing pipeline in such a way to be able to register event handlers to all events on the Page class. The reason is, I need to maintain a session-bound instance of a component that needs to be notified of all important Page events, starting from OnPreInit.
There's an arbitrary number of Page descendants in the application, which are not under my control. Hence I cannot use an approach like using a single custom descendant, that would notify the session-bound component, as a base class for all pages in the web application.
I don't think creating a custom IHttpHandler or IHttpModule implementation would solve the problem. Also note I cannot create a custom HttpApplication descendant.
It isn't going to be an elegant process to do what you are looking at, especially if you need to handle multiple page events, but in theory it is fully possible from within the Global.asax to setup handlers that you need for each and every page.
The trick here is to add your code to the global.asax in the PreRequestHandlerExecute method, from here you can get access to the HttpApplication object, get access to the page from there, and then register your events. This process is necessary as a new page instance is created for every page that is processed.
Now, other options as you know are far more elegant, but this should get to where you need to be. One helpful tutorial I found although around Themeing shows you the whole process here.
EDIT:
After seeing your comment, yes, you can simply do what I'm stating above, in a custom HttpModule. The article I linked even shows you that process :)
Without knowing more about what you're trying to accomplish it really sounds like you do indeed want to create a http module or handler. You might want to take a look at this question
I know why runat="server" is currently required (ASP.NET why runat="server"), but the consensus is that it should not be required if you incorporate a simple default into the design (I agree of course).
Would it be possible to modify, extend, decompile and recreate, intercept or otherwise change the behavior of how ASP.NET parses ASPX and ASCX files so that runat="server" would no longer be required? For instance, I assume that a version of Mono could be branched to accomplish this goal.
In case specific requirements are helpful, the following highlights one design:
During parsing, when configured namespace tags are encountered (such as "asp"), default the element's runat property to "server"
During parsing, when configured namespace tags are encountered (such as "asp"), if the element's runat property value is available, then that value should be used in place of the default
New page-level setting introduced (can be set in the page directive or web.config) that specifies the default runat value for a specific namespace tag
I'm afraid you'd have to modify the entire page parser to accomplish this, and I don't think that's possible.
On the other hand, you should be able to create your own. See the buildProviders Element and the BuildProvider class. You should be able to create your own build provider for .aspx pages and use it to replace the built-in provider.
Unfortunately, the PageBuildProvider class used by ASP.NET is internal, and the PageParser class that it uses to parse pages is sealed. You'll be entirely on your own.
Consider that runat="server" has been in ASP.NET for a decade now, and I think you'll see that this won't change anytime soon.
You'd also lose Designer support, but maybe you don't care about that.
So far as I know, there are no hooks deep enough in the ASP.NET Page handling process that would allow this. I know of no way to override or extend the parsing or processing of actual aspx/ascx code.
While ASP.NET is fairly flexible and lets your override many default behaviors (like how ViewState is saved/loaded, where Session is stored, etc) this is not one of them.
However... technically the Page object is just another HttpHandler. You could write your handler and do anything you wanted with it. All you have to do is implement everything the Page class does and then throw in this extra functionality. :) Alternately, pull out Reflector and dig through the Page object's ProcessRequest method and see where it is actually parsing/initializing the objects declared in aspx and you might get a clue how to implement the functionality you're looking for. But I suspect you'd be wasting your time.
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.