Custom Framework

[steelmanronald06]

I am working on a custom framework.  It isn't much, but I still want to do it.  It will have a PM system in it, a mail system, database abstraction layer (to come later), and a few other things I find myself using over and over when I create sites. I would also like to offer this as a download for others, an open source project. However, I'm stuck.  I understand that a framework is huge folder, with many different files and folders in it, each containing oop, so that when you call one of the files it draws all the functions from its matching folder to allow you to use the pre-made functions. 

So my question is, what is some basic structure things I should be aware of?  Any advice on this would be great.

[trq]

There is [b]alot[/b] more to a framework than a ...

[quote]huge folder, with many different files and folders in it, each containing oop, so that when you call one of the files it draws all the functions from its matching folder to allow you to use the pre-made functions.[/quote]

If you are serious about developing a framework that you think people will be interested in downloading you might try using some of the frameworks that are allready available. There are plenty of great frameworks available for php and using them will give you a great insight as to how they work, as well as give you some ideas on what you really want to do with yours. Honestly, I think you'd be real hard pressed to improve on something like [i]cake[/i] or [i]symphony[/i], though saying that.. there are still plenty of good reasons to roll your own.

[redbullmarky]

i'd actually say that cake could be improved. whilst it's not too hard to pick up and is bloody good, it's still somewhat 'heavy' and comes with a learning curve that others are starting to bring down.

but i do agree that looking at existing frameworks will greatly help with the structure. as i'm building mine, i'm using 3 frameworks as reference points - CodeIgniter (www.codeigniter.com), CakePHP (www.cakephp.org) and rails (www.rubyonrails.org). All three are actually very similar implementations of the MVC structure.

personally, what i've tried to do is to keep my framework and application completely seperate. in effect, i have two folders. my httpdocs, which contains my app specific stuff, and my framework folder. the essentials of these is the index.php in the httpdocs. literally all this does is to include a single file in my framework directory, which does the job off pulling everything together automatically.

httpdocs: img folder, js folder, css folder, app folder (containing my app specific config, code and templates), index.php

framework: framework.php, libraries folder (including template engine, DB, PDF handling classes etc), helpers folder.

this way, i never have to touch the framework. all i need to do is make a few tweaks to the app config file, tell the index.php where my framework is located, and voila - my framework does the rest. as i've forced a structure, its very easy for my framework to work out where all its bits and pieces are automatically.

[trq]

Im in love with [url=http://www.djangoproject.com/]django[/url] at the moment, a web framework built on mod_python. Much the same sorts of ideas as ROR, yeah... another MVC implimentation.

Its just so nice to have the framework do most of the work, setting up database tables and fields and even building a default backend website for administration. Of course, you customise the backend, but just the fact that alot of it is built for you gets things done REAL quick.

[Jenk]

Take a look at the Zend Framework preview.

[448191]

[quote author=Jenk link=topic=114286.msg465488#msg465488 date=1163089901]
Take a look at the Zend Framework preview.
[/quote]

LOL, I hate to agree with Jenk AGAIN  :P, but I do. If your looking for a clean OOP framework, ZF is what you should be looking at. It's not finished, but it still provides a good look into solid implementation of MVC frameworks. You'll need to get some understanding of the MVC first though, or it will make little sense.

[redbullmarky]

maybe we should start a 'best frameworks' argument somewhere else, but having looked at ZF, I can pretty much say that it's far too chunky and OTT as far as i'm concerned. i had a look at django after thorpes comments and, whilst i have little understanding of python, it seemed pretty well structured and easyish to grasp - whereas after DL'ing the Zend framework and spending a fair chunk of time with it, it really doesnt come across as user friendly at all. Too much of a 'PHP OOP showcase' for my liking, rather than a lightweight, easy to use product. Most of the weight behind it at the moment is the name of the company and the hype, IMHO.

I'm also not into '[b]strict[/b] best practice' either - and having learnt certain 'best practices', all 3 of my faves break the rules occasionally (CodeIg, Cake, Rails) but kind of all have an "i dont give a toss" attitude and do whats right for easy of use rather than best practice.

Ronald, will be interested to find out what your conclusions are in the end.

[steelmanronald06]

Well, I took a look at ZF.  I don't understand any of that.  I always thought a framework was a file, say mail.php. Them mail.php had a function that included all the files from the /mail/ folder, which you could then use the classes from each file there to write mail applications in varying ways without having to do all the code yourself.  am i far off?

[448191]

It's quite a little more general than that:

[quote=wikipedia]In computer programming, an application framework is a term usually used to refer to a set of libraries or classes that are used to implement the standard structure of an application for a specific operating system. By bundling a large amount of reusable code into a framework, much time is saved for the developer, since he/she is saved the task of rewriting large amounts of standard code for each new application that is developed.[/quote]
[quote=wikipedia]A web application framework is a set of software tools to make it easier to create web applications. They typically provide functionality such as database access, templating and session management.

Such tools range from simple libraries such as DBI and the much larger PEAR, or pure Ajax presentation mechanism such as ZK, to systems using Model-view-controller concepts, where the mere structure of the data is all that needs to be specified to create a fully-functional application.[/quote]

Like I said ZF is not going to make any sense unless you understand the MVC first. Plenty of resources on that in the sticky.

Like Mark said, let's not make this a 'best framework' argument, but I'd say BECAUSE it's such an 'OOP showcase', it's very extensible and actually EASIER to understand, because it makes use of known patterns that are often even identified by class name.

[Jenk]

Agreed, ZF is far more flexible than the likes of CakePHP, which in my opinion, tries to do too much for you, and often gets it wrong.

Frameworks are the foundations of an application. Often you'll find frameworks are accompanied by a library of classes that accomodate common functionality, such as Data layers, Views, Caching and so on.

[steelmanronald06]

So I should learn MVC before I can pick up any type of framework?  What is MVC? 

*feels stupid*

[redbullmarky]

the resources at the top of the App design forum will probably explain it better than I can, but MVC = Model/View/Controller.
As you've got access to the dealings here, it's probably better to look at SMF as an example, as you probably understand it. The model would generally be dealing with the database. The view would deal with all things template, etc. The controller would deal with user requests. So a simple controller might be:

[code]
<?php
$request = $_GET['page'];

switch($request)
{
  case 'home':
      include('home.php');
      break;
  case 'post':
      include('post.php');
      break;
}
?>
[/code]

a View would be dealing with the output - so the template engine, and templates, would form part of the view.

the model - getting users/posts/threads, etc, from the DB. generally dealing with data.

the point of MVC is to encourage seperation. your Views (templates) dont get littered with business logic code, your main code doesnt get littered with HTML, etc. when you need to make changes to the main application, you can leave your HTML well alone, and vice versa. as you have models to deal with your databases, you can write much of your application code without considering how/why the data is retrieved.

i'm sure i've simplified it quite a bit, but it doesnt need to be massively complex. if you've used a template engine before, you've probably already got the basic understanding of seperation you need, and already understand the benefits. seperating your app even more just takes that one step further.

[steelmanronald06]

I picked up smarty, but I didn't much like it.

[redbullmarky]

try the code on this site:
http://www.massassi.com/php/articles/template_engines/
it's absolutely tiny but does the same thing, and doesnt require learning new syntax. lets you just use basic php in your template files. my current template is  pretty much totally based on that,altho now with tonnes of extra features i've added along the way. it was actually that article that got me used to  the whole idea of seperation, albeit just seperating my application from my templates. the MVC theory came after, and to be honest came quite easily due to having a basic understanding of templating to seperate from main PHP code.

in all, i'm probably quite new to PHP compared to yourself, but it only took about week to make the transition from Dreamweaver templates (HTML files with all its PHP code at the top, much of it auto-generated by DW itself) to a "proper" template  driven site. Afterwards, I moved on to the idea of routing everyhting through one single file (index.php) and basing the page on $_GET requests (such as ?action=post&topic=114286) just like this forum does, and the rest is a synch after that (or at least enough to get you getting things done).

at first i thought it was unnecessary to have a PHP file and a template file, possibly other files, just to render one page - but going back into the site and making changes is a doddle. i find myself able to redo a site in a few days whereas before it'd take me a week or two. it's not even just the practice/style of coding, it's more the rules/discipline it kinda imposes on you that make you work a little more efficiently and smarter. IMO, of course.