redbullmarky

is your hosts file all ok? amond the other ones i've set up for local dev, my hosts file contains: 127.0.0.1 localhost ::1 localhost

http://www.sxc.hu/

damn that brings back some memories

we use Litmus at work. Is pretty good and easy to use and good for email testing, too....

yeah I was thinking what they'd do, actually - considering many of the namespace "examples" use These_Really_Really_Long_Class_Names to demonstrate the benefits. I suppose it's one of the reasons why I've held off on delving further into it with the view of integrating it into my own projects, as I don't fancy doing a hefty restructure/rewrite once (if) the framework gets reworked and upgraded.

it's not so much the way they're named, but many of them strike me as far too long.

going back to earlier - as it's not always necessary to attach a plugin to the controller (by $this->addPlugin('my_plugin')), is it considered bad practice to have a sort of registry purely for plugins, so I can just pass in what I need as required? For example (I'll call it PluginManager for less of a better name for now) public function testAction() { $page = Page::loadByRequest($this->rq); PluginManager::addPlugin('nav'); // add nav by default PluginManager::addPlugins($page->getPlugins()); // add those associated with my page // when editing a page, I might want to do this... $form = $page->getEditForm(); $form = PluginManager::getEditForm($form); // makes a magic method call, which in turn calls the method of same name in each of the plugins (if exists) // when viewing a page, I might do something like this instead... $params = PluginManager::beforeRender($page->getParams()); // manipulate page vars // the page is constructed as normal $out = $this->tpl->render('page.tpl', $params); $out = PluginManager::afterRender($out); } as my need is specific, and plugins are essentially not just reacting to and changing page properties but all sorts of things, is this acceptable, or am I really going off tangent now? I still like the context idea and, to some extent, helps with a lot of my issues - however, when it comes to extra processing like the form that's generated by the model, I can't see it working as i'd like it to. (nb - the code above is just scratchy as an example/proof of concept, rather than tried/testing/working code or anything resembling what the final code may be like)

with the imminent release of 5.3 and not long to version 6, this argument seems a bit of a cop-out nowadays. Sure - some hosts still dont support v5, but personally i'd move my hosting if that's the case - with all new stuff people demand from sites, etc, i want a host that's going to move forward with the projects i want hosted. over time, you tend to find good and bad things about all frameworks. the only thing you tend to find is that none of them are actually great for personal requirements unless your requirements are very simple. However - whilst I don't like the complexity of Zend (especially naming conventions, classnames, not to mention many advanced concepts), I do appreciate the fact that, given time, it can be put together to operate to taste - due to the fact that it's more a collection of solid libraries than a cliche'd "framework."

The WP site itself has plenty of tutorials. In addition, there are hundreds of templates that could easily be picked apart to suit your needs whilst at the same time giving you an understanding of them.

Aeglos - thanks for the link. Not came across that one before but the haphazardness of PHP4-OOP was one of the main reasons I steered clear of CodeIgniter even though it has much to be admired.

hmm possibly another thought - adding everything to a context, including the plugins? public function testAction() { $c = new Context($this); // context can access getRequest, getUser, etc methods if required by plugins $page = Page::loadByRequest($this->rq); $c->setParams($page->getParams()); // pass page vars (title, body, etc) to context - Django-ish, I suppose... $c->addPlugin('test'); // add a default plugin that ALWAYS gets used $c->addPlugins($page->getPlugins()); // add plugins that are attached to a page. $c->addView($this->tpl); // set the view object to use to render page return $c->renderContext('page.tpl'); } the thought being that my context object is left to handle plugin calls, variable setting, filters, etc and its render method uses a View class to render the final HTML response. thoughts?

i have a dispatcher class with a dispatch method. The chunk in question is: // ...do the stuff with whatever we have from the router/request object $class = $this->getClassName($this->rq->getParams()); $controller = new $class($this->rq); $controller->init(); if (method_exists($controller, $this->rq->action)) { $action = $this->rq->action; // could be 'viewAction' $p = $this->rq->getParams(); $out = call_user_func_array(array($controller, $action), $p['args']); } echo $out;

My only query is - let's say I have a route such as /:controller/:action/* , where does MyPageController::generate() come in to play as far as getting called? (maybe my example use of a 'viewAction' method wasn't the best, but I suppose I meant it would be invoked with a route of something like /my_page/view)

hmmm. on second thought, this is just one action method. as there are without a doubt going to be many more, I don't want to keep setting up the same old hooks (ie, with $this->event() ) - these are probably things that should trigger automatically at certain points so i can keep my action methods short and sweet. Narrowing things down, I suppose I want to be able to have hooks to: - react to certain requests (in the Request object) - for example, a post, 404, permissions, etc - manipulate variables before they're passed to the template to be rendered - manipulate the HTML after it's been rendered plus more. any thoughts on this as well as my previous post?

hmm. have been playing with a few ideas based on what you've been saying - any thoughts would be great. here's a sample action controller. I've set up a "Context" object like this (for saving space, I've exluded the getXXXX methods as they just return what was set): class Context { function setRequest(Request $rq) { } function setParams($params) { } function setOutput($output) { } ... etc ... } class MyPageController extends Controller { function init() { $this->loadPlugin('nav'); $this->context->setRequest($this->rq); } function viewAction() { // load page from DB and returns assoc array of title, body, etc $page = Page::loadByRequest($this->context->getRequest()); // load any plugins attached to the page (as set up in the database) $this->loadPlugins($page->getPlugins()); $this->context->setParams($page); $this->event('afterLoad'); $tpl = new Template(); $tpl->setAll($this->context->getParams($page)); $tpl->setOutput($tpl->render('page.tpl')); $this->event('afterRender'); $out = $this->context->getOutput(); return $out; } } The Context object is instantiated when the controller is. The Controller::event() method basically loops through all loaded plugins looking for an event of that name. If found, it's ran - and has access to the Context object. afterLoad will do any manipulation to page variables, afterRender will take the final HTML output as generate by the template engine and process it as required (like injecting stuff). Of course there could be other "hooks", and these might be unsuitable, but should give an idea of what i'm up to. Am I along the right lines? Is there a cleaner way to achieve the above?

no no, it's fine - i think i've seen some frameworks using a 'Request' object in this fashion but I'm guessing things could get more specific than that.

hmm sorta looks more along the lines, yeah. couple of q's about your example: 1, would the 'draw' method be better to take a Template object (which it does in your example) and manipulate it rather than outputting anything, before returning the modified object for the controller to render? 2, can you explain more about what you mean by 'context' - sure, i know what the word means but is it a specific pattern/practice? what part of my system does it represent in this case? got any further reading? Great help though - cheers!

in fact - is there anything that's similar to Drupal, but more object based?

yeah Drupal sort of has some nice features in that respect, but I suppose i'm on a bit of an OOP exercise so applying the same ideas that Drupal has is often tricky. But yeah - I suppose a hybrid of Drupal and Django isn't too far from what I'm trying to achieve. Thanks so far

in addition - my structure at the moment is a bit like: / framework/ site/ config/ config.php routes.php models/ page.php user.php modules/ common/ <-- contains site base classes for other modules to extend from content/ content.php admin.php routes.php media_manager/ admin.php routes.php plugins/ nav.php contact.php

yeah i've considered that, but the key here is what a CMS user can do. From when I was trying to work it our from a site administrators point of view, I thought like this: 1, user sees a page with 2 tabs - Content and Plugins. The Content tab contains editable boxes for 'title' and 'body'. The plugins tab shows a list of plugins, etc that are installed for the current page. 2, On the plugins tab, user clicks on '+' - ie, add a new plugin. They select the plugin they want from the list of available plugins (for example, 'Contact Form') and click on save. The Content form now has two extra fields - Recipient and Body After Post, which can be filled in and saved with the record. Now - the above method assumes that my ContentController::pageAction is called and it's generating a dynamic page. But let's say I have another controller, ExampleController::exampleAction. Within that, I want to use a plugin - but as it's actually not a CMS page, therefore doesn't have a record in the 'pages' table and therefore doesn't have any 'plugins' associated with it, I'd need the ability to add plugins via the controller itself as and when I needed them. In this case, I might consider loading my plugins from my Controller::init() method that I have. Hard to explain, but hopefully you follow.

yeah, i guess - if you take a look at this which is the auto-generated Admin area in Django, that's what I'm trying to achieve, but taking things a step further where plugins can actually add extra fields to the interface or manipulate what the front end displays and react to events such as a form post, etc - but all in a single self-contained plugin. I suppose one of my biggest priorities is to keep things as clean as possible and easy to develop for, which is why it seems like it requires more thought. I'm thinking that attaching my plugins to the controller: <?php class Controller { protected $plugins = array(); public function addPlugin(Plugin $plugin) { $this->plugins[] = $plugin; } } ?> might be the best way, but I'm not 100% sure whether there may be any pitfalls. Still follow?

either your php.ini file or create a .htaccess file.

sure, let's take a 'contact form' plugin. My CMS works by reading a page from the database, setting variables in the view, and returning the rendered view, all from within a simple Page Controller. Now - my model has some nice little features, loosely based on Django - ie, each database field is set up in this manner in my Model::init() method: <?php $this->addField(new PrimaryKey('id')); $this->addField(new CharField('title', 200)); $this->addField(new TextField('body')); // etc etc ?> My model has a method called 'getForm' which, given an empty 'Form' object, will attach to it appropriate input fields for my model fields and return the form object back. Rendering this form will produce a full form that I can edit my record with. Now - a "basic" page consists of a page title and a page body. Additional fields are to be provided by plugins. Now - with a contact form plugin, it essentially needs the following (at its most basic): 1, a list of recipients the form will go to 2, body text to display after form is posted successfully 3, the ability to add fields to the form mentioned above when editing the page (so probably passing the result of Model::getForm through a plugin method) 4, ability to send a 'you have recieved contact from a form' type message, or perhaps even store the form info in a table. Via the CMS, these plugins would be attached to a page (using plugin table and page_id foreign key, perhaps?) as and when required. So on a regular page, I see a page title and body. When I edit the page, I see two fields - title and body. But when I install the contact plugin, I see the page title, body and contact form, but the body and form is replaced when the form is posted. When I edit the page, I want to see two extra fields - one for form recipients, one for the post-submit body. I suppose where my confusion lies is that I might wish to use these plugins in other controllers that are unrelated to my CMS - so it won't have need for the plugins table but will probably install them manually in my actions. I'm really just looking for the cleanest way to install them (and WHEN down the chain they should be installed), the cleanest interface to use (ie, what to instantiate them with, what to pass into the methods, etc), how they should be used from my views etc. I'm thinking that it's possibly heading into the territory of the 'Observer' pattern to trigger certain events at particular times, but I'm not sure. So really - any thoughts on how the best way to implement this would be great (and apologies if that lot made no sense ) Cheers Mark

Hi all Apologies beforehand if this seems like a rehash on any old questions of mine.... I've recently finished restructuring the MVC framework I've been using for a while, and now I'm pretty happy with it. Now I'm looking at the best way of implementing plugins to the system - mostly in the View/templates, but I'm also trying to make things as generic as possible so I can drop them in anywhere. My controllers are split into actions, and anything the action returns is what's displayed - then I can use a template system if I choose to format the output before returning it. Now - for the CMS that's being built onto of the framework, there are 2 ways that I need to be able to install/use plugins: 1, From the controller action directly 2, From the template, maybe using something like $this->plugin('nav', $args); The View at the moment literally handles just that - it has no access to controllers or models (or anything else for that matter) unless they're passed in as variables via $tpl->set('varname', $object); . I sort of like this "view doesn't concern itself with anything else" but lets say I need a plugin that deals with navigation. I might drop a line into my template such as: $this->plugin('nav', array('type'=>'main')) - as pages are stored as database records, building the nav is going to need the database. It's also going to need the Request object so that it can decide which nav item to highlight as the current one. My questions (at last) - what would be the cleanest way to implement plugins? Should I keep my database and request objects inside my registry and access them from my plugins? How can I make the plugins as generic as possible so that they're not just "view helpers"? Would this be where I'd look at implementing some sort of 'beforeView', 'afterView', 'onPost', etc hooks system instead? How can I make the behaviour of invoking a plugin from a template identical to if I was to install it via a controller? Any help/thoughts on the best way of implementing plugins and hooks would be great Cheers