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

TomB · July 14, 2015, 2:32pm

tony_marston404:

But that is not all that my transaction generation process does. For example, the most common transaction pattern in all the applications which I have built is the LIST1. This is part of a family which also includes the ADD1, ENQUIRE1, UPDATE1, DELETE1 and SEARCH1 patterns. When you create a LIST1 task it performs the following:1) Generates the transaction script for the LIST1 task.2) Adds the LIST1 task to the TASK table in the MENU database.3) Adds the LIST1 task to the MENU table in the MENU database.4) Generates the transaction scripts for the associated ADD1, ENQUIRE1, UPDATE1, DELETE1 and SEARCH1 tasks.5) Adds ALL these task to the TASK table in the MENU database.6) Adds ALL these task to the NAVIGATION table in the MENU database.

This means that the LIST1 task will be instantly available on that subsystem’s menu bar, and all the associated tasks will be available on the LIST1 task’s navigation bar. All these tasks will be runnable with default behaviour but without having to write a single line of code - no PHP, no HTML no SQL. Can YOUR framework do that?

Simply put: it doesn’t need to because putting it together doesn’t require so many repeated steps each time I want to add something… as I said, it violates DRY.