In a web I am using content pages, master pages and user controls. Kindly guide me what are best practices to write css for all of these. Should in page ? In seprate file. A seprate file for each (content, master and user control) ? or one seprate file for all ?
What is the way to write in professional environments considering easy changes and extendability.
I am writing nesting CSS code.
Thanks
You should write separate css files, linked from the master page. How many files depends on the complexity of your app.
Putting css directly in your pages will cause unneeded extra bandwidth usage, whereas separate files could be cached. Same with Javascript, btw.
Don't be dogmatic about stuff like this. As a rule of thumb put your styles that are used throughout your site in a separate stylesheet.
If you have a one-off style that only applies to one page or control, don't feel bad about just sticking it on the page itself. The more you do this though, the harder it is to modify the look of your whole site. There are trade-offs.
Related
As much as I develop an asp.net web forms project, more and more css and javascript files become needed to load in every page. Beside, There are also some conditional statements like
<!--[if lte IE 9]>
So the question is: Is this a good practice to bundle all css and js script loadings in an asp.net user control and then putting only that user control in page header instead of adding all those lines to every page/masterpage?
Your solutions are appreciated.
This has been a practice with user controls: to bundle resources (js, css, images) with the control in order to make it self-contained.
However, main problem that arises out of this is that the resources can't get cached on the client-side and hence are loaded every time that page is requested. Moreover, if multiple controls use some or all of the resources, then they are loaded multiple times and code reuse is defeated.
You will have to weigh in your options carefully. If your app is relying too much on user-controls then you have to live with that. You can identify common resources and separate them out and load them in pages where required.
I would suggest identifying common resources and bundling them (using tools or manually) into one file and load in individual pages (or master page as appropriate) and do a js minify. Typically css goes in head and js goes at the end of page.
Bundling everything in a single user-control will give problems of maintainability, version control and of course caching as mentioned above.
With regard to css specifically, I would suggest that you use ASP.Net themes (stylesheet themes). That way all styles remain in one place and provide easy customization options.
We have a fairly large public website and have recently redsigned it with a new layout. The problem now is that with our redesign we find ourselves constantly hardcoding the html layout for all of our pages. This is clearly not the best solution.
My question is what are some options on ways to share/inherit, in a sense, a web template that all our ASP.Net projects can pull from for the layout. Specifically the HTML side of the layout. Any changes made to this template will update all web sites that use it. I'm sure this exists but do not know how to approach it.
Master Pages is what you are looking for. See: http://www.asp.net/master-pages/tutorials
or http://www.asp.net/master-pages/tutorials/creating-a-site-wide-layout-using-master-pages-vb
That's the technical solution. Oftentimes, the bigger challenge in retrofitting sites that were built with numerous one-offs is determining which parts of your pages belong in the master page or content areas. Keep in mind that you can have multiple content areas and you can provide default content in a master page that can later be overriden in a content page. It's very flexible. Have fun!
The simplest approach I know is to create a header and footer file for every page. Include the header just after the <body> tag and the footer just before </body>. You content goes in between.
I prefer a more sophisticated approach with a templating system like Smarty, but that's PHP. I don't know what your ASP options are.
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.
Our Dev team had been developing enterprise web page more than 2 years ago. We are curious to know what is the best way to write a contract for CSS usage. For example, if we have a COMP, how we agree on a contract so our developers and our designers agree and we don't have to go back.
Is there a tool that is available for this type of technical writing?
What is the threadhold of information put in the CSS versus on the HTML page? Some of our designers thing that some things should go directly into the HTML page. The general opinion is that everything that is style should go in a CSS and all else in the html.
Thanks for your input.
Well, if a webpage has very specific CSS just for itself, I guess there is an argument for defining the CSS in the page, otherwise I would always have the CSS in an external file.
Try to avoid or at least minimise in-lining the CSS as a style attribute on HTML elements though, that would be a PITA to manage.
Most pages will be template driven with standard content styles, and thus the CSS styles will be defined in external files.
One thing you might want to think about are the number of CSS files - some people suggest that you should minimise this to just one file site-wide or per-template (or area of the site) to minimise HTTP requests to the server and avoid delayed CSS loading and funny looking styling up until that point.
So this "contract for CSS usage" is actually just a coding standard for HTML pages?
I'm a purist, so for me HTML is for content and structure and CSS is for layout & styling. That's really what each of them were created for.
See CSS Zen Garden for a great example of this. Same HTML and hundreds of different layouts & designs.
What are the reasons your designers give for styling to be in the HTML?
Edit: The main goal here is consistency across the site, correct? The more you have abstracted away from each page, the fewer changes you'll have to make.
The idea that the HTML should merely encode information and not style is called semantic markup. It has several advantages that you already know about, like separation of concerns, and a few that you probably haven't thought about.
If you stick to the web standards and separate your style and content you will also end up with a page that is more accessible to those with disabilities.
If you need to have some things styled differently for a specific page, use separate CSS include file for that page only and then use a CSS class on the element you want to style.
If I have style that is for a one time, single use page, I will consider putting it in the header of that page, as my templating system allows for that.
However you should never use inline styles. Even if you do a page with a block in it for a one off. That way should you find that you "one time" item becomes a site wide style, you can simply move the CSS into the external CSS file and not edit the content.
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.