[PHP] OOP/Organization - Including files

[s-p-n]

So I've decided to redo much of the WysGUI brain with OOP. Not only did this increase load time & functionality significantly, it made me more clearly see & read the code. I think it looks more lean as well.

The content loading works great, and there aren't any problems.. that I've found yet. In fact, this system made it right away compatible for content in the Header, L/R Sidebars, Body, or Footer. In fact, you can even make a custom template with more/less parents [or sections] and get it to work (after I write the new and improved docs that go with it). Technically, it's possible to make sub-section parents, but I need to work some things out, experiment, and release docs.

Now, I also decided to redo the module include system. Thaat's where it got a bit ugly. All was good at first until I noticed something when I logged in. It went much faster, but something was missing. Oh yeah, the welcome message. It's stored in the `action.php` part of the module. Note that each module composes of 4 core include files. The message is stored in a regular variable called $goodMsg. It is then called to & displayed in the `form.php` part of the module. Before when I did it procedurally, everything worked as expected. The include was being executed on the page the user sees. So all of the variables & functions were all treated as if they were included precisely the part of the page they were told.

So that's when I noticed variables are lost if you include a page through a function() method, as opposed to just saying `include($moduleRow['settings']);` with a procedural method.

- Let me stop for a second and start again by saying this:
If you create a new page called `pageName.php`, It's organized like this:

[INDENT]pageName.php
- template.php
- - include brain.
- - call Module Class [MC]
- - include module settings/action
- - begin constructing <HTML>.
- - include <head> data & module head data
- - begin constructing <body>
- - call Content Class [CC]
- - - Note: [apply [MC] if content type is module, and puts `form.php` where it belongs.]
- - apply [CC] to header.
- - apply [CC] to l_sidebar.
- - apply [CC] to mainbody.
- - apply [CC] to R_sidebar.
- - apply [CC] to footer.
- - end.
[/INDENT]

So I imagine the problem is most likely in the Module Class.

I include this page into the template. [brain's action. {settings, head_data & form closely follow this method}]

<?php
$action = new load_from_module();
    $action->type = 'action';
    $action->url = $thisURL;
    $action->place();
    $errMsg .= $action->error_message; //temp. work around
    $goodMsg .= $action->good_message; //temp. work around
?>

The `load_from_module` class is preloaded inside the brain because it's going to be used on every page. Just like content. That's pretty much it...

So here's the code for the module class:

<?php
class load_from_module extends MySQL_Connect
{
    
    public $type,
    $url,
    $error_message, //Temp. Work Around
    $good_message; //Temp. Work Around
    private $include_path;
    
    
    private function load()
    {
        $this->connect();
        $query = mysql_query('SELECT `'.$this->type.'` FROM `modules` 
                                WHERE `pageURL` = "'.$this->url.'" 
                                OR `pageURL` = "*"');
        $t = 0;
        while($row = mysql_fetch_array($query)) 
        {
            if(file_exists($row[$this->type])) 
            {
                $t++;
                $this->include_path[$t] = $row[$this->type];
            }
            else 
            {
                $this->error_message = '<p>Could not load Module `'.$this->type.'` for ''.$row[$this->type].''.</p>';
            }
        }
        
    return $t>0 ? true : false;
    }
    
    
    public function place()
    {
        if($this->load())
        {
            
            for($i=0;$i<=count($this->include_path);$i++)
            {
                if( file_exists($this->include_path[$i]) ) include($this->include_path[$i]);
                $this->error_message = $errMsg; //Work Around for Failing Error Messages.
                $this->good_message = $goodMsg; //Work Around for Failing Good Messages.
            }
            return true;
        }
    }
    
}

?>

Notice the Work Arounds. Those are temporary until I sort this out. There must be a way for you to connect variables between different parts of modules. That's a tiny, yet key peace to my goal for a versatile engine. I want to use this one function, place() to place every single part to every single module, on every single page it's assigned to. That's why when I click "Log In" on the lean login page, I can hardly blink twice before the page notifies me I'm logged in. [only notifies me after the work-around :]


Moving onto a possible solution:

Here's one way it might work, that I don't really approve of, but it's not that bad..

I include this page into the template. [instead of the last one]

<?php
$action = new load_from_module();
    $action->type = 'action';
    $action->url = $thisURL;
    if($action->load())
        for($i=0;$i<=count($action->include_path);$i++)
            if( file_exists($action->include_path[$i]) )
                include($action->include_path[$i]);
?>

With this method, I'd have to make load() & $include_path public. Which isn't a problem except for the fact that $this->connect() is protected. Other than that, the whole thing is run by $type & $url.. which are public. I just don't know if it will connect globally or just within that little class.. Actually I think MySQL connections will be fine. If not, I'll make that work.

I would also have to execute these lines of code 4 times. [action, settings, head_data, and form].

The only role the class plays is loading the data from MySQL into an array. From there, it's all procedural.

The only way to make a connection is to extend the connection class. However, you do not need to worry about MySQL connections when working within modules because it's included within a function within that class, so technically, it already is extending MySQL_Connect and makes a connection when load() is called. With that said, calling $action->load() should make a root connection.

My question: Is there a better method for using classes & functions for including pages, or do I have to make a Frankenstein OOP+Procedural mess on 4 pages like I provided above? -> :ehh:

Oh yeah, and what's a Method do again? That must be what solves my problem *Re-Researches* :/:

Edit: Oh wait, is a method just a function/variable in a class?

 

[Daevius]

A method is a function of a class, aka a member function. Data members are variables of a class.

As to your problem, I don't think you should be including the pages, but rather handle what should be done with the pages (being displayed) _within_ the page's class.

So, just something that comes up, suppose you have a main class which takes the URL passed, the theme, config files etc. Then within the main class you could analyse the URL and decide what page to be displayed (some array with strings as keys, which stores a Page class as value). This Page class is in fact a derived class of base class Page, which has an overloaded display() method (and more methods you like to share between all pages). As main class you simply call display(). Within the derived Page class you could then include several pre-made templates (or not, for flexibility).

Though better would be just one base Page class, which then displays a Smarty template file (depending on the theme) which then includes other Smarty template files it could need. Then within the Page class you include the PHP file belonging to the page and send data to Smarty as well as handling POST / GET data.

To be honest, for PHP I find OOP only reasonable with large scale projects (like yours I suppose). PHP itself is already very compact, easy to read / use, though I never really tried OOP with PHP I must admit (procedural is always so much easier and less bulky, I either have to release the code or it's really large scale before I'd be using OOP).

 

[foxx]

Is it just me, or you like a month ago tried to flame the **** out of King Izu who told you OOP is better? Wasn't it like "OOP is **** I'm not gonna use it until php 8"?

 

[s-p-n]

Is it just me, or you like a month ago tried to flame the **** out of King Izu who told you OOP is better? Wasn't it like "OOP is **** I'm not gonna use it until php 8"?

Ah, You caught me!


Actually I was supportive of using it in the brain files. I was talking about an individual module [a module to make modules :/] back then and he decided to associate it with the whole project.. or something..? I'm over it, did it procedurally, now I'm working on implementing the output of that form, {4 setting pages in a folder named the same as the module}, which eventually builds the module as 4 pieces on each page it's called on. Now I'm also working on calling the module. I'm using OOP to do these things, and never said I wouldn't.

Also, I tip my hat to King-Izu for making me do a lot more research on PHP OOP. I appologized to him privately, and now I see that the brain is much better designed with OOP then before. I even found a way to increase load-time during the process. I sure hope it works reasonable in PHP4, it's warningless in PHP5, haven't tested in PHP6, but I don't see why not. [the Brain is all of the header files including all the files which look at the url, and build the page on the template]

Anyway, moving forward ->

I'm having second thoughts, but when I said this,

Frankenstein OOP+Procedural mess

I meant I didn't want to mix the two styles. It's not easy on my brain. but I guess 3 extra lines of code won't make that much of a difference, and I live by my own rules so watch out!

Daevius! You never seize to amaze me. [You too foxx]
But I don't think WysGui and Smarty are put together the same way. You see, the pages are almost static, rather then 100% dynamic. I didn't want to use htaccess for file tricks & such, though I'm not against it.

Think of it this way->

In WysGui,

When you make a new page, it has one line of code which includes the selected skin.

That line of code is: <?php include('skins/template.php'); ?>

So all of my site's pages have that line, but it might be a different file depending on the skin I'm using.

So now we have a template file.

I sort of mapped out the structure of how the pages are put together in the first post,

- template.php
- - include brain.
- - call Module Class [MC]
- - include module settings/action
- - begin constructing <HTML>.
- - include <head> data & module head data
- - begin constructing <body>
- - call Content Class [CC]
- - - Note: [apply [MC] if content type is module, and puts `form.php` where it belongs.]
- - apply [CC] to header.
- - apply [CC] to l_sidebar.
- - apply [CC] to mainbody.
- - apply [CC] to R_sidebar.
- - apply [CC] to footer.
- - end.

Now, there's no reason to make a unique name for each file, well there is, but that's the filename. So the brain uses the filename [from the URL] to put all of the data on the page.

Each module & piece of content is assigned a page, parent, & group to be assigned to.

The main parents are the header, left sidebar, main body, right sidebar, and footer.

Groups can be anything, they just organize the content. Groups can be ascending or descending, and can be repositioned around other groups when need be.

Groups can also be rank protected. If the group rank does not include your rank, then you will not see the page. Default rank is always guest, and all ranks may see everything in a group if no rank is set. In the form view, if the group has no rank, it notifies the admin that all users may see entities within that group.

​

With all that said, the brain doesn't think about the skin or how it looks, it just grabs body parts and spits it at the skin. If the skin is put together properly, it will arrange everything in it's place. That way the page doesn't have an arm coming out of it's face. [Or a sidebar module in the header..]

To make it easy, there's just a few basic include files nested in the template.

Brain = Header Files, Thinking, Data Handleing
Skin = template/stylesheet
Body = Content/Modules

I think that rather then including the files, I should grab the whole file with file_get_contents() and put that in the array.. Hmm.. All I know is the file cannot be called to within a function, or all of the inner functions/variables will not be usable from the settings to the other parts like needed. The main problem is that I lose every function from settings.php in every module. I can only call to it within settings, and I need them to work in the action or the form in most cases.. If I can't define just one function in settings, then I need to define it twice in form & action.. Might as well not even have settings if that's the case :/ Get what I mean?

Needs to be Flexible? Yes!
I need it to be flexible.

I want to be able to type every single kind of web compatible code in that little text editor all with expected results. I want my friend Smith to use WysGui to learn PHP & HTML because it teaches good procedural practice & organization with programming & web design. At least in my opinion.

I plan on doing folders dynamically like Windows does. So you'd be able to sort by name, type, date created, last editted, last viewed. Also some new options for content & modules {or interior parts of pages}, like page, parent, group, type, date created, last editted, most views.

Each option will be Ascending the first time selected, and Descending the second time selected. Switching back and forth accordingly.

When you right click, you'll be able to more quickly edit this information.

I also have plans for modules to have a strong GUI editor, like content's WYSIWYG editor. That was NOT the plan from the start, ironicly.

Anyway, it's big. So the brain wants OOP. ~~

As always, modules are compatible with OOP. Right now, considering the current state of organization, it only works because they all extend the main class, {MySQL_Connect = main, I guess}

Oii too much typing :blink:

So basically, I got it figured out now. I guess it's destiny or something but nobody laid a hand on any of my code for WysGui yet. One person gave me a security fix and that's it.. Something I already meant to do too, but set aside and forgot about.. It wasn't even a breach because any page's icon could be seen, but if the page was rank protected it was still fine. And it would've never been possible if the admin panel was restricted from guests & registered users.. But to be perfectly honest, that was nothing I didn't already know.

Everything King-Izu said before- nothing I didn't already know.

Boy did I gain some experience since December 26, 2008 when the internet went out for 2 weeks & I first spoke the term "Smart Site" :

Everything PHP-related before that point I thank RageZone and the viewers at Coder's Paradise.

Special thanks of course, to Daevius & Frag-Frog. ~ As Always ~