🚀 go-pugleaf

On 2009-06-09, user <dag@allemaale.be> wrote:
> Stel, je hebt een site met 1000 pagina's, waar telkens ergens dezelfde html
> tekst in voor komt.
>
> Omdat je dat niet 1000 maal wil opslaan op je site (ik heb 100Mb), zou je
> zoiets moeten kunnen importeren in html/(java)script..
>
> ...
> html code
> include http://mijnsite.be/user12345/pub/local/file.txt
> html code 
> ...
>
> Op deze manier kun je wat plaats besparen, maar hoe doe je het??
>
>
>

Standaard heeft html dat niet, scripting talen zoals php kunnen dit
wel.  Waarschijnlijk zal het wel mogelijk zijn met javascript maar
daar kan ik je geen raad bij geven.

wimpunk <ybwdlapvxvun@spammotel.com> wrote:
> On 2009-06-09, user <dag@allemaale.be> wrote:
>> Stel, je hebt een site met 1000 pagina's, waar telkens ergens dezelfde html
>> tekst in voor komt.
>>
>> Omdat je dat niet 1000 maal wil opslaan op je site (ik heb 100Mb), zou je
>> zoiets moeten kunnen importeren in html/(java)script..
>>
>> ...
>> html code
>> include http://mijnsite.be/user12345/pub/local/file.txt
>> html code 
>> ...
>>
>> Op deze manier kun je wat plaats besparen, maar hoe doe je het??
>
> Standaard heeft html dat niet, scripting talen zoals php kunnen dit
> wel.  Waarschijnlijk zal het wel mogelijk zijn met javascript maar
> daar kan ik je geen raad bij geven.

Als de webserver SSI spreekt is dat ook een optie.  Een veel betere optie dan
PHP.

 - Philip

-- 
Philip Paeps                                    Please don't email any replies
philip@paeps.cx                                     I follow the newsgroup.

> html code
> includehttp://mijnsite.be/user12345/pub/local/file.txt
> html code

Zoiets kan je perfect met javascript oplossen, en dan zijn dit twee
populaire methodes die ik al ontdekt heb:
jquery.com
prototypejs.com

ze maken beide gebruik van XmlHttpRequest om een stuk HTML te gaan
ophalen op een URL en ergens in de geladen pagina in te voegen (beter
gekend als Ajax)

Philip Paeps wrote:
> wimpunk <ybwdlapvxvun@spammotel.com> wrote:
>> On 2009-06-09, user <dag@allemaale.be> wrote:
>>> Stel, je hebt een site met 1000 pagina's, waar telkens ergens dezelfde html
>>> tekst in voor komt.
>>>
>>> Omdat je dat niet 1000 maal wil opslaan op je site (ik heb 100Mb), zou je
>>> zoiets moeten kunnen importeren in html/(java)script..
>>>
>>> ...
>>> html code
>>> include http://mijnsite.be/user12345/pub/local/file.txt
>>> html code 
>>> ...
>>>
>>> Op deze manier kun je wat plaats besparen, maar hoe doe je het??
>> Standaard heeft html dat niet, scripting talen zoals php kunnen dit
>> wel.  Waarschijnlijk zal het wel mogelijk zijn met javascript maar
>> daar kan ik je geen raad bij geven.
> 
> Als de webserver SSI spreekt is dat ook een optie.  Een veel betere optie dan
> PHP.

hebt ge't over http://httpd.apache.org/docs/2.2/mod/mod_include.html ?
waarom is dat een veel betere optie?

flor <flor@nospam.invalid> wrote:
> Philip Paeps wrote:
>> wimpunk <ybwdlapvxvun@spammotel.com> wrote:
>>> On 2009-06-09, user <dag@allemaale.be> wrote:
>>>> Stel, je hebt een site met 1000 pagina's, waar telkens ergens dezelfde html
>>>> tekst in voor komt.
>>>>
>>>> Omdat je dat niet 1000 maal wil opslaan op je site (ik heb 100Mb), zou je
>>>> zoiets moeten kunnen importeren in html/(java)script..
>>>>
>>>> ...
>>>> html code
>>>> include http://mijnsite.be/user12345/pub/local/file.txt
>>>> html code 
>>>> ...
>>>>
>>>> Op deze manier kun je wat plaats besparen, maar hoe doe je het??
>>> Standaard heeft html dat niet, scripting talen zoals php kunnen dit
>>> wel.  Waarschijnlijk zal het wel mogelijk zijn met javascript maar
>>> daar kan ik je geen raad bij geven.
>> 
>> Als de webserver SSI spreekt is dat ook een optie.  Een veel betere optie dan
>> PHP.
>
> hebt ge't over http://httpd.apache.org/docs/2.2/mod/mod_include.html ?
> waarom is dat een veel betere optie?

Kort antwoord: Omdat alles beter is dan PHP.

SSI is low-overhead en eenvoudig en doet precies wat je nodig hebt.  PHP is
een organisch gegroeid beest van vele megabytes en geeft je veel mogelijkheden
om jezelf in de voeten te schieten.  Als je het niet nodig hebt en/of het niet
wil babysitten zet je het best niet op een webserver.

 - Philip

-- 
Philip Paeps                                    Please don't email any replies
philip@paeps.cx                                     I follow the newsgroup.

On 2009-06-10, the following emerged from the brain of Philip Paeps:
> Kort antwoord: Omdat alles beter is dan PHP.

Kom kom, er is nog altijd ASP...

Philip Paeps wrote:
> flor <flor@nospam.invalid> wrote:
>> Philip Paeps wrote:
>>> wimpunk <ybwdlapvxvun@spammotel.com> wrote:
>>>> On 2009-06-09, user <dag@allemaale.be> wrote:
>>>>> Stel, je hebt een site met 1000 pagina's, waar telkens ergens dezelfde html
>>>>> tekst in voor komt.
>>>>>
>>>>> Omdat je dat niet 1000 maal wil opslaan op je site (ik heb 100Mb), zou je
>>>>> zoiets moeten kunnen importeren in html/(java)script..
>>>>>
>>>>> ...
>>>>> html code
>>>>> include http://mijnsite.be/user12345/pub/local/file.txt
>>>>> html code 
>>>>> ...
>>>>>
>>>>> Op deze manier kun je wat plaats besparen, maar hoe doe je het??
>>>> Standaard heeft html dat niet, scripting talen zoals php kunnen dit
>>>> wel.  Waarschijnlijk zal het wel mogelijk zijn met javascript maar
>>>> daar kan ik je geen raad bij geven.
>>> Als de webserver SSI spreekt is dat ook een optie.  Een veel betere optie dan
>>> PHP.
>> hebt ge't over http://httpd.apache.org/docs/2.2/mod/mod_include.html ?
>> waarom is dat een veel betere optie?
> 
> Kort antwoord: Omdat alles beter is dan PHP.
> 
> SSI is low-overhead en eenvoudig en doet precies wat je nodig hebt.  PHP is
> een organisch gegroeid beest van vele megabytes en geeft je veel mogelijkheden
> om jezelf in de voeten te schieten.  Als je het niet nodig hebt en/of het niet
> wil babysitten zet je het best niet op een webserver.

wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)

flor <flor@nospam.invalid> wrote:
> Philip Paeps wrote:
>> flor <flor@nospam.invalid> wrote:
>>> Philip Paeps wrote:
>>>> wimpunk <ybwdlapvxvun@spammotel.com> wrote:
>>>>> On 2009-06-09, user <dag@allemaale.be> wrote:
>>>>>> Stel, je hebt een site met 1000 pagina's, waar telkens ergens dezelfde html
>>>>>> tekst in voor komt.
>>>>>>
>>>>>> Omdat je dat niet 1000 maal wil opslaan op je site (ik heb 100Mb), zou je
>>>>>> zoiets moeten kunnen importeren in html/(java)script..
>>>>>>
>>>>>> ...
>>>>>> html code
>>>>>> include http://mijnsite.be/user12345/pub/local/file.txt
>>>>>> html code 
>>>>>> ...
>>>>>>
>>>>>> Op deze manier kun je wat plaats besparen, maar hoe doe je het??
>>>>> Standaard heeft html dat niet, scripting talen zoals php kunnen dit
>>>>> wel.  Waarschijnlijk zal het wel mogelijk zijn met javascript maar
>>>>> daar kan ik je geen raad bij geven.
>>>> Als de webserver SSI spreekt is dat ook een optie.  Een veel betere optie dan
>>>> PHP.
>>> hebt ge't over http://httpd.apache.org/docs/2.2/mod/mod_include.html ?
>>> waarom is dat een veel betere optie?
>> 
>> Kort antwoord: Omdat alles beter is dan PHP.
>> 
>> SSI is low-overhead en eenvoudig en doet precies wat je nodig hebt.  PHP is
>> een organisch gegroeid beest van vele megabytes en geeft je veel mogelijkheden
>> om jezelf in de voeten te schieten.  Als je het niet nodig hebt en/of het niet
>> wil babysitten zet je het best niet op een webserver.
>
> wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)

C.

 - Philip

-- 
Philip Paeps                                    Please don't email any replies
philip@paeps.cx                                     I follow the newsgroup.

  Real programmers have read the standards manual
  but won't admit it.

> wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)

ruby on rails en python zijn de laatste jaren heel erg populair
geworden,
met java kan je ook websites maken (jsp)

en ik heb recent zelf nog een platform op Delphi ineengstoken:
http://xxm.sourceforge.net/

in elk geval lijkt 'the way to go' toch met compileren te zijn, en
niet meer met een parsed script taaltje...

StijnSanders wrote:
>> wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)
> 
> ruby on rails en python zijn de laatste jaren heel erg populair
> geworden,
> met java kan je ook websites maken (jsp)
> 
> en ik heb recent zelf nog een platform op Delphi ineengstoken:
> http://xxm.sourceforge.net/
> 
> in elk geval lijkt 'the way to go' toch met compileren te zijn, en
> niet meer met een parsed script taaltje...

ruby en python worden vziw niet gecompileerd.

StijnSanders wrote:
>> wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)
> 
> ruby on rails en python zijn de laatste jaren heel erg populair
> geworden,
> met java kan je ook websites maken (jsp)
> 
> en ik heb recent zelf nog een platform op Delphi ineengstoken:
> http://xxm.sourceforge.net/
> 
> in elk geval lijkt 'the way to go' toch met compileren te zijn

en waarom lijkt dit zo te zijn? omdat iedereen het doet?

flor <flor@nospam.invalid> wrote:
> StijnSanders wrote:
>>> wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)
>> 
>> ruby on rails en python zijn de laatste jaren heel erg populair
>> geworden,
>> met java kan je ook websites maken (jsp)
>> 
>> en ik heb recent zelf nog een platform op Delphi ineengstoken:
>> http://xxm.sourceforge.net/
>> 
>> in elk geval lijkt 'the way to go' toch met compileren te zijn, en
>> niet meer met een parsed script taaltje...
>
> ruby en python worden vziw niet gecompileerd.

Python in ieder geval wel.  Ruby veronderstel ik ook.

In tegenstelling tot bijvoorbeeld C worden ze meestal niet naar machine code
gecompileerd maar naar bytecode die dan geïnterpreteerd wordt.

 - Philip

-- 
Philip Paeps                                    Please don't email any replies
philip@paeps.cx                                     I follow the newsgroup.

  <Monty> x86 architechture sadly
  <azz> oh, that'd explain it

> > in elk geval lijkt 'the way to go' toch met compileren te zijn
> en waarom lijkt dit zo te zijn? omdat iedereen het doet?

Omdat je zo ten minste wat performance haalt!
Omdat je zo je server het minste belast.
Omdat je geen werk weggooit met altijd maar hetzelfde te gaan
parsen...
(Omdat het het dichtst ligt tegen wat Philip Paeps ook zegt: C)
(Maar ik lees hier ook dat ruby en python ook niet echt compileren?
vreemd want ze roemen zichzelf op hun compiler, toch?)

On 2009-06-12, the following emerged from the brain of StijnSanders:
> (Maar ik lees hier ook dat ruby en python ook niet echt compileren?
> vreemd want ze roemen zichzelf op hun compiler, toch?)

Naar bytecode gaan is evenzeer compileren.

-- 
Middle age is having a choice between two temptations and choosing the
one that'll get you home earlier.
	~ Dan Bennett

StijnSanders wrote:

>> > in elk geval lijkt 'the way to go' toch met compileren te zijn
>> en waarom lijkt dit zo te zijn? omdat iedereen het doet?
>
> Omdat je zo ten minste wat performance haalt!
> Omdat je zo je server het minste belast.

In de meeste gevallen is de performance van Python etc. "genoeg", en dan
kijk je naar de tijd die het kost om iets te ontwikkelen.  Vergeet niet dat
hardware vaak goedkoper is dan de tijd van een developer, en dat response
times meestal I/O-bound zijn, m.a.w. je klanten gaan geen of weinig verschil
zien tussen je toepassing in C vs. je toepassing in Python.

Je kan performance-kritische code in Python overigens altijd vervangen door
code in C, C++, Fortran, &c.  Dat is wat je ziet in de wetenschappelijke
wereld (bio-informatics & gentechnologie bijvoorbeeld).


(En waar ik hier Python zet is natuurlijk ook toepasselijk op veel andere
zogenaamde "scripting" talen.)

-- 
JanC

JanC schreef:
> StijnSanders wrote:
> 
>>>> in elk geval lijkt 'the way to go' toch met compileren te zijn
>>> en waarom lijkt dit zo te zijn? omdat iedereen het doet?
>> Omdat je zo ten minste wat performance haalt!
>> Omdat je zo je server het minste belast.
> 
> In de meeste gevallen is de performance van Python etc. "genoeg", en dan
> kijk je naar de tijd die het kost om iets te ontwikkelen.  Vergeet niet dat
> hardware vaak goedkoper is dan de tijd van een developer, en dat response
> times meestal I/O-bound zijn, m.a.w. je klanten gaan geen of weinig verschil
> zien tussen je toepassing in C vs. je toepassing in Python.

En waarom denk je dat het sneller is om iets te schrijven in Python dan 
in C?

Groeten,
Rene

Rene <a@b.c> wrote:
> JanC schreef:
> > StijnSanders wrote:
> > > > > in elk geval lijkt 'the way to go' toch met compileren te zijn
> > > > en waarom lijkt dit zo te zijn? omdat iedereen het doet?
> > > Omdat je zo ten minste wat performance haalt!
> > > Omdat je zo je server het minste belast.
> > 
> > In de meeste gevallen is de performance van Python etc. "genoeg", en dan
> > kijk je naar de tijd die het kost om iets te ontwikkelen.  Vergeet niet
> > dat hardware vaak goedkoper is dan de tijd van een developer, en dat
> > response times meestal I/O-bound zijn, m.a.w. je klanten gaan geen of
> > weinig verschil zien tussen je toepassing in C vs. je toepassing in
> > Python.
>
> En waarom denk je dat het sneller is om iets te schrijven in Python dan in
> C?

Dat vraag ik me ook steeds af. :-)  Voor "throwaway" dingen waar architectuur
niets uitmaakt zijn scriptjes ongetwijfeld sneller geschreven omdat je geen
rekening moet houden met details als memory management of het converteren van
een "interne representatie" naar strings ofzo.  Maar zodra je iets van enige
complexiteit hebt, of iets met architectuur, is het volgens mij niet veel
sneller om <x> te schrijven dan C.

Ik zou zelfs durven stellen dat C sneller is om te schrijven omdat de taal zo
eenvoudig is dat je er niet over moet nadenken.  Ongetwijfeld hebben mensen
die jaren ervaring hebben met <x> daar echter een andere mening over.

 - Philip

-- 
Philip Paeps                                    Please don't email any replies
philip@paeps.cx                                     I follow the newsgroup.

  It's a single distributed point of failure.
  	-- Gerald Tripp

Philip Paeps wrote:

 Als je het niet nodig hebt en/of het
> niet wil babysitten zet je het best niet op een webserver.
> 
>  - Philip
> 


van een andere discussie vond ik dit, en firefox zou het niet aankunnen (
als het een pdf betreft ..)


        <EMBED src="invsrela/pdfs/ChairmansLetterToShareholders_2008.pdf"
width="1050" height="835"></EMBED>


mooi, als het zopu werken ...


-- 
--
700+ Radio Stations on SW http://swstations.tk/
Shortwave transmissions in English, Francais, Nederlands, Deutsch,
Suid-Afrikaans, Chinese, Dansk, Urdu, Cantonese, Greek, Spanish,
Portuguese, ...
http://radiolanguages.tk  Updated every month or so ....

TomB wrote:

> On 2009-06-10, the following emerged from the brain of Philip Paeps:
>> Kort antwoord: Omdat alles beter is dan PHP.
> 
> Kom kom, er is nog altijd ASP...


Omdat je vuilaard van een minister je dat op school leerde ...

Wacht tot je commerce asp een beetje verandert, en je ziult kunne vloeken...
de commerce moet soms eens de winkel doen draaien ...


-- 
--
700+ Radio Stations on SW http://swstations.tk/
Shortwave transmissions in English, Francais, Nederlands, Deutsch,
Suid-Afrikaans, Chinese, Dansk, Urdu, Cantonese, Greek, Spanish,
Portuguese, ...
http://radiolanguages.tk  Updated every month or so ....

flor wrote:

> wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)

Nothing beats PHP when it comes to security,
or the reason why I stopped worrying and settled on Python years ago:
http://zope2.zopyx.de/about-zope-2/six-reasons-for-using-zope/zope-is-secure

Iemand stats on Ruby/ROR?

-- 
Greets,
WouterVH

flor wrote:

> wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)

Nothing beats PHP when it comes to security,
or the reason why I stopped worrying and settled on Python years ago:
http://zope2.zopyx.de/about-zope-2/six-reasons-for-using-zope/zope-is-secure

Iemand stats on Ruby/ROR?

-- 
Greets,
WouterVH

flor wrote:

> wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)

Nothing beats PHP when it comes to security,
or the reason why I stopped worrying and settled on Python years ago:
http://zope2.zopyx.de/about-zope-2/six-reasons-for-using-zope/zope-is-secure

Iemand stats on Ruby/ROR?

-- 
Greets,
WouterVH

Wouter Vanden Hove schreef:
> flor wrote:
> 
>> wat is dan wel beter dan php (met dezelfde mogelijkheden), oh guru? ;)
> 
> Nothing beats PHP when it comes to security,
> or the reason why I stopped worrying and settled on Python years ago:
> http://zope2.zopyx.de/about-zope-2/six-reasons-for-using-zope/zope-is-secure
> 
> Iemand stats on Ruby/ROR?

Zulke statistieken zijn altijd erg interessant, maar zeggen helemaal 
niets zonder het aantal gebruikers van elk platform mee te geven.

flor wrote:

> Zulke statistieken zijn altijd erg interessant, maar zeggen helemaal
> niets zonder het aantal gebruikers van elk platform mee te geven.

Uiteraard, naarmate software meer gebruikt wordt
ontstaan er meer bugs door slijtage.


-- 
Greets,
WouterVH

flor wrote:

> Zulke statistieken zijn altijd erg interessant, maar zeggen helemaal
> niets zonder het aantal gebruikers van elk platform mee te geven.

Uiteraard, naarmate software meer gebruikt wordt
ontstaan er meer bugs door slijtage.


-- 
Greets,
WouterVH