Onderwerp: Link in nieuw venster openen

Ronald Klip wrote:
> "[ Martin ]" <[ Martin ] @www.WinampNederlands.nl> schreef:
>>>> <?php
>>>> $adres = "http://nu.nl/deeplink_html/";
>>>> $begin = "<b>Sport</b>";
>>>> $eind = "<b>Net</b>";
>>>> $openen = fopen("$adres", "r");
>>>> $lezen = fread($openen, 200000);
>>>> $data = eregi("$begin(.*)$eind", $lezen, $tekst);
>>>> fclose($openen);
>>>> $tekst[1] = str_replace
>>>> ("/novum/","http://nu.nl/novum/",$tekst[1]); echo $tekst[1];
>>
>>>> Wat moet ik toevoegen om de links in een nieuw venster te laten
>>>> openen?
>>
>>> Het kan eventueel met een target (of een base href)
>>
>> Ja, dat begrijp ik (target="_blank"). Maar waar plaats ik dat in de
>> code?
>
> fclose($openen);
> $tekst[1] = str_replace ("/novum/","http://nu.nl/novum/",$tekst[1]);
> $tekst[1] = str_replace ("</a>", "target='_blank'</a>", $tekst[1]);
> echo $tekst[1];

Dan krijg je <a>...target='_blank'</a> en dat werkt dus niet...

Mark

Daniel Tryba wrote:
> [ Martin ] <[ Martin ] @www.winampnederlands.nl> wrote:
>> Je ziet dat de link van een nieuwsitem nu
>>
>> <a
>>
href="/http://nu.nl/novum//article.phtml?url=sport/infostrada.05-22-2003
..003
>> 8.xml">Krajicek niet naar Roland Garros</a>
>>
>> wordt, dan zou dus
>>
>> <a
>>
href=http://nu.nl/novum//article.phtml?url=sport/infostrada.05-22-2003.0
038.
>> xml target="_blank">Krajicek niet naar Roland Garros</a>
>>
>> moeten zijn... Enig idee hoe ik dat voor elkaar krijg?
>>
>
> Wat een moeite voor zoiets simpels. Waar de target staat boeit voor
> geen meter en de link si te herkennen aan een 'href='. Dus met een
> simpele
> string replace kan je een target in de a plakken:
>
> $tekst[1] = str_replace('href=','target="_blank" href=',$tekst[1]);
>
> Geen regexp voor nodig.
>
> BTW Marcus AFAIK ereg is niet PCRE compliant, preg wel

Ik ben niet zo thuis in php, akelige taal.... waarom werkt s/../../g
niet gewoon

Mark

Marcus <doei@bannerswapnl.com> wrote:
>> Wat een moeite voor zoiets simpels. Waar de target staat boeit voor
>> geen meter en de link si te herkennen aan een 'href='. Dus met een
>> simpele
>> string replace kan je een target in de a plakken:
>>
>> $tekst[1] = str_replace('href=','target="_blank" href=',$tekst[1]);
>>
>> Geen regexp voor nodig.
>>
>> BTW Marcus AFAIK ereg is niet PCRE compliant, preg wel
>
> Ik ben niet zo thuis in php, akelige taal.... waarom werkt s/../../g
> niet gewoon

Ongeacht of je nu wel of niet thuis bent in een taal (in dit geval PHP),
een regexp voor deze oplossing is niet de goede. Ook in perl is het
zonde om voor het invoegen van een string op een heel herkenbare plek
zonder een verdere manipulatie een regexp te gebruiken. Maar als je al
zo graag een regexp gebruikt had je natuurlijk gewoon
s/href/target='_blank' href/g kunnen gebruiken (wat zich in php vertaalt
naar preg_replace('/href/','target="_blank" href',$str)) zonder enige
backreference.

--

Daniel Tryba

NNTP-Posting-Host: cust.91.90.adsl.cistron.nl
X-Trace: ncc1701.cistron.net 1054304078 21714 195.64.91.90 (30 May 2003 14:14:38 GMT)
X-Complaints-To: abuse@cistron.nl
NNTP-Posting-Date: Fri, 30 May 2003 14:14:38 +0000 (UTC)
User-Agent: slrn/0.9.7.4 (Darwin)
Xref: nl-news.euro.net nl.internet.www.server-side:29673

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> Ook in perl is het zonde om voor het invoegen van een string op een heel
> herkenbare plek zonder een verdere manipulatie een regexp te gebruiken.

Dat is pas merkbaar als je honderdduizenden toevoegingen gaat doen (op mijn
machine haal ik 170000 regex-'inserts' per seconde), en de code om het met
regular expressions te doen is IMO leesbaarder:

$str =~ s/href=/target=_blank href=/;
vs
substr($str, index($str, "href="), 0) = "target=_blank ";

--
robert

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > Ook in perl is het zonde om voor het invoegen van een string op een heel
> > herkenbare plek zonder een verdere manipulatie een regexp te gebruiken.
>
> Dat is pas merkbaar als je honderdduizenden toevoegingen gaat doen (op mijn
> machine haal ik 170000 regex-'inserts' per seconde), en de code om het met
> regular expressions te doen is IMO leesbaarder:

Dat het in perl niet veel uitmaakt dat is leuk voor perl (de keren dat
ik perl gebruik maak ik daar dankbaar gebruik van). Maar in php zou de
impact val een [ep]reg tov een str_replace wel eens groot kunnen zijn
(niet getest overigens). En wat indien het taaltje wat je gebruikt
helemaal geen regexp bevat?

Leesbaarheid: dan moet je natuurlijk wel al regexpen kunnen lezen, namen
als substr,index en str_replace spreken ook wel voorzich.

--

Daniel Tryba

Daniel Tryba wrote:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>>> Ook in perl is het zonde om voor het invoegen van een string op een
>>> heel herkenbare plek zonder een verdere manipulatie een regexp te
>>> gebruiken.
>>
>> Dat is pas merkbaar als je honderdduizenden toevoegingen gaat doen
>> (op mijn machine haal ik 170000 regex-'inserts' per seconde), en de
>> code om het met regular expressions te doen is IMO leesbaarder:
>
> Dat het in perl niet veel uitmaakt dat is leuk voor perl (de keren dat
> ik perl gebruik maak ik daar dankbaar gebruik van). Maar in php zou de
> impact val een [ep]reg tov een str_replace wel eens groot kunnen zijn
> (niet getest overigens). En wat indien het taaltje wat je gebruikt
> helemaal geen regexp bevat?

zelfs js en vbscript hebben regexes... Als de impact bij php
daadwerkelijk groot is dan is het natuurlijk gewoon pruts
geprogrammeerd...

> Leesbaarheid: dan moet je natuurlijk wel al regexpen kunnen lezen,
> namen
> als substr,index en str_replace spreken ook wel voorzich.

Maar dat je een waarde aan een substring toe kan wijzen spreekt IMHO
niet voor zich.




Mark

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>> > Ook in perl is het zonde om voor het invoegen van een string op een
>> > heel herkenbare plek zonder een verdere manipulatie een regexp te
>> > gebruiken.
>>
>> Dat is pas merkbaar als je honderdduizenden toevoegingen gaat doen (op
>> mijn machine haal ik 170000 regex-'inserts' per seconde), en de code om
>> het met regular expressions te doen is IMO leesbaarder:
>
> Dat het in perl niet veel uitmaakt dat is leuk voor perl (de keren dat
> ik perl gebruik maak ik daar dankbaar gebruik van). Maar in php zou
> de impact val een [ep]reg tov een str_replace wel eens groot kunnen
> zijn (niet getest overigens). En wat indien het taaltje wat je gebruikt
> helemaal geen regexp bevat?

Dan moet je iets anders verzinnen, maar ik ga echt niet stoppen met het
gebruiken van RE's in Perl omdat ze in PHP misschien traag zijn, of in
Brainf*ck niet bestaan.

> Leesbaarheid: dan moet je natuurlijk wel al regexpen kunnen lezen, namen
> als substr,index en str_replace spreken ook wel voorzich.

Een 'insert string here' regular expression is nou niet echt het toonbeeld
van complexe code; afgezien van de syntax van het uitvoeren van een regex
(s///) is het prima leesbaar lijkt me.

--
robert

Marcus <doei@bannerswapnl.com>:
> Daniel Tryba wrote:
>> Maar in php zou de impact val een [ep]reg tov een str_replace wel eens
>> groot kunnen zijn (niet getest overigens).
>
> zelfs js en vbscript hebben regexes... Als de impact bij php
> daadwerkelijk groot is dan is het natuurlijk gewoon pruts
> geprogrammeerd...

De Wijze Heren des PHP's hebben ooit besloten dat het niet nuttig is
een regular expression eenmalig te compileren om 'em daarna te kunnen
hergebruiken; in een loop van 1 mio [ep]reg_replace's wordt AFAIK dezelfde
RE dus eerst 1 mio keer gecompileerd en daarna gebruikt, om aan het einde
van de loop weer weggemikt te worden.

En tja, dan wil ik wel geloven dat het (in grote hoeveelheden) traag wordt.

Maar ja, Daar Is PHP Natuurlijk Niet Voor Bedoeld (tm)

>> Leesbaarheid: dan moet je natuurlijk wel al regexpen kunnen lezen,
>> namen als substr,index en str_replace spreken ook wel voorzich.
>
> Maar dat je een waarde aan een substring toe kan wijzen spreekt IMHO
> niet voor zich.

Daar had ik nog niet eens over nagedacht

--
robert

Marcus schreef:
> Ronald Klip wrote:

[knip]

> Dan krijg je <a>...target='_blank'</a> en dat werkt dus niet...

Gddmm, ik dacht dat ik het bericht gecanceld had...

--
groet, Ronald

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > Dat het in perl niet veel uitmaakt dat is leuk voor perl (de keren dat
> > ik perl gebruik maak ik daar dankbaar gebruik van). Maar in php zou
> > de impact val een [ep]reg tov een str_replace wel eens groot kunnen
> > zijn (niet getest overigens). En wat indien het taaltje wat je gebruikt
> > helemaal geen regexp bevat?
>
> Dan moet je iets anders verzinnen, maar ik ga echt niet stoppen met het
> gebruiken van RE's in Perl omdat ze in PHP misschien traag zijn, of in
> Brainf*ck niet bestaan.

Ik zeg alleen maar dat er in andere talen in vele gevallen een simpelere
(en snellere) oplossing is dan het gebruik van regexps.

> > Leesbaarheid: dan moet je natuurlijk wel al regexpen kunnen lezen, namen
> > als substr,index en str_replace spreken ook wel voorzich.
>
> Een 'insert string here' regular expression is nou niet echt het toonbeeld
> van complexe code; afgezien van de syntax van het uitvoeren van een regex
> (s///) is het prima leesbaar lijkt me.

_Als_ je uberhaupt al weet wat een RE is. een ~= operator gevolgt door
s/foo/bar/g is voor de leek vaag.

--

Daniel Tryba

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> >> Maar in php zou de impact val een [ep]reg tov een str_replace wel eens
> >> groot kunnen zijn (niet getest overigens).
> >
> > zelfs js

Ook "pas" sinds 1.3 (ECMA).

> > en vbscript

Vanaf versie 5.

> > hebben regexes...

> > Als de impact bij php daadwerkelijk groot is dan is het natuurlijk
> > gewoon pruts geprogrammeerd...

En dus een zeer zinnige reden om ze te vermijden.

> De Wijze Heren des PHP's hebben ooit besloten dat het niet nuttig is
> een regular expression eenmalig te compileren om 'em daarna te kunnen
> hergebruiken; in een loop van 1 mio [ep]reg_replace's wordt AFAIK dezelfde
> RE dus eerst 1 mio keer gecompileerd en daarna gebruikt, om aan het einde
> van de loop weer weggemikt te worden.
>
> En tja, dan wil ik wel geloven dat het (in grote hoeveelheden) traag wordt.

Dat geldt voor zowel ereg als preg? Ik zou immers van preg* enige
intelligentie verwachten omdat deze uit een externe lib gelinkt wordt.

> Maar ja, Daar Is PHP Natuurlijk Niet Voor Bedoeld (tm)

PHP is echt niet de enige taal die het zo aanpakt, bv in het pre Java
1.4 tijdperk was je afhankelijk van externe RE implementaties, en in 1
van de populaire (apache.regexp) mocht je ook zelf een pattern compilen
voor later hergebruik indien je het vermoeden had dat het wel eens vaker
gebruikt zou kunnen worden. Dat perl geweldig en perfect is weet
iedereen nu wel, maar als je dan advies geeft in een mindere taal hou
dan wel even rekening met de gebrekken.

--

Daniel Tryba

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> Ik zeg alleen maar dat er in andere talen in vele gevallen een simpelere
> (en snellere) oplossing is dan het gebruik van regexps.

Nee, je zei specifiek dat het ook in Perl zonde is om RE's te gebruiken

>> Een 'insert string here' regular expression is nou niet echt het
>> toonbeeld van complexe code; afgezien van de syntax van het uitvoeren
>> van een regex (s///) is het prima leesbaar lijkt me.
>
> _Als_ je uberhaupt al weet wat een RE is. een ~= operator gevolgt door
> s/foo/bar/g is voor de leek vaag.

Dat is een drogreden. In Perl is '=~' een veelgebruikte operator; als
iemand ('de leek') zich waagt aan de taal, dan ga ik ervan uit dat deze
persoon zich eerst verwittigt van de syntax van de taal. Anders kan je over
elke taal wel moeilijk gaan doen (zoals een bepaalde '===' operator die
uitblinkt in duidelijkheid .

--
robert

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
>> De Wijze Heren des PHP's hebben ooit besloten dat het niet nuttig is
>> een regular expression eenmalig te compileren om 'em daarna te kunnen
>> hergebruiken; in een loop van 1 mio [ep]reg_replace's wordt AFAIK
>> dezelfde RE dus eerst 1 mio keer gecompileerd en daarna gebruikt, om
>> aan het einde van de loop weer weggemikt te worden.
>
> Dat geldt voor zowel ereg als preg? Ik zou immers van preg* enige
> intelligentie verwachten omdat deze uit een externe lib gelinkt wordt.

PCRE heeft gewoon een pcre_compile() en pcre_exec(). Het cachen van
gecompileerde RE's is niet iets wat in zo'n lib thuishoort, dat moet PHP
doen.

Maar wees gerust; ik heb de source er nog even op nageslagen, en PHP cachet
netjes gecompileerde RE's.

--
robert

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > Ik zeg alleen maar dat er in andere talen in vele gevallen een simpelere
> > (en snellere) oplossing is dan het gebruik van regexps.
>
> Nee, je zei specifiek dat het ook in Perl zonde is om RE's te gebruiken

Tsja, maar dat is het ook indien het onnodig gebeurd, immers volgens je
eigen benchmark is de RE trager dan de string replace variant

> > _Als_ je uberhaupt al weet wat een RE is. een ~= operator gevolgt door
> > s/foo/bar/g is voor de leek vaag.
>
> Dat is een drogreden. In Perl is '=~' een veelgebruikte operator; als
> iemand ('de leek') zich waagt aan de taal, dan ga ik ervan uit dat deze
> persoon zich eerst verwittigt van de syntax van de taal. Anders kan je over
> elke taal wel moeilijk gaan doen (zoals een bepaalde '===' operator die
> uitblinkt in duidelijkheid .

=== is in 1 regel uit te legen (verglijking inclusief type), waar
regexps toch al heel wat regeltjes worden. De ruimte die je overhoud op
het A4tje voor andere leuke spulletjes is dus al significant minder

--

Daniel Tryba

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > Dat geldt voor zowel ereg als preg? Ik zou immers van preg* enige
> > intelligentie verwachten omdat deze uit een externe lib gelinkt wordt.
>
> PCRE heeft gewoon een pcre_compile() en pcre_exec(). Het cachen van
> gecompileerde RE's is niet iets wat in zo'n lib thuishoort, dat moet PHP
> doen.
>
> Maar wees gerust; ik heb de source er nog even op nageslagen, en PHP cachet
> netjes gecompileerde RE's.

Dan kan ik nu weer met een gerust hart verder slapen

--

Daniel Tryba