raptor wrote:
>
> <%# &my:preif() %>
>
> <%# &my:preelse() %>
>
>
>
> Will my::preif and my:preelse have the access to the HTML code in their
> container ..?
>
At compile time, this type of functionality might have access
to the ASP code in its container as a string only.
> > I
> What I mean by post processing is for a tag like this
>
>
> some HTML
> <% # ASP code block %>
>
>
> The &my::tag() sub executes after the contained HTML & ASP
> do, so that its $HTML in $_[1] is static output from the
> wrapped ASP/HTML. You don't get any function executing
> as a prepro
> What I mean by post processing is for a tag like this
>
>
> some HTML
> <% # ASP code block %>
>
>
> The &my::tag() sub executes after the contained HTML & ASP
> do, so that its $HTML in $_[1] is static output from the
> wrapped ASP/HTML. You don't get any function executing
> as a prepro
raptor wrote:
> >
> > But, if you really want pre processing & post
> > processing, we need something new, since the current
> > XMLSubs model just handles post processing.
> ]- isn't the XMLSubs replace the tag with function-call before executing the
> ASP code... ?!!
What I mean by post process
> Off the top of my head, why have your tags translate to
> my::default, wouldn't this be better to have:
>
> PerlSetVar XMLSubsDefault my::default
>
> then
>
> sub my::default {
> my($tag_name, $args, $html) = @_;
> ...
> }
>
> But, if you really want pre processing & post
> processing, we n
