[bug] Alias zorgt niet voor actief forum in overzicht

[pasta]

Hoi,

In GTK staat een alias naar een topic in A61, als ik echter in Categorie 1 kijk, dan zie ik dat er in GTK geen nieuwe posts zijn. Technisch gezien klopt dit ook, maar gezien ik verder vrijwel nooit in A61 kom mis ik dus ook de replies in dat topic.

Kan dat gefixed worden?

[moto-moi]

Da's bij design afaik, aangezien er een paar mods waren die het tof vonden om overal aliassen te maken, en die dan telkens en block in de active topics kwamen, wat ook geen gezicht is

[cowgirl]

Behalve in de list_category_topics, daar komen ze nog steeds en block in: Topics in category 'Devschuur®'

[pasta]

Ze hoeven wmb ook niet bij Active Topics komen te staan, maar wel dat list_category weergeeft dat er in dat forum gepost is, alhoewel dat technisch gezien niet klopt though.

[.oisyn]

Hoe staat het hier eigenlijk mee? Het viel me vandaag op, toen ik een keer in Programming keek, wat ik vrijwel nooit doe, dat er ineens een groot topic stond waarvan ik niet eens wist dat het bestond. Ik gebruik namelijk altijd de Active Topics lijst met een specifiek filter, en het betreffende topic is een topic dat eigenlijk in het Apple forum staat, wat ik wegfilter. Ik snap dat mensen het irritant vinden dat zo'n topic meerdere keren in hun AT voorkomt als ze al de betreffende fora ook tonen, maar het lijkt me nog irritanter dat zo'n topic gewoon ineens compleet weg is als je toevallig het bron-forum hebt weggefilterd.

[crisp]

Ik neig naar een wontfix/by design in deze. Aliassen worden integraal weggefiltert uit de AT met een duidelijke reden. Dat iemand een forum wegfiltert waar het originele topic in staat is dan jammer, maar het is vrijwel ondoenlijk om daar allerlei checks omheen te gaan bouwen.

Ik wil nog wel kijken of de 'new'-indicator voor een forum nu wel goed geupdate wordt bij activiteit op het topic waar een alias in dat forum naar verwijst.

[.oisyn]

Ondoenlijk? Dat lijkt me stug. Wellicht moet je het gewoon niet op databaseniveau op willen lossen. Het kan desnoods in de template zelf.

[crisp]

.oisyn schreef op donderdag 16 april 2009 @ 11:57:
Ondoenlijk? Dat lijkt me stug. Wellicht moet je het gewoon niet op databaseniveau op willen lossen. Het kan desnoods in de template zelf.

Dan moet je dat dus gaan hacken (want dat is het) in elke view en functie die iets met die data doet (dus ook RSS/XML views en de verschillende andere plekken waar we active topics laten zien zoals myReact). Bijkomend effect is dat je nooit een vast aantal AT's meer hebt in je overzicht tenzij je weer onnodig extra topics gaat fetchen 'just in case'.

[.oisyn]

crisp schreef op donderdag 16 april 2009 @ 12:45:
[...]

Dan moet je dat dus gaan hacken (want dat is het) in elke view en functie die iets met die data doet (dus ook RSS/XML views en de verschillende andere plekken waar we active topics laten zien zoals myReact).

Goh, je zou zeggen dat ze voor dat soort dingen in de informatietechnologie het concept 'procedure' of 'functie' hebben uitgevonden . Maar goed, ik weet verder niet hoe uitgebreid het template systeem van React is. Daarnaast is er niets mis met een hack. Hell, het hele topic alias systeem is een grote hack. Maar goed, het was verder sowieso maar een suggestie, volgens mij heb je ook toegang tot de sourcecode zelf dus daar zou je het evt ook kunnen aanpakken. Ik wilde alleen maar even aangeven dat het niet erg is om het niet op databaseniveau aan te pakken als dat het daadwerkelijke probleem is.

Bijkomend effect is dat je nooit een vast aantal AT's meer hebt

Ja maar dat argument gaat dus nergens over he . Wil je daadwerkelijk beweren dat het gegeven dat het aantal topics in je AT lijst vast staat belangrijker is dan het feit dat er mogelijk topics niet tussen staan die er wel tussen zouden moeten staan? Kom nou

[ Voor 22% gewijzigd door .oisyn op 16-04-2009 13:08 ]

[crisp]

.oisyn schreef op donderdag 16 april 2009 @ 12:51:
[...]

Goh, je zou zeggen dat ze voor dat soort dingen in de informatietechnologie het concept 'procedure' of 'functie' hebben uitgevonden .

Ej, jij begon over het aanpakken in de templates

Maar goed, ik weet verder niet hoe uitgebreid het template systeem van React is. Daarnaast is er niets mis met een hack. Hell, het hele topic alias systeem is een grote hack. Maar goed, het was verder sowieso maar een suggestie, volgens mij heb je ook toegang tot de sourcecode zelf dus daar zou je het evt ook kunnen aanpakken.

Did you miss something: plan: Tweakers.net neemt ontwikkeling React in eigen handen ?

Ik wilde alleen maar even aangeven dat het niet erg is om het niet op databaseniveau aan te pakken als dat het daadwerkelijke probleem is.

Het is wel aan te pakken op databaseniveau, maar voor zover ik nu kan inschatten enkel op een zeer omslachtige manier wat performance technisch gewoon niet wenselijk is.

[...]

Ja maar dat argument gaat dus nergens over he . Wil je daadwerkelijk beweren dat het gegeven dat het aantal topics in je AT lijst vast staat belangrijker is dan het feit dat er mogelijk topics niet tussen staan die er wel tussen zouden moeten staan? Kom nou

Wel voor views waar maar een relatief weinig aantal topics getoond worden zoals in myReact; het valt wel op als je lijstje daar ineens 3 items korter is omdat bijvoorbeeld Feedback op moderatie binnen de Devschuur een nieuw bericht heeft, en de 3 aliassen er nadien in de template uitgefiltert worden omdat het originele topic ook al in de listing staat...

Overigens kan je AT wel opvragen inclusief aliassen: http://gathering.tweakers...pics?data[show_aliases]=1

Anyway, ik heb ondertussen gefixed dat een update op een topic met aliassen ook de fora-data waar die aliassen in staan updaten zodat die ook meekleuren op de index.

Het wel of niet opnemen van (een) alias(sen) indien in de AT het forum van het oorspronkelijke topic gefiltert is is feitelijk een ander request en hoort dus thuis in een ander topic, maar dan moeten er wel sterke argumenten zijn om mijn huidige wontfix standpunt te kunnen veranderen