On Thu, 27 Jul 2000, Joshua Chamas wrote:
> Matt Sergeant wrote:
> >
> > On Thu, 27 Jul 2000, Ime Smits wrote:
> >
> > > 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.
> >
>
> ???. This will be a generic parser for VBScript. What I would
> feed it from Apache::ASP is a wholly native VBScript, with all
> the static html ASP parts compiled out already into $response->write('');
> string, or something to that effect. Ime's VBScript parser
> will not have to know anything about static HTML bits, nor ASP
> objects, that's the beauty of something like a pure vbscript to
> perl parser. I'll handle all of the object definitions on the
> other side, I already do, and do both pre & post processing to
> the ASP script so that hey can focus on the hard part, the
> VBScript parser.
I guess what I was picturing, was setting up Apache::ASP so that its no
longer perl dependant at all, and that language specific bits aren't
included anywhere. If you pass:
>>
Response.Write "Hello "
$response->write("World!");
<<
To a VBScript parser it should die. So you could define the concept of how
to write "$response->write( ... );" in other languages somehow, in the
actual class that implements (or calls) the parser. That way pluging in a
JScript parser becomes easier, and you could even support multiple
languages in the same file, a-la MS ASP.
--
<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
