Re: Apache::ASP compiling extensions
Aaron Johnson wrote:
I think to help people coming from CGI or EmbPerl that are used to having all params
in the same
place that having $Form be automatic is a must have. You can have it be an option in
the globals if
there is any potential performance hit for doing it I suppose ( could it even be on
if the passed
information was huge since it is referenced or does it have dereference then build a
new reference?
The auto form fill for ASP is just done, see prior mail.
Additional, I propose that setting PerlSetVar RequestParams 1
will create a $Request-{Params} collection like Form QueryString,
but represents a fused version of both, as in:
if($r-dir_config('RequestParams')) {
$self-{'Params'} = bless { %$parsed_query, %$form },
'Apache::ASP::Collection';
}
If someone then wanted to use params as form, they could:
use vars qw($Params);
sub Script_OnStart {
$Request-{Form} = $Request-{Params}; # or script global $Params
$Params = $Request-{Params};
}
- 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
I'll check it out later. Did you have "PerlSetVar UseStrict 1" set?
You need to have this when doing "use strict" coding.
I am interested in the compile time feature, but will it in fact then run any code?
With EmbPerl it
has custom meta commands and the automated html handling, will those blocks of code
be passed to
that module or will they simply be lost? I for one would rather see ASP use some of
the more
helpful features of other packages, but have them be built in.
The compile time features would be aimed at translating foreign
tokens or tags, like [+ +], cfif, xsp:logic to the ASP
structural equivalent prior to parsing to perl code compilation.
- Perl programmers are Lazy why should they have to add a function to something that
could be done
inside the existing structure with little change on the maintainers end and the
knowledge that it is
done right for the end user.
- There is already code that is outside of the ASP "standard" (Script_OnStart etc.)
so adding other
features is truly enhancing the reasons to use Apache::ASP vs. MS ASP.
- New users don't want to have to wade through modules and probably can't and for
them to understand
references is a bit of a stretch. So yes some of the added code is ridiculously
simple if you know
what is does, but that is the beauty of being the magician.
Yes, yes, yes.
-- Josh
Re: Apache::ASP compiling extensions
Joshua Chamas wrote:
Aaron Johnson wrote:
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.
I think I know what you mean, and I'm not sure that's its worth
developing those things, is this a big priority?
Embperl:
table
tr bgcolor="[+ $row % 2?'gray':'white' +]"
td align="center"font size="+1"[+ $multi[$row][$col] +]/font/td
/tr
/table
VS.
ASP:
table
% for my $row (0..$#multi) { %
tr bgcolor="%= $row % 2 ? 'gray' : 'white' %"
% for my $col (0..$#array) { %
td align="center"font size="+1"%= $multi[$row][$col] %/font/td
% } %
/tr
% } %
/table
There are other things, like auto href, form elements etc. that are very helpful.
Perhaps it is the
lack of examples then on how to emulate some of the functions from other modules.
- 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.
sub Script_OnStart {
$Form = { %{$Request-{Form}}, %{$Request-{QueryString} };
}
does this need a config?
I think to help people coming from CGI or EmbPerl that are used to having all params
in the same
place that having $Form be automatic is a must have. You can have it be an option in
the globals if
there is any potential performance hit for doing it I suppose ( could it even be on if
the passed
information was huge since it is referenced or does it have dereference then build a
new reference?
). One less thing to add to "remember/keep track" of. Remember I am a Lazy Perl
programmer :^). I
want things under mod_perl to be as simple as possible for new comers, I think have
POST and GET in
separate variables is only relevant to people coming from MS ASP platform, which is
good, but not at
the expense of proficient CGI programmers.
Shouldn't they just be the same information?
Is there a need to keep them separate?
Its the ASP API. I just ported it.
- 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.
Huh? From http://www.chamas.com/bench/hello.tar.gz, so you
can run it yourself ...
hello]# ./bench.pl -version -time=15 ASP Embperl
Test Name Test File Hits/sec Total Hits Total Time sec/Hits
Bytes/Hit
-- -- -- --
-- --
Apache::ASP v2.09 2000 h2000.asp 229.1 3444 hits 15.03 sec 0.004365
28997 byte
HTML::Embperl v2.0a18 2000 h2000.epl 248.7 3732 hits 15.01 sec 0.004022
28809 byte
Apache::ASP v2.09 hello.asp 395.1 5933 hits 15.02 sec 0.002531
241 bytes
HTML::Embperl v2.0a18 hello.epl 461.4 6933 hits 15.03 sec 0.002167
219 bytes
Apache Server Header Tokens
---
(Unix)
Apache/1.3.14
OpenSSL/0.9.6
PHP/4.0.3pl1
mod_perl/1.24
mod_ssl/2.7.1
PERL Version: 5.00503
Operating System: Linux 2.2.14-5.0smp (root@porky) (gcc egcs-2.91.66) #1 2CPU [gate]
Sorry, I can't get it much faster on hello world, Embperl is written
in C, Apache::ASP in perl. But check out the h2000 tests, much more
representative of real world templates, not just startup time.
My bad, I hadn't looked at the latest results and I wasn't reading the h2000 results
correctly.
- 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.
I haven't seen this in a while, give me a test script I'll fix it.
%
use strict;
$greeting = "Hello";
print "$greeting";
%
( used Apache::ASP 2.03 and it worked correctly, 2.07 on a different machine and it
didn't )
This gets me undefined subroutine as the error message. If I comment out 'use strict'
it runs fine.
I am getting different messages on more complex pages, but this was working correctly
before, but I
am not sure when it broke. ( post 2.03 maybe )
- 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?
ASP does have a UniquePackages feature that could possibly make use
of this garbage collection, but then you are not in the same package
as global.asa where you get to init easy to use globals such,
its a trade off.
To do things really cleanly, keep one global hash for per
process data, and then undef it in Script_OnEnd. The rest
should be caught by the UseStrict config.
- No auto form fillin. I know this has been
Apache::ASP compiling extensions
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
Re: Apache::ASP compiling extensions
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
Re: Apache::ASP compiling extensions
Aaron Johnson wrote:
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.
I think I know what you mean, and I'm not sure that's its worth
developing those things, is this a big priority?
Embperl:
table
tr bgcolor="[+ $row % 2?'gray':'white' +]"
td align="center"font size="+1"[+ $multi[$row][$col] +]/font/td
/tr
/table
VS.
ASP:
table
% for my $row (0..$#multi) { %
tr bgcolor="%= $row % 2 ? 'gray' : 'white' %"
% for my $col (0..$#array) { %
td align="center"font size="+1"%= $multi[$row][$col] %/font/td
% } %
/tr
% } %
/table
- 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.
That's the way the API is, I could create a config to merge them,
but its always seemed as easy to
sub Script_OnStart {
$Form = { %{$Request-{Form}}, %{$Request-{QueryString} };
}
does this need a config?
Shouldn't they just be the same information?
Is there a need to keep them separate?
Its the ASP API. I just ported it.
- 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.
Huh? From http://www.chamas.com/bench/hello.tar.gz, so you
can run it yourself ...
hello]# ./bench.pl -version -time=15 ASP Embperl
Test Name Test File Hits/sec Total Hits Total Time sec/Hits
Bytes/Hit
-- -- -- -- --
--
Apache::ASP v2.09 2000 h2000.asp 229.1 3444 hits 15.03 sec 0.004365
28997 byte
HTML::Embperl v2.0a18 2000 h2000.epl 248.7 3732 hits 15.01 sec 0.004022
28809 byte
Apache::ASP v2.09 hello.asp 395.1 5933 hits 15.02 sec 0.002531
241 bytes
HTML::Embperl v2.0a18 hello.epl 461.4 6933 hits 15.03 sec 0.002167
219 bytes
Apache Server Header Tokens
---
(Unix)
Apache/1.3.14
OpenSSL/0.9.6
PHP/4.0.3pl1
mod_perl/1.24
mod_ssl/2.7.1
PERL Version: 5.00503
Operating System: Linux 2.2.14-5.0smp (root@porky) (gcc egcs-2.91.66) #1 2CPU [gate]
Sorry, I can't get it much faster on hello world, Embperl is written
in C, Apache::ASP in perl. But check out the h2000 tests, much more
representative of real world templates, not just startup time.
- 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.
I haven't seen this in a while, give me a test script I'll fix it.
- 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?
ASP does have a UniquePackages feature that could possibly make use
of this garbage collection, but then you are not in the same package
as global.asa where you get to init easy to use globals such,
its a trade off.
To do things really cleanly, keep one global hash for per
process data, and then undef it in Script_OnEnd. The rest
should be caught by the UseStrict config.
- No auto form fillin. I know this has been discussed, I have even made
crude code that allows it.
I would like to develop this too. Thanks for your feedback.
So I take it you're not particularly interested in the
compile time feature additions? :)
--Josh
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
