a practical example

Now we'll give an example to furthermore clarify how OOOGUI works.

Let's consider a data model to represent employees that work on projects: for example the employee john smith that works on project of a new house building:

OOOGUI paradigma Object Oriented Programming paradigma Database programming paradigma
Object: employee Class: employee Table: employee
Instance "john smith" of Object "employee" Instance "john smith" of Class "employee" Record "john smith" in the table "employee"
Properties for employee Object: name (simple string), address (simple string), born (date), picture (image), curriculum (multilingual text) Variables for employee Class: name (string), address (string), born (date), picture (file handler), curriculum (string) Fields for employee Table: name (varchar), address (varchar), born (date), picture (blob), curriculum (text)
Object "employee" has a Relation called "works on" with the Object "project" Class "employee" has an array of Instances of the Class "project", and the array is called "works_on" Exists a Table called "employee_works_on_project" that bind employees ids with projects ids
Instance "john smith" of Object "employee" is related with instance "new house building" of Object "project" Instance "john smith" of Class "employee" has, as an element of his array "works_on", the instance "new house building" of Class "project" In the table "employee_works_on_project" there is a row with the id of record "john smith" of table "employee" and the id of record "new house building" of table "project"
The Query "employees_list" returns all Instances of Object "employee" The method "getEmployees()" returns all Instances of Class "employee" Sql Query: SELECT name FROM employee ORDER BY name


Steps that you will do with OOOGUI to create this data model will be explained in examples section, but here we'll anticipate the most important:

  • create a new Object and call it "employee"
  • add properties to the Object. for each property choose at least a name and a data type
  • add at least the Instance "john smith" to the object "employee"
  • create a new Object and call it "project"
  • add properties to the new Object "project".
  • add at least the Instance "new house building" to the object "project"
  • create a relation from object "employee" to object "projects" and call it "works on"
  • edit instance of employee "john smith", and in the relation "works on" add the instance of project "new house building"
  • that's all, of course

As you can expect, OOOGUI generates runtime all the CRUD functinoalities for the new objects "employee" and "project": you can view all employees, sort and search them in variuos ways, and create/modify/delete each of them. Just as any other CMS. But all without writing any code.

Now that we have the data model and the interface to manage its contents, we move to the frontend tier: creation of webpages to represent this data model in a public view.

Suppose we need these pages:

  • employees list
  • employee detail
  • projects list
  • project detail

Each of them is made up by modules, with a schema like this:

  • employees list¬†
    • module header
    • * module employees list
    • module footer
  • employee detail
    • module header
    • * module employee detail
    • module footer
  • projects list
    • module header
    • * module projects list
    • module footer
  • project detail
    • module header
    • * module project detail
    • module footer

With OOOGUI the creation of pages, and creation/assignment of modules to each page, is all made by a WYSIWYG interface. Furthermore the interface lets you see modules in a tree structure, exactly as happens in the DOM (Document Object Model) of any HTML page.

Module header and module footer are simple template files, written in html, without any query to the db. In OOOGUI we specify a template file name, or we create and edit a new file. Obviously we create the header and footer modules only once, and than we assign them to all pages. And if we modify something in a module, modifications will be inherited by all pages that contain the module.

Modules marked with an * are dynamic modules, that is: modules with a query that returns some data from the data model. Also the creation of the queries is totally visual, and no code writing is required. For each query we choose:

  • the object whose instances will be returned as a result
  • the properties of this object that we want in the result
    • properties can be selected for the output object, but also for objects related to the output object
  • conditions on all properties (properties of the output objects but also properties on related objects)
  • sorting criteria for properties of the output instances

For example, let's consider the first dynamic module: employees list.

  • first we create the module
  • than we assign to it a query (that is: we create a new query called "employees_list")
  • this query will return instancers of object "employee"
  • properties returned are "name" and "address" of the employees, but not yet the picture (it will be present in module employee detail)
  • order is by property "name"
  • that's all

For a static module we just need an html template file, but when we create a dynamic module we need the template file but also a php file that calls the associated query, and assigns results to the template. OOOGUI generates these two files for you, according to the query you created. It creates a php file and a tpl file, with pagination, links to detailed views of each object involved in the query, and some other nice features. For example it creates the specific views in the template according to the data type: if we are visualizing a property of type "image", in the generated tpl will be present a javascript widget to zoom the image; if we are visualizing a property of type "video", in the generated tpl will be present a flash player too view video; if the data type is "geo localization" will be visualized a correctly positioned google map.

We said OOOGUI generates the php files: this is usefull if you need to add some business logic to them, or some other customization. But if you don't need customization, you don't need to modify them.

When we finished creating all pages, what remains to do is only the graphic work. As graphic is a subjective matter, cannot be automated: we open each template file and add/modify in it the css and html views of our choice.