How much INCLUDE is too much?

[slider]

I'm building a CMS and am entertaining thoughts of making it entirely an index.php thing, with every function of the site being written into a PHP function and stored in a series of external *.inc.php files. Everything would redirect back to index.php and a session variable could be used to determine what function the user wants to perform.

I can see this will require a lot of IF statements, but I think that may be better than a lot of files with duplicated information in them. Also layout and design will be a bit easier with index.php being the only front-line file.

I expect this system to stay relatively small, but am wondering the implications of using this idea even for medium to large scale PHP solutions.

Any thoughts?

[KillAllDash9]

From a technical standpoint, what your describing should work. However, I personally don't like that kind of layout. It makes the code harder to work on, and it adds unnecessary overhead to the system.

If your main concern is not wanting to duplicate information/functionality across different pages, just create include files with related functions/classes and include these in each of your pages. For instance, most applications that I create have an 'app_init.php' and an 'app_exit.php' file that is included at the beginning and end of each page respectively. 'app_init.php' takes care of things like starting a session, turning on output buffering, creating a template object, including class files that are frequently used, etc., and 'app_exit.php' takes care of cleanup tasks such as flushing the buffer, error reporting, etc.

[noise]

ok i think i made a misstake here...
i'm not sure if i understand yall but chanses are that i have been doing things like slider here was thinking...
i would like to hear more about diffrerent ways to navigate and include, remove, replace header, body etc.. etc...

although.. i could be way of here.. noob

anyway.. here is how my current project looks like..
index.php

<?php

include 'header.php';

if (isset($_GET['link_loop'])) {

    switch ($_GET['link_loop']) {



        case "1";

        include 'incl_def.php';

        break;



        case "2";

        include 'incl_pedagogisk_plattform.php';

        break;



        case "3";

        include 'incl_koanmalan.php';

        break;



        case "3_submit";

        include 'incl_koanmalan_code.php';

        break;



        default:

        include 'incl_def.php';

    }



} else {

    include 'incl_def.php';

}



include 'right.php';

include 'footer.php';





?>

that was the entire file.. but i just started on this site and what you see is like
1 default body
1 simple page with text
1 submission form containing 2 files that needs to be included...

oh i dont wanna anoy you with this.. would just like to know of other way to do this...

thanx

//noise

[Alarion]

noise, that is *sort of* what I was doing with EQGMS

Although, what I did was make a page for each section (news.php, admin.php, events.php, etc).

The index file would always handle the request, and parse the query string, and example of which would look something like this:

index.php?section=news&op=post_news

index.php would then look at the section argument and call the appropriate file (news.php in this case).

in news.php there is an include that calls api/news.api.php while houses all the news-related functions.

news.php then parses the "op" argument (through a rather lengthy case statement, similar to what you listed) and call the appropriate function.

the entire process looked similar to this (some code snippets from EQGMS)

index.php

include_once("header.php");

include_once("footer.php");



if (isset($HTTP_GET_VARS['section'])) {

    switch($HTTP_GET_VARS['section']) {

        case 'user':

            include_once("user.php");

            break;

        case 'admin':

            include_once("admin.php");

            break;

        case 'events':

            include_once("events.php");

            break;

        case 'news':

        default:

            include_once("news.php");

            break;

    }

} else {

    include_once("news.php");

} 

now, here is news.php as an example of what is going on there

include_once("api/news.api.php");



if (isset($HTTP_GET_VARS['op'])) {

    switch ($HTTP_GET_VARS['op']) {

        case 'viewnews':

            $news_body = news_view($config);

            break;

        ...

        default:

            break;

    }

} else if(isset($HTTP_POST_VARS['op'])) {

    switch($HTTP_POST_VARS['op']) {

        case 'post_comment':

            post_comment();            

            break;

        ...

        default:

            break;

    }

} else {

    $news_body = news_summary(10);

}



// this loads a template.. don't worry about this 

$templates = array();

$templates['news_page'] = '';

$newspage = '';



load_templates($templates, $config['template_set']);



eval("\$newspage = \"{$templates['news_page']}\";");

// $newspage now holds HTML from the template

// $page_header and $page_footer are previously defined and contain HTML

echo $page_header;

echo $newspage;

echo $page_footer; 

I hope that helps you out some -- although, it might have confused you more than helped

Slider,
Using an include system is very viable, especially for a smaller system.

For a larger system, I don't see *too* much overhead occuring if you use case statments. A large if/else if block might not be too bad either.

I have recently been experimenting with including the function name in the query string. something like:

index.php?class=News&method=PostComment&id=10

I have successfully been able to call, for example, the $$_GET['class']News->$$_GET['method']() method, but it gets kind of fuzzy when trying to access arguments, which will probably have to be ripped from the query string. I don't remember the exact syntax I used, but it was similar to the above.

this totally eliminates if/else/if blocks, as well as case statements -- possibly allowing your application/cms to scale quite a bit higher. I don't have any examples of this here at work, but if you would like one, just say so and I will post what I have at home (when I get ther)

[slider]

What a trip. Alarion, your EQGMS is exactly what I'm building. Though I'm still in the preliminary stages of it, lots of planning still to do even. I even envisioned/planned v2.0 with full phpBB integration. How long have you been working on EQGMS? How many hours would you say you've put into it already? Is it just you working on it alone?

The reason I'm thinking of doing it all through includes is cause the layout is all the same. I'm going to have a little box in the upper left corner that will either display login fields (if you're not authenticated) or a welcome message (if you're authenticated). I'm going to have a top navigation area with links to the overall site areas, and a left navigation area with links to the separate functions within each major site area. I see no reason to make separate files to do all this, as the header, nav panels, login/authentication box will all be in includes, and then the main page area (think frames here, but done without frames) will just be variable based on whatever the user is wanting to do/see. If a single session variable is used to track what "function" the user is wanting to perform the main page area could simply be an include for that specific function. While I was just gone to class after I posted this thread I even thought of a way to do this without having to use any IF or case statements. And if you look at it right, it is exactly the opposite (if that's the right word...) method from using separate front-end files. I'll be using separate back-end (include) files. Each one of the include files will simply be named appropriately so that as a user navigates around the site, the session variable can be used inline to include the appropriate back-end file. The user wants to see the news?

$_SESSION['action'] = "news"; redirect to self...

top of index main include is simply include ($_SESSION['action'].inc.php);

Other includes will be standard, layout will be standard, no need to have separate front-end files. index.php covers all the bases. I think using the above it's even scalable to a large degree, though that would need to be tested.

Further thoughts?

[Alarion]

that's also a good idea, actually. That's sort of the way my database abstraction library works (actually, most PHP DB Abstraction libraries work like this).

the main included file includes the appropriate "driver" file and calls functions which are redefined in each include file. Applying this to a CMS, your presentation layer would be your drivers, but they would be things like "news" or "forums" etc...

as for EQGMS.. I mainly worked on it at work when things were slow (shhh, don't tell my boss) I would say it took... less than 60 man hours. that includes database design, template input, etc. while that might sound like a lot, there were a lot of things I had to figure out (mainly algorithms).. like nested comments and a halfway efficient way to display and navigate them (nested, slashdot-style comment system)

I think I started the project a little over a year ago

[slider]

I downloaded your files from sourceforge, but haven't looked at them yet. What state is your project in at present?

[KillAllDash9]

What I'm curious about is the actual benefit you are realizing by having everything be parsed through 'index.php' as opposed to having a real URI for the information someone is trying to get to and simply including a header and footer file in that page which holds the global functionality that needs to be present.

[slider]

Originally posted by KillAllDash9
What I'm curious about is the actual benefit you are realizing by having everything be parsed through 'index.php' as opposed to having a real URI for the information someone is trying to get to and simply including a header and footer file in that page which holds the global functionality that needs to be present.

Well, I don't know really. I was trying to figure that out. I'm still new to this and my project is still in its very early stages. I think after working on it tonight I've decided that parsing everything through index.php isn't very viable.

I had a nice epiphany earlier, but you know how epiphanies can go... wasn't all that practical once I really worked out all the details.

[noise]

lol

What a trip. Alarion, your EQGMS is exactly what I'm building. Though I'm still in the preliminary stages of it, lots of planning still to do even. I even envisioned/planned v2.0 with full phpBB integration. How long have you been working on EQGMS? How many hours would you say you've put into it already? Is it just you working on it alone?

hehe same here...
here is what i'm doing on a another site:
let's say that site has 9 different MAIN MENU links (9 different main sections of the site, like "lyrics, contact, links, etc)

here is a snippet of MAIN menu:

<a class="link1" href="test_main.php?main_menu_loop_id=5&sub_menu_loop_id=lyrics_def">...lyrics</a>

<a class="link1" href="test_main.php?main_menu_loop_id=9&sub_menu_main_id=main_def">...main_page</a> 

and within every og those 9 there are couple submenus:
like... lyrics -> (def.php search_db.php, submit_lyrics,.. etc)

here is SUBmenu of lyrics section:

<a class="link2" href="test_main.php?main_menu_loop_id=5&sub_menu_loop_id=lyrics_def">updates</a>

<a class="link2" href="test_main.php?main_menu_loop_id=5&sub_menu_loop_id=lyrics_2">search</a>

<a class="link2" href="test_main.php?main_menu_loop_id=5&sub_menu_loop_id=lyrics_3">upload</a>

<a class="link2" href="test_main.php?main_menu_loop_id=5&sub_menu_loop_id=lyrics_4">rules</a> 

this is test_main.php (like INDEX.php)
all includes are handled here...

<?php



include ('include_static/main_include_static/main_2_page2.php');

include ('include_static/main_include_static/main_3_page3.php');









///////////////////////////////////////////////////////////////////////////////////////

////                                                                main_menu_loop_id  ////

///////////////////////////////////////////////////////////////////////////////////////



if (isset( $_GET['main_menu_loop_id'])) {

    switch( $_GET['main_menu_loop_id'] )  {

            

            case "5";

                include ('../../admin/include_dynamic/lyrics_include_dynamic/lyrics_4_page4.php');

                break;



            case "9";

                include ('../../admin/include_dynamic/main_include_dynamic/main_4_page4.php');

                break;





            default:

                print( '<font size="10px"><b>SYS_ERROR \

                            ...page does not exist!!!</font><font size="3px">

                <br><br>contact sys admin at [email]noise@mindless.com[/email]</font></b>' );



    }

} else {

    include ('../../admin/include_dynamic/main_include_dynamic/main_4_page4.php');

}







/////// sub menu main start //////////////////////////////////////////////////////////////////////////////////////////////////





if (isset ( $_GET['sub_menu_loop_id'])) {

    switch( $_GET['sub_menu_loop_id'] )  {

        case "main_def";

            include ('../../admin/include_dynamic/main_include_dynamic/main_5_1_page1.php');

            break;



        case "main_2";

            include ('../../admin/include_dynamic/main_include_dynamic/main_5_2_page2.php');

            break;



        case "main_3";

            include ('../../admin/include_dynamic/main_include_dynamic/main_5_3_page3.php');

            break;



        case "main_4";

            include ('../../admin/include_dynamic/main_include_dynamic/main_5_4_page4.php');

            break;



/////// sub menu lyrics start //////////////////////////////////////////////////////////////////////////////////////////////////



        case "lyrics_def";

            include ('../../admin/include_dynamic/lyrics_include_dynamic/lyrics_5_1_page1.php');

            break;



        case "lyrics_2";

            include ('../../admin/include_dynamic/lyrics_include_dynamic/lyrics_5_2_page2.php');

            break;



        case "lyrics_2_search";

            include ('../../admin/include_dynamic/lyrics_include_dynamic/search.php');

            break;



        case "lyrics_2_list";

            include ('../../admin/include_dynamic/lyrics_include_dynamic/show_list.php');

            break;



        case "lyrics_3";

            include ('../../admin/include_dynamic/lyrics_include_dynamic/lyrics_5_3_page3.php');

            break;



        case "lyrics_4";

            include ('../../admin/include_dynamic/lyrics_include_dynamic/lyrics_5_4_page4.php');

            break;

    }

} else {

    include ('../../admin/include_dynamic/main_include_dynamic/main_5_1_page1.php');

}









include ('include_static/main_include_static/main_6_page6.php');

include ('include_static/main_include_static/main_7_page7.php');

include ('include_static/main_include_static/main_8_page8.php');





?>

and it works pretty good but i'm kinda worried about what happens later on when i'm workin on the last section. i have a feeling that it's gonna get very very complicated deeling with links and navigation, include files etc.

One more thing... i noticed that every path i put in (image, dir, etc) anywhere in any dir/file.. path is always starting from the dir that test_main.php is in (INDEX.php).

but i want to know more about what KillAllDash9 said earlier:

From a technical standpoint, what your describing should work. However, I personally don't like that kind of layout. It makes the code harder to work on, and it adds unnecessary overhead to the system.

If your main concern is not wanting to duplicate information/functionality across different pages, just create include files with related functions/classes and include these in each of your pages. For instance, most applications that I create have an 'app_init.php' and an 'app_exit.php' file that is included at the beginning and end of each page respectively. 'app_init.php' takes care of things like starting a session, turning on output buffering, creating a template object, including class files that are frequently used, etc., and 'app_exit.php' takes care of cleanup tasks such as flushing the buffer, error reporting, etc.

sounds lill simpler.. but i did'nt understand quite well

*all this prolly looks like a n00b's way of doing things.. but that's just what i am..

//noise

[KillAllDash9]

Originally posted by noise
but i want to know more about what KillAllDash9 said earlier

sounds lill simpler.. but i did'nt understand quite well

Basicly what I mean is that each "page" contains only the logic for displaying the information that a particular visitor wants to see or the action they wish to perform. Let's take a simple diary/photo-album personal site for example.

This site would have the following areas:

Homepage - lists the last diary post and displays thumbnails of five most-recently added pictures.

Date Index - lists diary entries and photos by date, shows date and title for x entries at a time with previous/next buttons.

Topical Index - lists topics that diary entries and photos appear under, clicking a topic takes you to a list of entries for that topic.

Diary Entry - displays a single diary entry.

Photo - displays a single photo with caption.

Admin section - it would have to be there, but I won't describe it here for the sake of brevity.

Let's also say that you require visitors to login to the site before they can read entries or view photos (wouldn't want your boss to know what you really think of him now, would you?)

There is certain functionality that should be present in every single page. You will need to start a session to keep track of the logged-in user, you will need to access the database on each page, and you want to use output buffering on each page. You might write a script called 'app_init.php' with the following:

<?php

ob_start();

session_start();



define('APP_FS_ROOT', '/var/www/mysite/mydiary'); //the physical path to this application

define('APP_SITE_ROOT', '/mydiary'); //the path to this application relative to your website's virtual root

define('APP_SITE_URL', 'www.example.com'); //the hostname of your website

define('APP_SSL_ENABLED', FALSE); //whether or not the server supports SSL encryption



require_once(APP_FS_ROOT . '/inc/classes/DBConnection.php'); //include the file for your database class

require_once(APP_FS_ROOT . '/inc/classes/DBQuery.php'); //include file for database query class

$objDB = new DBConn('host', 'database', 'username', 'password'); //create a database connection object (this is just an example)



require_once(APP_FS_ROOT . '/inc/classes/Template.php'); //include the file with your template class

$objTpl = new Template(APP_FS_ROOT . '/inc/Templates'); //create a template object



require_once(APP_FS_ROOT . '/inc/classes/Page.php'); //include the class for a page object.



$objPage = new Page($objTpl); //create the page object (tracks information such as page title and body contents) and pass it the template object so it can create it's own output.

?>

and you might write a script called 'app_exit.php' with:

<?php

echo $objPage->Assemble(); //assemble the page information and output result



//cleanup objects generated in 'app_init.php'

unset($objPage);

$objDB->Close();

unset($objDB);

unset($objTpl);



ob_end_flush(); //send output to browser

?>

These two files hold all the logic that needs to be present in every one of your other scripts (or at least the vast majority of them). They are included at the top and bottom, of these scripts, respectively. So your homepage at 'index.php' might look like this:

<?php

require_once('inc/app_init.php');

$objPage->setTitle('Home Page - Diary of KillAllDash9);

$objPage->setTemplate('standard_layout.html');



$strQ = "SELECT PDate, Title, Body FROM Diary ORDER BY PDate DESC LIMIT 1";



$objQ = new DBQuery($strQ, $objDB);

if ($objQ->Execute() && ($objQ->getNumRows() == 1)) {

  $objData = $objQ->fetchRowAsObject();

  $objPage->appendBody($objTpl->Process('diary_entry.html', $objData));

} else {

  trigger_error("Unable to retrieve last diary entry.", E_USER_NOTICE);

}



$strQ = "SELECT Id, ThumbPath FROM Pictures ORDER BY PDate DESC LIMIT 5";



$objQ = new DBQuery($strQ, $objDB);

if ($objQ->Execute() && ($objQ->getNumRows() > 0)) {

  while ($objData = $objQ->fetchRowAsObject()) {

    $objPage->appendBody($objTpl->Process('image_thumb.html', $objData));

  }

} else {

  trigger_error("Unable to retireve any image thumbnails.", E_USER_NOTICE);

}

require_once('inc/app_exit.php');

?>

In this way, the only code in index.php is code that deals directly with displaying the information that appears on index.php. All of my navigation, authentication, etc that is applicable to the entire site is handled by logic either within or included by 'app_init.php' and 'app_exit.php'.

Note: the database connection (DBConnection), database query (DBQuery), and Template classes are examples only. Don't get to bent on figuring out that syntax if you don't get it right away. :-)

[slider]

The thing that's sticking the index.php idea in my head is the great way that frames worked (we all know frames suck, but that's for reasons other than their great way of presenting your site). I guess I've been trying to design a frames-based site without frames. Everything (nearly) in my site is going to be the same except for the main display area, so why not have it be the same front-line file, and that file simply calls appropriate functions through includes for what it needs to display in the main display area? That's my thinking. I don't think it will work too well, so I'm rethinking the entire design (not that I have much yet to have to rework).

What I'm getting interested in now, especially after reading your above post kill, is object stuffs, and templating. I don't know jack about either. Where can I go to learn that stuff? How much do you think it applies to what we've been talking about?

Thanks.

[KillAllDash9]

Originally posted by slider
What I'm getting interested in now, especially after reading your above post kill, is object stuffs, and templating. I don't know jack about either. Where can I go to learn that stuff? How much do you think it applies to what we've been talking about?

Well, I think it applies 100% based on your statements about frames. By using OOP (Object Oriented Programming) and presentation templates, you allow yourself to code something once and use it across multiple pages (and even multiple projects).

For instance, in the 'index.php' example I gave above, there is the following command (more or less):

$objTpl->Process('diary_entry.html', $objData); 

Now, $objData is an object with properties that describe a diary entry: the post date, the title, and the body. If we were to define this class, it would look like:

class DiaryEntry

{

  var $PDate;

  var $Title;

  var $Body;

} 

Of course, we don't have to define it, because it is created automaticly based on the class stdClass that is built into PHP, but that at least describes the properties of the object at this point.

However, the object itself doesn't know how to display the data to the user. I use a template object to take care of this, because the goal is to seperate the data form the presentation. So our template file, 'diary_entry.html', might look like this:

<h1><?php echo $objData->Title; ?></h1>

<strong>Posted on: <?php echo date('m/d/Y H:i:s', $objData->PDate); ?></strong>

<p><?php echo nl2br($objData->Body); ?></p>

When we call the Process method of the template object, we basicly combine the data in $objData with the template. By separating this into a template, we can then use the same template that we used on the homepage on the page that displays specific posts (selected from either the 'date' or the 'topical' indexes described in my prior post.)

Basicly, code it once, use it wherever.

[noise]

i definitly think that i need to learn some more before i get my hands on OO

gonna go trough this book first and then give it a try...
when you say, "code it once use it whenever",
i'm thinking
well i prolly could manage to get trough it and finnaly produce the code. but then what?
i'm in the learning process and "code it once" would'nt give me much i think... specially when i realise that i have no basic ground to stand on.

thanx for the advice.. gona print it out and save it for later reading

//noise

[KillAllDash9]

Yeah, you definately need to learn the basics of the language before you can really make the best use of OOP. :-) I remember some scripts I wrote when I was first starting out that were almost 100% procedural code. Looking back, "Ick" is the only thing I can say if I think about all the wasted lines of code and inneficient programming. However, I also know I wouldn't be at the level I am now had I not gone through that stage. And I also know I still have a long way to go, and that in 5 years I'll probably look back on the stuff I'm coding today with that same thought.

[Alarion]

I think KAD9 summed that up pretty well.

A programmer is always learning new things (techniques and technologies, etc). Every year, one could probably look back at something they coded and think "why the heck did I do THAT?!"

Stick with it though, it will come in time.

[noise]

So true! And the same goes for moste of the things in life, a specially if you are dealing with some kind of creation process. "The more you learn the less you know"