You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Gerald Richter <ri...@ecos.de> on 2001/10/01 19:47:58 UTC

Re: Embperl.v2 + SSI Syntax / tables

>
> Ok, I've got a better patch now.

Great :-)

> I've removed my earlier debug code and
> the <!--#include embperl="foo"--> hack. I've changed the code for
> <!--#include file="file"--> So that it does this instead:
>
> Execute ({inputfile=>$file, output=>$return, syntax=> "Text"})
>
> May as well use the technology if it exists, instead of opening and
> reading the file manually...
>

Yes and No. Open, read and output is faster then useing Execute, but with
Execute you get all benefits of EmbperlObject. Maybe it would be a good idea
to add a syntax argument, so we can also include Embperl files...

> <!--#include virtual="file"-->
>
> Basically does this now:
>
> Execute ({inputfile=>$virtual_file, output=>$return, syntax=>"SSI"})
>
> If somebody wants to put Embperl code into $virtual_file, right now
> they'd have to switch the syntax using <!--#syntax type="Embperl
> SSI"-->. I'm not to sure how this could be made smarter, or inherit the
> default of the calling document.
>

Either add a (optional) syntax argument or maybe look at the file extention.
The second possiblity will come into Embperl in one of the next releases,
where you will be able to make mappings for example file extention to
syntax.

> The only other thing I need to play yet with, is to get this to work:
>
> <!--#include virtual="/something?foo=bar&baz=tan"-->
>
> I guess basically split on the ?, then throw the arguments into %fdat...
>

Yes, but do not directly throw it into %fdat, but instead pass them as fdat
parameter to Execute


What is the following code good for ? It looks a little bit like a hack...


 if ($filename =~ /^\//) {
 $filename = $ENV{DOCUMENT_ROOT} . $filename;
 }



> > > Is optDisableTableScan gone forever?  Or is it one of those things
> > > that's hard to reimplement in the 2.0 rewrite?
> >
> > Maybe it will come again, not sure. I prefer more to make Embperl more
smart
> > to handle such situations automaticly correct...
>
> Of course... by the way, regarding the </td>/tr/table thing I discovered
> the other day... I discovered something which may or not help, but I'll
> mention it anyway since it might help. I was taking a look at
> HTML::Embperl::Syntax::EmbperlHTML::Init, and noticed that it wasn't
> doing a AddTagBlock for td...

Yes, Embperl never had looked at td tags, only tr and table

> so I commented out the AddTagBlocks for tr
> and table, and now <td></tr></table> comes through fine...
>

Of course it comes out fine now, because Embperl didn't look at tables at
all. That's the same behaviour as $optDisableTableScan in 1.x, but you can't
switch it dynamicly on and off, so you won't have any dynamic tables.


Gerald



-------------------------------------------------------------
Gerald Richter    ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting

Post:       Tulpenstrasse 5         D-55276 Dienheim b. Mainz
E-Mail:     richter@ecos.de         Voice:    +49 6133 925131
WWW:        http://www.ecos.de      Fax:      +49 6133 925152
-------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org