Help
I`ve been reading more abour Server Side Includes recently.
http://www.yourhtmls...t/includes.html
I always assumed that it was necessary to use PHP or some other
server based scripting language to implement "includes" for common
page elements like navigation.
At least now I know why some pages have .shtml file extension type (although I dont see many of these).
I was wondering what are the pros and cons of using SSI versus
doing the same thing in PHP?
For example page load performance, search engine visibility , validation and so on.
SSI pros and cons?
Whether you're a seasoned veteran or a struggling beginner, Web Radiance is the web development and web design forum for you. You'll find answers to all your HTML, CSS, SEO, and Programming needs. Pull up a chair and stay awhile.
Page 1 of 1
- You cannot start a new topic
-
This topic is locked
SSI pros and cons?
Rate Topic:
MultiQuote
#2
- the owner3r
-
- Group: Administrators
- Posts: 1,578
- Joined: 04-April 06
- Location:North Wales, UK
- Interests:Art, Boxing, MMA, Graphic Design, Web Design etc. ;)
Posted 18 May 2008 - 07:40 PM
I dont know of any :S Remember its done server side, so any validation, seo etc all comes from the final output. Meaning whatever method you use it will produce the same result.
#3
- 日本語 Ninja
-
- Group: Members
- Posts: 652
- Joined: 21-September 07
- Gender:Male
- Location:Yokohama, Japan
Posted 19 May 2008 - 02:58 AM
I suppose it may at a slight load time, since the file has to be compiled from multiple sources rather than just one, but the difference would most likely be measured in milliseconds, and probably not noticeable to human eye.
Other than that, no problem at all with them.
Although I am curious, having never used them (I use php includes since I am a php guy), is the .shtml extension required to be able to use SSI?
Other than that, no problem at all with them.
Although I am curious, having never used them (I use php includes since I am a php guy), is the .shtml extension required to be able to use SSI?
<a href="http://www.jaypan.com" target="_blank">Jaypan</a>
<a href="http://www.dudes-japan.com" target="_blank">Dudes Japan</a>
<a href="http://www.dudes-japan.com" target="_blank">Dudes Japan</a>
#4
- A.K.A. Sirkent
-
- Group: Administrators
- Posts: 2,145
- Joined: 04-April 06
- Gender:Male
- Location:Kent, UK
Posted 19 May 2008 - 03:03 AM
There might be some slight performance issues, but I don't know if SSI or PHP would be faster. The truth of the matter is that it doesn't matter - what's being done is so simple that any different would be largely unimportant. It really comes down to whether or not you think you'll need anything more complicated than the features SSI can offer, further down the line. PHP can do so much more and it's actually a useful skill to have, compared to SSI.
QUOTE(benbramz @ Aug 17 2007, 07:44 AM) Ive noticed that quite a few people are now adding quotes from the board into their signature. I think its started an new web-radiance craze.. :P
#5
- Codesmith
-
- Group: Administrators
- Posts: 1,049
- Joined: 04-April 06
- Gender:Male
- Location:San Diego
Posted 19 May 2008 - 03:35 AM
The only time I'd use SSI is if a server didn't have support for PHP/ASP/ASP.NET. Not that it's bad, but like everyone else said you'd get some more useful things out of the scripting languages.
At a very minimum I always use server side languages with my CSS menus to throw a "class='current'" onto the LI for the page the user is on, which you couldn't do with SSI.
At a very minimum I always use server side languages with my CSS menus to throw a "class='current'" onto the LI for the page the user is on, which you couldn't do with SSI.
#6
- W.R. General
-
- Group: Administrators
- Posts: 2,849
- Joined: 04-April 06
- Gender:Male
- Location:Massachusetts - USA
Posted 19 May 2008 - 05:47 AM
Catalyst, on May 19 2008, 04:35 AM, said:
At a very minimum I always use server side languages with my CSS menus to throw a "class='current'" onto the LI for the page the user is on, which you couldn't do with SSI.
Ah, yes, but you can achieve that effect without using a scripting language too.
#7
- Administrator
-
- Group: Administrators
- Posts: 1,140
- Joined: 06-April 06
- Gender:Male
- Location:United Kingdom
Posted 20 May 2008 - 02:59 AM
Marc Amos, on May 19 2008, 10:47 AM, said:
Ah, yes, but you can achieve that effect without using a scripting language too.
Care to share this secret that you so obviously know?
#8
- 日本語 Ninja
-
- Group: Members
- Posts: 652
- Joined: 21-September 07
- Gender:Male
- Location:Yokohama, Japan
Posted 20 May 2008 - 03:16 AM
I'll share it, but the only reason I know it is because Famous Amos posted it in another thread one time.
Give the body tag on each page an id.
Give each button a class or id. So you declare the style for the button on all pages where it's not the current page
Then you also declare the style for the specific page, using the identifier in the body tag
Do this for each button, and they will all have a different state when they are current!
Give the body tag on each page an id.
<body id="home">
Give each button a class or id. So you declare the style for the button on all pages where it's not the current page
a.home
{
color: #000;
}
Then you also declare the style for the specific page, using the identifier in the body tag
#home a.home
{
color: #FFF;
}
Do this for each button, and they will all have a different state when they are current!
<a href="http://www.jaypan.com" target="_blank">Jaypan</a>
<a href="http://www.dudes-japan.com" target="_blank">Dudes Japan</a>
<a href="http://www.dudes-japan.com" target="_blank">Dudes Japan</a>
#9
- A.K.A. Sirkent
-
- Group: Administrators
- Posts: 2,145
- Joined: 04-April 06
- Gender:Male
- Location:Kent, UK
Posted 20 May 2008 - 05:39 AM
That's still using a scripting language though... at some point, something on the page must change dynamically in order for the relevant style to take effect?
And it means that if you have lots of tabs/selections then you'll end up with lots of CSS declarations that only apply to one page each?
And it means that if you have lots of tabs/selections then you'll end up with lots of CSS declarations that only apply to one page each?
QUOTE(benbramz @ Aug 17 2007, 07:44 AM) Ive noticed that quite a few people are now adding quotes from the board into their signature. I think its started an new web-radiance craze.. :P
#10
- W.R. General
-
- Group: Administrators
- Posts: 2,849
- Joined: 04-April 06
- Gender:Male
- Location:Massachusetts - USA
Posted 20 May 2008 - 06:13 AM
Sirkent, on May 20 2008, 05:39 AM, said:
That's still using a scripting language though... at some point, something on the page must change dynamically in order for the relevant style to take effect?
And it means that if you have lots of tabs/selections then you'll end up with lots of CSS declarations that only apply to one page each?
And it means that if you have lots of tabs/selections then you'll end up with lots of CSS declarations that only apply to one page each?
There's nothing changing dynamically. The method that haku wrote about, which is the one I was referring to, assumes you have a unique body element on each page (or, at least, each page you have a nav-link for) ... I know that some of us prefer to have www.site.com/index.php?pagename, and in that case, yeah, you're likely using the same physical body element for every page...
So, again, in a site that truly has a unique body element per page, you give it a unique, unchanging ID. Then, you give each nav item a unique class name (unshared, contrary to what a class is used for). Then, like haku mentioned, your css contains something like this, which represents a style to render when a person hits a page, showing them "You are here":
#aboutPage .aboutLink,
#contactPage .contactLink,
#shopPage .shopLink,
etc. etc.,
etc. etc. {
color: #fc9; /* Change the color of the specific nav text to orange, only when the visitor hits the page represented by the nav text */
}
#11
- A.K.A. Sirkent
-
- Group: Administrators
- Posts: 2,145
- Joined: 04-April 06
- Gender:Male
- Location:Kent, UK
Posted 20 May 2008 - 07:05 AM
I guess it depends whether or not you're looking at this as a designer or a developer. To me, your solution seems much messier than adding a class to the relevant menu item in a server side language.
QUOTE(benbramz @ Aug 17 2007, 07:44 AM) Ive noticed that quite a few people are now adding quotes from the board into their signature. I think its started an new web-radiance craze.. :P
#12
- W.R. General
-
- Group: Administrators
- Posts: 2,849
- Joined: 04-April 06
- Gender:Male
- Location:Massachusetts - USA
Posted 20 May 2008 - 08:36 AM
It helps in many other ways, too. Having unique ID's on body elements also affords the css writer a new hook for 'that-page-only' style changes. For example: Stake holder says the <h1>s on the About Us page should be blue, instead of the color used on all of the other pages. Instead of writing a special ID/Class for that <h1>, you simply utilize the existing body ID:
body#aboutUsPage h1 {color:blue;}
Also, and quite obviously, the css-method affords people with static html websites to achieve the same 'you-are-here' effect.
body#aboutUsPage h1 {color:blue;}
Also, and quite obviously, the css-method affords people with static html websites to achieve the same 'you-are-here' effect.
#13
- 日本語 Ninja
-
- Group: Members
- Posts: 652
- Joined: 21-September 07
- Gender:Male
- Location:Yokohama, Japan
Posted 20 May 2008 - 08:20 PM
I guess it could be considered scripting of a sort, although there are no traditional if statements as it were. The if is implied rather than expressly stated as being an if statement.
I can see advantages in both methods, but the biggest one would be, as herk says, that people with static sites and/or no programming background whatsoever, can still achieve something that shows pages to be current.
As a side note, I love this talk of theory and discussing methods etc.
I can see advantages in both methods, but the biggest one would be, as herk says, that people with static sites and/or no programming background whatsoever, can still achieve something that shows pages to be current.
As a side note, I love this talk of theory and discussing methods etc.
<a href="http://www.jaypan.com" target="_blank">Jaypan</a>
<a href="http://www.dudes-japan.com" target="_blank">Dudes Japan</a>
<a href="http://www.dudes-japan.com" target="_blank">Dudes Japan</a>
#14
- Codesmith
-
- Group: Administrators
- Posts: 1,049
- Joined: 04-April 06
- Gender:Male
- Location:San Diego
Posted 20 May 2008 - 11:44 PM
Typically when I carve up the code in a page into separate files for use as includes, the BODY tag ends up being in one of the included files (or in the MasterPage). That's why I prefer the server side method of setting the current menu item, it lets me keep BODY with other consistent content header and page top. Plus I wrote my menu setter once and now I just drop it into any site without having to make any other changes. Then if I need to I'll throw a div or span around the unique content of each page to get per-page styling.
Not that I think it's a better or worse way, I think it more reflects a different preference between client-side and server-side developers. Karl and I do a lot of server code so that way seems more elegant to us.
Not that I think it's a better or worse way, I think it more reflects a different preference between client-side and server-side developers. Karl and I do a lot of server code so that way seems more elegant to us.
#15
- W.R. General
-
- Group: Administrators
- Posts: 2,849
- Joined: 04-April 06
- Gender:Male
- Location:Massachusetts - USA
Posted 21 May 2008 - 06:41 AM
@Catalyst - Yeah, I can see that. It's certainly a preference that is influenced by a person's position (back-end developer, front-end, etc.). I worked with a developer, once, who was insistent on putting everything from the DOCTYPE down to the first unique paragraph of a page into one include, thinking that everything within it would most certainly be used on every page.
Then, then the designers and/or the client asked for unique bits to be put onto some pages and not others, style-wise, it was a pain in my ass to target a particular element without adding extraneous IDs/classes to the element in question. Likewise, when all of that stuff is put into one include, you're often having the visitor download more than he or she needs to, using up precious bandwidth (on a high-traffic site anyway). Often there will be CSS, JS, and even some meta elements that simply aren't necessary on every page, and those things shouldn't be in an include that is inserted into all pages.
Often, I tend to leave the following things out of include files:
Then, then the designers and/or the client asked for unique bits to be put onto some pages and not others, style-wise, it was a pain in my ass to target a particular element without adding extraneous IDs/classes to the element in question. Likewise, when all of that stuff is put into one include, you're often having the visitor download more than he or she needs to, using up precious bandwidth (on a high-traffic site anyway). Often there will be CSS, JS, and even some meta elements that simply aren't necessary on every page, and those things shouldn't be in an include that is inserted into all pages.
Often, I tend to leave the following things out of include files:
- DOCTYPE
- HTML opening tag
- Head opening and closing tags
- Title element
- Description meta element
- Body opening element
#16
- W.R. Private
-
- Group: Members
- Posts: 43
- Joined: 21-November 08
Posted 24 November 2008 - 03:12 AM
I am also using PHP i also face some difficulty. But some points are positive in PHP.
It's a quick and easy server side scripting language.
It works well with databases, file systems, images.
It has regular expression support.
It has extensive database support.
Cons
No namespaces
Global configuration parameters can change language semantics, complicating deployment and portability.
Plenty of special purpose forms, but insufficient general purpose forms. Can someone explain what "special purpose forms" are for me?
Lacks named parameters, which have to be simulated with associative arrays or other techniques. I miss named parameters.
It's a quick and easy server side scripting language.
It works well with databases, file systems, images.
It has regular expression support.
It has extensive database support.
Cons
No namespaces
Global configuration parameters can change language semantics, complicating deployment and portability.
Plenty of special purpose forms, but insufficient general purpose forms. Can someone explain what "special purpose forms" are for me?
Lacks named parameters, which have to be simulated with associative arrays or other techniques. I miss named parameters.
Share this topic:
Page 1 of 1
- You cannot start a new topic
-
This topic is locked