Hi All ,
Is there any way in Apache::ASP to dynamically give a XSL file rather setting
to default like template.xsl in .htaccess file as given in eg directory.
Also iam seem to be having erros when using LIBXSLT
XSLT/XML processing error: Can't locate object method "new" via package "XML::LibXSLT"
at /Net/stmdvocs/sbcexp/devl/SunOS/sparc-5.6/run/pd/cpan/5.6.1-eval/lib/Apache/ASP.pm
line 1718. ,
/Net/stmdvocs/sbcexp/devl/SunOS/sparc-5.6/run/pd/cpan/5.6.1-eval/lib/Apache/ASP.pm
line 3817
Seem to be having a problem in the line
my $xslt = XML::LibXSLT->new();
Any pointers what iam doing wrong would be very helpful.
Thanks
Raghu
-----Original Message-----
From: Josh Chamas [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 21, 2002 2:52 PM
To: Brat Wizard
Cc: Apache::ASP Mailing List
Subject: Re: Yet more code (Was: Re: A nifty code sample to share)
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]
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
