When I'm working with DataBound controls in ASP.NET 2.0 such as a Repeater, I know the fastest way to retrieve a property of a bound object (instead of using Reflection with the Eval() function) is to cast the DataItem object to the type it is and then use that object natively, like the following:
<%#((MyType)Container.DataItem).PropertyOfMyType%>
The problem is, if this type is in a namespace (which is the case 99.99% of the time) then this single statement because a lot longer due to the fact that the ASP page has no concept of class scope so all of my types need to be fully qualified.
<%#((RootNamespace.SubNamespace1.SubNamspace2.SubNamespace3.MyType)Container.DataItem).PropertyOfMyType%>
Is there any kind of using directive or some equivalent I could place somewhere in an ASP.NET page so I don't need to use the full namespace every time?
I believe you can add something like:
<%# Import Namespace="RootNamespace.SubNamespace1" %>
At the top of the page.
What you're looking for is the #Import page directive.
Related
i have a usercontrol named filebox (which wraps a fileupload and some related stuff)
in a certain .net class i have need to use this type as a ctype
but i cant seem to call ctype(aobject,filebox)
or either ctype(aobject,Controls_filebox) (which is the correct name)
how can i convert an object to this type?
thanks a million!
You need to add the class' namespace.
It's probably in the ASP namespace; you can check in the Object Browser.
You can change the namespace by adding Class="My.Namespace.Filebox" in the <%# Control directive.
I seem to be having a lot of trouble with this.
I want to create an ASP.NET control that implements some core logic, and then I want to be able to derive several controls from that, which each implement their own specialized logic.
I started with a User Control, but I couldn't find a way to derive from it. I tried setting the Inherits attribute in the derived control but, no matter what I did, the derived control just didn't seem able to recognize the base control.
So then I tried a custom server side control by using a regular class that inherits from Control. (Note that all my rendering is done from code.) But I can't seem to find any way to get a page to recognize the control. I've tried different syntax in the #Register directive but either it tells me the src attribute is missing or it just can't find the control. (Note that I prefer not to create a separate assembly if I don't have to.) I have no idea what to put as the assembly if the control is from the current assembly.
Can anyone make suggestions on this? Any examples that would work for my configuration, or perhaps a different approach entirely?
Note that I am not currently using page/control code-behind. All my page scripting is stored in the same file as my markup.
In fact, despite various error messages about missing attributes in the #Register directive, I found it works just fine if I reduce the number of attributes in this directive to just tagprefix and namespace.
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.
Although the classic ASP method of server-side includes works in ASP.NET, I get the impression it is not the preferred method. How am I "supposed" to be achieving the same effect?
This is how I'm doing it at the moment:
<!-- #include file ="functionlib.aspx" -->
You now have a number of options that provide this effect, but in a different manner.
User Controls (.ascx)
Master Pages (.master)
Server Side Controls (.dll)
Class Libraries (.dll)
App_Code Classes (.cs/.vb)
Each are used for differently to achieve different things. It depends what you're really trying to do. Given the name of your include file, I'd imagine you're trying to include library functions that will be used within the context of your page.
Consequently you'd write a class library that contains the methods and import them into your application/aspx.
If you're looking at templating a page that will do most of the layout work to provide a body for differing content then you'll be interested in Master Pages.
If you're looking at templating controls that can be used in many pages, then you're going to be after User Controls.
If you're looking at templating controls that can be used by many users across many projects, then you'll be looking at Server Side Controls.
If you're looking at a library of classes/methods then you'll develop a class library or use an app_code class which can be JIT compiled the first time it's called. This could at a stretch be considered more like classic ASP, but really it functions more like a class from a class library as a single unit. You can call it from within your codebehind or within <% %> tags in your aspx/ascx code without requiring a reference to a class library.
We don't really use "includes" per se any more, but each of these tools in your toolkit allow you to provide similar concepts for different scenarios. As a developer you will interact with the entire page lifecycle of your web pages differently. ASP.NET is a very different beast than classic ASP. It truly takes a different view/approach and will take some amount of patience to figure out the differences.
How about <% Response.WriteFile("myFile.aspx"); %>?
See: https://support.microsoft.com/en-us/help/306575/how-to-dynamically-include-files-in-asp-net
If you'e using ASP.NET MVC then Html.RenderPartial is your friend here.
http://msdn.microsoft.com/en-us/library/system.web.mvc.html.renderpartialextensions.renderpartial.aspx
A partial view can be implemented as a .ascx or an .aspx and putting the above call in your "primary" page basically says "get the output from this partial view and render it here".
Parial views can make use of the ViewData that your primary view received from the controller.
Sounds like what you need to be looking at is the entire concept of MasterPages.
Unless you are looking at just importing functions and other utilities (not html content). If that is the case (and you are using the code-behind model), you should just be able to include the appropriate file or namespace using the imports command at the top of your .vb page (adjust accordingly for C#).
I'm having some trouble trying to inherit a control that uses an embedded resource.
the trouble is - this control uses me.GetType() instead of GetType(ControlName).
now when I try to use the derived control, it looks for the resources in the derived control's assembly, instead of the base control assembly, and obviously - doesn't find them.
how can I fix this?
Since the call is in the base control's definition, there isn't much you can do if you can't override the method where its called; you could duplicate the resource file if possible, or try to override that method where the resource is being called. It's hard when you don't have control over the base class.
It's also hard to advise when I don't know what the code looks like; if you could post the signature of the part of the class in question and refer to this in your question, that would help.
HTH.