February 20th, 2014 at 7:42 PM
I'll be honest. The whole page hooks system has been a bit more complicated than I expected it to be. I've decided to go with the concept still, but I'm not sure how everything being organized into one class is going to work haha. It might not be quite that simple. (This is my first "major" project, so I'm pretty much learning this stuff as I go. )
The good news is that the module hooks system is working and is fully functional. That is of course also a good thing because it was pretty simple to implement. As far as page hooks, here is the latest model I am going to attempt to use.
Page Hooks
Page hooks will actually be a group of different hooks allowing menu items, blocks, notifications, etc... to be added to the page. I've decided to do a template system, which will manage HTML templates and have variables in the templates for different menus, block panels, etc... So, a sample template might look like this:
As you can see, many of the templates will use variables that will be replaced by the template engine. However, where are these variables defined?
MyBB, for example, requires plugins to be made to add page elements that aren't included in MyBB core. Adding menus, sidebars, etc... are often done with straightup HTML in the code because it's a pain to code all of these elements into plugins. The advantage of this is that themes are only HTML templates and CSS, making it very easy to distribute PHP-free themes. However, the disadvantage is that there is less flexibility for a truly fluid page layout. Also, designing plugins that interact with the page layout is more difficult because there are no hooks in the templates, and the actual HTML has to be modified by a plugin. Because of this, not all plugins are compatible with all themes.
Adding menu links requires template edits, for example. My goal with filecave is to prevent that from being the case. The advantage of my latest "model" at the moment is that modules that interact with the page structure will be much easier to make. Menu items, blocks, layout changes, etc... will be much easier to implement. For example, if a module adds a new menu, it will not be necessary to literally code the HTML fully for the menu. It can create a new instance of the menu class, and work with that instead. Furthermore, someone could even create a plugin for that module and further modify the menu. It leaves the door wide open for customization and flexibility.
The disadvantage is that themes that take advantage of the additional functionality and create additional page elements will require a PHP file to be distributed with the theme. Wordpress requires many themes to use PHP as well, and I believe Drupal does as well (although I'm not sure, it's been a while since I messed with drupal). It has its disadvantages, but I think it will show a lot of customization potential, especially when it comes to mutli column layouts, block panels, etc...
So, in essence, the current model will have each theme distributed with a PHP "page" class that defines instances all of the menus, sidebars, etc... The theme can then make use of these new page elements by using template variables to insert them. Because all of these basic page elements will be defined in the $page class, it will be easy to implement globally, and theme designers will be able to control almost every basic aspect of their design by creating page elements as they wish. Of course not all themes will require this to be defined. The default theme's $page class will be used if a theme does not distribute an alternative, so themes that do not require PHP code will of course be possible as well. My goal is to create all of the page elements that the majority of themes will need, such as main menus, etc..., so that only highly customized themes will require the PHP functionality. Performance is also something that I'll be watching out for carefully. My goal is not to make this too server intensive.
Of course we'll see how this works out once I get more of this coded. It's a huge project to take on, and is pretty much a roadblock to further development until I get all of this completed. Anyway, what are your thoughts so far?
The good news is that the module hooks system is working and is fully functional. That is of course also a good thing because it was pretty simple to implement. As far as page hooks, here is the latest model I am going to attempt to use.
Page Hooks
Page hooks will actually be a group of different hooks allowing menu items, blocks, notifications, etc... to be added to the page. I've decided to do a template system, which will manage HTML templates and have variables in the templates for different menus, block panels, etc... So, a sample template might look like this:
Code:
{$header}
{$pagetitle}
<div class='pagebody'>
{$sidebar_left}
{$content}
</div>
{$footer}|
As you can see, many of the templates will use variables that will be replaced by the template engine. However, where are these variables defined?
MyBB, for example, requires plugins to be made to add page elements that aren't included in MyBB core. Adding menus, sidebars, etc... are often done with straightup HTML in the code because it's a pain to code all of these elements into plugins. The advantage of this is that themes are only HTML templates and CSS, making it very easy to distribute PHP-free themes. However, the disadvantage is that there is less flexibility for a truly fluid page layout. Also, designing plugins that interact with the page layout is more difficult because there are no hooks in the templates, and the actual HTML has to be modified by a plugin. Because of this, not all plugins are compatible with all themes.
Adding menu links requires template edits, for example. My goal with filecave is to prevent that from being the case. The advantage of my latest "model" at the moment is that modules that interact with the page structure will be much easier to make. Menu items, blocks, layout changes, etc... will be much easier to implement. For example, if a module adds a new menu, it will not be necessary to literally code the HTML fully for the menu. It can create a new instance of the menu class, and work with that instead. Furthermore, someone could even create a plugin for that module and further modify the menu. It leaves the door wide open for customization and flexibility.
The disadvantage is that themes that take advantage of the additional functionality and create additional page elements will require a PHP file to be distributed with the theme. Wordpress requires many themes to use PHP as well, and I believe Drupal does as well (although I'm not sure, it's been a while since I messed with drupal). It has its disadvantages, but I think it will show a lot of customization potential, especially when it comes to mutli column layouts, block panels, etc...
So, in essence, the current model will have each theme distributed with a PHP "page" class that defines instances all of the menus, sidebars, etc... The theme can then make use of these new page elements by using template variables to insert them. Because all of these basic page elements will be defined in the $page class, it will be easy to implement globally, and theme designers will be able to control almost every basic aspect of their design by creating page elements as they wish. Of course not all themes will require this to be defined. The default theme's $page class will be used if a theme does not distribute an alternative, so themes that do not require PHP code will of course be possible as well. My goal is to create all of the page elements that the majority of themes will need, such as main menus, etc..., so that only highly customized themes will require the PHP functionality. Performance is also something that I'll be watching out for carefully. My goal is not to make this too server intensive.
Of course we'll see how this works out once I get more of this coded. It's a huge project to take on, and is pretty much a roadblock to further development until I get all of this completed. Anyway, what are your thoughts so far?