Hi there,
cold wrote:i've developed a simple framework for handling my simple projects.however,each class does it job separatly.they are not united in a good way.
Not all of your classes have to be united in any way at all (unless they need to be that is).
A framework is a "wireframe" or "skeleton" of an application which consists of a library (like what you currently have) which developers can use for functionality like database abstraction, email, xml parsing, pdf generation and request handling. Each class does one thing and one thing well (which I hope your classes currently do).
The application skeleton, has functional parts, but does not have the logic to make it's functional parts work together to answer a request. This functionality is left for the framework's users to put in.
Having a set architecture and a defined way of usage is probably what makes a framework a framework.
It has a set of tightly knit classes divided into layers (though layering is not a prerequisite for simple frameworks) which relate to each other and a set methodology to putting in the necessary concrete logic to respond to requests eg extending an abstract base class, implementing an interface, putting files in a set place etc.
-I use singleton for every class on it's own.
-Every application i create depends on most of the classes all the time(i ALWAYS need i18n,errors,templates classes loaded) some other times i load database and files classes when needed.
how do i manage those classes?
I highly discourage the excessive usage of the singleton pattern for everything as it makes your class accessible globally from any layer of your application. Instead, what you could do is perhaps use a Registry.
The Registry pattern and other creational patterns like Service Locator and Dependency Injection lend themselves nicely to a framework. In a sense that it provides a central location for you to create an access objects that your framework uses.
Plugging in a registry or other creational patterns (as required) into your framework will aid in simplifying the management of dependencies. As an out of scope example, I pass a Dependency Injector (which is the Registry pattern's bigger brother) to classes which have lots of varying dependencies like controller layer viewhelpers in my framework and let the controllers and viewhelpers decide which objects they need.
// php 5
class ds_user_action_SaveProfile
{
protected $_view;
protected $_gatewayLocator;
public function __construct(cubix_Injector $injector)
{
$this->_gatewayLocator = $injector->get('cubix_gateway_Locator'); // injector knows how to create an instance of cubix_gateway_Locator from including the correct file, to creating a class instance.
}
public function execute()
{
// some logic to save profile.
}
}
// php 4
class ds_user_action_SaveProfile
{
var $_view;
var $_gatewayLocator;
function ds_user_action_SaveProfile($injector)
{
$this->_gatewayLocator = $injector->get('cubix_gateway_Locator'); // injector knows how to create an instance of cubix_gateway_Locator from including the correct file, to creating a class instance.
}
function execute()
{
// some logic to save profile.
}
}
Regarding your directory structure, it's all pretty much dependent on how you plan to organise and load your classes etc.
My advice... have a look around at existing frameworks and see what they are doing and WHY they are doing it the way they are doing it.
HTH.
Regards,
