If what you are saying is that current EmbPerl code would be able to run
almost unchanged under ASP that would be very interesting, but presently
my biggest issues with Apache::ASP are:
- Doesn't "help" with any HTML.
- QueryString and Form from the Response are separate, this makes a
programming headache if you are used to Embperl or if you are not sure
what type of input is coming in for some reason.
Shouldn't they just be the same information?
Is there a need to keep them separate?
Why don't other modules do it that way if there is?
- Slow processing time, on the Hello World test it is one of the slower
ones. EmbPerl 2.0 is supposed to be even faster then the present
version.
- Poor error reporting. This seems to be possibly a resurfaced bug, but
when use strict is turned on ( not the global one, but on a per page
level ) when testing a page for compliance it gives no intelligent error
message as to where the problem might be. I see in the docs where this
has been addressed (fixed) before.
- No automatic variable clean up. I think EmbPerl runs each page as its
own package to keep things "clean" is that possible under Apache::ASP?
- No auto form fillin. I know this has been discussed, I have even made
crude code that allows it.
To be fair I better list some of what I like:
- Script_OnStart and Stop: This makes it easy to build headers and
footers for even complex applications.
- Built in Session handling
- Only one type of tag to remember ( <% ), well ok two if you count <%=
There are others, but those are the main ones I can think of off the top
of my head.
I think making it do its job better and faster is more important then
trying to allow for other delimiters IMHO.
Aaron Johnson
Joshua Chamas wrote:
> Hey,
>
> I am considering long belated compile time extensions
> that would allow at least partial handling of other languages
> formats like Cold Fusion, XSP, Embperl, ... a developer would
> be able to rewrite a template at compile time into ASP.
>
> Here's what I have in mind:
>
> PerlSetVar TagParseMatch ^xsp:
> ## for XSP conversion of <xsp:logic>...</xsp:logic>
> # global.asa
> sub Script_OnTagParse {
> my($tag, $begin, $args) = @_;
> if($tag eq 'xsp:logic') {
> my $replace = $begin ? '<%' : '%>';
> } ...
> }
>
> PerlSetVar TokenParseMatch [+,+],[*,*]
> ## for Embperl conversion of [* *] type constructs
> # global.asa
> sub Script_OnTokenParse {
> my $token = shift;
> if($token eq '[*') {
> '<%';
> } elsif($token eq '*]') {
> '%>';
> } ...
> }
>
> The results would then be inserted into the parse stream
> for ASP before other language parsing is done.
> Once compiled, there would be no extra overhead to
> running the code, unlike with XMLSubsMatch. XMLSubsMatch
> will continue to be the only way to handle the text
> contained within a tag like <tag> text </tag>.
>
> So what do you think? Will anyone use this?
>
> -- Josh
