Forum Moderators: coopster
Ok, here goes
It's based on an MVC architecture, at the heart is in-depth ORM layer defined by dictionary schema. It will connect to most data sources in much the same way using the same commands. It has its own very simple template engine which can be replaced with either XSL or Smarty. It has some JavaScript integration, session management, email, FTP, file, XML, LDAP and a heap of other stuff it can do behind the scenes as well as what you define.
I would like to give you an example of a basic action:
$obj = new Ivy_Database('table_schema');
$obj->select(); //selects everything, you can add WHERE clause and an array of fields to retrieve
$this->display->addResult($obj->id); // this will add the results to the display
$this->display->addForm($obj->id); // this will a form to the page populated with the first record bought back.
if ($obj->insert() !== FALSE) { // attempts to validate and insert the data, if a non false value is returned, then add some text to the display.
$this->display->addText('Record added!');
}
That's pretty much the just of it, in the dictionary you have keys defined as:
For the html parts: title, type, size, class, id, cols, rows etc
For the back end logic: type, size, regex, minsize, required, unique etc.
You also have other parts to JOIN other tables, also to build a select list from another table (or static array) and even a way to replace keys with their real values from other tables (example: product ID = product name (product ID) perhaps))
The SQL generated is a single query from a single request with sub queries / JOINs where needed. As you may tell the dictionary contains meta data for the display, validation, even JavaScript validation reads form this file so you don't have to define JS to validate code.
I don't want to keep babbling on much longer so finally the other main part is the ability to access any data source in the exact same manner. The "$obj->select()" will work with Oracle, MySQL, MsSQL, AD, File, INI and XML. It doesn't care what it is you still define the data in the exact same way and the API layer handles everything else. When you want to switch to normal query mode "$obj->query('select * from table');", the layer will attempt to match the fields it brings back with its meta data, meaning you can continue to build forms and result sets with out having to make a template specific to that query.
I wanted to tell a few people about this as I have hit a stage in it's development where I could be ready for a public release. It's hosted on Sourceforge (using SVN to transfer it between work and home) and I am finalizing my install script and adding documentation. Because I have been the only one working on this I have a very narrow view on what I think is good and what isn't. I really want to find out from you guys is if you think that any of what I have described could be useful to someone! Many thanks!
I will be interested in seeing the install and doc.
further I was never able to feel in love with smarty
how much of a task will it be to instead use any other "homemade" template system?
It will be pretty easy to replace the engine that does the pre-parsing of templates (if it be Smarty or something else). All display data is held in a single assoc array that contains navigation, content, results sets, form, user - everything that you need to see on the template. This data in turn is accessed by the parser. It used to be XSL a long time ago, now it's a custom tag replacement (much the same way Smarty works but much less to it).
