Would you agree this is the definition of a PHP framework?

PHP
1

Or friendly neighborhood PHP heretic @tony_marston404 just wrote this definition of what a framework is in a discussion over the SP article on creating a simple Laravel CRUD application. (Too bad it is in Disqus, otherwise I wouldn’t have to start this thread.)

If you have to write your own code to call the framework components, then it is not a framework, it is a library. A “true” framework is in fact a mini-application with which you should be able to both generate and run your application components.

Anyone agree with this definition?

Scott

2

/grabs some popcorn and marks this thread to follow

2 Likes
3

https://tribkswb.files.wordpress.com/2014/11/michael-jackson-meme.png?w=562

4 Likes
4

To my mind, the difference is this: A library is a collection of code that solves a specific problem, so you have templating libraries to deal with creating markup, image libraries to deal with image manipulation, and so on. To build an application will usually require multiple libraries for different tasks. A framework, on the other hand, brings together all (or most) of the common functionality needed to build an application, usually providing a more consistent API and often some of the boilerplate code to wire components together.

I think Tony’s definition is more that of a Rapid Application Development (RAD, likely where Radicore gets its name) framework, which is a particular kind of framework, some of which allow users to build (or, more accurately, customize) an application via a GUI without having to know how to program. Of course, the applications you can build with such a framework are limited by the supplied components. I doubt you would be able to build an online image editing app, for example, using Radicore.

1 Like
5

To be absolutely honest after that thread I feel very little importance for anything tony_marston404 has to say about programming unless we are talking about maintaining old, antiquated code bases.

6 Likes
6

@fretburner - nice reply.

I agree. Saying frameworks, like Laravel or Symfony, are libraries, because “you have to write your own code to call the components” is off by a country mile.

Scott

7

[citation needed], end of thread, surely?

8

Not sure what you mean.

Scott

9

Well, either tony needs a reference to back up his claims or the discussion is pointless and I’m guessing he doesn’t have one.

10

Ahhh. Gotcha. I looked up some references on what a framework is.

This is the best part.

Frameworks contain key distinguishing features that separate them from normal libraries:

  • inversion of control: In a framework, unlike in libraries or normal user applications, the overall program’s flow of control is not dictated by the caller, but by the framework.[1]
  • default behavior: A framework has a default behavior. This default behavior must be some useful behavior and not a series of no-ops.
  • extensibility: A framework can be extended by the user usually by selective overriding or specialized by user code to provide specific functionality. non-modifiable framework code: The framework code, in general, is not supposed to be modified, while accepting user-implemented extensions. In other words, users can extend the framework, but should not modify its code.

Many people equate the term software framework with an object-oriented software library, or set of libraries, intended to provide reuse. However, there is an important difference between a framework and a library, that difference is often called “inversion of control.” If you’re using a library, the objects and methods implemented by the library are instantiated and invoked by your custom application. You need to know which objects to instantiate and which methods to call in order to achieve your goals. On the other hand, if you’re using a framework, you implement the objects and methods that are custom to your application and they are instantiated and invoked by the framework. A framework defines the flow of control for the application.

http://ifacethoughts.net/2007/06/04/difference-between-a-library-and-a-framework/
http://www.codeproject.com/Articles/5381/What-Is-A-Framework

http://martinfowler.com/bliki/InversionOfControl.html

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework’s code then calls your code at these points.

It is quite interesting how often IoC is stated as a determining factor for considering a framework a framework. I guess that proves DI isn’t so evil after all. :stuck_out_tongue_winking_eye:

Scott

11

If we’re going to have this thread then lets try to do it without bashing please. There is a kernel of discussion to be had here - namely what constitutes an app, a library, a package, a component, a framework, and where do the lines get blurry. My opinion.

Components

A component is a tight group of related classes tasked with accomplishing a single task. Ideally components should be independent and share a namespace - that is the classes within a component don’t need to make use statements to address each other. A task too small for a component is likely going to fall to a single class.

Symfony’s HttpFoundation is a good example - providing a basic I/O framework. It’s not just used by Symfony, but also by Drupal 8, Laravel and Silex (that I know of).

Packages

Packages are groups of related components. Twig is one example, Symfony in general refers to these as “Bundles”. Unlike a component which is usually a more or less drop it in decision, Packages tend to have more far reaching effects on the application since taking advantage of them will require some forethought and outside code will need to be aware of their API.

The smallest frameworks and the largest packages is a very blurry line - but frameworks style themselves to be more complete solutions than packages tend to be.

Frameworks

Frameworks provide a road map to solving a particular type of problem. There are general purpose frameworks - Symfony. Frameworks devoted to small scale websites - Silex, and everywhere in between. What makes Frameworks distinct from packages is they:

  • Have a distinct over arching paradigm, either Model-View-Controller or Model-View-Presenter
  • Have components and packages to implement the
    areas of that paradigm.
  • Have a configuration methodology set up in non-PHP files, usually one of XML, INI or YAML.

The largest frameworks are almost indistinguishable from apps and are ready to go from install, but the distinguishing line here is whether a non-programmer can be expected to set the code up and get it running. If not then, no matter how large and featured it is, it’s still a framework, not an app.

As a rule of thumb, the more a framework can do the harder it is to customize it. This isn’t always true though, and it also depends on what area of the app is being customized. The best frameworks tolerate having their components and packages switched out though the incoming packages will usually need a wrapper of some sort especially if the interface in that area hasn’t been standardized.

Apps

At the top, apps. If a non-programmer can be expected to install and configure the app without touching a single line of code then it’s an App. Drupal 8 is one example, and a rather huge one at that. Apps may or may not have further customization possible though the most popular ones are. The smaller apps out there can be smaller than some frameworks.

The distinctive feature of an app is installer code that creates the database, writes the config file and overall automates the setup process for a non-programmer user. Frameworks don’t have these though they might have tools for handling some parts of the install process, like creating blank model classes, route files or the like.

Increasingly in the PHP world the leading applications bring together components and packages from various vendors. The only major PHP project that doesn’t anymore is WordPress which can get away with this largely due to its marketshare - even then I’ve seen Wordpress plugins make use of component libraries. Given time even Wordpress will probably evolve over, though it’s going to have to get rid of its horrid “The Loop” to do so.

12

I can agree with that - doesn’t really conflict with what I said and to some degree restates “Have a distinct overaching paradigm” – though “inversion of control” is a better way to put that.

As to what makes Apps distinct from frameworks, the presence of an installer for a non-programmer to use to deploy the program would be that element.

13

Fowler’s actually talking about a different kind of IoC. In fact, that the term IoC was getting overloaded with different meanings was the reason Fowler coined the term dependency injection. When it comes to libraries vs frameworks, the inversion he’s talking about is the hollywood principle. “Don’t call us, we’ll call you.”

1 Like
14

Yes, I understand. I found this article, which explains it best.

DI is about how one object acquires a dependency. When a dependency is provided externally, then the system is using DI. IoC is about who initiates the call. If your code initiates a call, it is not IoC, if the container/system/library calls back into code that you provided it, is it IoC.

DIP, on the other hand, is about the level of the abstraction in the messages sent from your code to the thing it is calling. To be sure, using DI or IoC with DIP tends to be more expressive, powerful and domain-aligned, but they are about different dimensions, or forces, in an overall problem. DI is about wiring, IoC is about direction, and DIP is about shape.

Scott

15

Incorrect. My definition of a framework is exactly the same as that found in https://en.wikipedia.org/wiki/Software_framework

Incorrect. While the framework does allow a developer to create basic user transactions from a catalogue of Transaction Patterns without having to write a single line of code - no PHP, no HTML, no SQL - you cannot put “meat on the bones” and deal with complex business rules without having programming skills.

Correct. Radicore is not a general purpose framework for building any type of application, it was purpose built for the rapid development of web-based enterprise applications which is not, as a lot of people believe, the same as a pubic-facing web site.

16

This is absolutely correct. These features are supported in Radicore as follows:

Inversion of control: Radicore implements the Model-View-Controller design pattern, and in this pattern the flow of control is dictated by the Controller script, and these scripts are provided by the framework and do not have to be created or modified by the application developer. There is a separate script for each Transaction Pattern.

Default behavior: When each user transaction is generated from a Transaction Pattern it can immediately be selected on a menu bar or navigation button and run. It will exhibit default behaviour, which includes primary validation which uses the contents of the table structure file to define the validation rules.

Extensibility: While the generated transactions perform only default behaviour it is possible to extend this behaviour by modifying the contents of the table’s class file. This is done by copying one of the empty customisable methods from the abstract table class, then filling this empty method with relevant code. At runtime the method in the concrete table class will override the empty method in the abstract table class.

Non-modifiable framework code: Components such as the Controller, the View (which includes the reusable XSL stylesheets) and the Data Access Object are part of the framework and do not have to be either generated or modified by the application developer.

17

If we’re now using Wikipedia to define terms, then you’ll also notice that on that particular page there is an Examples section, which lists Web Application Framework as one kind of software framework. If you follow that link, you’ll see that page then gives the following examples of frameworks:

which you’ve previously claimed are libraries, not frameworks.

Firstly, what I actually said was “some of which”. I was not specifically referring to Radicore.

Secondly, you are now contradicting yourself:

vs

so which is it?

18

I agree with points 1 and 2, but not 3. If I have a framework which satisfies points 1 and 2, then how can the fact that it has a PHP configuration file suddenly make it a “non-framework”? How it is configured is surely an implementation detail.

19

I am not contradicting myself. If you read what I wrote you will see that the Controller (which is a framework component) controls which methods are called on the Model (which is an application component) and in which order. All methods in the Model are inherited from a single abstract class, and some of these methods are empty as their sole purpose is to provide places into which the developer can insert code to extend the default behaviour provided by the framework.

The framework component still controls the flow of the application, and the default behaviour can be extended by placing code into an existing but initially empty method which is already called within the processing sequence.

20

Nothing is a framework, except Tony’s. Haven’t you learned that yet?

Scott