Popular just now

ad1

Berlinto is a better Drupal

In the beginning Drupal (after v5) was a simple CMS to work with and because of this simplicity it could be used as a framework of sorts. Unfortunately the community drew the core more to site builders and the code that made Drupal simple became very complicated.


But the essence of the core system and what drew developers to Drupal was it's flat architecture.
This changed significantly in Drupal v6 and is almost none existent in Drupal 7 and 8. Drupal became famous for the flexibility of it's code base. This flexibility was traded for out of the box site building capability in Drupal 6. In other words Drupal is now a point and click CMS and no longer does it have the code flexibilty needed to do the thing for which it has become famous, development ease.

 In developing Berlinto PHP Framework I aim to rollback to the original reasons Drupal became noticed and build a better Drupal.

Remove:

  •  All the weight that has been loaded on to it trying to do things that can be done easier with PHP and a few conventions. 
  • All the wrappers 
  • Weird naming
  • Database centric system design
  • The system architecture and code that looks like the scribblings of a 3 year
  • Trying to be a jack of all technologies and master of nothing
  • Simulation object oriented functionality and polymorphism with badly designed methodologies
  • The need to use caching to get "normal" page load times
  • Resource and memory consumption without having done anything more than install the CMS
  • The need to use the word hack when dealing with core code.
  • "The Drupal Way"
  • "Elegant"
  • "Enterprise"
  • Cartoon Question marks from the heads of PHP developers and programmers.

Add:

  • Some solutions based on Design patterns  like Strategy, Singleton, Observor and Factory
  • Use of Object oriented programming tools like Reflection 
  • Flatter file system architecture with nesting only when it is unavoidable
  • Implement Standards like XML for persistent data use with Forms,  content types etc.
  • Simple copy and upload deployment
  • Readability and easy navigation through the system code 
  • Decoupled module classes
  • Make using Enterprise level Third-party component libraries like Zend, Symfony, Aura, ezComponents in a module easy.
  • Emphasis on developing web based software in PHP with a low, shallow or non-existent learning curve.

 I am taking some of the better Drupal ideas and implementing them differently using newer PHP 5 Object Oriented functionalities. Below you can see the architecture of a typical module and some of the code.

berlinto

The modules architecture and naming schema are a conventions that make it easier to find things. The classes used in a module are decoupled without dependencies. You can for example have a module with only an administration class that show only in the administration index. The class names are important as they are loaded when the system to looks for items in the suffixes list in the config.ini file:
 
[suffixes]

1 = "form"
2 = "admin"
3 = "forms"

In the case above Berlinto will autoload "blog, blog_form, blog_admin, blog_forms" class files if called.This architecture has the effect of creating sections easily. An example being the Administration index which uses all module classes with the suffix "_admin" in their name and then uses the hook for the menus located in each.

The hook system based on the use of PHP's call_user_function() construct was the core of Drupal.

Berlinto uses programming Reflection

Drupal uses drupal_init() to aggregate set up actions for modules before a page is rendered.  This is a hook and not really needed.

Berlinto uses the PHP __constructor method.

Drupal uses an untold amount of hooks to do actions and have them happen after a module is loaded.

Berlinto simply uses a destructor by of PHP's __destruct() method.

This is just a start and this post is not complete. I'll update it everytime I remember what pisses me off about Drupal and I come up with a better or more pragmatic programming solutions.

No comments:

Post a Comment