Re: Is Pear RADy ?
| From: | Olivier Guilyardi | Date: | Fri, 23 Jul 2004 11:30:21 +0000 |
| Subject: | Re: Is Pear RADy ? | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.pear.general |
| Request: | Send a blank email to pear-general+get-13827@lists.php.net to get a copy of this message | ||
Justin Patrin wrote:
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.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.
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? -- og