If you’ve been around PHP a little, you’ve probably run into asp2php before, an app which attempts to convert ASP 3.0 code (VBScript mainly) to PHP automatically. I’ve mentioned and joked about this stuff before but recently been playing with something that looks serious.
While asp2php is a brave project and I have no wish to knock it, from past experiments found it unconvincing. Yes it delivers something resembling PHP but the real issue is what still remains TODO - basically an 80/20 thing. And while that is to be expected with any tool of this kind, the problem is there’s no way to control what get’s generated, other than by modifying the C source.
A while back, while looking for tools able to parse PHP1), run into ASPA, developed by Anakreon Mejdi: “ASPA attempts to automate the process of translating asp pages into php. The supported languages are JScript and VbScript.”.
ASPA is written in Java and builds on top of ANTLR, a mature, Open Source parser generator framework. What makes it special, IMO, is it’s fairly easy to control the output PHP by virtue of XML “mapping” files which are loaded at runtime (during conversion). You’ll find this describe a little here (PDF).
After playing with ASPA for a while, here’s a few notes / thoughts.
- Expect to have to spend time installing - you’ve got usual Java pain to deal with here, including ant - I needed to rebuild ASPA. Here I’m only going to give hints based “it worked for me” on WinXP.
- I used version 1.2 of ASPA. It lacks various dependencies namely antlr, log4j, dom4j and commons-collections, which Anakreon describes. A quick way to get them all is to download the 1.1 of ASPA which has them all in the ./lib subdirectory - just copy across the v1.2 ./lib subdirectory. What’s missing though is the Jaxen .jar, which also needs to go into the ./lib directory - you can get a built version from here
- If you look in the ./etc/log4j.properties file you’ll find it identifies a log file like log4j.appender.FILE.File=logs/log.txt - this is relative to the base ASPA directory and you’ll need to make sure this file / directory exists. Once you have ASPA built with ant, the aspa-1.2/build/classes/gr/omadak/leviathan/asp/log4j.properties file can be used to control how much logging happens every time you convert
- With ASPA built, the XML translation files can be found at aspa-1.2/build/classes/gr/omadak/leviathan/asp/objects. I believe (not tested) you can create new XML files here with filenames corresponding to the ASP / ActiveX objects you want to convert to PHP as described here (PDF). While what ASPA does here is a great start, it strikes me that to really empower users, something like Rhino or Jython is needed, combined with access to parse time information from ASPA.
- To put it to the test, I picked the first ASP Blogging app, published under GPL, that I could find via Google - Ublog. For comparison, I’ve dumped the results here along with the ASPA log file. Haven’t modified that or done any significant tuning of the output. Basically it’s at the 80% mark I’d guess. Some files it failed to convert, as explained in the log. Other things like calls to require name a .asp which will have been converted to a .php file so no longer exist. Meanwhile some thought need to go into XSS implications of all those print statements. And thought is needed as to whether APIs have been translated in the smartest manner e.g. the DB calls which ASPA primes for use with John Lim’s ADODB but look to be about 90% there API-wise. But the donkey work has been done - the last 20% is doable and by pushing at much as possible into the XML translation files, it may be possible to get down to 5% or lower.
Overall ASPA is looks to be very much at the “it works” stage but now needs to aim for “it’s accessible”. In particlar the ability to modify the output PHP fairly easy marks it as significant and there’s potentially a serious tool for “the masses” here, if an easy to install binary distribution can be put to together and, better yet, if a GUI to be stuck on top to help manage conversions (e.g. the XML translation files are “global” to ASPA but their use would likely be application specific). In it’s current form I guess this would be a big help to ASP developers interested in having PHP versions of their code. There’s also opportunity to inject some kind of PHP framework into the mix, as the target output API - one that’s primed to support common ASP idioms. Perhaps those droves might happen one day after all ;)
Side note: What led me to ASPA was looking for tools able to parse PHP scripts, for doing something like a PHP lint. Interestingly there are hardly any that really “understand” PHP and when they do, it seems to lead to people wanting to keep the results closed source. Aside from hand coded stuff like phpxref, two exceptions are scintilla (which you can tap into in Python via SilverCity or wx.STC but the tokens are very general) and spident (which was more Java than I cared to submit myself to).
No comments:
Post a Comment