On Thu, 27 Jul 2000, Ime Smits wrote:
> | Well you still have to implement a VBScript parser (Damian, of course,
> | implemented a latin parser), and the problem is that ASP is parsed by
> | Apache::ASP, not by perl, so you'd have to make use of the VB parser at
> | that point.
>
> Hi, just wanted to let you know, I'm going to pick this up in about one or
> two weeks from now, as soon as I tackled some deadlines.
>
> In short, I have the following in mind and partially worked out in actual
> code. A package VBScript::Parser which offers:
>
> $parser=new VBScript::Parser;
> $evalable_perl_code = $parser->parse($complete_asp_page);
No. The problem is that it would be really great if this could be a
generic VBScript parser, rather than an ASP/VB parser.
I can see two methods to do this (there are probably more):
1. Create a parse tree out of the ASP, the parse tree can be dead
simple, just an array of blessed scalar refs, the bless objects being
::Characters, ::Code and ::Output (presumably Apache::ASP::...). Then do a
second pass that converts each using the parser to pure perl, using an
appropriate language module. (the perl version can reproduce the perl code
verbatim, the VB one has to do some translating).
2. Have language modules that contain getBinder, getResponseStr, etc
methods. For Perl this is "->", and "$Response" respectively. Or something
similar that allows you to construct language independant
$Response->Write() parts for non-delimited parts (the plain HTML bits) and
<%= ... %> delimited parts. Then you end up with a single script in either
Perl or VB. Then you pass it to the translate() method, which in perl is
simply sub { return shift; }, and in VB does all the work, using a generic
VB to Perl translator.
--
<Matt/>
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org
