Thread

What is a framework? It a collection of tools right?

So when do you think collections of tools will become useless?

That title demands attention!

Maybe the reign of “tightly integrated” frameworks is over. Developers need different libraries under different circumstances. Nobody would claim that CI fits every application’s demands, at all times. Some CI libraries are simply sub par. Component libraries are the way to go.

As pyro points out, you can integrate components with CI. However, you can’t easily integrate CI’s libraries into other frameworks. CI’s libraries cannot easily be separated. They are not truely modular. What if I wanted to use a different front controller? No problem with the Zend Framework. Not possible with CI. Also, CI and other tightly integrated frameworks have some quirky conventions that don’t jive well when mixed with other components. Flexible file structure is important. Consistency in class/method naming is important.

Very true. I have wanted to use CI’s database libraries at times but they are tied into the core so that is out.

This is the reason that I built MicroMVC for my blog. I love the libraries from frameworks like Zend and CI - but I can’t stand all the junk that loads with them. I want a front end that loads the bare-minimum and then I can load optional libs from there as I need them. While CI is the closest at this goal - but I think it still has a ways to go.

I just want a single, simple MVC entrance to my site (as apposed to multiple files like a CMS) and I can take it from there.

I think some people are looking at this from a slightly inconvenient angle. Complaining that libraries and modules aren’t interchangeable in a framework, or that not all other framework libraries work in other frameworks, or about the way files are laid out is a bit of a non-issue. My opinion is this…

If we make the conscious decision as a web developer to use a specific web application framework - we must adhere to it’s rules and procedures according to its documentation to get the best out of it. If we don’t agree with this, then we are either using the wrong framework or we shouldn’t be using a framework at all.

Like it has already been mentioned, CI isn’t the perfect choice for all situations at all times - it is our job to decide the best tool for the job.

But CI is a fairly useful one in a lot of cases 😉

If we make the conscious decision as a web developer to use a specific web application framework - we must adhere to it’s rules and procedures according to its documentation to get the best out of it. If we don’t agree with this, then we are either using the wrong framework…

Well, perhaps CI is the wrong framework. Seriously, less rules, standard conventions, and better modularity are important. For example, PEAR and the Zend Framwork share conventions. Class autoloading and flexible directory structures are possible due to naming conventions.

...or we shouldn’t be using a framework at all.

All software is built on a framework - even if it’s your own making.

Well, perhaps CI is the wrong framework. Seriously, less rules, standard conventions, and better modularity are important.

For whom and in what context? We all have different needs for our own individual apps - and thankfully we have the ability to enjoy the choice of framework - CI, Symfony, Cake, Zend, and so on.

All software is built on a framework - even if it’s your own making.

Not strictly true. A lot of software makes use of things such as Microsoft’s .NET framework, or Qt/GTK GUI libraries, or other miscellaneous platform-specific APIs; but some software is just plain code - a collection of functions that may call each other. That’s not really a framework by the definition we are all familiar with I don’t think.

Well, perhaps CI is the wrong framework. Seriously, less rules, standard conventions, and better modularity are important.

For whom and in what context?

Yes, my response was snarky. I’m one of many who is less inclined, as you put it, to accept the rules and procedures of this framework. CI has never followed (edit: popular conventions), and it is no longer leading (evolving edit: quickly). Good developers evolve (edit: attempt to improve). 

All software is built on a framework - even if it’s your own making.

...some software is just plain code - a collection of functions that may call each other. That’s not really a framework by the definition we are all familiar with I don’t think.

IMO, you’ve just defined all frameworks: “a collection of functions”. A framework is a structure, which could mean anything - even a single file of reusable functions. I think everyone has their own fuzzy idea of what qualifies as a real framework. xwero, according to this thread’s title, doesn’t think the zend framework is a framework.

A good framework will also dissuade you from all those language constructions that are fast to develop with but make maintenance a real pain later on. It does that by actively preventing or discouraging bad practices and smoothing out some APIs or constructions with simpler function calls. In that sense, I think frameworks will always be useful because they reduce the number of “why the hell did [I/he/she/they] do this” moments later on down the road.

Does it matter if CI libraries don’t run in other frameworks? My old ASP site doesn’t run on PHP either.

When i gave that example i was making the link with javascript libraries that run in their own namespace but it will be highly unlikely to use controllers from another framework as a partial. But i think it would be great if it could.

I think the greatest flaw of framework is that their classes are build to work, without changes, in only one environment where libraries don’t make that assumption. The example i used earlier was the use of the log_message function in the constructor of each class.

Framework libraries are built to make code cleaner, faster, easier to understand, etc. That should not just mean the code we are writing.

If a framework uses nothing but native PHP in all of its libraries then sure, you could put them anywhere, but what would be the point of that?!

Not just talking about libraries but all the helper functions, plugins, core functions, etc use framework specific code which is logical and a good thing.

An example I was looking at the Twitter PHP class from Xeoncross and the first thing I’m going to do to that is rip out its native cURL code and put in calls to my cURL library. I have written a cURL library, so now the Twitter library can use that and be smaller. It means I cant use it as a native library anymore, but how is this an issue?

If I move frameworks, I will update my libraries and my code like web developers have always done when they convert from one system to another.

If you aren’t using a framework, you will be using a bunch of classes downloaded from PHPClasses.org or coded yourself. Then you will start coding some logic in to your file structures and then… you will have a framework!

Then you get into issues of reinventing the wheel, which is a well-known software design antipattern. Decoupling is nice, but it requires either a certain amount of repeated functionality (in the form of commonly-used patterns, like reimplementing a logging function for every library), or additional complexity in the form of defining interfaces and a just-in-time dependency injection mechanism (see Spring for Java).

To illustrate, let’s say that objects in a software toolchain are tied together only by their common logging interface. This isn’t true, but for the sake of an argument, let’s say it is. In this case, there are four approaches to logging messages.

First, you can define the logging function as part of a broader ecosystem in which all a subsequent developer’s code will execute. This would be equivalent to CodeIgniter’s approach: they define a logging function at the outset and all subsequent code that obeys the laws of the framework will have access to that function. The function is defined once and has a consistent interface throughout, but comes at the expense of application flexibility.

Second, you can define a logging function for each library you produce. This allows loose coupling of your libraries, so you could use your libraries in many different PHP toolchains. You could drop it into Drupal or PHP-Nuke, Vanilla, or Wordpress. Or use it in a ‘flat’ PHP project. The downside is that every time you produce a new library, you have to either re-implement or copy/paste your logging system to your new library project. If you ever discover a bug in your logging system, you now have to dig through all your libraries to make that change.

A third approach, and the first of the aspect-oriented-programming approaches, would be to declare publicly how your library “wishes” to do logging. It would have a means by which an arbitrary logging tool could be bound to it when the code begins to execute (probably by one or more callback functions). This allows you to develop your own sophisticated logging system that your users can choose to use, or they can choose to build their own that adheres to your publicly-described interface.

Lastly, you could define a series of events that all your libraries implement, to which an arbitrary number “listeners” could be applied. There are several ways to go about implementing such a system (an event delegator, for instance), but listeners could be attached at the beginning of run time and perform actions based on the events that flow in. This is how Spring (from what little I understand of it) works, and is how GUI event listener systems work in practice. The benefit is that once you define the set of events you plan on using, you can design a logging system that works for it, or your users can design a logging system that meets their needs exactly, since you are providing much greater granularity in status updates on your objects. This is perfectly decoupled (aside from the necessary dependencies or overhead of designing an event delegator), but adds a huge amount of complexity in your application and overhead to your execution time. It also requires that all developers buy into approximately the same idea of event handling, which, from my experience with JS frameworks, is difficult-to-impossible.

I guess what I’m trying to say is, both the tightly-integrated and loosely-coupled approaches (especially when taken to gross extremes) give you a long length of rope to hang yourself with. You just get to pick which color and whether or not you intend to use it.

An example I was looking at the Twitter PHP class from Xeoncross and the first thing I’m going to do to that is rip out its native cURL code and put in calls to my cURL library. I have written a cURL library, so now the Twitter library can use that and be smaller. It means I cant use it as a native library anymore, but how is this an issue?

Glad to hear it is being used 😉

Also Nick, I think that you are missing the ultimate form of design (which CI uses in some of the system).

First, you can define the logging class as part of a broader ecosystem in which all a subsequent developer’s code will execute. THIS oriented-programming approaches, would declare publicly how your library “wishes” to do logging. THEN you can develop your own sophisticated logging system (that adheres to your publicly-described interface) OR you can use the built-in one.

This is how CI handles core classes (most anyway) and allows people to use great helper objects like validation and sessions BUT ALSO allows people to throw those classes out the door in favor of their own way of handling things.

Perfect flexibility and yet you can still keep a standard.

The problem with this approach is, unless you want to go around performing code surgery, you’re tightly coupled with the CodeIgniter structure and inflexibilities. You can add your own logging stuff on top, but why bother when the “Tao of CodeIgniter” is to use the built-in functionality whenever possible and to extend that functionality via CI-approved channels if you don’t get exactly what you want. The last three of the approaches I described above allow you move your library into any framework or ecosystem without any code modification.

I think I used Aspect-Oriented Programming without explaining what it is, but CodeIgniter is definitely not set up to use it in any complete sense. It would require a core extension for just about all the classes available and probably some Base4 and Base5 hacking to really make a completely AOP system. It probably wouldn’t be appropriate in the CI context anyway: the typical CI application doesn’t require that level of sophistication and decoupling.

accidental double post, sorry.