[Bug] [list]-tag bokt door onafgesloten [google]-tag

[NMe]

Ik probeerde zojuist het volgende te posten:

---

Dit is:
[list=1]
[*]een bekend fenomeen in databaseland en is wel te vinden, bijvoorbeeld door [google=automatically delete foreign key]
[*]niet de juiste manier om een topic te starten op GoT in het algemeen en al helemaal niet in [forum=14]Programming[/forum] in het bijzonder. Zie ook [faq=beleid,topicplaatsen]Het algemeen beleid #topicplaatsen[/faq] en [topic=1104694///#quickstart]Programming Beleid - De "quickstart"[/topic]. :)
[*]Niet de eerste keer dat je op puntje 2 gewezen bent, zie [MESSAGE=26442595]niesje in "Export MS project naar outlook"[/MESSAGE] ;)
[/list]

---

Dat komt er geparset zo uit te zien:

---

Dit is:

2. een bekend fenomeen in databaseland en is wel te vinden, bijvoorbeeld door [google=automatically delete foreign key]
3. niet de juiste manier om een topic te starten op GoT in het algemeen en al helemaal niet in Programming in het bijzonder. Zie ook Het algemeen beleid #topicplaatsen en Programming Beleid - De "quickstart".
4. Niet de eerste keer dat je op puntje 2 gewezen bent, zie niesje in "Export MS project naar outlook"

---

Misschien dat ik een denkfout maak ofzo, maar waarom wordt dit niet netjes naar behoren geparset als een ordered list? Ik heb het zelf maar met HTML opgelost (-NMe- in "[SQL] Regel verwijderen") maar ik kan me voorstellen dat de gewone gebruiker minder goede oplossingen tot zijn beschikking heeft.

[momania]

1. een bekend fenomeen in databaseland en is wel te vinden, bijvoorbeeld door
2. niet de juiste manier om een topic te starten op GoT in het algemeen en al helemaal niet in Programming in het bijzonder. Zie ook Het algemeen beleid #topicplaatsen en Programming Beleid - De "quickstart".
3. Niet de eerste keer dat je op puntje 2 gewezen bent, zie niesje in "Export MS project naar outlook"

---

Komt door de [google] tag... die moet je ff netjes afsluiten met een [/google]

[edit]
En waarom dat weet ik niet, maar dat kan crisp je wel uitleggen denk ik

[ Voor 5% gewijzigd door momania op 17-01-2007 13:23 ]

[Osiris]

momania schreef op woensdag 17 januari 2007 @ 13:21:
Komt door de [google] tag... die moet je ff netjes afsluiten met een [/google]

Nee hoor, in principe niet, da's alleen als je er een beschrijving bij wilt zetten:

quote: http://gathering.tweakers.net/forum/faq/ubb#tag_google

De google-tag

Syntax: [google=keyword] ( omschrijving [/google] )

Bugje dus

(Al zou ik liever zien dat ze blokhaken ([]) gebruiken voor optionele parameters, zoals je meestal ziet )

[ Voor 11% gewijzigd door Osiris op 17-01-2007 13:23 ]

[NMe]

Titlefix.

Osiris schreef op woensdag 17 januari 2007 @ 13:22:
(Al zou ik liever zien dat ze blokhaken ([]) gebruiken voor optionele parameters, zoals je meestal ziet )

Nee, da's lekker handig in een lijst met bb-code waar bijna alles al tussen blokhaken staat.

[ Voor 93% gewijzigd door NMe op 17-01-2007 13:24 ]

[momania]

Osiris schreef op woensdag 17 januari 2007 @ 13:22:
[...]

Nee hoor, in principe niet, da's alleen als je er een beschrijving bij wilt zetten:

Snap ik, de google tag werkt zoals hij hoort, maar verzoorzaakt wel de problemen hier

[JHS]

2. [google=automatically delete foreign key]
3. niet de juiste manier om een topic te starten op GoT in het algemeen en al helemaal niet in Programming in het bijzonder. Zie ook Het algemeen beleid #topicplaatsen en Programming Beleid - De "quickstart".
4. Niet de eerste keer dat je op puntje 2 gewezen bent, zie niesje in "Export MS project naar outlook"

vs.

1. een bekend fenomeen in databaseland en is wel te vinden, bijvoorbeeld door (...)
2. niet de juiste manier om een topic te starten op GoT in het algemeen en al helemaal niet in Programming in het bijzonder. Zie ook Het algemeen beleid #topicplaatsen en Programming Beleid - De "quickstart".
3. Niet de eerste keer dat je op puntje 2 gewezen bent, zie niesje in "Export MS project naar outlook"

vs.

2. [google=automatically delete foreign key]
3. Het algemeen beleid #topicplaatsen en Programming Beleid - De "quickstart".

vs.

2. [google=automatically delete foreign key]
3. Programming Beleid - De "quickstart".

vs.

2. [google=automatically delete foreign key]
3. bla

vs.

2. [google=automatically delete foreign key]
3. Programming Beleid - De.

vs.

2. [google="automatically delete foreign key"]
3. Programming Beleid - De.

vs.

2. [google=automatically delete foreign key]
3. Het algemeen beleid #topicplaatsen

vs.

2. [google=automatically delete foreign key]
3. foo

2. [google=automatically delete foreign key]
3. foo
4. foo

---

Het lijkt hem in de combinatie van de google tag en het hebben van een andere tag op de volgende regel te zitten.. Of zoiets..

[Rafe]

Kennelijk wordt de */li tag niet goed afgesloten. Zelfs als je ze handmatig afsluit krijg je rare resultaten:

1. een bekend fenomeen in databaseland en is wel te vinden, bijvoorbeeld door [google=automatically delete foreign key]
2. niet de juiste manier om een topic te starten op GoT in het algemeen en al helemaal niet in Programming in het bijzonder. Zie ook Het algemeen beleid #topicplaatsen en Programming Beleid - De "quickstart".
3. Niet de eerste keer dat je op puntje 2 gewezen bent, zie niesje in "Export MS project naar outlook"

Sluit je echter de Google-tag wel af, werkt het prima, ook zonder de */li tags te sluiten

1. een bekend fenomeen in databaseland en is wel te vinden, bijvoorbeeld door g00gle search
2. niet de juiste manier om een topic te starten op GoT in het algemeen en al helemaal niet in Programming in het bijzonder. Zie ook Het algemeen beleid #topicplaatsen en Programming Beleid - De "quickstart".
3. Niet de eerste keer dat je op puntje 2 gewezen bent, zie niesje in "Export MS project naar outlook"

Search tag doet hetzelfde. Open tags in een list doen onverwachtse dingen dus.

[crisp]

Als je singletons wil gebruiken binnen een listitem-element moet je geen singleton voor het listitem-element gebruiken maar expliciet [li] ... [/li] doen:

1. [google=foo]
2. [google=foo]

edit: hmmz - blijkbaar is de tagparser na het voorkomen van een singleton wel z'n parent kwijt...

RML_TAG_INCOMPLETE_OPEN gooit inderdaad roet in het eten omdat dat toch een extra level genereerd waardoor het bepalen van de parent bij de volgende open/close pair incorrect is

aan de nadere kant rammelt er sowieso nog wel het een en ander aan het parsen van singletons. Met name voor de listitem singletons en de /me-singleton kan de parser nog steeds niet goed bepalen waar de impliciete end-tag zou moeten komen. Vooralsnog is dus nog steeds het advies: als je problemen krijgt met nesting gebruik dan de end/close-tag pairs ipv singletons.

[ Voor 85% gewijzigd door crisp op 17-01-2007 22:59 ]

[NMe]

Ik post dit maar hier omdat het gerelateerd is aan deze kwestie volgens mij.

Waarom gaat dit fout?

---

[norml]

1. Als je je code eens zou uitlijnen, dan is die veel duidelijker. Zie onze FAQ voor informatie.
2. Gebruik [norml][code][ /norml]-tags als je code post. Dat maakt het voor ons makkelijker om je code te lezen.
3. Het noemen van het adres van je website wordt hier niet echt gewaardeerd tenzij het direct te maken heeft met de oplossing van je probleem.
4. Zoals prototype al zegt is je ontwerp slecht. In plaats van een oplossing te zoeken voor je directe probleem, doe je er beter aan je databaseontwerp eens onder de loep te nemen en netjes te normaliseren.

[/norml]

1. Als je je code eens zou uitlijnen, dan is die veel duidelijker. Zie onze FAQ voor informatie.
2. Gebruik [code]-tags als je code post. Dat maakt het voor ons makkelijker om je code te lezen.
3. Het noemen van het adres van je website wordt hier niet echt gewaardeerd tenzij het direct te maken heeft met de oplossing van je probleem.
4. Zoals prototype al zegt is je ontwerp slecht. In plaats van een oplossing te zoeken voor je directe probleem, doe je er beter aan je databaseontwerp eens onder de loep te nemen en netjes te normaliseren.

---

Zonder norml-tags gaat het wel goed, dus blijkbaar zijn die de boosdoeners.

[crisp]

Geen [norml]-tag gebruiken maar tag-escaping: \[code]:

1. Als je je code eens zou uitlijnen, dan is die veel duidelijker. Zie onze FAQ voor informatie.
2. Gebruik [code]-tags als je code post. Dat maakt het voor ons makkelijker om je code te lezen.
3. Het noemen van het adres van je website wordt hier niet echt gewaardeerd tenzij het direct te maken heeft met de oplossing van je probleem.
4. Zoals prototype al zegt is je ontwerp slecht. In plaats van een oplossing te zoeken voor je directe probleem, doe je er beter aan je databaseontwerp eens onder de loep te nemen en netjes te normaliseren.

Dat is inderdaad wel een bug in de parser, maar volgens Parse gaat die parser toch op de schop...

[ Voor 6% gewijzigd door crisp op 28-03-2007 09:55 ]

[NMe]

Check.

[Spider.007]

okay