New Page On Blogger

Do you know, blogger has recently added a new feature to add standalone page to your blogger blog? This page are different from traditional posts. You can add new pages like 'about','contact','terms' etc to your blogger blog and these won't be shown on posts category.

This feature is just like the page feature of wordpress. You can add new page on wordpress those are not belongs to other blog posts. However in blogger, you can add up to 10 pages max, not more than that.

Adding page on blogger blog is quite easy. log in to your blogger account, goto the 'posting' tab of your specific blog; Under this there is a sub menu that contains an option along with others named 'Edit Pages'. Click on it. There you will find all options to view your existing page, create a new page, edit an existing page just like any other blogger post.

 

Now just add important pages that you want to show to your visitors. You can add a page gadget to your blogger layout to show all the pages or just the specific pages that you want. In other ways, you can add menu items manually in your template to give them a better view.

Their location are located in shorte format like urblog/p/page-name.html . Enjoy using page on your blogger blog.

Nested Master Pages

We know that masterpage is used to share some common content all over every page so that we don't have to write the same things over and over. But, in many cases we need the same thing that resides in the content place.

We can take this a step forward and have a master page be the content for another master page. In other words, we can have nested master pages, whereby a master page inherits the visual appearance of another master page, and the .aspx content pages inherit from this second master page. The secondlevel master page can look something like the following:

<%@ Master Language="C#" MasterPageFile="~/MasterPage.master"
AutoEventWireup="true" CodeFile="MasterPage2.master.cs" Inherits="MasterPage2" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
Some other content...
<hr style="width: 100%;" />
<asp:ContentPlaceHolder ID="MainContent" runat="server" />
</asp:Content>

Because we can use the same ID for a ContentPlaceHolder control in the base master page and for another ContentPlaceHolder in the inherited master page, we wouldn’t need to change anything in the content page but its MasterPageFile attribute, so that it uses the second-level master page.


This possibility has great promise because we can have an outer master page that defines the very common layout (often the companywide layout), and then other master pages that specify the layout for specific areas of the site, such as the online store section, the administration section, and so on. The only problem with nested master pages was that they didn’t have design-time support from within the
Visual Studio IDE (as we do for the first-level master page). However, with the release of Visual Studio 2008 and the related Express products this is no longer a problem.

To be honest, we prefer editing content pages in the Source view in the editor, because it gives us more control over the HTML and we can structure it as we see fit, so not having design support never really bothered us as developers. Additionally, this is not much of a problem for most developers who prefer to write the code themselves. It will give us a deeper understanding of what the structure of our HTML looks like and ways we can cut down on the messy code that the visual editor generates.

Basic Model of Master Page

This tutorial is only for those who don't understand masterpage properly yet. Masterpage is a new feature of asp.net introduced in version 2.0. Here are some basic concepts of masterpage that is explained following the description from a book i was studiying:

A master page enables us to put the common layout code in a single file and have it visually inherited in all of the content pages. In a sentece, A master page contains the overall layout for your site. All other Content pages can inherit the appearance of a master page, and place their own content where the master page has defined a ContentPlaceHolder control. Although this has the effect of providing a form of visual inheritance, it’s not really implemented with inheritance in an OOP sense — instead, the underlying implementation of master pages is based on a template model.

An example is worth a thousand words, so let's see how this concept turns into practice. A master page has a .master extension and is similar to a user control under the covers. The following is some code for a master page that contains some text, a header, a footer, and defines a ContentPlaceHolder control between the two:

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="MasterPage.master.cs"
Inherits="MasterPage" %>

<html>
<head id="Head1" runat="server">
<title>TheBeerHouse</title>
</head>
<body>
<div id="header">The Beer House</div>
<asp:ContentPlaceHolder ID="MainContent" runat="server" />
<div id="footer">Copyright © 2008 Nicholas Berardi</div>
</body>
</html>

As we can see, it is extremely similar to a standard page, except that it has a @Master directive at the top of the page instead of a @Page directive, and it declares one or more ContentPlaceHolder controls where the .aspx pages will add their own content. The master page and the content page will merge together
at runtime — therefore, because the master page defines the common contents and tags, we can easily guess that the content pages must not define them again. Content pages will only define the content for the master’s ContentPlaceHolder controls, and nothing else. The following extract shows an example of a content page:

<%@ Page Language="C#" MasterPageFile="~/MasterPage.master" AutoEventWireup="true"
CodeFile="MyPage.aspx.cs" Inherits="MyPage" Title="The Beer House - My Page" %>
<asp:content contentplaceholderid="MainContent" id="MainContent" runat="Server">
My page content goes here...</asp:content>

The first key point is that the @Page directive sets the MasterPageFile attribute to the virtual path of the master page. The content is placed into Content controls whose ContentPlaceHolderID must match the ID of one of the ContentPlaceHolder controls of the master page. In a content page, we can’t place anything but Content controls, and other ASP controls that actually define the visual features
must be grouped under the outermost Content controls. Another point to note is that the @Page directive has a new attribute, Title, which allows us to override the value specified in the master page’s <title> metatag. If we fail to specify a Title attribute for a given content page, the title specified on the master page will be used instead.

The figure below provides a graphical representation of the master page feature:

 

When we edit a content page in Visual Studio, it properly renders both the master page and the content page in the form designer, but the master page content appears to be "grayed out". This is done on purpose as a reminder to us that we can’t modify the content provided by the master page when we’re editing a content page.

It is important to point out that our master page also has a code-behind file that
could be used to write some C# properties and functions that could be accessed in the .aspx or code-behind files of content pages.

When we define the ContentPlaceHolder in a master page, we can also specify the default content for it, which will be used in the event that a particular content page doesn’t have a Content control for that ContentPlaceHolder. Here is a snippet that shows how to provide some default content:

<asp:ContentPlaceHolder ID="MainContent" runat="server">
The default content goes here…
</asp:ContentPlaceHolder>

Default content is helpful to handle situations in which we want to add a new section to a number of content pages, but we can’t change them all at once. We can set up a new ContentPlaceHolder in the master page, give it some default content, and then take our time in adding the new information to the content pages — the content pages that haven’t been modified yet will simply show the default content provided by the master.

The MasterPageFile attribute at the page level may be useful if we want to use different master pages for different sets of content pages. If, however, all pages of the site use the same master page, it’s easier to set it once for all pages from the web.config file, by means of the element, as shown here:

<pages masterPageFile="~/Template.master" />

If we still specify the MasterPageFile attribute at the page level, that attribute will override the value in web.config for that single page.

Experience with domain/hosting package of godaddy

Recently, I have purchased a domain and hosting package from godaddy.com . I was y=using free hosting on 000webhost and byethost before this. Both free hosting were good, but was also having problems in various aspects. So, I decided to get a new paid hosting. And as godaddy is a renowned name in this industry, so i just chose them and purchased a limited package(As I have no commercial site to host, i will have nothing useful purchasing unlimited hosting :) ). Another reason behind this is to get a windows hosting. As I do work with asp.net also, I needed a iis/asp.net based hosting to host some work.

So far I am using there package, they are working well to me. I was having a problem of ftp users creation those are permitted to use a specific folder and those users couldn't access their directory. So, I submitted a support ticket and they promptly replied and solved the problem.

Another great thing about them is that, they use highly secured server/ssl for users accounts. In this case, my suggestion is that, if your internet connection is slow, then you will have big trouble using your account on godaddy as with ssl/https , user experience is much slower even with high internet connection; So, be careful.

TO purchase a domain and mange that, godaddy should be your first choice, even if you don't choose this as your hosting provider.



Main reason behind is security and flexibility. Moreover, you won't have to pay much higher than other domain provider.

Hope you will have a good experience with godaddy as like me.

Advantages of using css over table layout

I knew about very little before I came to know in details while studying this in a book. Some points that were mentioned are as follows:

* If we use DIVs(and similar html tag elements) and a separate style sheet file(.css file) to define appearance and position, we won’t need to repeat this definition further more, for each and every page of our site. This leads to a site that is both faster to develop and easier to maintain later.

* The site will load much/significantly faster for end users! We should remember that the style sheet file will be downloaded by the client only once, and then loaded from the cache for subsequent requests of pages until it changes on the server. If we define the layout inside the HTML file using tables, the client browser instead will download the table’s layout for every page, and thus download more bytes, with the result that downloading the whole page will require a longer time and cost we more in bandwidth. Typically, a CSS-driven layout can trim the downloaded bytes by up to 50%, and the advantage of this approach becomes immediately evident. Furthermore, this savings has a greater impact on a heavily loaded web server — sending fewer bytes to each user can be multiplied by the number of simultaneous users to determine the total savings on the web server side of the communications.

* Screen readers, software that can read the text and other content of the page for blind and visually impaired users, have a much more difficult job when tables are used for layout on the page. Therefore, by using a table-free layout, we can increase the accessibility of the site. This is a very important requisite for certain categories of sites, such as those for public administration and government agencies. Few companies are willing to write off entire groups of users over simple matters like this. An easy way to see how a screen reader for the blind will read our site is to remove all the style sheets from our website. If it doesn’t flow straight down and is broken up into content sections, they are going to have a tough time figuring out which content is important and how it should be read.

* CSS styles and DIVs provide greater flexibility than tables. we can, for example, have different style sheet files that define different appearances and positions for the various objects on the page. By switching the linked style sheet, we can completely change the appearance of the page, without changing anything in the content pages themselves. And it’s not just a matter of colors and fonts — we can also specify positions for objects in CSS files, and thus have a file that places the menu box on the upper-left corner of the page, and another one that puts it on the bottom-right corner. Because we want to allow users to pick their favorite styles from a list of available themes, this is a particularly important point.

* CSS even enables we to create a specific layout for the printer. This is a very important point, because the user is usually interested in printing only the content of the page and not the sidebars and login information that is presented in the browser. These elements of the page can be easily set to not be displayed through CSS when they are being printed. Also, if we use a lot of dark background colors that would just use up ink, we can change the dark backgrounds to white to save the end user some money on the cost of ink and still have our website print in a way that we control.

* CSS enables us to target different classes of devices in some cases without requiring new HTML markup, such as mobile devices like PDAs or smartphones. Due to their constrained screen size, it is necessary to adapt the output for them, so that the content fits the small screen well and is easily readable. we can do this with a specific style sheet that changes the size and position of some containers (placing them one under the other, rather than in vertical columns), or hide them completely. For example, we might hide the container for the banners, polls, and the header with a big logo. Try to do this if we use tables — it will be much more difficult. we’ll have to think about a custom skinning mechanism, and we’ll need to write separate pages that define the different layouts available; this is much more work than just writing a new CSS file.

Model, VIew and controller definition

MVC is the most popular software development approach. I knew about this from long before. But, became familiar with it more deeply while learning asp.net mvc that was launched on later 2008 with .net 3.5 sp1.

The most popular definition for MVC(Model View Controller) design pattern by Reenskaug is as follows:

Model: Represents knowledge. A model can be in the simplest case a single object in your
application, or in a complex case a combination of objects. It should represent the world as seen
by the developer for the application that is being developed; in other words, your database or
domain.



View: Visual representation of the model. It should highlight specific aspects of the model while
minimizing the others where possible. According to Reenskaug, it should act as a presentation filter.
What he describes as a presentation filter is the notion of a contract created between the model
and the view that will provide the parts of the model requested for the presentation by the view.

Controller: A controller provides a link between the user and the system. It provides the user
with actions that can be taken against the model, which in other words creates a set of inputs that
can be acted upon and represented to the user in one or more ways through a view.


If you are interested to get example to understand, you can visit here to get an old example that actually deals with the very basic idea to be understood.

MVC example