macrob7 wrote:- Interface to the template parser ( This was built from the ground up - I am confident that this is faster and I know it is not as bulky as SMARTY, it may not have all the fancy stuff that smarty has but it does what a template parser was meant to do, and there are no additional 'tags' that you must learn ).
Template libraries are notorious. Why not just use PHP as a native template language -- all the power in the world and it's free -- at least in terms of re-inventing the wheel. Google bTemplate see what I mean.
macrob7 wrote:Helper functions to make a programmers life easier.
So there inside a base or master class? Surely not every instance needs access to those functions. Helper functions are usually an indication that the methods have no been properly grouped or categorized -- not saying they are appropriate being called "helpers" just make sure they are truely generic.
macrob7 wrote:Methods to load libraries, content and plugins etc.
One thing I dislike about most frameworks. Why have a module/library loader? Whats wrong with include or __autoload???
As for content and plugins -- sounds more specific to a CMS than a generic application framework.
macrob7 wrote:you are not limited to doing these tasks just in the controller
That is, I believe, where initialization should occur -- passing/injecting instances of required object to the model to remove any unnessecary dependencies the model may have on outside classes.
macrob7 wrote:Pure MVC Architecture - Using this framework introduces a programmer to the power of developing with an MVC Approach
I think most are -- some are just more diligent about separation/dependencies than others. For example, your master class, sounds like it would be better off as a registry (I think arborint said that already). I would also personally rather see registry injected into the controller or model as opposed to pulled into the controller or model with a call to a static method in each base class.
Code: Select all
class Model_Base{
$_registry = null;
function __construct()
{
$this->_registry = Registry::getInstance(); // Bad
}
}
Alternative:
Code: Select all
class Model_Base{
$_registry = null;
function __construct($registry)
{
$this->_registry = $registry; // Good
}
}
Highly extendable framework
Haha...aren't they all? If you couldn't build something ontop of a framework, it wouldn't be much of anything except a cluster of source codes.
An Advance, Intelegent and scalable Template Parser Engine
Look into bTemplate -- I promise it's not as advanced, scalable or intelligent.
In short, selling frameworks is a tricky business. There are so many of them adn more are constantly popping up daily -- yours is an example.
Your arguments were typical and although logical, no more convincing than than Zend, php.MVC, CodeIgnitor, Symphony, CakePHP, etc...not to mention the various CMS frameworks, like Drupal, CMSMS, Typo, Mambo, etc...
What I'm looking for in a framework, at least in a sales pitch, is basically a simplified, well written (ie: strict conventions), loosely coupled library of components. But most importantly, a practical comparison of pros and cons between frameworks.
You nailed it once, with that comparison between CI and your framework -- with the issue of having the master class available in your models and controllers NOT just controllers like CI. Although I disagree with that requirement, that is the kind of comparison I'm looking for.
Keep at it -- keep us informed.
Cheers
