Overleg help:Parserfuncties

Titel

Moet deze pagina niet eigenlijk Help:Parseerfunctie heten?

Of misschien Help:Reken- en keuzefuncties.--Patrick 23 jun 2006 17:16 (CEST)

Vragen tot gebruik

• Het lukt mij gewoon wel om hiermee te spelen. Maar ik loop nu tegen een probleem op... Ik ben nu bezig in een tabel, waar ik een paar kollommen conditioneel wil laten zien, wanneer deze word ingesloten. (Een agenda van de week waar de huidige op te zien is. En ik wil geen gebruik maken van templates per dag.)

{|
...
|-<includeonly>{{#ifexpr:({{CURRENTDOW}}=5)|</includeonly>
| '''Vrijdag''' || <code>10:30 - 12:30h</code> || Bezigheidstherapie: Studeren
<includeonly>|}}</includeonly>
|}

Dit is wat ik nu heb--Sent 8 sep 2006 10:03 (CEST)-----

1. Gebruik "includeonly" alleen om het hele sjabloon alleen zichtbaar te laten zijn wanneer opgenomen in de pagina.
2. CURRENTDOW geeft de dag in UTC, neem liever LOCALDOW, die werkt met MET/MEZT.
3. Tussen de verticale balken die de parameters van #If: van elkaar scheiden mag je geen verticale balken plaatsen, maar m.b.v. Sjabloon:! lukt het wel.
4. Ik heb je voorbeeld even werkend gemaakt:

<includeonly>
{| border="1"
{{#ifexpr:({{LOCALDOW}}=5) | 
{{!}}- 
{{!}} '''Vrijdag''' {{!}}{{!}} 10:30 - 12:30h {{!}}{{!}} Bezigheidstherapie: Studeren | }}
|}
</includeonly>

Succes! - Erik Baas 8 sep 2006 11:17 (CEST)

Bedankt! Het was een nuttige tip voor het gebruik van {{!}} (heb die even gecopiëerd naar mijn wiki). Het gebruik van LOCALDOW is (nog) niet mogelijk op de installatie van MediaWiki waar het voor was. En ja, in mijn werkelijke versie was die INCLUDEONLY ook over stukken code die de HTML netjes houden. Alleen in het voorbeeld hierboven was ik eerst vergeten om de |- mee te copiëren.

Nogmaals bedankt! --Sent 8 sep 2006 15:16 (CEST)

Fortran

Wat wordt bedoeld met Fortran-achtige wetenschappelijke notatie ? Handige Harrie 6 jul 2010 18:34 (CEST)

Volgens deze pagina is dat bijvoorbeeld 12345E-3 om het getal $\scriptstyle 12345\cdot 10^{-3}$ (= 12,345) weer te geven. Richard 7 jul 2010 11:12 (CEST)

Dat heeft niets met Fortran te maken - het kan in (bijna) elke programmeertaal op die manier. En het kan ook niet juist zijn, want de letter E werkt in de parserfuncties ook. Ik heb die mogelijkheid aan de tekst toegevoegd. Handige Harrie 7 jul 2010 11:19 (CEST)

Dat zal toch wel bedoeld zijn, dat kon eerst niet. Ik heb het weggehaald.--Patrick (overleg) 7 jul 2010 15:46 (CEST)

Bijna elke programmeertaal betwijfel ik eigenlijk. Maar als de parserfuncties het nu aankunnen is het goed dat er nu een voorbeeld staat en de opmerking dat het niet kan weggehaald is. Richard 8 jul 2010 09:29 (CEST)

Ik ken geen enkele programmeertaal waarin de letter E niet op die manier wordt gebruikt, maar veiligheidshalve heb ik het woordje 'bijna' tussen haakjes toegevoegd. Daarom vind ik 'Fortran-achtig' een slechte omschrijving.

(Mijn schoonmoeder kent ook geen enkele programmeertaal waarin de letter E niet op die manier wordt gebruikt, maar dat zegt niet zo veel) Handige Harrie 8 jul 2010 10:07 (CEST)

(grijns) Ik ken er meerdere, maar die zijn geen van allen bedoeld voor wetenschappelijke toepassingen. Richard 8 jul 2010 10:41 (CEST)

Gebruik op artikelen ?

Erik bewerkt hier de waarschuwing. Graag zou ik van hem of van een ander horen wat hiervan een voorbeeld is. Een artikel is voor zover ik weet altijd statisch, daarmee bedoel ik dat variablen die daar gebruikt kunnen worden niet veranderen wat gebruik van ParserFuncties uitsluit als nuttig iets. Uiteraard staat geen enkele richtlijn vast voor de eeuwigheid. Daarom hoor ik graag een werkelijk voorbeeld of denkbare situatie waarin ParserFuncties buiten de Sjabloon-naamruimte "uttig, noodzakelijk of handig " zijn. –Krinkle 19 jul 2010 23:23 (CEST)

Ik kan er genoeg bedenken, maar die zijn (veelal door eenmansacties) verdwenen, net als sommige erg handige sjablonen die ineens niet meer "toegestaan" waren. En wat dacht je van #subst: en #titleparts: ? Dat zijn ook parserfuncties, die zouden we dus ook niet meer "mogen" gebruiken ? Verder blijft de vraag open waarom het niet zou mogen, en wie deze regel bedacht heeft (en meteen maar tot wet verheven heeft). - Erik Baas 19 jul 2010 23:32 (CEST)

De functie {{#time:U}} met resultaat 1715699060 is op een artikel zeer zinvol (al zal ik hem zelf niet vaak gebruiken) Handige Harrie 20 jul 2010 00:13 (CEST)

En nog eens wat: geldt deze "wet" ook voor de zg. "Magic words"? En geldt het verbod het alleen voor pagina's in de hoofdnaamruimte, of ook bv. Help-, Wikipedia- en diverse overlegpagina's ? Pfft, ik zie een heleboel uitzonderingen, en ik denk dat dat hele rode kader met dat grote stopbord-met-politiehand maar gauw weer weg moet... Erik Baas 20 jul 2010 00:22 (CEST)

Ik weet niet wat een "magic word" is (behalve Xyzzy). En ja, de wet geldt op alle pagina's behalve sjablonen. Dat is wiedes, want een sjabloon is bedoeld om door een andere pagina opgeroepen te worden. In mijn wijziging van [1] heb ik het beschreven, naar mijn niet zo bescheiden mening beter dan in dat rode kader. Handige Harrie 20 jul 2010 08:26 (CEST)

Lees eerst even deze pagina over "magic words"; ik heb het gevoel dat je de omvang van het probleem niet inziet... Verder geef jij ook geen antwoord op de vraag "waarom". - Erik Baas 20 jul 2010 13:28 (CEST)

Goed, magische woorden kunnen zinvol zijn, dus die zijn toegestaan.

De vraag waarom - bedoel je waarom parserfuncties niet in de hoofdnaamruimte mogen voorkomen? Die vraag heb ik beantwoord: parserfuncties zijn meestal zinloos als er geen parameters instaan, en parameters komen alleen in sjablonen voor. Maar daar zijn uitzonderingen op, het is dus geen wet van Meden en Perzen.

Ze zeggen dat parserfuncties een zware belasting betekenen voor de servers, maar ik merk er niks van en er staat niets over op help:Parserfuncties.

Handige Harrie 20 jul 2010 13:45 (CEST)

Ja, "meestal zinloos" klopt wel. En er is ergens (en:, meta ??) een pagina met uitleg over (te) zware serverbelasting door MW's en parserfuncties, maar ik kan 'm nu even niet vinden. - Erik Baas 20 jul 2010 15:06 (CEST)

Met behulp van parserfuncties heb ik ervoor gezorgd dat op de pagina zomertijd dynamisch van het vorig, het huidig, en de komende drie jaar de begin- en einddatum van de zomertijd getoond worden. Zonder parserfuncties zou dit ieder jaar met de hand aangepast moeten worden. Wat mij betreft mag dat rode blok weg. Dan is de aanpassing op help:Parserfuncties waarin van alle expr's de uitkomst ingevuld is ook direct overbodig geworden (en zou wat mij betreft teruggedraaid mogen worden - jammer van het werk dat erin gestoken is).

Dat parserfuncties voornamelijk in sjablonen gebruikt worden is een ander verhaal.

Richard 20 jul 2010 10:15 (CEST)

Juist. - Erik Baas 20 jul 2010 13:28 (CEST)

"jammer van het werk dat erin gestoken is", nou dat valt wel mee. Met Subst is het zo gesmurft. Handige Harrie 20 jul 2010 13:45 (CEST)

De reden waarom ik het kader van opgelet bovenaan de pagina plaatste is omdat regelmatig gebruikers menen te denken dat parserfuncties speelgoed zijn dat overal maar moet worden toegepast omdat het leuk is. Ik ken zelf enkele voorbeelden op artikelen waar het gebruik van parserfuncties gewenst zijn, maar dat zijn echt uitzonderingsgevallen en daar is niets mis mee. Er zijn overigens verschillende discussies in het verleden geweest over parserfuncties en andere magic words (zoals deze) waarbij het gebruik ervan in de meeste gevallen op artikelen niet als wenselijk wordt beschouwd.

Ik heb bij plaatsing van het kader wellicht iets te strak geformuleerd wat ik bedoelde te zeggen, maar ik ging er van uit dat gebruikers als Erik Baas wel weten wanneer op artikelen het wél zinvol is en dat ze zich hierdoor niet laten weerhouden, maar andere gebruikers die deze pagina tegenkomen en denken "leuk speelgoed" meer hierin worden weerhouden.

Het gebruik van parserfuncties kan mijn inziens onmogelijk volledig als verboden op artikelen beschouwd worden, maar in zeker 99% van de gevallen zijn ze daar niet nodig en ongewenst beschouwd. Het doel van het rode kader is om gebruikers duidelijk te maken dat het vrijelijk zinloze gebruik van deze Mediawiki-functionaliteit op artikelen niet de bedoeling is. Het gaat doorgaans om statische artikelen, waarbij de dynamische parserfuncties geheel overbodig zijn. Groetjes - Romaine (overleg) 20 jul 2010 13:47 (CEST)

@Harrie: tsja, da's ook weer waar. Toch, in het kader van leesbaarheid van de wikitekst: zullen we die wijziging ongedaan maken? Nu kan het nog... Richard 20 jul 2010 14:17 (CEST)

Met die formulering kan ik wel vrede hebben. - Erik Baas 20 jul 2010 15:01 (CEST)

Met het bericht van Romaine kan ik het helemaal eens zijn.

Op Help:Parserfuncties kun je schrijven:

<no wiki>{ { #expr: 30 / 7 } }</no wiki> = { { #expr: 30 / 7 } }

<no wiki>{ { #expr: 30 / 7 } }</no wiki> = 4.2857142857143

Het eerste is heel erg hypocriet, het komt niet overeen met wat in Romaines rode kader staat. Het enige voordeel is m.i. dat de getoonde waarde automatisch verandert als de software verandert en de berekening meer of minder nauwkeurig wordt. Handige Harrie 20 jul 2010 15:23 (CEST)

Tijd

Hallo, in de paragraaf over de functie time staat: 'Wanneer geen "tijd" is gespecificeerd, wordt de datum en/of tijd getoond op het moment dat de pagina gerenderd werd.' Wat betekent 'gerenderd' in dit geval? Ik zou me wat betreft een tijd-functie twee betekenissen kunnen indenken, nl. de tijd dat de laatste bewerking werd gedaan (ofwel de laatste keer dat de pagina werd opgeslagen) en de tijd dat de pagina door een lezer wordt opgeroepen en op diens scherm wordt weergegeven. To render betekent weergeven. Renderen betekent bij webpagina's naar ik meen het weergeven van de html door de browser. In dit geval gebeurt natuurlijk eerst een vertaling door de wiki-software in html en vervolgens een vertaling van html in een schermweergave door de browser, maar dat gaat meestal binnen een seconde dus maakt praktisch geen verschil voor de betekenis. Ik heb nu op mijn kladblok een paar tijdfuncties geprobeerd maar zo te zien wordt steeds de tijd getoond van de laatste keer dat de pagina is opgeslagen (die ook onderaan, in de voettekst onder het eigenlijke 'artikel' staat), ook als ik met F5 of Ctrl+f5 de pagina ververs. Ik geloof dat het dus toch de eerste betekenis is die ik noemde en niet de tweede. Maar klopt het woord 'gerenderd' dan wel? Groeten, Bever (overleg) 4 jul 2013 21:39 (CEST)

Het deel van het renderen waar het hier om gaat is de vertaling van de wikitext in html, dus onder meer het invullen van de tijd. Ik heb het aangepast.- Patrick (overleg) 4 jul 2013 22:05 (CEST)

Ik heb nu de bovengenoemde 'magische woorden' gebruikt in het Partijtje van het Schaakcafé. Dit bestand wordt tevens getoond als onderdeel van het Wikipedia:Schaakcafé (met de code {{/Partijtje}}. Het blijkt dat als je nu de partijtjespagina oproept (met de eerste link), de laatste bewerkingstijd van dat bestand wordt getoond, maar wanneer je het partijtje bekijkt als onderdeel van het Schaakcafé, wordt de laatste bewerkingstijd van het Schaakcafé getoond (of de laatste van beide tijden). Dit geldt natuurlijk ook wanneer deze code in een sjabloon wordt opgenomen. Kennelijk wordt de broncode opnieuw naar html omgezet wanneer je de moederpagina verandert?

De opmerking over caching begrijp ik ook niet helemaal, bedoel je caching op de wikipedia-server? Wanneer wijkt dit wel en niet af van de laatste bewerkingstijd? Meestal wordt de pagina meteen na een bewerking getoond aan de bewerker (en dus in html vertaald), zodat je zou verwachten dat deze tijden overeenkomen.

Overigens staat er nu als laatste tijd in Wikipedia:Schaakcafé/Partijtje 22:15 terwijl de laatste bewerkingstijd 22:10 was. Bever (overleg) 4 jul 2013 22:47 (CEST)

Alleen al het feit dat purge (bijv. http://nl.wikipedia.org/w/index.php?title=Wikipedia:Schaakcafé/Partijtje&action=purge) de tijd bijwerkt laat zien dat de weergegeven tijd niet die van de laatste verandering in de partij hoeft te zijn. - Patrick (overleg) 4 jul 2013 23:36 (CEST)