sunwukung

the value of using a pre-built framework a) common standard that can be shared between developers b) code you write can be picked up easier by subsequent developers c) documentation is better d) good quality components already available e) component have been tested in superior number of projects f) access to community with common knowledge g) learn a great deal about application architecture by studying someone else's work disadvantages: a) learning curve b) can be rather bloated for task at hand c) different frameworks excel at different types of application - but you won't know that until you've used them for a while d) can be tricky to implement AJAX functionality at first pass The only real value in writing your own is that a) you learn a lot from doing so b) the framework you write may be a lot more lightweight since it is custom built for your way of working c) it does something that no other framework does However, as your homebrew gets bigger, you will find yourself maintaining that code over time too.

IME, while Magento has a lot of nice features, it's pretty hard work - and it DEVOURS resources. That's why you get Magento specialist hosting. Personally, I'd give Magento a miss and go for a different cart system - probably commercial for the sake of customer support.

You won't stop using "core" php simply because you use a framework - it's not quite as abstracted as a JS lib like jQuery. You'll still get your hands pretty dirty in the logic/model layers of any application. It should just take the pain out of some fairly standard tasks - view management, database connections, form validation. You may find that you're only really using the MVC setup, and the rest is raw code.

Not so fast! It really depends on the usage/application design. You could make a single "cart" object, and each item the user picks then becomes a property of the cart. That might take the form of a discrete property for each item, or alternatively part of an associative array which can be used as a reference point from which you can pull up product data if the user wishes to review their purchases later. You can then persist the object in medium X (a database would allow you to keep the cart data on hand for the next time the user logs in). On the other hand, it may be overkill if that's ALL the cart does, since that will reduce the object to little more than an expensive associative array. You may, however, think of additional functionality to append to the cart which can then be brought to bear on the cart contents, like sorting, adding, removing, changing quantities etc... Try to think of the "cart" as representing an object in the real world - what would it do? This is fundamental to the concept of the Domain Model, a conceptual model of a given business domain. Since all data can be represented as arrays, why use objects at all? I'd recommend reading up on Domain Modelling, it will help bridge the gap from OOP theory to practice: http://www.infoq.com/minibooks/domain-driven-design-quickly

I've just figured it out. The calling class (Application) should be given responsibility for executing runConfig - not the Config class...DOH! I knew something was smelling... thanks for replying

No offense, but are the images you're loading png's/gifs etc? Can you provide us with some of the error messages? It might be any number of reasons - file size is too large, image wasn't copied to location x...

I wanted to know if there was a way to prevent a method in a class being called unless it is called by a specific (non-inheritance chain) object. I'm borrowing from the Zend Bootstrapping pattern: class abstract Config_Abstract(){ public function runConfig(){ //iterate over methods declared in child and execute each in turn } } class Config extends Config_Abstract(){ publc function initGood(){ //do some stuff } publc function initBad(){ $this->runConfig(){//VERY BAD - CIRCULAR CODE } } } class Application(){ public function run(){ $Config = new Config(); $Config->runConfig();//should only be executed by Application class } } $App = new App(); $App->run(); there are two methods I've thought of so far, but I wanted to know if Reflection or magic methods had something that could deal with this 1: use debug_backtrace() to detect the calling object 2: pass in a reference to the calling object in the configRun() argument Can anyone offer some insight?