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