homepage Welcome to WebmasterWorld Guest from 54.196.62.23
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
Forum Library, Charter, Moderator: open

JavaScript and AJAX Forum

    
'Including' files (js, ssi, php, dw...) -- your thoughts?
Advantages, disadvantages, caveats...?
ThatAdamGuy

10+ Year Member



 
Msg#: 256 posted 12:36 am on Jan 11, 2003 (gmt 0)

Hi there,

I recently asked about performance issues with regards to using SSI (Server Side Includes) to include elements in Web pages. (see [webmasterworld.com...] )

I'd like to broaden this issue to examine aspects of using javascript, php, and Dreamweaver (Libraries) to insert elements such as navbars, footers, and so on... especially in the context of cgi-generated HTML pages.

I had previously been using Dreamweaver MX's "Library" function to include repeating elements (like footers) in pages, but got tired of always having to re-upload my entire site every time I made a change. So I switched to SSI-based includes.

The problem I quickly discovered, however, was that dynamically generated pages via CGI (like feedback form acknowledgements, database-driven results pages, and so on) don't parse SSI! :-(

I'm guessing they wouldn't parse php stuff either, right?

How about javascript?
I'm aware that not everyone has javascript turned on in their browsers, but from my understanding, the js-naysayers are only about 2% of users, right? Probably the same users that are using NS 4.7 that I don't code for anyway, I'm guessing? :)

So anyway, I'd love to hear from you regarding your thoughts on the advantages, disadvantages, and caveats of using the following to include elements in pages:
- SSI
- javascript
- php
- Dreamweaver Libraries
- anything else I've forgotten

Thanks very much!

Regards,
Adam

[edited by: korkus2000 at 10:27 pm (utc) on Jan. 11, 2003]
[edit reason] fixed link [/edit]

 

txbakers

WebmasterWorld Senior Member txbakers us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 256 posted 3:22 am on Jan 11, 2003 (gmt 0)

I use ASP and use lots of include files.

dingman

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 256 posted 5:16 am on Jan 11, 2003 (gmt 0)

Same deal, only with PHP ;)

Why would you want to use SSI in a CGI, PHP, ASP, or Perl generated page? You've already got a complete programming language capable of doing the includes itself.

Thought on the specific solutions:

SSI - Works as long as your needs are simple and will not grow.

Javascript - Text mode browsers? Spiders? Handheld browsers? People w/o Java? General potential for weirdness when you don't have any control over the execution environment? I'd limit it to stuff that is not essential to the use of the page. Form input validation as a user convenience, that kind of thing. (*never* *ever* use anything client side as your only validation. Not even once.)

PHP, Perl, ASP, JSP - Server-side. Excellent. Here, you have a single known execution environment, and the output is straight HTML, so it works on anything. I'm a fan. Personally, I use a lot of PHP, a little Perl, and none of the other two.

DW libraries - huh? I code by hand, in Xemacs.

tedster

WebmasterWorld Senior Member tedster us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 256 posted 5:35 am on Jan 11, 2003 (gmt 0)

This is slightly off topic, but I want to take another stab at countering some commonly held misinformation. Java and javascript are not related, although they can interact. Browsers with no Java Virtual Machine are still very capable of executing javascript. They are NOT "java scripts".

Back on topic now -- as far a search engines go, getting scripts into external files helps you. Further, external js and css files are cached by the browser, improving download on subsequent pages that use the same files. Maintenance is also made easier - one edit can change many pages.

SSI has no effect on the search engines or the cache -- they both get a document with the includes already in place. But the imporvement in easy maintenance is still a delight.

AFAIK, Dreamweaver libraries are commonly used javascript and css files. Because they try to serve a broad section of needs, they also tend to be bloated code for your own individual purposes - but other thatn that, all the advantages of external files can be there.

gsx

10+ Year Member



 
Msg#: 256 posted 10:46 am on Jan 11, 2003 (gmt 0)

SSI doesn't work because you are sending the wrong headers? (I think)

Content-type: text/html

Is incorrect, you are sending a shtml document.

I use SSI within a set of Perl generated documents:

open(<INF>, "filetoshow.html"); @footer = <INF>; close(<INF>);
foreach $footer (@footer) { print $footer."\n"; }

As simple as that, but check the links and graphics work as you may be in a different directory - using s/// to alter them works a treat.

chiyo

WebmasterWorld Senior Member chiyo us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 256 posted 11:08 am on Jan 11, 2003 (gmt 0)

We sometimes use external js for rotating scripts for our ads. Our advertisers are not interested or dont know about PR so dont get hung up about that, and search engines (I think still) dont parse links in js.

We once thought of going to a more sophisticated PHP solution, but though best to leave things as they were! (Hope you are not listening GoogleGuy!)

So thats another reason why js "includes" can be useful.

MWpro

10+ Year Member



 
Msg#: 256 posted 7:25 pm on Jan 11, 2003 (gmt 0)

definately php includes. I swear by them.

DrDoc

WebmasterWorld Senior Member drdoc us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 256 posted 8:43 pm on Jan 11, 2003 (gmt 0)

You can make any page parse for SSI .. as long as you have root access to the server.

The reason why dynamically generated pages (printed directly to the browser) can't display SSI content is that the web server has little to do with them. SSI happens on the server before the page is sent to the browser.

If SSI is critical in dynamically generated pages I suggest that you let the script write to a file (*.shtml) and then send that link to the browser (using print "Location: path_to_file\n\n";)

As far as advantage/disadvantage .. Everything you can do on the server side is definately an advantage (as long as it doesn't require a lot of server capacity of course)

Otherwise, as long as it doesn't slow down on the client side you should be ok, no matter the method you use.

andreasfriedrich

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 256 posted 9:44 pm on Jan 11, 2003 (gmt 0)

You are talking about three kind of including techniques here:

  1. server side includes

    server side scripting languages

    I do not think of server side scripting languages as falling within this category. Generally a script will handle certain types of requests. There is really nothing there at first that you could include anything to. Of course most languages will provide some syntactical construct for some kind of modular programming. Only in the widest sense of including techniques you might like to subsume these under 'Including' files.

    Using server side scripting gives you the freedom to do whatever is possible using that language. Of course this comes at the price of having to learn such a programming language.

    content handling modules

    Languages that may be used to write such modules (Perl, C(+{1,2}¦#), Delphi, etc) have some form of include syntax as well. So the same objections as mentioned above apply for these modules as well.

    With those modules you are sitting within the server and have the full power of the server´s API to play around with. You can build handler chains, reconfiguer the server, etc. Since these modules run within the server process there is need to start a new process as is the case with CGI.

    Using server modules you can crash the whole server. So use with care and only after extensive testing.

    SSI

    SSI in the technical sense as provided by Apache´s mod_include and other servers´ similar modules is an including technique in the strict sense of the term. You have a base document into which certain other files are included.

    Easy to use and easy to learn. Not that powerful but a lot more powerful then most people think if all you want to do is to include something.

  2. client side includes

    Those encompass a whole range of techniques.

    visual

    The iframe element can be used to include an inline subwindow.

    The object [w3.org] element can be used to include a whole lot of different objects.

    The frame element can be used to inlude a tiled window within a frameset.

    The applet element can be used to include a Java applet.

    The img [w3.org] element can be used to include an image into your document´s text flow.

    structural

    The script [w3.org] element can be used to include external files via its src attribute.

    The link [w3.org] element can be used to include external script and stylesheets.

    @import can be used from within CSS to include an external stylesheet.

  3. design time includes

    Most HTML editors have some kind of proprietary includes system. Most CMS (if they have some sort of offline preprocessing capabilities) systems provide some methods for design time includes.

    Doing whatever can be done at design/upload time will save processing time on the server. Combined with a decent tool to syncronize files with the server this is a solution I like very much. Bear in mind that my CMS produces PHP files which allows for the truly dynamic things to be done on the server.

    It is true that you need to upload some files when you make changes but that is ok if you only update files that were really changed. If you leave truly dynamic things to server side scripting than this is a great way to use your resources efficiently.

    That way you can have your CMS produce a PDF or Word/Excel/Powerpoint version of your project at upload/compile time. Of course one could let the webserver do that once when the document is requested and cache it for later requests but I like the philosophy of letting your http server serve http requests very much.

Andreas

andreasfriedrich

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 256 posted 9:52 pm on Jan 11, 2003 (gmt 0)

I use SSI within a set of Perl generated documents:

open(<INF>, "filetoshow.html"); @footer = <INF>; close(<INF>);
foreach $footer (@footer) { print $footer."\n"; }

Why not just use print <INF>; after opening the file? If you are concerned about memory usage then you should use a while(<INF>) loop instead of reading the whole file into an array at once and then looping over it.

You do not need to add a newline to each line as the newline is included in the line(s) returned by the angle operator. To be sure you wouldn´t need a newline at all in your HTML output.

Andreas

dingman

WebmasterWorld Senior Member 10+ Year Member



 
Msg#: 256 posted 10:07 pm on Jan 11, 2003 (gmt 0)

To be sure you wouldn´t need a newline at all in your HTML output.

Certainly not necessary, but I often add newlines and tabs to generated HTML just so that it will be easier to read if I want to look at the output myself later. 'Course, I have yet to come up against the bandwidth issues that some people cite as a reason to remove whitespace from the code.

BTW, nice post Andreas.

ThatAdamGuy

10+ Year Member



 
Msg#: 256 posted 6:25 am on Jan 14, 2003 (gmt 0)

Okay, I must humbly admit that the last bunch of posts went zzzzzzzt over my head! :-(

However, I have decided to go with php, largely because I've discovered so many neato scripts and add-ons that are available, particularly with the blog software I currently use.

And luckily, at this time, I think I've managed to bypass the need to have cgi-script output parsed for php.

Thank you to the many of you who offered me interesting and useful information on different methods for including elements into Web pages.

[edited by: tedster at 7:18 am (utc) on Jan. 14, 2003]

BlobFisk

WebmasterWorld Senior Member blobfisk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 256 posted 10:18 am on Jan 14, 2003 (gmt 0)

One thing to bear in mind when choosing a Server Side Language is what languages does your hosting service support?

If you run and maintain your own server, fantastic - then you just install PHP. However, if you are using a Windows server, many hosting services may not support PHP files, only ASP and cgi/perl. Having said that, most hosting services seem to use *nix servers with PHP support and some even support bother PHP and ASP... although JSP support seems quite thin on the ground.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / JavaScript and AJAX
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved