My next framework

PHP
21

I’m not convinced it’s a good idea from a scalability point of view.

I used to work for a company who ran the whole company through the website. There were probably well over 1000 different views which used javascript in some way. Including all this script on every page would have been:

Inefficient: It probably would have totalled well over 500kb of script and some people would never visit a page which used certain scripts due to their user type/permissions.

It’s also a potential namespacing nightmare. With separate files per pages, you don’t need to worry about creating a function called updateContent() because you know what’s loaded. Someone writing a function for another view wont accidently break yours.

22

:nono:

Hmm… Remedial Javascript lesson time I suppose. For an HTML page to use a javascript it must be included inline or refrenced using a script tag with a src attribute. That src attribute can point to any file on the site, so even if a page has hundreds of views or thousands of pages, they all reference the same javascript. The browser caches the file after the first load.

Now large scale applications, javascript or not, need file organization. Typically in an object oriented program every class has a file. Javascript can be organized this way, but this incurs a loading penalty after awhile. It takes far more time to download 20 1K files than download 1 20K file.

The framework accepts the penalty of the former route during debugging because having the scripts in separate files makes the process of fixing their bugs easier and quicker. Once the move to production is made the framework binds up the files into one comprehensive javascript that is used site wide.

Yes, it is redundant for the browser to have the javascript of the whole site in memory, but it’s also faster, and speed is the prime concern here.

Now if you are under the impression that I have to put this script binding code in every single page template you’re just insulting my intelligence. Only one template holds this code.

23

No, that’s pretty much it. I know PHP can do non-web related tasks, but that’s beyond the scope of what I’m trying to do. I’ve always saw this project as a CMS Framework which is designed to be easily and quickly modified by programmers. Joomla & Drupal and easily modified and customized by end users, but for that functionality to be available the programmer has to jump through a LOT of hoops. In my experience they present too many options for many clients who would prefer to have as much as possible taken care of for them by the developer.

Drupal and Joomla both put way to much ‘tech’ stuff in the hands of end-users I agree. However there are a lot of CMS/CMF that realize this as well that may be of interest to you:

  • ModX
  • SilverStripe
  • CMSMS
  • TypoLight

In all fareness, Drupal with it’s CCK/Views modules allows a developer to build basic/advanced content types very quickly and instantly have full CRUD-S interface for adminisitration or end-user viewing.

If your a real hack with CCK/Views you can easily out perform any developer trying to build something very similar.

Then if you need something extra, say a notification email sent to ABC upon suncessful submission of the form, you can:

  1. Search and find a module that can hook into events that will send an email for you based on configuration options you provide.

  2. Implement a custom module and really fill in the blanks from that point on.

Where Drupal sucks is in true componentized mini-application development, which is where Joomla fills the gap. Joomla components are essentially mini-applications running under the context of the Joomla CMF. The promotion of MVC allows for much cleaner SoC than drupal modules, and therefore much more robust components are found in the Joomla ecosystem than are in drupal.

There are few if any decent shopping carts in Drupal as modules, because modules are not intended to be full scale applications, but little pluggable modules that manipulate workflow, interface, etc.

If you could merge those two CMS into one, drop the complexity and access baggage from the end-user interface and focus strictly on usability that would be my single tool I would master. Unfortunately, I have to first figure out my clients abilities/comfort level and determine whether Drupal, Joomla or WordPress would be more appropriate. Bah!!!

Cheers,
Alex

24

Since you didn’t read it the first time…

Hence the callbacks of many functions are embedded in their respective php controller and event files, not in the js files.

25

First off, javascript is treated as a full member of the code and not a tack on citizen. Controllers and Events with a javascript component to their duties will have javascript in them.

It doesn’t build a master template for each request, or even start a template engine at all until it is truly needed.

Templates are broken out so that elements can be accessed and used by javascript or php equally.

But basically, every framework I’ve seen was written first then Ajax was added later. This is being written with ajax in mind from the get go. That’s why the system organizes itself into an event based design - because Javascript is an Event Driven OOP language. It’s one thing to provide callbacks for js, quite another to provide callbacks that don’t incur unneeded overhead. For that to happen the framework has to be written with minimal service starting in mind from the get go.

This goes all the way down to the heart of the system. The framework can respond to a validation query on a field without starting the database because the event is doesn’t need user authentication. I’ve yet to see a framework, particular a CMS framework, that doesn’t assume that every connection requires at least one database lookup and starts the database immediately on start.

26

While we are on the subject of user-auth, i would like to bounce off this idea:

Lets say that user has a cookie , which is made from


$key = $user_login_hash . '|' . $timestamp . '|' . $cookie_vertification_hash;

When user opens the site , system vertifies user like this : [list][]can i make the vertification_hash from rest of the cookie and the user’s IP ?[]is the <timestamp> acceptable ( not too old, not too new ) [/list]
If the timestamp is too old but the cookie is valid, system request new cookie ( involving DB queries and the whole show ).

So … would this work, or am i missing something ?

27

As far as I’m concerned the cache is just another model type alongside the db. I do plan to use caching on this thing extensively. But the structure of the framework isn’t due to caching concerns but rather load concerns, particularly in trying to make sure the latency on js callbacks is as low as possible even on a machine that has no major burden.

28

This is a false position. You should be using a caching mechanism. Furthermore, since this is a PHP forum damned near all your datatypes that go past the int/string etc variants are going to be arrays.

Pick up a NoSQL solution for things that lives as keypair values. Use memcache to keep a highspeed buffer.

I just find it weird you are trying to code a framework to do what you want when you should be building a third party library for something like CodeIgniter then augmenting it with a custom Templating library.

If you are talking 10,000 users you have no business not using some sort of cache. Also, you should be looking at Nginx and fastcgi instead of Apache with mod_php :shifty:

Anyways, I don’t mean to sound so negative toward your project. I’d really like to see more code. You have a github or bitbucket repo?

29

I’ve yet to see a framework, particular a CMS framework, that doesn’t assume that every connection requires at least one database lookup and starts the database immediately on start.

A CMS is essentially CRUD application with metadata, usually stored in a db, to describe what you are looking at. Unless you are building all the metadata into application constants and class attributes I don’t see why you care if there is a database instance.

A management dashboard doesn’t need database connection but it is true many frameworks will a connection instance to a db. But really, most of them will be singleton patterns and they will utilize a pre-existing connection pool. So the overhead is insignificant enough to the point of being transparent.

If I have an application instance and I want a raw class to be able to use methods out of different libraries in its footprint I would just make a function grab_instance that would give me access to the application instance:

$APP =& grab_instance()

You can limit all the methods available to keep your footprint low. You could even call DB instances dynamically instead of at runtime. However, wouldn’t you rather benefit from connection pooling?

30

Yeah, each response has it’s own callback block. Further the given class doesn’t need to define a callback because it will be inheriting a default.

Modules typically take their post and do whatever is needed. The page class then recalls just that module on ajax requests and tells it to send it’s current view state. If it wasn’t an ajax request the page rebuilds itself which will include recalling the module and creating that view state - same block of code. The outer js and php framework handle the updating of the module’s view state for an ajax request.

31

@Michael Morris

From what you have described, your framework honestly sounds more like a CMS Framework or “CMF” - Content Management Framework. If I understand what you’re saying correctly, pages are a core concept within the framework and URL routing that are always present, no matter what other functionality you build in with events. I am curious to know why you chose this approach. Please correct me if I misunderstood the design.

32

Templates are broken out so that elements can be accessed and used by javascript or php equally.

Thats a good practice, makes everything far more reusable.

But basically, every framework I’ve seen was written first then Ajax was added later. This is being written with ajax in mind from the get go. That’s why the system organizes itself into an event based design - because Javascript is an Event Driven OOP language. It’s one thing to provide callbacks for js, quite another to provide callbacks that don’t incur unneeded overhead. For that to happen the framework has to be written with minimal service starting in mind from the get go.

I think AJAX should be added on later, personally. Otherwise you end up coupling controllers or PHP code directly to JavaScript, no?

For instance, in my applications, everything is always done at the controller action, no more do I instantiate Locale, DB or anything in the bootstrap.

My views, are like yours. The resulting HTML page returned to user-agent is a composition of many parts.

For that reason, I prefer to implement my regular actions, then later implement AJAX actions, REST actions, CLI actions, etc. Any request, regardless of where it comes from goes through the same index.php

This goes all the way down to the heart of the system. The framework can respond to a validation query on a field without starting the database because the event is doesn’t need user authentication. I’ve yet to see a framework, particular a CMS framework, that doesn’t assume that every connection requires at least one database lookup and starts the database immediately on start.

I have never had to instantiate a DB object to validate incoming data. Validation is a distinct operation from DAL. It’s business logic usually and thus should be done in the model layer not in a database. This is common practice, except when you use a ORM like Doctrine, which I believe has validation services built in (bloat overhead if you ask me).

CMS are a different story, because ones like Drupal store everything in the database. Routing tables, mappping URI to pages for instance, so by design it needs a DB almost immediately upon loading. Personally I opt to store routing files/maps in files, so a DB isn’t required after the expected controller and action has been invoked, avoiding senesless overhead.

Cheers,
Alex

33

Again scale that up and it becomes larger and larger. By all means, load your JS framework and core files on each page (jQuery, prototype or whatever) but loading all the javascript which will ever be used throughout the site? Insane. For instance, imagine that on facebook or google as a whole. There would likely be 10mb+ of scripts to download.

34

Interesting concepts.

So everything is going to be run through a provided pre-existing Page controller, and you add functionality and respond to different events and HTTP requests though event triggers that are somehow registered with the framework?

So if I needed to respond to GET “/events/7341.json”, how would I do that? I understand you may not have all the code setup to answer this, but even a purely conceptual answer will do.

35

You should be looking into Class Interfaces at that point. You can framework out some common methods then implement them in classes specifically for what options is needed.

Moreover, since memcache and mongodb/couchdb or any key->val system should be able to make a very elegant system for each type of datastore. One for keypairs engines and one for relational database engines.

36

Just posting this here, http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html

Very interesting, and can reduce complexity and still outperform using memcached as a simple query result cache.

37

The whole framework feels built around this method more or less. This post answers several questions up thread now that I’m prepared to answer them.


public function __invoke( $url = '/' ) {
		$this->setInitialRequestEvent();
	
		// Let the heartbeat commence.
		do {
			// Get an event.
			$event = array_shift($this->queue);
			
			try {
				// If the event is a page, assign it and clear the queue and responses.
				if ( $event instanceof Page ) {
					$this->startPage($event);
				}
				
				// Validate the page (yes, pages validate themselves).
				$event = $this->page->validate( $event );
				
				// Parse the event.
				$result = $event( $this->page );
				
			} catch ( Exception $e ) {
				//Problem, start an error page.
				$this->startPage (
					new $this->services['settings']['core']['errorPage']( $e, $event, $this )
				);
			}
			
			if (is_array($result)) {
				foreach ( $result as $r ) {
					$this->route($r);
				}
			} else { // Handle just the one result.
				$this->route($result);
			}
		} while( count($this->queue) > 0);
		
		/**
		 * Now as our last step give the page the responses and compose the
		 * final response.
		 */
		$this->page->respond( $this->responses );
	}

The code that precedes this function’s call exists just to get this thing running smoothly. To review what is upthread:

The framework is divided into events. Pages are a special type of event which provide a context for the others. GET events require a GET request from the browser to access, POST events require a post event. INIT events are called by the page anytime it’s instantiated, and EXCEPTION events manage exceptions that must be reported to the outside world because they are uncaught or are the fault of the user (404 Not Found for example). Modules are areas of a page, they have events of their own.

Examples.

Homepage.

  1. User arrives at site, URL is ‘/’.
  2. Router determines “Page” is the class to handle this.
  3. Page is started by dispatcher.
  4. When page validates itself as an event it simply returns itself.
  5. Page’s own event fires. It returns an array with it’s init event (“UserAuthOptionalEvent”) and it’s modules (“Login”, “HeaderMenu”, “HomeNews”, “FooterMenu”, “HeaderAd”) and finally the requested event (“IndexEvent”).
  6. UserAuth returns a guest event.
  7. The modules run, each returning their IndexEvent. Those are put on the queue.
  8. The page indexEvent runs, returning a reponder. It is put on the responder queue.
  9. Each module indexEvent runs, returning a responder. Again, those go to queue.
  10. Having exhausted the queue, Event Dispatcher calls page->respond and gives it the responses.
  11. Page->respond pulls the page’s own index event from the response queue (it should be first because of LILO event resolution) and gives it the other responses and orders it to respond.
  12. The responder composes the response and prints it.

The user logs in.

  1. URL is /index.php?module=login&action=login - method is post/AJAX
  2. Router determines “Page” is the class to handle the page.
  3. Page is started by dispatcher.
  4. When page validates itself as an event it simply returns itself.
  5. Page’s own event fires. This is an an AJAX request and a module is specified. Page does not do it’s init, the module will. It’s returns the login module, but it also returns the modules that are “listening” for the login action - the final list is “Login”, “HeaderMenu”, and “HeaderAd” (which is listening for * so refreshes on any action).
  6. Login runs, is successful, return UserInfo IndexEvent,
  7. The listening modules run, returning their indexEvent (A listener can be a unique event or a pointer to a refresh event.)
  8. Each module indexEvent runs, returning an HTMLResponder for their new content and a JSresponder to execute their update.
  9. Having exhausted the queue, Event Dispatcher calls page->respond and gives it the responses.
  10. Page Responder diverts to AJAX response. This function creates an XMLResponder then harvests the array of responders into an XML tree (see example below) and returns it.
  11. Clientside script updates relevant areas of the page.

That XML response looks like this


<r>
  <j> (the javascript callbacks of each module, in order.) </j>
  <UserInfo><![CDATA[ ( html) ]]></UserInfo>
  <HeaderMenu><![CDATA[ ( html ) ]]></HeaderMenu>
  <HeaderAd><![CDATA[ ( html ) ]]></HeaderAd>
</r>

And that’s all. I hope it’s clear now why I feel that this truely something different from the other frameworks out there - it is an Event Based MVC system rather than the traditional static MVC with AJAX tacked on as an afterthought, if at all.

Note that in the second example if the form is submitted without AJAX the page will be able rebuild itself and send a new copy of itself out.

38

I agree that DB is the slowest part of CMS. MySql is great at first, but as you tables grow in size, mysql starts to use temporary tables during selects, especially when there are some table joins. I think if you want your cms to be able to handle very large data you should start looking at NoSQL database as a backend. Something like MongoDB or Cassandra or CouchDB. But of cause it’s totally different way of thinking, not like mysql at all. In NoSQL there are always duplication of data, something that programmers try to avoid at all cost with traditional database design is a norm with NoSQL.

There is also a new emerging trend to use Node.js, a server-side javascript processing. This way you can write your templating language in javascript then you will be able to execute the same javascript on the server for server-side processing or in browser for ajax-based processing.

39

As of this morning I have the first draft Control and Response system essentially completed. I still need to write some exception handling routines. Now comes the conversion of my old data access system over to using PDO. The framework will use that for the management of its own internals, but should be able to deal with a third party model such as Doctrine being used provided a wrapper is applied.

Hell, as much as I hate smarty, it can be used if a wrapper class is employed.

40

And that’s all. I hope it’s clear now why I feel that this truely something different from the other frameworks out there - it is an Event Based MVC system rather than the traditional static MVC with AJAX tacked on as an afterthought, if at all.

Posting code would be best, but explaining how it’s different from existing solutions, comparing to WordPress, Drupal, Joomla, CakePHP, CodeIgnitor, Zend and maybe Symphony.

MVC is a term loosely thrown around, yet most don’t really enforce MVC rather they promote a controller architecture. Whether the developer implements business logic (or some of it) in the controller layer is entirely dependent on the implementor. Admittedly it is hard to enforce true model/controller/view seperation and whether all developers agree on what constitutes business logic and controller logic will vary as well.

It sounds as though you have a page assembly engine integrated with your interpretation of MVC.

I use Drupal a lot these days, and while it requires a lot of hacks to get things just as I like them. I am always curious how system X is better than Drupal? Worse than Drupal? Or Joomla, etc.

What is the key difference here? From what I gather from your post above, it is that events are triggered server side and AJAX on the server can query for view partials?

For example if someone logs into the site, the view partial responsible for showing the login FORM will automatically be replaced by the authenticated view, such as a “Welcome PCSpectra”???

Cheers,
Alex