Is there a standard practice to organize the process of developing a simple website. there is no use implementing MVC as there is no data base involved. It will be very useful in organizing the project and separating
the aspx files and master
page content(this can be very useful in implementing simple cms techniques)
user controls
scripts
styles
images
is there any industry standard or best practice for this.?
thanks in advance :)
Update: yes the way i have listed is convenient. but it would be great if i could separate server codes and files like master,aspx.. and the actual page content.
One more reason for not using MVC: I usually outsource the SEO process. Now an MVC application can be greek/latin for my SEO expert. :)
The final structure:
Project
Images
Scripts
Styles
Images
Weblets
Pagelets
aspx files..
the images, styles and scripts will contain only those that are common for the whole project. The weblets and pagelets are in the idea as follows...
Weblets should contain a collection of weblets. A weblet is folder containing a user control,it's styles,scripts,images etc.,
Pagelets should contain a collection of pagelets. A pagelet is a folder containing the content for the aspx page. If there is an aspx file named "aboutUs.aspx" then there is a corresponding pagelet named "aboutUs" which contains aboutUs.html,it's styles,scripts and images. the aspx page should only include them here.This can be very useful in configuring CMS.
If there can be betterments please do post..:)
No industry standards as such, but most developers I know would separate things out the way you did.
i.e. - different types of content in different directories.
That is right there is no such industry standard for this. But in my opinion i really like the Web Application Template from ASP.Net 4.0. It is more like MVC Template but it remain very useful in terms of scalability.
http://weblogs.asp.net/scottgu/archive/2009/08/26/starter-project-templates-vs-2010-and-net-4-0-series.aspx
ASP.Net MVC isn't just for database applications. In fact I would suggest it's easier to work with than webforms after the small learning curve. The concept of convention over configuration will help you with your question. There is a standard structure that MVC sets up for you that works great and anybody that opens your MVC code will be able to understand where everything is.
Related
When using ASP.NET webforms, I see two main ways to structure a project:
1) Have a lot of .aspx files (including code behind files) and maybe some .ascx files (with code behind files.
2) Rely on a lot of .cs files (class files), and have the classes construct everything with Controls.Add(), etc.
The first method above results in a lot of aspx and ascx files and very few .cs files. The second method above results in a lot of .cs files, but very fewer aspx and ascx files.
Is there a "best practices" way to structure project? Does Microsoft recommend one of these techniques? Is there any information on which of the two styles is used more commonly?
I would stick with the first approach. Some controls are extremely tedious (or difficult) to be created progamatically.
Take the GridView or ListView for example, create an *.aspx page with a GridView which has custom templates with template columns. Then run your application, find the *.dll in the ASP.NET temp directory, decompile the class and look how messy and complicated is the code. It would be very difficult to maintain it over time and/or make changes.
On the other hand, having some declarative code isn't bad as long as you try to maintain the balance.
If you haven't done so, check out ASP.NET MVC. If you cannot opt for MVC you can implement MVP pattern with ASP.NET WebForms. These two patterns provide good way to separate presentation, model and routing.
There is nothing wrong with either approach. Which one you use depends on personal preference, feasibility, and requirements.
One issue you may face is that fewer developers will be able to pick up your project and run with it if you use the second approach, or will take much longer to get up to speed with it. You will find a lot more developers that can easily pick up the first approach and go.
Use approach one as much as possible and only resort to approach two when the out of the box controls do not give you the functionality you require - you can create a custom control by inheriting from an existing control in this case. This is not an "either/or" scenario - you should use both approaches judiciously.
I've refactored my web application into one page (single page app). I'm just wanting some advice on whether serving up the one page index.cshtml with a controller is overkill (I'm not using any razor code that can't be substituted for normal html/js). Should I just change it to be a index.html page and just serve it as normal?
I'm sure it's only a minor thing, but want to know what the best practice is here.
No, it's not an overkill.
Just split your code into 3 parts: logics, HTTP processing, view.
It will be MVC even if all 3 parts are in 1 file.
Absolutely no need for MVC and all that BS.JS huge files when you're building a single page portfolio.
Just create a new HTML file.
This may be a broad question because part of the problem is that I actually don’t know what the question is. What I would like to know is how you commonly organise ASP.NET applications in terms of placement of pages (aspx), user controls (ascx), server controls and other support classes and utility functions etc. First, let’s assume that there is already some data layer somewhere (perhaps in a different project). This is the not issue.
The issue I frequently face is that create several pages and realize that they need to share some common rendering logic or some utility function, class etc. Another typical case is that some pages become too large so that it seems handy to split them (say into some user controls). What is the best place to put these utility classes, share classes, user controls, server control etc.? Here are several possibilities.
Don’t really care about any organisation and place all types of files next to each other. So in one directory, you may have an aspx files, some cs files etc. This is not really an option probably.
Organize files by types. Let’s say you create a directory for user controls and put all user controls there. OK, but what about server controls and other regular classes? Should they be in special directories as well? It does not sound right. What I dislike most on this is that when you work on a feature (logically related piece of code), you must hunt it all over the place. I think that features and logical sections of your applications should be also grouped on the file system level in some way.
What I would like to have is to have the pages (aspx), user controls (ascx) and handlers (ashx) basically as dummy placeholders sitting in the directory structure organized from the logically according to the point of view of the outside visitor while the actual code (page, user controls implementations, serve control and utility classes) should be placed in s different folder structured into logical namespaces (organized by the modules or features of the application). It seems to me that the only way to achieve this is to manipulate the <%# Page ... %> directive manually.
Does it sound crazy? Am I asking too much? Is there a better way? What are your best practices? Do you know some good examples?
Edit: Another idea. This does not mess up with the generated aspx, aspx.cs and aspx.designer.cs files. One on my original requirements was that I wanted to place the code driving aspx pages to my own location and put it to a custom namespace hierarchy. So what if I simply subclass the aspx classes generated by VS? Let’s say I have a project called MyApp and MyPage.aspx page in it. VS then creates MyApp.MyPage inherited from System.Web.UI.Page. I leave this class be (no code will go there), but create a subclass, say in MyApp.SomeNamespace.SomeSubNamespace.MyPage, inherited from MyApp.MyPage. This way MyApp.SomeNamespace.SomeSubNamespace.MyPage will get access to the autogenerated protected fields corresponding to the server controls of MyApp.MyPage and I’ll get an entire "private" namespace for all the support classes which are related to this page. Any major disadvantages? Another related problem which bothers me is where should this new cs file be physically placed? In web projects, there is a standard folder for it called App_Code, but I’m interested in web applications. Creating a directory in the root of the application (such as Code) does not sound right.
Remember that you can create page classes that don't actually correspond to any markup. We often create base pages that our actual UI pages inherit from. This is a simple way of organizing "base" page functionality. Then when you create your .aspx pages, make them inherit from the base page class, rather than System.Web.UI.Page.
We usually place our base page .cs files into the top level directory if it's a small project, or for slightly larger projects we'll create a "Shared" or similar directory where they live.
However, we also have a huge enterprise web project, and we simply build our webcontrols and base pages into a class library called CompanyName.Web.UI, with a couple sub-namespaces to that. All our actual web site projects import that assembly and all the code for the controls, etc. is elsewhere. This sounds like it might be a good option for you.
If you remember that your .aspx codebehinds can inherit from any class file, it should make it easier for you to organize.
Scenario:
I have a pretty standard master page for all my pages. It includes the usual login forms and other dynamic lists to be extracted on each page. Webdesigners can already modify the central content place holder of each page. But still, the design and layout for the master page is still in my project and any modification to the design must be made in Visual Studio and the project re-compiled and re-deployed.
What is the best way to provide near-full access to designing the master page through a CMS? Some of the problems I can identify is the inclusion of any dynamic lists or specific controls such as a login form.
Thanks.
Unless you want to host your content within a portal I don't know of a perfect answer to this.
If the bits they design just amount to look and feel for the page then this can be controlled by css and you could allow them to create themes using different css files.
This is indeed an interesting question, and there is no perfect solution. I worked for an ecommerce shop with this issue, and frankly, I just asked the designers in many cases to provide me there html and css, then I would grab the html pieces and css and add them to my project. Yes this was tedious....
Then we we built a cms where the designers could copy and paste their html into html editors, and we would store those pieces of html in a database. My web app would grab those from the database at run time. This solve some issues, but not all, since it did not give them complete control of the design of the web page.
The bottom line is you need to standard as to how the designer will submit their work to you. If you have that, and you can count on the html and css, then you can star to think of possibly building a CMS around that. In this days of RAD, I have found it easier to just work with the html and css delivered to me and simply copy and paste the pieces into my master page and other pages as needed.
While this is not a CMS answer, you do have the ability to allow designers to open the master pages in Expression Web. I will not say it is the greatest tool in the world, but I have had designers work up the master page designs in Expression with good results.
There is a pain point, however. If the entire project is opened, the designer will see the code behind files as separate items, not like the treeview view seen in Visual Studio.
I imagine you could have the master page checked out for use with Expression through a CMS, but there is no built in way to do this, nor do I know of a third party tool to do this. Hopefully Expression Web 3 will make things easier.
If you have a CMS, you may be better to give it full control over page content. If there are things the CMS cannot do, you could look to write extensions or plugin modules for the CMS that your designers can then drop onto the page in the CMS's page editor.
If your CMS doesn't support plugin modules, you may be trying to force both the CMS and master pages to do things they were not intended to do.
If the above doesn't work in your situation, here's another thought: place inline frames on your master page that host pages that are edited in the CMS.
Hope that helps.
Would it be possible for you to put placeholders in the Master Page in place of the areas that designers should be allowed to edit? Since Master Pages are only editable in Visual Studio, it may be your only feasible option at this point in time. One problem with this approach is that the content put in the placeholders is unlikely to be valid, since you would probably have tags left open in one placeholder and closed in another.
<html>
<head>
<title></title>
<asp:PlaceHolder ID="headerContent" runat="server"></asp:PlaceHolder>
</head>
<body>
<asp:PlaceHolder ID="beforeContent" runat="server"></asp:PlaceHolder>
<asp:PlaceHolder ID="centralContent" runat="server"></asp:PlaceHolder>
<asp:PlaceHolder ID="afterContent" runat="server"></asp:PlaceHolder>
</body>
</html>
I know it's ugly, but it might give you the control you need (as long as you don't mind the XHTML validator warning you all the time). What you put in the placeholders could be your user controls or literal content or whatever, but you'd have to load it dynamically.
Thoughts?
EDIT: This won't work. The PlaceHolder is going to render <div> tags that would mess things up. Maybe you could extend PlaceHolder and override how it renders its HTML.
Interesting question,
been dabbling in that area myself a while ago.
How knowledgeable are these web designers when not in the realm of not-inside-Photoshop-or-flash?
If using a DIY-CMS, perhaps you can template the most susceptible objects, e. g. making a generic (as in whatever you feel like, not whatever they feel like ;-)) list and a way of entering design, if applicable.
As long as you have a thorough framework set up, that deals with the attributes available to the designers through the CMS, there shouldn't be any need for recompiling... but of course, I can easily see a developer (read : me) stumbling
into the gap of nitty-pitty-perfection....
I'm afraid the easiest, and only manageable, path is to standardize how the designers express their needs&wants to you...it just won't code itself...
Could you provide some examples?
Well, with a Web Application Project pages are not compiled until accessed (link is 2005 but it still applies). This means that the actual .aspx (and .ascx etc) page is deployed in its original state. A designer can update the format of the page on the server and the updates will be compiled the next time someone requests that content.
It would be relatively trivial to allow designers to download the current pages and upload replacements through your website's UI. However, it isn't very secure (and probably should never be done). It would be better to allow designers access to the virtual directory over the web so they can connect to it using a tool such as Expression Web. This way the designer can open the current website, edit pages, and push the results directly into production (scary tho that thought may be).
As I'm getting downvoted for having a correct answer, let me point out something.
Website projects compile codebehind and pages on demand. If you need to update code regularly, its an okay solution.
Web application projects can be configured to be updatable. All codebehind and classes are compiled into an assembly, and all aspx, ascx, etc pages are deployed and compiled on demand. This means that a designer can connect to the website, update the layout and static content, and see the changes on the next request.
This is my preferred method of deployment. I have a few web application projects out there in the wild, with updatable aspx files deployed alongside my dll. The idea being that users of the website can alter the UI without having to submit updates to me so I can recompile it for them.
a .master is just a text file. They can edit it however they like. There's certainly nothing they'd do to it that would require you to recompile the code just to view it. That's the big win with Master Pages in the first place: designers and other non-programmers can edit them manually without breaking anything.
Give them access to the file under source control and let them go nuts.
The problem I'm having with writing a web application architecture is that I want separate components that work together. By this I simply mean, for example, a navigation bar and the actual page content (as well as a header, which is static) in ASP.NET.
Now, here's where it gets interesting:
There are no two pages the same
The navigation pages on every page have security on them on a user-by-user basis
The navigation has links to other locations
The problem I'm mainly having is that you've usually got to have a full web page in Visual Studio, and if you have portions i.e. excluding your <html> tags then Visual Studio will end up underlining everything as incorrect.
The way is this application is currently being dealt with is using frames (yes, frames) to keep everything separate, but working together. I want to move away from this, although the web system is very large, and very important in that it must be available 24/7.
Any ideas?
Have you looked at Master Pages in ASP.NET 2.0? These can be used in conjunction with User Controls, and the Site Map Navigation.
Master Pages Quickstart Tutorial
MSDN Overview
Master Pages: Tips, Tricks, and Traps
Example Template Set
There's a really good book you should check out that might shed some light on your problem. It's "ASP.NET 2.0 Website Programming: Problem - Design - Solution", part of the Wrox series.
Is it not possible to implement UserControls for this? for example a navigation user control that can handle the security for itself etc etc.
Hope this helps a little.