DB interface builder

We have a 'NoSQL' database with an API (which we'll provide). The API allows to: - manage content - manage structure - query the database This API is a webservice API (returns JSON). The database is used by companies already and is liked because of it's flexibility and ease of use. We want to expand the system now with an 'interface builder' for this database. The project we are proposing here is a web based 'app builder' for this database. Some terms: - Queries; these are searches in our query language (this is just a simple boolean thing) - Views; these are graphical representations of the data using a query - Pages; these are dynamic html pages containing views - App; a collection of pages + a theme - Template; a HTML + custom tag representation of how a page or view should look - Theme; a combination of templates and css defining the layout of an app The current system allows users to define and store queries, queries can be requested per user or per list; this gives back a list of currently defined queries which you can use. Query can have variables, these are indicated with {{name}} in the query; these variables should be used, unless otherwise indicated, with server request parameters (get/post). Defining a view starts with picking a query or a table (which is comparable to select * from table; without the where). The user has to specify the following configuration options for the view; - name - query / table - type (see below) - options (type dependent) - permissions (view/add/edit/delete) - connections (see below) - default sorting - fields The type of the view is the most important; this just be extendable (NOT hardcoded) with plugins; we need to be able to internally in our company add new types. Type examples are; - list; show records in a table list structure - card; show 1 record - form; show an add/edit form - graph - ... etc A type is defined by a template and a number of options; those options depend heavily on the chose type. For instance when you pick a list type you need options like; [x] sorting [x] pagination [x] search ... When you define a graph, you need to define stuff like; [pie / bar / line / dot] [x] legenda ... etc We assume, for version 1, that we have 10 types. Provider will aid us in defining the options for those. Templates should be *very* simple and without code; we did not yet select a template mechanism, but it should be simplistic, not exploitable (so no executable code) and easy to port to other languages, meaning it should be *small*. Not something horrible like Smarty. Permissions are based on roles; the user can define roles and permissions are set on these roles. Connections are type dependent and indicate where links go for a view. For instance, a list type has links: - global links - - add - row based links - - edit - - delete Those links need to lead to end points; aka pages which have views conforming to that action. If they are NOT filled, the action will point to itself, so the edit/add screens will open in place of the list and return to the list afterwards, but they can also point to another page which should in that event respond to the action correctly and when the action is finished, return to the previous page. You can add custom links which, on a row level, jump to the link using the id of the row (all rows have an unique id) and the table id and on a global level they use only the table id. The resulting page/view can/should use the information to 'do something'. Custom parameters can be added to custom links; the target needs to respond to them. Now is a good time to tell a little more about pages; pages have views on them; there are different page layout types; 0 column, 1 column, 2 column. We need to be able to add more, but the basic concept is; you can add views to sidebars and to the content (main) pane. And when you link them up, you link to a page/view. So you cannot only link to a page, you need to pick a page a