why OOOGUI exists

so here is the base idea of OOOGUI: give the designer the ability to create his own custom data model via a WYSIWYG interface, and let OOOGUI do all the work to runtime generate the CRUD functionalities to manage contents of the data model. In other words: OOOGUI is a CRUD interface to create custom CRUD interfaces; or, if you prefer, a CMS to create CMSes. Someone called OOOGUI a meta-CMS.

 

let's try to be clearer.

the typical work process for a developer is something like this:

• backend tier:
• 1 - get problem specifications from the customer
• 2 - translate specs to a data model and to some business logic
• 3* - implement the data model with a database (sql/etc...)
• 4* - write code for CMS CRUD administration of the data (both queries and templates: sql/php/html/css/smarty/etc...)
  
  
• frontend tier:
• 5* - define the wireframe: create pages hierarchy for the frontend, and for each page define it's main layout, intended as a composition of modules (html/css)
• 6* - for each module write queries (the business logic) to fetch data (sql/php/etc...)
• 7* - for each module write templates to show data (html/css/flash/etc...)
• 8* - personalize the graphic layout and style sheet of the templates
  
  
• the lifecycle of the software:
• 9 - deploy software to production
• 10 - get feedback from customer and users
• 11 - modify specifications
• 12 - goto 2

 

traditionally in this process the steps marked with a * are real programming (writing code) activities for the developer, so these are the most time and resources consuming steps. Well, the goal of OOOGUI is to give developer WYSIWYG tools for steps 3,4,5,6 and 7. That is: the only code to be written is the step 8: the personalization of the html/css/flash view. About all the rest will (should!) take care OOOGUI.