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.
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 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.
We are working on an ASP.NET CMS project using jQuery as the basis for our client side scripting.
The jquery-1.2.6.js file is the only script file that is always included. Other script files are currently included depending on what components the CMS editor is using on a page or page template.
A lot of the script combiners produce a static script. If we took that approach we would have to add all possible script files in just in case they were needed. We are not currently using any of the ASP.NET Ajax extensions so have not looked at what that may give us.
Anyone got any suggestions?
I have read Combining and Caching multiple JavaScript files in ASP.net but I don't think that covers off the conditional nature of our situation
So great I can use ScriptManagerProxies and some methods on the base master Page. However there is one other thing. Stopping all the ASP.NEt Ajax guff being sent down to the client. I am going to take a look at bleroy's hack until ASP.NEt 4.0 releases
TIA
Pat Long
Working in Sitecore on a site that had multiple scripts for different pages, we created a list of script items in Sitecore, then added a Multlilist field to the Items. We had a placeholder in the head of the master page, and dynamically added the scripts as they appeared in the multilist field. We did the same thing with CSS as well. It worked out nicely. (Specifically, it was on http://www.utulsa.edu)
Edit: I misunderstood what you originally meant. It seems like you may need combine and produce all the possible static scripts you need, then dynamically include the one you are looking for, if you're looking for only one script include per page.
Otherwise, you could just depend on caching to keep your script requests down, and do what you are currently doing
Edit 2: A third thought is you could write your own combiner that will combine scripts on demand, and include the generated (or pre-generated) script
I don't know if this will help you or not, but Scott Hanselman posted on twitter that you could download issues of MSDN Magazine for free. I followed the link and looked through a couple of issues and this month (Feb, 2010), and one of the first articles discusses predictive fetching with jQuery and ASP.NET Ajax.
This looks like it could be along the lines of what you're looking for. As far as stopping the AJAX requests, I haven't read the entire article, but I'd assume it mentions something in there (as predictive fetch would have to account for this).
you must have seen widgets like code which people place inside their HTML and it starts showing a small widget in there, how we can we do it in ASP.net, for example if i want to show some specific data of my site to anywhere some specific code is placed, how can i generate that embeddable code that can start showing my specific block of data to anywhere from any site?
Here are a few methods used by various people to embed a snippet of content on an external website.
1) An iframe!
iframe's can be a right old pest, but are quite good at displaying a bit of external content. They have been added back into the HTML standards in the HTML 5 draft specification, so you should get futureproof support for them in the future.
<iframe src="http://www.widget-address.com/Widgets/SomeWidget/" title="Some Widget"></iframe>
You can style your iframe (give it a width and height) and all that jazz.
2) External Image
This is largely used by advertising engines. You pop an image on the page and the image is dynamically created to display some advert - each time it appears it is different. This isn't great if you want information to be screen-readable (i.e. accessible).
<img src="http://www.widget-addrees.com/Widgets/SomeWidget.jpg" alt="Some Widget">
3) Server Side API
You could make an API available so people can call a "service" on your site that supplies them with the information for the widget. For example, their ASP.NET code or PHP code (or whatever language) calls http://www.widget-address.com/Widgets/WidgetService/ and it returns some data that they can format and display on their page. This would give you the benefit of inline HTML, which is the most accessible and valid way of displaying the data.
There are lots of other methods, so if you don't fancy one of these, I'm sure more suggestions will flood in - including (be careful...) JavaScript / AJAX.
I'm not quite sure I understand the question, so I'm sorry if I'm way off here. But I guess you are using the webforms framework for asp.net? If you are there is something called server controls. Those can be used to create widgets like calenders for example (that is already included in the framework, so no need to build it again).
If you are looking for code block, similar to <?php [[code]] ?> in php (if you have used that), then the answer is <% %>. Those are code blocks in the .net world. If you want to write something out you use Response.Write("string to write"); inside the code block. Or you can use the faster way: <%="string to write"%> that will render the same think (string to write).
If you are using the webforms framework you can also take advantage of the built in server controls in the framework. You can read more about the framework here or simply google asp.net webforms.
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.