I desperately want to use server-side includes in a project I'm working on because I just have some HTML that repeats and I need to get it on several pages. Must I use ascx or some other include technology... I mean, will lightning strike if I use server-side includes?
My client -- the middle-person -- says "do what's easiest, this will probably be redone in a CMS soon anyway." Can I not use server-side includes?
It's ASP.NET 2.0.
Note: I feel this has been asked before, but I couldn't find it. If it has, please let me know and I will personally delete it, thanks!
Edit: Any way to get an include ON ONE LINE would be fine with me, if you have suggestions.
Edit: Why do I like includes?
Include code:
!--#include file="inc_footer.aspx"-->
the same code for a control. First you need one of these
<%# Register TagPrefix="a" TagName="HeyFooter" Src="inc_footer.ascx" %>
and then you can use it like this
<a:HeyFooter runat="server" />
this is kind of long for what I need.
Note Two security concerns with includes: 1) don't use the .inc extension, since it can be browsed. 2) do not include filenames based on user variables, as the best answer points o ut.
If you include a file via a string variable: <!--#include file=some_variable -->, then depending on how that variable is filled there are possible attacks a hacker could do to include his own files and run arbitrary code on your machine. But as long as you use a string literal, you won't run into this problem.
I would use Master Pages in ASP.NET. This is the accepted way to have common areas of a page.
You would create a Master Page similarly as you would regular pages, then modification of each of the other pages would be minimal. Add a single line to the top of each page file, then specify the sections used.
No, you most definitely do not need to use fancy .NET web form ways of doing this, if you want to keep it simple. Just put this at the points where you want it inserted:
<!--#include virtual="../repeatStuff/fun.html" -->
The html will show up there. I gave a path one up and down another directory. This is "easiest", but also has the virtue of being very straightforward. Note that this won't show up in your visual designer. (I never use it anyway.)
I still use includes every once in awhile for exactly the purpose you describe.
You don't really need to register a user control because it's just plain html anyway. And you don't want a master page because it's really just a snippet of html that needs to be on a few select pages.
So I've got includes like this from a glossary of help text files:
<!--#include file="~/Glossary/BusinessDetails.inc"-->
In my opinion there's nothing wrong with using old school include files for this purpose.
Related
I developed a (small) company website in Visual Studio, and I'm addicted to learning more. I really just have two simple questions that I can't google.
1 - Asp:hyperlinks:
What is the purpose of an asp.hyperlink? I know I can't use these in my resource files -- I have to convert 'em all back to html links. At first, asp:hyperlinks looked sophisticated, so I made all my links asp:hyperlinks. Now I'm reverting back. What's the purpose of an asp:hyperlink, if any?
2 - Resource Files and strings:
In localizing my website, I have found that I'm putting the .master resource files in the directory's App_LocalResources folder VS created, because you can't change the top line stuff in a .master file and put a culture/uiculture in there. But all of my regular .aspx pages are going into the root App_GlobalResources folder into 1 of 4 language resource files (de, es-mx, fr, en). I'm making 2 or 3 strings per .aspx page. So when you have 47 pages in your website, that's about 100 strings on a resource page.
I just learned about all of the resources stuff from this forum and MSDN tutorials, so I have to ask, 'cause it's a lot of work. Is this okay? Is it normal? Am I going about this the wrong way?
I've never used resources, so can't comment on that.
Differences between asp:hyperlink and a tag that I know of:
asp:hyperlink is converted to an A tag by the ASP.NET engine when output to the browser.
It is possible asp:hyperlink could make browser specific adjustments, to overcome browser bugs/etc.. which is kind of the point of ASP.NET, or at least one of them. If not already in it, they could be added later, and by using those objects you'll get that when/if added.
Both can be used in code behind (you can set runat="server" for an A tag), but the asp:hyperlink has better compile-time checking in most cases -- strong type-casting for more items vs generic objects.
asp:hyperlinks are easier to get HTML bloat, but only if used with a poor design. For example, it is easy to set font styles and colors on them.. but I wouldn't, since that generates in-line styles that are usually pretty bloated compared to what you would do by hand or in a CSS file.
asp:hyperlinks support the "~/Folder/File.ext" syntax for the TargetUrl (href), which is nice in some projects if you use a lot of different URLs and sub-folders and want the server to handle mapping in a "smart" way.
The purpose of is to display a link to another webpage.
With the resource files, since you're not a programmer and just developing a small program, use something you're comfortable with. Resource files are easy to use for beginners when you want to localize your web content -- and yes, it's normal to be adding many strings if you need them.
For #1
Using a hyperlink control over just a piece of text will allow you to access the control at runtime and manipulate its contents if you want to change the link dynamically, if you have static links that will never change then its simpler to just use plain text ie. <a href=''>
I'm noticing code accumulating in my project that looks like this:
Response.Redirect("/Foo/Bar.aspx");
This seems brittle -- if I move or rename Bar.aspx file, I need to find places where I've referenced it and correct those string constants, both in markup and codebehind. It seems like their should be a better way. Something like:
Response.Redirect( MyNamespace.BarPage.GetUrl() );
In other words, let the 'stack' figure out the URL I need. Note: I know that I can consolidate references to a particular page with a hand-coded BarPage.GetUrl() method, but even that seems failure-prone.
Isn't there a better way?
The best way would be to resource them. Add a meaningful key and the URL value to the resource file, and redirect that way.
Response.Redirect(Properties.ASPXUrls.FooBar);
The problem you'll face is that there's no real inherent link between a code-behind and it's code-infront except the <%#Page %> directive. There's no real reason a codebehind has to even have the same class name as the code-infront's file name, it only happens because it's convention and it's how the auto-generator lays it out.
This means you're not going to find anything you can reference at compile-time that even knows what aspx the .cs links to. The closest thing you'll find is the typeof(MyNamespace.BarPage).FullName which will give you the code-behind's name and by assuming things follow convention you could (but I don't recommend) construct the URL for the code infront page it's associated with.
Personally I think you're better off just doing a find-all for "barPage.aspx" when you rename it and doing a little refactoring. You'll have to deal with hyperlinks in the code-infront anyway. If barPage.aspx represents some abstract concept (Like "The login page") it may help to add a property for it, but if barpage is just another page with no real globally inherent meaning I'd leave it as-is.
I'd recommend creating a static class with different properties for each of the links. That way, you only have one place to update.
Redirects in general are fragile, no matter how you get the name of the next page. They are also a performance problem.
If you find them collecting in your system, the first question you should really ask is why: excessive redirects are almost always a sign of an architectural problem.
i have a current asp website that i need to keep in sync but it has stuff like this:
<!--#include file="inc_search_form.asp" -->
i can't change this file at all as it exists in another asp website so i can't break that compatibility..
is there anyway i can just shove this same file into my asp website and have it work the same?
There is an assumption here that the other asp website may want to change the content of this asp file and you would want such changes reflected in your new website. If that isn't the case you would simply create ASP.NET version of this content in your new webstie.
There isn't really enough info in your question for a good answer to you specific scenario.
To the general scenario the answer is a flat no.
However there may be some mitigation depending on what the include actually does. For example it may be possible simply read the ASP file in ASP.NET perhaps do some text based tweaking and include the final HTML content in your ASP.NET pages output. This approach though is very fragile if the include is subject to change (if not see first paragraph in this answer).
Another mitigation might be if the include file can generate the desired content when requested directly, in this case you may get away with making HttpWebRequest looping back to this ASP page whilst processing the ASP.NET page. Ugly and again fragile but possible.
To what extent does the include file depend on the includer to have created a context for it? For example does the include file use variables that it expects the includer to have created? In which case the answer is no.
Does the include expect to be placed in a specific part of an overal HTML page, does it contain inline Javascript and does it attempt to interact with other parts of the containing page? Loop back HttpWebRequest might work in this case.
The most likely answer is no. Even if the answer is yes what ever the solution it will be fragile. Personally I just wouldn't even attempt it despite any perceived benefits. In the long run maintaining a ASP.NET version of this content in parallel with the existing ASP version in the other site is much more tenable.
I have a ASP.NET file at
http://localhost/nn/n.aspx
Output from processing that file is included in
http://localhost/index.asp.
Is there some general or specific things I should do so that the ASP.NET code sitting on the client knows were it is?
Setting <form action="http://localhost/nn/n.aspx
makes it post to the right location, but my update-panel is failing.
I think perhaps that's the ScriptPath of the ScriptManager, and i can probably figure that out.
But I am afraid there could be other issues, and i am hoping there is something like the HTML tag that i can use to tell my client code where it is.
Thanks
Olav
A). What exactly does "..Output from processing that file is included in.." mean?
B). <base> tags are evil html-smells which cause more problems than they solve and are the symptom of a failed architecture
C). What do you mean by HTML page? There's no way a normal HTML page can include .aspx content, HTML is not a server side language. Certainly there are ways and means, but you need to be specific.
D). you need to give us some more idea about your code and site architecture, there's not enough info here to work this out "my update-panel is failing" is very vague indeed. How is it failing?
Are you looking to create a server-side control? You don't include "output from processing" one ASPX file in another one. Instead, you create an ASCX file - a server side control and then incorporate that in the target ASPX file.
It is easy to do and may well be what you are looking for. However, your question is quite ambiguous so I cannot tell for sure!
One thing that's really been making life difficult in getting up to speed on the codebase on an ASP classic project is that the include file situation is kind of a mess. I sometimes find the function I was looking for being included in an include file that is totally unrelated. Does anyone have any advice on how to refactor this such that one can more easily tell where a function is if they need to find it?
EDIT: One thing I forgot to ask: does vbscript have any kind of mechanism for preventing a file from being included twice? Sorta like #ifndef's from C?
There are a few basic things you can do when taking over a classic ASP application, but you will probably end up regretting doing them.
Eliminate duplicate include files. Every classic ASP app I've ever seen has had 5 "login.asp" pages and 7 "datepicker.js" files and so forth. Hunt down and remove all the duplicates, and then change references in the rest of the app as necessary. Be careful to do a diff check on each file as you remove it - often the duplicated files have slight differences because the original author copied it and then changed just the copy. This is a great thing for Evolution, but not so much for code.
Create a rational folder structure and move all the files into it. This one is obvious, but it's the one you will most regret doing. Whether the links in the application are relative or absolute, you'll have to change most of them.
Combine all of your include files into one big file. You can then re-order all the functions logically and break them up into separate, sensibly-named files. You'll then have to go through the app page by page and figure out what the include statements on each page need to be (or stick with the one file, and just include it on every page - I can't remember whether or not that's a good idea in ASP). I can't comprehend the pain level involved here, and that's assuming that the existing include files don't make heavy use of same-named globals.
I wouldn't do any of this. To paraphrase Steve Yegge (I think), "there's nothing wrong with a classic ASP application that can't be fixed with a total rewrite". I'm very serious about this - I don't think there's a bigger waste of a programmer's time in this world than maintaining an ASP app, and the problem just gets worse as ASP gets more and more out of date.
#MusiGenisis bullet point list is good advice to follow but I'd disagree with -
"I wouldn't do any of this. To paraphrase Steve Yegge (I think), "there's nothing wrong with a classic ASP application that can't be fixed with a total rewrite". I'm very serious about this - I don't think there's a bigger waste of a programmer's time in this world than maintaining an ASP app, and the problem just gets worse as ASP gets more and more out of date."
All very well, but if it's a sizable legacy app doing complete re-writes is often not possible due to a lack of developer time/resource.
We have a fairly large classic ASP app which has grown arms and legs over the years, it's not pretty but it does serve the business needs. We have no time to spend the next six months doing a complete re-write, it would be nice, but just not possible. Our approach is -
Where there's new functionality required, it's implemented in ASP.NET. This happens 95% of the time. The 5% edge cases usually being that there are a large number of points where the new app code touches the old app requiring us to do a lot of classic ASP re-work potentially making the app more fragile.
Where there's a change in functionality we assess whether we can refactor to ASP.NET with minimal impact. If this isn't possible then we'll implement the change in classic ASP and tidy up existing code as we go along e.g. simplifying include file nesting, replacing javascript with more cross browser friendly code, that kinda thing.
In answer to your question about #ifndef's, there isn't an equivalent I'm afraid.
Use one file to global headings and includes (lets name it t-head.asp). This file is included in all asp files.
Use one file to make the site visual global header (logos, menus, etc) and include it right behind . Let call it t-begin.asp
Use one file to make the site visual global footer (copyright, google analytics, etc.) and closing all divs or tables opened in t-begin.asp. Lets call this file t-end.asp
Use one folder to put the business logic files, called BUS. The files in this folder can not have includes. Every function inside the file must be preceded by the name of the logic unit (IE: all function in products.asp must begin with product_*)
Use one folder to put some reused UI code called UI. The files in this folder can not have includes.
Example:
<%# Language=VBScript %>
<% Option Explicit %>
<% Response.Buffer = true%>
<html>
<head>
<!--#include file="../general/t-head.asp"-->
<!--#include file="../bus/product.asp"-->
<title>Products page</title>
</head>
<body>
<!--#include file="../general/t-begin.asp"-->
<% 'all your code %>
<!--#include file="../general/t-end.asp"-->
</body>
</html>
Wow. It constantly surprises me how many people have a hate for ASP. In decent hands it's a perfectly capable language for designing web applications.
However, I will concede that the way include files are managed in ASP can be a bit of a brainache -- because (depending on how you use them) they have to be loaded and parsed even if you're not using half the functions contained within.
I tend to have one include file (initialise.asp or some such) that itself includes links to several functions libraries (lib_http.asp, lib_mssql.asp or similar) and all library functions are self-contained so there is no worry about crossing variables. Any global vars are declared and set in the master file. This means I can use a function anywhere, any time and not worry about where it was defined, it's just there for use. And IDEs such as Visual Studio and Primalscript have the ability to "jump to definition" when you find a call to a function that you don't recognise.
Then, any script-specific includes are included in the script after the call to this master include file.
I concede that this is a memory-hungry approach as all the functions in all the libraries are compiled for every script call, so the method needs refining for each site you develop -- decide what to call via the master include and what is more page-specific. It would be nice to be able to only load what you need -- but that's the DLL approach and is not available for the majority of real-world developments, and also you'd have to weigh up the processor cost of compiling small scripts vs loading components.
A concise directory structure is requisite and easily developed, but it can be a chore to wade through all the code in an existing site and change any links or mappath calls. Also, be aware that some IIS administrators disallow the '..\' method of traversing directories via VBScript, so then all file references have to be absolute paths.
i think you should consider moving your code from ASP VBScript to Visual Basic COM DLLs. that'll ease on you having too much includes.
I don't know of a way to prevent a double inclusion, other than getting an error message that is. Are you seeing includes placed throughout the page, which is making them difficult to spot?
Just as an aside, are you working with a copy of the code and the database on a development server? From my experience, the first thing to do is separate yourself from the live site ASAP. While a hassle initially, it'll give you the freedom to make changes without messing up the live site. It's easy to make that one tiny change in an include and BAM! the whole site goes down.
I've worked through a few projects like you've described and used the following strategies:
Complete rewrite - perfect when there's time/money, but usually I get the call when something has gone wrong and results are needed ASAP.
Smaller projects - I open up everything in the IDE and just start searching all the project files for the functions/sub, in order to build a knowledge of the include logic. Pretty much each time, everything is spread out everywhere, so I start rebuilding the includes organized by business logic. I've also run across inline code (raw code, not subs or functions) thrown into an include, so I'll usually just pull the code back into the page for refactoring later.
Larger projects - I'll use some code I have laying around to parse the includes for lines with sub/function headers and dump those to a text file to build up a list of what routines are where and refer to that. This comes in handy when you've got a ton of includes on each page and can't get your head around the codebase.