I have an ASP.NET application which calls aspx-pages in other ASP.NET applications (all on the same server and the same solution). This aspx-pages should be shown in a (fixed) region on the main-site in that way that that only the embedded pages is renewed, during user interactions there. Is an IFRAME the only way to achieve this goal, or can I use for example the AJAX update-panel or are there further possibilities / techniques. I have read something about the a control "UFRAME". Maybe this is the solution for my question !?!?
If you want to display a page within another page, you'll need to use frames or an i-frame. If you have access to all the code for these other ASPX pages though, it would probably be better to use User Controls (ASCX files) instead. You can then easily re-use these in as many pages as you like.
Related
In jsp and php it's very common to have files with pieces of HTML/Java/PHP code and have other jsp/php files consume them. That's fundamental for reusability.
In asp, M$ created another approach, master pages. But I'm having trouble to get used to it, to be forced to have ALL reusable code in a unique file. In example, some apps with many pages may have a breadcrumb area, while simpler apps won't need it.
Yes I can put those blocks inside a ContentPlaceHolder and just add them empty to asp pages they aren't needed. But I'd rather have them on their own files and include them when needed, instead of "removing" them when not needed.
Another example is about menus. Each app has its own menu. In jsp and PHP I can have a local file with the HTML menu and add it. In asp, the best I could imagine is have the "master master page" with an example menu code, then have a local "nested master page" only with local app's menu, and have asp files consume that "nested master page".
Is it the only way to do these stuff? Or is there a better way for doing it?
You have many choices with ASP.NET web forms.
If you just need to share server code, such as utility functions, you can add additional classes to your web project and instantiate/call them just like any other code. Classes added in this manner are accessible to all of your pages.
If you want to share server side code across multiple projects, you can create a new project of type "Class Library," compile it, and set a reference to the resulting DLL from all of your web projects.
If you have a page snippet or section (e.g. a menu system) that is common across pages, you have two choices: custom controls or user controls.
Custom Controls: these are controls written from scratch exclusively using code. Essentially, you write a class which extends Control (directly or indirectly), and you take care of everything. You need to write logic to create child controls that you want to use, and you override the Render method to perform rendering. Typically, you build this control into a redistributable assembly (i.e. a DLL), which can then be used by any ASP.NET applications, simply by placing the assembly in the 'bin' directory of the app (or in the Global Assembly Cache).
User Controls: these control are written using an ascx file, which looks much like an aspx page. i.e. you can simply drag and drop the UI elements that you want to use into the design surface. You don't need to worry about control creation, nor about overriding the Render method.
Sounds to me like you want a user control in this scenario. Here is a helpful walkthrough to get you started.
I will echo scheien's sentiment and tell you that you might want to look carefully at MVC, which is totally different but might fit better with your PHP mindset.
Does Padarn support the concept of .NET Master Pages and/or the concept of Classic ASP #include?
I would like to reuse my .aspx pages in other .aspx pages as well as implement a single Header & Footer for the web site.
It appears as though Padarn doesn't support .aspx page reuse explicitly and that, maybe, I will need to dynamically generate/call Document objects within a Padarn Page to simulate the Master Page effect.
Before I try to get clever with simulating .aspx reuse within the Padarn framework, I would like to know if there is built-in support for this and/or if there is a best practice for this.
Padarn doesn't have built-in support for master pages or classic ASP syntax. For page element re-use (headers, footers, menus, etc) we typically use a base class in the code behind where we have methods that can render these elements. We then derive pages from the base to get the common functionality.
I am creating a website that has 5 different sub-sites each with the same overall look, but each has a different logo and added navigation.
What do you feel is a better approach:
Use the new nested master page capabilities to create 5 sub-master pages.
Use a single master page and dynamically load user controls corresponding to each sub-site's
specific logo/navigation.
I'm currently going down the nested master page route.
Update (12/19/2008):
I am using Nested Master pages, and it is working out great. You are able to pass-through ContentPlaceHolders, and even have default content for the placeholders.
Nested Master is much better than loading a user control dynamically. Dynamically loading a control is slow.
A MasterPage is a control, which could also be loaded dynamically. However, to answer your question, it sounds like different masterpages are the way to go. It will give you much more flexibility, especially if say, one client wants their logo running down the side or something that a user control would not be able for. Master will give you full control over wrapping html.
I've never created a web page and I'm just learning ASP.NET now and all the examples I see are mostly with filling out forms etc. So I'm wondering if the lively, colorful, and snazzy web sites can be done with ASP.NET. I have also been playing with a trial of Expression Web. It seems to be for the "fancier" side of things. Are the two sides of the web mutually exclusive or can an ASP.NET page be just as colorful? Keep in mind I'm new to doing anything on the web.
Thanks for your help?
Yes, you can make an ASP.NET page look just like a static web page. The look and feel of a web page is done completely on the client side, using HTML, Javascript and CSS. ASP.NET lets you use all of these things, but it provides the ability to generate output to the page on the server side before sending it to the client's browser. Once it gets to the browser, the HTML, Javascript and CSS will apply just as if the client was loading a static page.
Absolutely yes!
You may be confused with the tutorials which are focused on teaching backside technology and poor on page design. Isn't microsoft.com colourful enough?
Asp .Net just outputs html.
ASP.NET is simply a web application framework. What is sent to the browser is *usually** HTML, so anything that you can do with a static HTML page, you can do with ASP.NET.
In my personal experience, I have had better luck with producing "lively" pages using ASP.NET MVC, since I have better control over the markup, and I don't have to contend with ViewState or munged control IDs. Subjectively, the pages feel less sluggish than those of ASP.NET, and I can use JQuery to improve the user experience.
Yes you can, just do not use Web Controls. I have written several Blogs on this so far this year. http://professionalaspnet.com/archive/tags/Thin+ASP/default.aspx
Ultimately, html is sent to the browser irrespective of the server side technology, so question is a bit awkward.
But for aesthetics side, asp.net provides features called master pages, themes, skins. By providing these it goes beyond css.
ASP.NET can be used to produce very lively and colourful pages, but you need to understand how to create the pizzaz. Mostly that's going to be media and javascript. For that, you need to understand HTML, and then what the ASP.NET Server controls render as in HTML so that you can control and manipulate it in your javascript more easily.
The reason that ASP.NET tutorials feature data and forms is that the need to manage data (and dynamic content deriving from it) is what makes people use ASP.NET rather than static html.
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.