I am using the AJAX Control Toolkit in an ASP.NET web site. I would like to change the names used to refer to the toolkit's classes according to my project's conventions, both in the Controls pane and in the markup itself.
Maybe something like:
<%# Register ?something? TagPrefix="MyControls" %>
For instance, I'd like to rename the AutoCompleteExtender class as SelectTextBox in the code, so I can use it like this:
<MyControls:SelectTextBox ID="sss" runat="server" ColumnList="aaa"
ColumnType="0" ColumnWidth="300" DataField="aaa"
DetailedSearch="1" FillQuery="SELECT XXX" ValueField="EmployeeID" />
Is it at all possible?
I was curious about your question (that's why I edited it in the first place), so I looked around, and I'm afraid I'm not coming back with good news.
Although facilities like type aliases do exist in C#, they will only affect the modules where the using directives are in effect, and will not propagate to the ASP.NET markup AFAICT (let alone to the Controls pane).
Barring extending Visual Studio itself, your best bet may actually be to derive your own classes from the ones in the toolkit, use these in your code, and create a custom Controls pane section out of them. That way, naming will be consistent everywhere in your environment.
On a more positive note, maybe someday you will want your SelectTextBox control to do something more than a plain AutoCompleteExtender, and then you will have the derived class already there waiting for you.
Related
It seems rather convenient. I was wondering if there was a good reason to load one of the RegisterScript methods.
The RegisterScript methods can be used without placing any markup in the page, and without knowing the specific type of the page. Also, you can add the same script more than once, and it will only be included once in the page.
This is convenient when you want to include script from a user control, as you then can use the control in different pages, and more than once in the same page.
Maybe I'm wrong, but I don't recall RegisterScript methods working on pages without a <form runat="server">...</form>. That bit me once. In those cases, using literals or placeholders is not a particularly bad option. The other options I can think of is to make sure the head tag (or some other useful tag) has runat="server" and then dynamically add to it.
Depends on what you are trying to achieve. Do you really need to generate the javascript dynamically? You could just create a separate js file and reuse that.
As with the RegisterScript methods you can control where you want to place the javascript. For example with RegisterStartupScript, it registers your script at the end of the page (helps perceived performance and ensure that all objects have been loaded)
If you use literal controls, you might have to remember to but it at the end or top of page.
I have an issue where I have two pages that deal with very similar things and as such quite a few of their methods and aspx server controls have identical method names and variables. In short, it's pretty obvious that the code was copy/pasted and the innards were merely altered. I have a pending request that the two pages be merged so I've explored a number of options as to how I should best merge them.
First I thought that perhaps I could put one of the pages in a masterpage that will allow for a content place holder wherein I'd then put the code/controls, but it looked to be a bad idea once I started to make plans. For one the similar names would probably still be a problem and second it seems a rather clunky way to merge two pages together.
I've considered renaming all the methods and controls but on the other hand it's going to take a lot of time picking over the code and the controls to rename them all. My worry is that if I try to change the problematic method names, controls, IDs, I'll introduce a lot of bugs in the code.
Is there a better way to view two pages in one webpage?
You can do so with iFrames. But I think the website gets better maintaining with .net controls (.ascx files), and then calling them in a new page
That thing is called user control.
UserControl class
read this official tutorial
I think there can be 3 options that will work for you:
1. Put all common stuff in a user control and use it in both pages. This is the most straight forward solution and this is the main reason user controls exist - reuse of both UI and code behind. This is most likely the best option.
2. Have a utility class that will contain all common methods. The disadvantage of this solution is that you will only share code, not UI.
3. You can have a BasePage that inherits from Page, and have both pages inherit from BasePage. Again, you will shared only the code, not the UI. This is usually a good solution when you want to add some functionality for all your web pages.
If it is for ASP.Net Web Forms have you checked out Nested Master Pages, not merely a single MastPage?
If you have a common Theme or layout this goes in the Base MasterPage, your nested MasterPage then exposes common UI controls, Events Handlers etc that are common between the next group of Pages (the layer you referred to), your final ASPX Page then exposes the individual page functionality that is different between the ASPX Pages, UI controls, Events etc for each unique page.
By using the # MasterType page declaration you ASPX Page has a strongly typed reference to one or all MasterPages which would allow the ASPX page to easily access methods and properties of the common MasterPage.
I have a site that gets deployed to over a dozen clients. The main website has a base template, and each client has a client folder that overrides the colours. The problem is that there are a lot of CSS files, so making a change that forces us to update every client takes a long time. The automated build process takes care of replacing the updated files.
I would like to change the CSS files to be usercontrols instead, and those usercontrols could then inherit from another usercontrol where client specific values are stored.
So instead of having a forms.css file and then a /client/forms.css file I would have a Forms.ascx file that inherits from a usercontrol that contains the colours.
Ex:
<%# Control Language="C#" ClassName="Forms" %>
<%# Register TagPrefix="css" TagName="Client" Src="~/css/ClientStyling.ascx" %>
/* CSS Document */
body
{
color:<%=Client.BodyColor%>
}
Then the masterpage would inherit from the usercontrol instead. This would make the maintenance of the client sites much easier.
So is this solution efficient and recommended? Or is there a better way to accomplish the same end result?
If this is possible, would it also be possible to have the Forms.ascx control output the markup as CSS? Or make the extension .css and still have the ascx properties?
Instead of a Web Control, you're likely better off creating a Generic Handler. This won't have the overhead that a web control has.
In your handler, accept the clientID via querystring - this allows you to cache on a client level
In your .master file, you can link to it < link src="MyCssHandler.ashx?ClientID=<%=ClientID%>" >
In your handler you have a few ways to work with the CSS.
Just have a bunch of response.write for the css, and put in relevant client values
Create an external CSS file with it's own special identifier - maybe <% %>. You could then load all the client specific values in a NameValuePair Collection, and then loop through the external CSS file, parsing <% NAME %> and replacing with the correct value. Then response.write this file. More complicated true but it allows for a hell of a lot cleaner CSS files
Another option to consider may just be to use a "CSS compiler" -- such as SASS, LESS or even HSS which may support handy constructs like "mixins" and including other files. This approach may allow a system that, while not dynamic, is easily configurable to your different client's needs.
For instance, with a "CSS compiler" the entire color schema could be stored in a single file as exportable variables or templates (depends on "compiler") -- modify that file, "recompile"** and wham, new color-scheme interface is everywhere (SASS also supports math on colors -- such as Hue shifting). This may make the deployment/management of using static content feasible enough for your purposes.
I use SASS (it fit my needs/style whereas LESS/HSS did not). I would not switch back unless I really, really had to (which is to say: uhh, never) -- SASS in SCSS mode also understands CSS syntax so you can micro-evolve or mix and match (LESS and HSS also work like this, but HSS only works with a stricter subset of CSS syntax). CSS compilers can also be used in conjunction templates engines (such as TT4) or take advantage of including dynamically generated files (not dynamic-dynamic as in the question, but dynamic in the sense that they come from some other data-source) if extra power is needed.
While just normal CSS cascading and class names/selectors can go a long ways, I find it much easier to separate the "logical cascade" (CSS, where CSS/cascading is vital) and "geeze, I wish this worked like a template" (CSS compiler, which should handle cases where CSS/cascading is abused).
** Both SASS and LESS can monitor files and recompile them automatically for you. SASS even allows monitoring entire directories
Write it out as a file and let the browser pick it up as it would any other CSS file.
Making inline stylesheets prevents the client cache mechanism, forcing your CSS to be served up with every page.
This is entirely possible. You might want to consider cascading your stylesheets too, so that the dynamic one imports a (presumably larger) static one.
Asp.NET has support for themes, too, but to be honest CSS is much more powerful.
Why are you thinking ASCX instead of ASPX though? I'd have thought that since one css file represents an entire response, it could all fit in a page.
an ashx is probably the lightest, fastest form of handler you can implement, so you might want to look at that...
Oh and make sure you get your caching parameters right!
Is there a c# command to include another web page - the equivelant of the php require?
I know how to do server side includes but was looking for something code based.
Thanks
Thanks for the answers all. I think I might need to explain further. I have several sub-pages that I will be loading during the use of the site using an xmlhttp request. Initially however, I need to load the starting sub-page before the user has interacted with the site. I could do this with js, but that would require more overhead in server calls from the client for the initial load. I already use master pages, but this is a little different. Since this is done serverside initally but must remain able to be refreshed clientside, I don't think I can make these pages into controls can I? I am pretty new to .Net so I may be making my life harder than I need to.
I think what you may be looking for are MasterPages and UserControls. A MasterPage allows you to define a basic template that is "filled in" by the implementing pages by having the implementing page add it's own content to the ContentPlaceHolders defined on the MasterPage. A UserControl is a re-usable piece of markup and associated code that you can reference from your mark up or add dynamically to the page being rendered in codebehind.
The way ASP.NET is structured, you shouldn't really need to do this. Code is compiled, so all of your classes and functions should be accessible simply by referencing the relevant assembly or namespace, without having to include individual code files.
You might be looking for user controls, which allow you to create fragments of markup with their corresponding code behind, and then reference these in your page.
With ASP.NET MVC it looks like this:
<% Html.RenderPartial("LogOnUserControl"); %>
This way you can put another UserControl on your page.
you can use include in asp.net like php include from below mentioned code
<!--#include file="include/leftmenuscript.inc"-->
You can also use a master page, as someone stated below, which flushes out your basic layout and lets you define content place holders, which other pages can implement and fill in the content. Master pages are a popular approach for defining page elements that are consistent across all pages, like your nav there (also things like headers, footers, common scripts, CSS, etc.).
I have created a webpart in c# for sharepoint.
its basically a form with text boxes, literals, validators and buttons.
im not sure how to render this form to make it look pretty.
The layout etc is being done entirely within this c# class.
At the moment to get started im just overrinding CreateChildControls() method
and adding each form control using something like: this.Controls.Add(submitButton);
any ideas on how best to layout this form?
Thanks.
When creating custom webparts I also prefer to implement them by overriding the CreateChildControls() and Render() methods. In the Render() method I have full control of the html output and I can render my inner controls by calling this.someInnerControl.RenderControl(writer).
Having full control of the html output also makes it easy to style the html using CSS. As other people suggests, use an external CSS file and apply the styes to the class attribute on html elements or CssClass property on ASP.NET web control.
When I implement webparts, that does not require special branding, I prefer to reuse the CSS classes defined by SharePoint. This will ensure that my webpart is visually similar to the webpart provided by SharePoint and that I keep a consistent look and feel.
When using the SharePoint defined CSS styles, you should be aware of your html output. Some of the CSS classes requires a specific html structure to properly render. You can always use the browsers "View Source" to check the html of the SharePoint element you are trying to imitate.
I would recommend grabbing the source from an existing sharepoint page and using the styles defined by sharepoint. This link to the styles in 2003 is old, but still a good guide to get started. Most of the CSS class names haven't changed.
In my web parts I include css files in the solution and inject them in the page using something like:
this.Page.Header.RegisterCss("/_layouts/path/to/css/file.css", false);
You can override the RenderContents(...) method to manually render the HTML in anyway you want to. This includes adding any css includes, scripting includes, etc. that you want/use.
You can render your child controls to strings and then output them as well, but you probably should NOT call the base.RenderContents(...) method.
Just make sure you don't forget to render your child controls.
If it's important for you to see as you design, use the SmartPart which embeds a user control in a web part. (In case you didn't know, user controls can be designed using the tools within Visual Studio.)
If you prefer to hand-code, then you're on the right track. Simply create and set initial properties for your controls within the CreateChildControls() method and use this.Controls.Add() as you have been.
In both cases, where possible use the CssClass property so you can tinker with the look and feel in a CSS file without having to recompile. You could hard-code the CSS class names but it would be better to use the web part properties or an external config source to store these. Have a reference to the CSS file in your master page or inject it into the page using the other techniques mentioned in this answer.
The MSDN articles Web Parts in Windows SharePoint Services or Creating a Basic Web Part might also help.