Programming C, C++, Java, PHP, Ruby, Turing, VB
Computer Science Canada 
Programming C, C++, Java, PHP, Ruby, Turing, VB  

Username:   Password: 
 RegisterRegister   
 Framework design.
Index -> General Programming
View previous topic Printable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic
Author Message
Craige




PostPosted: Sat Apr 07, 2007 11:09 am   Post subject: Framework design.

So, I'm (still) developing my private PHP framework that I was working on many months ago, and now I have some questions. about the design of it.

So, heres how it stands right now:

Ember

Elegant
Modular
B...I don't know, really.
Extensible
Reusable

The framework must follow these concepts, and must be configurable.

The framework interpretes the MVC design pattern slightly different then has traditionally been accepted. Instead of having controller objects, each page acts as a controller, letting you still have your directory/page structure.

There is a core class, named Ember, which handles many things. It loads and acts as a registry for core components and addons, it loads any pre-requisite scripts for addons, it loads the template class(s), and initializes them, and anything else that may fall along these lines.

There are 5 types of php scripts:
Core Component - Classes such as Ember, Ember_Exception, etc.
Module - Addon modules
Model - Database models
Librarys - Reusable code library objects. Auto-included (via __autoload), and included on a top-bottom structure. IE: page forms/topic.php requires a library, it is looked for in $LIBPATH /forms/topic, and if none found, it is looked for in $LIBPATH / forms, and then in $LIBPATH ($LIBPATH is a fictional variable).
End page - The page the user sees.

Now, my problem is that my design is starting to look a little spaghetti-like to me, which is obviously not what I want. Right now I'm trying to write a config class which I'm stull stuck on how to implement into the Core. I was thinking of an abstract factory type initialization, as so the config object can be chosen by the user. Data can come from a PHP page, XML, MySQL, or whatever. However, I'm not exactly sure how to implement this in a clean manner.

I know this description is poorly written, but if you could offer any improvements, it would be greatly appreciated.

Example page:
code:

try
{
  if ( !include $_SERVER['DOCUMENT_ROOT'] . '/../../EmberPHP/system/Ember.php' )  throw new exception ('Unable to load Ember class.', 401);

  $Page = Ember::init();
  $Page->loadComponents('Ember_Form');


  $Template->loadTemplate();

  $Template->addContent('TITLE', 'Test Page');

  try
  {
    $Page->Ember_Form->init(array("username" => array('min' => 3, 'max' => 15, 'name' => 'username'),
                                  "passwd" => array('min' => 3, 'max' => 15, 'name' => 'password') ) );
  }
  catch ( Ember_Exception $excep )
  {
    // Handle exeption based on previously deturmined settings
    $excep->handleException();
  }

  $content = 'Test page.<br /><br /><br /><br /><br /><br /><br /><br />';


  $Template->addContent('CONTENT', $content);
  $Template->addContent('Enable JS', 'true');
  $Template->addContent('PAGE JS', 'cpanel');
  $Template->addContent('PAGE_GEN_TIME', $Page->getGenTime());

  $Template->outTemplate();


}
catch ( Ember_Exception $excep )
{
  $excep->handleException();
}
catch ( Exception $e )
{
  echo $e->getMessage();
}
?>
Sponsor
Sponsor
Sponsor
sponsor
wtd




PostPosted: Sat Apr 07, 2007 11:13 am   Post subject: RE:Framework design.

You should really take a look at Cake, if you're determined to stick with PHP.

Note: everything in PHP will inherently start to look like spaghetti code after awhile.
Craige




PostPosted: Sat Apr 07, 2007 11:29 am   Post subject: Re: RE:Framework design.

wtd @ Sat Apr 07, 2007 11:13 am wrote:
You should really take a look at Cake, if you're determined to stick with PHP.

Note: everything in PHP will inherently start to look like spaghetti code after awhile.


I've looked at it, and I like it. I have a copy of it on my system right now, but I don't want to use it for the sites I'll be throwing up on this framework.
Craige




PostPosted: Wed Apr 11, 2007 8:18 pm   Post subject: Re: Framework design.

Okay, I get the feeling that my situation wasn't that well understood, and to tell you the truth, all that sounded allot like gibberish when I was typing it anyway. So, I'll do my best to rephrase it here.


You can ingnore this part for now, unless you want to read it and offer opinions.
Problem 1: Configuration

So, I was looking to create a configuration object, rather then placing variables into the global name space. What I have now is a simple object that uses a registry and php's __get and __set magic methods to store and retrieve the variables, as well as a construct which takes a (multi-dimensional) array of variables to initialize upon object initialization. It looks like this (not tested):

code:

class Ember_Config
{
  protected $registry = array();

  public function __construct(array $configurations = array())
  {
    foreach ( $configurations as $setting => $value )
    {
      if ( is_array($value) )
      {
        $configClass = __CLASS__;
        $this->registry[$setting] = new $$configClass($value);
      }
      else
      {
        $this->registry[$setting] = $value;
      }
    }
  }
 
  public final function __get($setting)
  {
    return $this->registry[$setting];
  }
 
  public final function __set($setting, $value)
  {
    $this->registry[$setting] = $value;
  }
 
  public final function purge($setting)
  {
    //code
  }
}


Now, what I am asking is how to initialize the object in a manner that allows me to switch back and forth between classes, thus I can have an Ember_XMLConfig extend that class, and get data from an XML file, or Ember_SQLConfig which pulls data from a mysql database. This initialization has to be blind to the end script, but configurable to the coder. I was thinking of an abstract factory type pattern, but without a factory pattern initializing the config object.....

Actually, I just got thinking. I could just have different factory objects initialize the config object however they want. The factory object could pull the data from the the XML file or SQL database, and this would work the same. The config object isn't dependent on how the data comes in, it just cares about storing it in the registry. Ignore this problem for now, unless you have any other tips about it.

Problem 2: Cleanliness

Right now I feel that my core is starting to get a little messy with how it handles components (and modules). They are stored in a registry, and available via PHP's __get magic method. The registry they are stored in (the 'main' object if you will) is a singleton, and can be retrieved from any scope.

However, as I said, I feel this is getting a little messy. Do you have any tips on cleaning it up? I can post code if you require it.
Display posts from previous:   
   Index -> General Programming
View previous topic Tell A FriendPrintable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Page 1 of 1  [ 4 Posts ]
Jump to:   


Style:  
Search: