RE: [PEAR-DEV] PEAR extension for Macromedia Ultradev ???

From: Date: Fri, 17 Aug 2001 01:06:51 +0000
Subject: RE: [PEAR-DEV] PEAR extension for Macromedia Ultradev ???
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-1578@lists.php.net to get a copy of this message
> Please describe once again, how this abstraction looks like. Is it one > file for each PEAR class? Is it one big file? Ultradev extensions are distributed as one file (kind of like a tar ball or zip file which contains all the needed files but with an .mxp extension). This file is executed by the Macromedia Extension manager and the extension manager handles installing it and setting it up on Ultradev. That installation process unpacks the MXP extension and copies the XML, Javascript, and HTML (in our case many PHP files as well) to various directories under the Ultradev program directory tree and keeps track of the installation for easy removal etc. The extensions themselves may contain many files. It is unlikely they would ever include any PEAR classes, rather they would include custom scripts that call and use PEAR classes, along with many HTML, XML, and Javascript files that make up the Interface. This is the stage where I see a benefit in having this be a part of CVS. The source scripts could be maintained there, and then when a "release" was ready we would compile that with Macromedia's tool, and place it somewhere for download (either available alongside the corresponding PEAR class, or right in the CVS). They could be stored out of the way in a separate area such as... ULTRADEV_DB/ or ULTRADEV_AUTH or even COMMERCIAL/ULTRADEV/DB, COMMERCIAL/ULTRADEV/AUTH. In theory there could be one file per PEAR package (although I am not advocating making Ultradev extensions for each and every PEAR component). The extensions, once installed in Dreamweaver would allow you to take advantage of PEAR from within Ultrdev by being able to call the various methods of PEAR classes. If for example you wanted to call a particular method of a PEAR class, and yet needed to initialize it with a particular parameters, those parameters would be outlined in the Ultradev extension interface and provided as HTML widgets. Once you had ran through the Interface, Ultradev would copy the correct code from the Extension to set up the PEAR component. If you were retrieving a dataset from the database for example, the extension interface would present a html widget form that would allow you to select the table(s) to query, and assemble the query and once done, the appropriate PHP code would be written to the application. The connection itself would also be handled by an HTML widget and corresponding PHP code, and XML to describe the data to Ultradev. A current implimentation, copies the whole database abstraction layer to the open application and creates the files that set up the application to use that database layer. What I was thinking before, there could be a common Ultradev extension to PEAR, that would handle error routines and other features of PEAR and the other Ultradev extensions can then take advantage of it. Maybe a CVS structure like... COMMERCIAL/ULTRADEV/PEAR COMMERCIAL/ULTRADEV/DB COMMERCIAL/ULTRADEV/AUTH COMMERCIAL/ULTRADEV/NUMBERS/ROMAN I did contact someone named Alexander Costin, one of the authors of the current Ultradev Extension about porting what they did. He told me that they were so far into development with the ADODB version of the Ultradev Extension that they decided to stick with it a while ago, but were very interested in helping me work on something like this. > At the moment there may be no other commercial products like UltraDev. > But that will surely change (there is a big market for such software). I can also perhaps an open source Ultrdev like application written with PHPGTK, and would welcome other commercial products like Ultradev, unfortunately there is nothing I am aware of right now, and I know if one could use PEAR and PHP from within Ultradev with the same convenience as you can ASP / JSP, that would make PHP a real viable alternative. One problem I face a lot is that people do not want to think of PHP as a "true" option for commercial development in part because it lacks many benefits like the fact that it is not as convenient and supported. I would like to help change that. Alan

« previous php.pear.dev (#1578) next »