[TweakBlogs] Postlengtelimiet

[YellowOnline]

Er is blijkbaar een postlengtelimiet (Scrabble, iemand?) op TweakBlogs.

Je post was meer dan 65535 karakters lang. Alleen de eerste 65535 zijn opgeslagen!

Fijn zeg: je typt een heel lange post en vervolgens wordt alles na karakter 65535 gewist. Dat lijkt me niet de ideale aanpak. Beter is een foutmelding zodra je op 'verzenden' klikt waarbij je post blijft staan, omdat:

1. Niemand een gedeeltelijke post wil posten uiteindelijk. Gedeeltelijk posten is nogal een bizar idee. Liever post je niets op dat moment en bewerk je je tekst om onder de limiet te komen
2. Je bent je tekst niet kwijt. In praktijk kan je je tekst weliswaar redden door de back-knop te gebruiken, maar gebruiksvriendelijk is alles. Gewoon back is niet voldoende trouwens: je moet twee pagin'as terug in de geschiedenis omdat je ander blijft hangen op een popup, althans in FF, dat de informatie opnieuw verzonden moet worden.

Is er overigens een reden dat er een 2¹⁶-1 limiet is of is dat een standaardinstelling waar nu eenmaal weinig mensen tegenaanlopen? Een van de redenen dat ik er tegenaan liep is, denk ik, dat binnen een [code]-tag de whitespace als karakters meegerekend wordt. Als ik dan een script van 541 lijnen post (dit script) begrijp ik dat het slecht afloopt.

Enfin, ik heb het op Pastebin gezwierd, maar hoop in de toekomst toch meer over scripting te kunnen bloggen zonder dat ik met een link naar een externe host moet werken.

---

Mag ik van de gelegenheid gebruikmaken om de heren devvers nog eens te wijzen op volgende suggesties:

• [Feat Blogs] Anoniem reageren & postcount
• [feat] Per tweakblogpost aangeven wel/geen anonieme reacties
• [feat] lijst met geplaatste reacties op Tweakblogs

[crisp]

Je bent waarschijnlijk de eerste die er tegenaan loopt En de reden is simpel: het databaseveld staat ingesteld op max 64KB. En ja, dat kunnen we wel verhogen.

Echter moet je jezelf ook afvragen of een weblogpost nog wel prettig leesbaar is als je over de huidige limiet heengaat. Op zich vind ik het helemaal niet gek om voor dat 541 lijnen tellende script naar een externe resource door te verwijzen, niemand gaat dat in een blogpost zitten lezen...

[YellowOnline]

crisp schreef op vrijdag 30 september 2011 @ 22:29:
Je bent waarschijnlijk de eerste die er tegenaan loopt En de reden is simpel: het databaseveld staat ingesteld op max 64KB. En ja, dat kunnen we wel verhogen.

Echter moet je jezelf ook afvragen of een weblogpost nog wel prettig leesbaar is als je over de huidige limiet heengaat. Op zich vind ik het helemaal niet gek om voor dat 541 lijnen tellende script naar een externe resource door te verwijzen, niemand gaat dat in een blogpost zitten lezen...

Ah, win ik iets nu?

Als het verhogen van de limiet je geen meerwaarde lijkt te bieden dan loont het inderdaad niet de moeite. Maar een goed gelexed script is even leesbaar op TweakBlogs dan op pakweg PasteBin.

[crisp]

YellowOnline schreef op vrijdag 30 september 2011 @ 22:33:
[...]

Als het verhogen van de limiet je geen meerwaarde lijkt te bieden dan loont het inderdaad niet de moeite. Maar een goed gelexed script is even leesbaar op TweakBlogs dan op pakweg PasteBin.

Daar gaat het niet om; de vraag is of elke lezer van je post ueberhaupt wel geinteresseerd is in dat volledige script

[RedHat]

crisp schreef op vrijdag 30 september 2011 @ 22:39:
[...]

Daar gaat het niet om; de vraag is of elke lezer van je post ueberhaupt wel geinteresseerd is in dat volledige script

De vraag is of iedere Tweakers.net bezoeker wel interesse heeft in alle content wat gepost wordt. Dit is natuurlijk een beetje een vage redenering (al snap ik hem wel).

Ik zou de limiet gewoon hanteren alleen het post-proces aanpassen. Een halve post gewoon posten is minder gebruikersvriendelijk dan gewoon netjes de melding met het tekstveldje waarin de tekst staat die gesubmit wordt.

[crisp]

RedHat schreef op vrijdag 30 september 2011 @ 22:53:
[...]

De vraag is of iedere Tweakers.net bezoeker wel interesse heeft in alle content wat gepost wordt. Dit is natuurlijk een beetje een vage redenering (al snap ik hem wel).

Wat ik bedoelde was meer dat zo'n volledig script wellicht niet interessant is voor elke lezer van de betreffende blogpost (die de post zelf dus wel interessant vind), en het dan dus enkel overmatig veel ruimte inneemt wat mogelijke lezers weer kan afschrikken (tldr).

Ik zou de limiet gewoon hanteren alleen het post-proces aanpassen. Een halve post gewoon posten is minder gebruikersvriendelijk dan gewoon netjes de melding met het tekstveldje waarin de tekst staat die gesubmit wordt.

I agree, hoewel ik er op zich ook geen moeite mee heb om de limiet wat te verhogen (startposts hier op het forum mogen ook al 256KB zijn).

[Wiethoofd]

Misschien op Tweakblogs de codeblokken default ook horizontaal ingeklapt neerzetten bij >50 lines?

TS op GoT is toch 200k, of is deze naar ons gezeur in het buitenlandse serie topic opgehoogd naar 256?

Op GoT heb je nu toch ook als je post ver over de tekenlimiet heen gaat deze opnieuw gepresenteerd wordt om te kopiëren met de melding dat je veul te veul tekst hebt geklopt, zoiets zou er op de tweakblogs ook moeten zijn (lijkt me)

[crisp]

Wiethoofd schreef op vrijdag 30 september 2011 @ 23:19:
Misschien op Tweakblogs de codeblokken default ook horizontaal ingeklapt neerzetten bij >50 lines?

Horizontaal inklappen moeten we ooit nog eens wat voor bedenken, is al vaker aangevraagd nmw (en niet alleen voor code).

TS op GoT is toch 200k, of is deze naar ons gezeur in het buitenlandse serie topic opgehoogd naar 256?

256 atm

Op GoT heb je nu toch ook als je post ver over de tekenlimiet heen gaat deze opnieuw gepresenteerd wordt om te kopiëren met de melding dat je veul te veul tekst hebt geklopt, zoiets zou er op de tweakblogs ook moeten zijn (lijkt me)

jep, dat zou wel beter zijn. Ik gok echter dat er toentertijd voor de huidige manier is gekozen omdat het blijkbaar niet triviaal was om het originele formulier weer ingevuld te tonen of zoiets - maar wellicht is dat op dit moment ook geen issue meer (ik heb al een tijd niet meer in die code gezeten )

[Verwijderd]

Wiethoofd schreef op vrijdag 30 september 2011 @ 23:19:
TS op GoT is toch 200k, of is deze naar ons gezeur in het buitenlandse serie topic opgehoogd naar 256?

Je vergeet dat de limiet van 256k geldt voor de gegenereerde HTML code. Niet de UBB zelf.

[crisp]

Verwijderd schreef op vrijdag 30 september 2011 @ 23:37:
[...]

Je vergeet dat de limiet van 256k geldt voor de gegenereerde HTML code. Niet de UBB zelf.

klopt

[Wiethoofd]

Verwijderd schreef op vrijdag 30 september 2011 @ 23:37:
Je vergeet dat de limiet van 256k geldt voor de gegenereerde HTML code. Niet de UBB zelf.

Dat wist ik, maar zelfs met de UBB die we toen lieten genereren en de html die dat opleverde gingen we er ruim (over de 200k) overheen (veel plaatjes met linkjes, ondanks de korte url's). Nu met een externe pagina met een net overzicht van de info wel veel meer ruimte

Maar een extra usecase voor horizontaal in kunnen klappen van items zorgt er vast voor dat ie hoger op het prioriteiten lijstje komt te staan Spoilers, grote afbeeldingen, codeblokken, pre-tags, cmd etc. en dus nu ook voor op Tweakblogs

[YellowOnline]

crisp schreef op vrijdag 30 september 2011 @ 23:15:
[...]

Wat ik bedoelde was meer dat zo'n volledig script wellicht niet interessant is voor elke lezer van de betreffende blogpost (die de post zelf dus wel interessant vind), en het dan dus enkel overmatig veel ruimte inneemt wat mogelijke lezers weer kan afschrikken (tldr).

[...]

I agree, hoewel ik er op zich ook geen moeite mee heb om de limiet wat te verhogen (startposts hier op het forum mogen ook al 256KB zijn).

Klopt het overigens wat ik denk, nl. dat whitespace binnen de codetags als tekst geïnterpreteerd wordt?

[Verwijderd]

Alles wat in de HTML staat neemt ruimte in. Je kan het zelf controleren door de broncode van de pagina te bekijken.

[crisp]

YellowOnline schreef op zaterdag 01 oktober 2011 @ 23:04:
[...]


Klopt het overigens wat ik denk, nl. dat whitespace binnen de codetags als tekst geïnterpreteerd wordt?

whitespace zijn ook gewoon bytes, maar daarnaast wordt whitespace binnen highlighted code ook omgezet in no-breaking space entities ( ) - een spatie neemt dan dus 6 bytes in en een tab zelfs 4x6 bytes.