Brat Wizard wrote:
>
> Josh- why not make it a simple directive, like a pragma-- then it could be
> specified inline by the end-user whenever (and if-ever) they need it one way
> or the other.
>
> Perhaps something like:
>
> $Apache::ASP::XMLSubsPostProc = 1
>
Right. I would never take away the current style/method of XMLSubs,
just add to it like you suggest.
> <my:sub>
> <my:nestedsub><%=$blech%> __TOKEN1__</my:nestedsub>
> <%=$foobar%> __TOKEN2__
> </my:sub>
>
> You could wait until after the first my:sub had been called to interpret the
> rest-- just process everything post. In my thinking __TOKEN1__ and __TOKEN2__
> would get resolved by the renderer function on the first pass and
> <my:nestedsub>, $blech, and $foobar, would get processed immediately
> afterwards-- after the tokens had been substituted.
>
> How would that work out do you think?
>
So then the parent XMLSubs output would be then evaluated
at runtime as ASP script automatically by the system. That
is an interesting way of looking at doing the pre-processing.
The only problem with this model is that runtime parsing/eval
of the code would be expensive. The other preprocessing model
that I was considering would not do ANY inner code substitution
on its own, leaving this to the XMLSubs definition to do if
it wanted to.
I am not sure which one I would lean to more, but they are both
interesting models.
>>my $pgimage = My::PgImage->new(
>> ASP => $asp,
>> Attrib => { pg=>"__PG__" sku=>"__SKU__" },
>> Parent => $pgloop
>>};
>>$pgimage->execute(\'');
>>$pgloop->execute(\$final_data_output_within);
>
>
>
>>This pre/post processing model would allow pgimage to
>>work with $self->{Parent}{sth}, or pgloop could populate
>>its own data in this way. Output from pgimage could be
>>trapped and inlined, passed into the execute() function
>>for pgloop.
>
>
> Hmm- sounds a little complicated. Not to mention you are exposing a lot of the
> $asp guts to the programmer/user that way and the goal should be the exact
> opposite-- to abstract that away from the programmer and toward the
> web-monkey/end-user...?
>
>
This was just an example of how the preprocessing model would
get executed. This would be more for the XMLSubs definer to
worry about. I ideally to the end user, things would just work.
I believe that XMLSubs will have to grow in complexity to be
able to do really doo things that other platform taglib functionality
offers. I will be looking hard as JSP & AxKit before I do any
next generation XMLSubs for sure.
>
> Actually I was thinking something very similar but for another reason-- if you
> use delayed processing, like I describe above, conditionals actually get
> pretty easy I think. You just build them into the my:sub "$body" text and let
> the post-processing pick them up.
>
I see the power of the preprocessing + execute output during post
processing model. The speed issue is the only one I have to get
over here. I'll look at some taglib libraries that I would like
to implement in Apache::ASP & see what kind of power we need here.
It may be that some things are only possible with the kind of
power that you suggest, and its a very interesting idea giving
the XMLSubs programmer the ability to rewrite the code on the fly.
> All you need to do is make the one adjustment to handle <% %> subs post
> instead of pre and I think the render function can handle the inbetween
> stuff. The __TOKEN__ format is very comfortable and intuitive to me in this
> instance. It seems very obvious that they are serving as placeholders for
> yet-to-be-in-scope data. And by delaying the <% %> processing, you allow
> substitution to occur _before_ conditional blocks take place.
>
>
> What is your take on all this?
>
> I think we've just descibed a very functional, useable processing paradigm
> that fits with the current "feel" of the asp system, and with the single
> exception of moving <% %> substitution to post-processing, you don't have to
> make any other radical changes to the Apache::ASP framework or api (at least
> I don't think you do).
>
> Your thoughts?
>
Pretty good stuff. I'll definately be following up on this later
when I go to implement, so stay tuned.
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
