Re: Is Pear RADy ?

On Fri, 23 Jul 2004 13:30:21 +0200, Olivier Guilyardi <ml@xung.org> wrote: > Justin Patrin wrote: > > > >>About phpCodeGenie : this is simple and straight-forward, it generates > >>some code for the usual task of editing tables, which code actually is a > >>base on which you can start building the real application. In my case - > >>developping an ERP/CRM intra(extra)net/extranet - this is a good tool, > >>because there are _many_ tables linked in _many_ various manner. > >> > >>Now, phpCodeGenie does not make use of PEAR, and second it's quite > >>limited. The whole project seems to involve a relatively basic knowledge > >>of php, but the idea is good, and it works(tm). > >> > >>So here comes my question : wouldn't the features FormBuilder/Frontend > >>attempt to provide better fit in a such code-generation application ? > >>More generally, what about a graphical/semi-graphical (web/gtk/etc...) > >>RAD tool specifically designed for PEAR ? > >> > >>pearBuilder ? > > > > DB_DataObject does code generation, but it can also be updated > > whenever you want without breaking your additions (That's what the > > AUTOCODE tags are for). FormBuilder is better because everything can > > be created dynamically and just because it's all OO. That genie thing > > is very......basic. > > Don't get me wrong on this, I'm not literraly comparing FormBuilder and > phpCodeGenie. It's like children : sometimes with a few words they're > able to say more than a hundred of philosophers who, despite the > kazillion of words they know, do not actually _mean_ anything anymore. > Now, if you're able to bring the best of both worlds, spontaneity and > knowledge, you are really getting somewhere. phpCodeGenie is spontaneous. > > The AUTOCODE feature is nice, although I'd like to see how it behaves > when a program gets big. > > > If you use my Frontend package, all you have to do is run > > createTables.php on your database, set up your DataObject.ini and > > db.links.ini, set up your display fields for linked tables, and you > > have a DB browser and data editor. Ok, so that's a lot of steps. Yes, > > it would be nice to have it all done in a GUI....but then again, it's > > not that hard to just write the code yourself. If you'd like to work > > on a Graphical configuration script, I'm sure we'd all welcome it. > > About a GUI, Gtk_MDB_Designer seems interesting, it lets you define > table links, although browsing the doc I couldn't figure out how the MDB > xml describe those links. But if it does, this schema - whether you > produce it with Gtk_MDB_Designer or a text editor - seems like gold to > me. From it one could generate 80% of the application, from the actual > sql tables to the html frontend, so that only remains the more > interessing part of hand-coding the business logic. > > A last question : would this MDB approach integrate well with DataObject? > Someone is working on an MDB version of DB_DataObject, but it's going to be a while. It's a different paradigm. I think it would be great to have MDB and its schema files working with DataObject. -- DB_DataObject_FormBuilder - The database at your fingertips http://pear.php.net/package/DB_DataObject_FormBuilder paperCrane --Justin Patrin--