RE: [PEAR-DEV] PEAR extension for Macromedia Ultradev ???
| From: | Alan T. Miller | 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