Is there any way to use ASP or ASP.NET to use an include of a HTML in another HTML file? Similar to the way that you can use an include with PHP with HTML and the AddType handler in .htacess?
I am trying to find a better way to update some navigation but the site sits on a windows server that doesn't have PHP installed on it.
There are a number of options available for you to use the first one I would mention is Master Pages if you going to use asp.net.
ASP.NET MVC uses layouts with the Razor view engine so you can control the page a bit more, I really like the MVC way of doing things as it keeps things simple in terms of your functionality and presentation.
Another option is the server side include (this is old fashioned and not really good):
<!-- #INCLUDE FILE="includeMe.html" -->
If you wanted to keep it as an html page you could 'hack' around in IIS to make html pages work with SSI but it is not a very good way of doing things.
Another way of providing information is by using jQuery to include snippets of html for your page to use, something like this, (sorry I haven't tested):
$("#destination-container").load("sourcepage.htm #content-in-this-page");
Again this is probably not the best way of doing things but you can use it for quick results.
My advice is to create a main page, whether it be a master page or a variation of one if you decide to go the MVC route then use PartialViews or something similar.
And of course look at the link Alex K provided: ASP.NET equivalent of server side includes
If the parent/containing code file has a .asp extension then you can use the following code to include another file.
<!-- #INCLUDE FILE="myfile.htm" -->
Related
I have been tasked with creating a small website using SharePoint 2010 Site Pages via SharePoint Designer. I am bringing over my favorite html template, which loads and runs as expected (mostly), but I quickly ran into the following problem.
I typically use PHP to inject certain data into my page by reading directly from a local file. I have no experience with ASP, which appears to be the only method to accomplish this. I have searched the docs and so many sites but haven't found a clear-cut way to do this, and now my head is spinning. Can anyone help me with a simple process for reading a file into the middle of my html file as it gets served?
For example:
<html>
<body>
Here's my title
<inject file contents here>
Here's my footer
</body>
</html>
Thanks all, any help will be much appreciated!
You cannot do this out of the box. You will have to create a customised solution to do this, by implementing a custom controls for instance.
When you start using Sharepoint you need to change your mindset about whatever you used before. Believe me you don't want to pick a fight with Sharepoint, because the beast will win.
back to your problem I think you should be looking at Reusable Content.
Here is a description about it:
http://en.share-gate.com/blog/sharepoint-reusable-content-a-forgotten-beauty
Basically you have a list where you manage all your reusable content bits (sort of like your files).
And then in the Rich text editor for the page content you can then insert a snippet that inject your reusable content.
if the content changes all the places you are using the reusable content bits will also change.
So this behaviour is pretty much the same you get if using a file. Except it's the SharePoint Way.
Good luck
I'm trying to figure out which would be the best way to go about serving asp classic pages in different languages. Some of the content on the page is generated server-side and some is hard-coded html. I would like to create a drop-down to select between different languages so that the server-side generated html as well as the hard-coded page content changes.
Thanks!
You have some options:
Place all localizable content into database and get them as you need:
<%= GetLiteral("Disclaimer", Session("language")) %>
Load a Scripting.Dictionary in global.asa with all localizable content and place it within an Application variable (beware)
To create a folder for each language (and use SSI #includes for common stuff, like layout)
From this set, first option is your best shot.
If you're starting a new application, I suggest you to look for an alternative platform, like ASP.NET.
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.
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.
I wonder what the best practice for this scenario is:
I have a Sharepoint Site (MOSS2007) with an ASPX Page on it. However, I cannot use any inline source and stuff like Event handlers do not work, because Sharepoint does not allow Server Side Script on ASPX Pages per default.
Two solutions:
Change the PageParserPath in web.config as per this site
<PageParserPaths>
<PageParserPath VirtualPath="/pages/test.aspx"
CompilationMode="Always" AllowServerSideScript="true" />
</PageParserPaths>
Create all the controls and Wire them up to Events in the .CS File, thus completely eliminating some of the benefits of ASP.net
I wonder, what the best practice would be? Number one looks like it's the correct choice, but changing the web.config is something I want to use sparingly whenever possible.
So in that case I would wrap it up in a feature and deploy it via a solution. This way I think you will avoid the issue you are seeing. This is especially useful if you plan to use this functionality within other sites too.
You can also embed web parts directly in the page, much like you do a WebControl, thereby avoiding any gallery clutter.
What does the ASPX page do? What functionality does it add? How are you adding the page into the site? By the looks of it this is just a "Web Part Page" in a document library.
I would have to do a little research to be 100%, but my understanding is that inline code is ok, providing it's in a page that remains ghosted, and thereby trusted. Can you add your functionality into the site via a feature?
I would avoide option 1, seems like bad advice to me. Allowing server side code in your page is a security risk as it then becomes possible for someone to inject malicious code. Sure you can secure the page, but we are talking remote execution with likely some pretty serious permissions.
Thanks so far. I've successfully tried Andrew Connel's solution:
http://www.andrewconnell.com/blog/articles/UsingCodeBehindFilesInSharePointSites.aspx
Wrapping it into a solution is part of that, but the main problem was how to get the code into that, and it's more leaning towards Option 2 without having to create the controls in code.
What I was missing:
In the .cs File, it is required to manually add the "protected Button Trigger;" stuff, because there is no automatically generated .designer.cs file when using a class library.
Well, it's a page that hosts user controls. It's a custom .aspx Page that will be created on the site, specially because I do not want to create WebParts.
It's essentially an application running within Sharepoint, utilizing Lists and other functions, but all the functionality is only useful within the application, so flooding the web part gallery with countless web parts that only work in one place is something i'd like to avoid.