Pricewatch filter URL, welke techniek?

[Verwijderd]

Als je in de pricewatch een aantal merken of andere eigenschappen selecteert, krijg je een URL als dit:

#filter:Nc0xCoNAFATQu0y9RYgawx5AsLCyFAv9f4oFceWvRCHk7tlCy3nDMF_MNq3aaoIfUNZPOJTvF0aHaEprAh
eFxyfwSLiwj7ZnUybJtFkQdmGFfzgkicZuOuGrO9wNF8pO7TfKdVfkdVVg_P0B

Heeft iemand een idee hoe dit werkt?

Dus, hoe zo'n code gemaakt wordt. Hoe ervoor gezorgd wordt dat er voor elke mogelijke combinatie van filters een andere code is.

En hoe je het op de server weer kunt onleden (in PHP)..

Heb al een tijdje in de javascript files zitten neuzen, maar ik kom er niet echt uit.

[Bosmonster]

of het is gewoon een filter sessie (of set)-ID

[ Voor 10% gewijzigd door Bosmonster op 01-09-2010 18:07 ]

[Fish]

Je mist gewoon een beetje fantasie volgens mij.

Voor het zelfde geld is dit een referentie naar een opgeeslagen zoekactie en niet meer
Dus Leeg nou eerst eens uit wat je aan het doen bent.

[Bosmonster]

Nou fish, beetje aardiger mag wel. Hij vraagt zich gewoon af hoe zoiets werkt.

[DexterDee]

Het lijkt me sterk dat het een sessie id is, want dan is 'ie wel érg lang. Volgens mij is het gewoon een obfuscated string waar de opties in staan, waarbij wat gespeeld is met rot13 / base64 of iets van encryptie. Met als doel dat mensen niet zelf (geautomatiseerd) een filter url kunnen samenstellen, maar dat dit verplicht via de selectors van de pricewatch gaat. But I could be wrong ofcourse

[Verwijderd]

Bosmonster schreef op woensdag 01 september 2010 @ 18:06:
of het is gewoon een filter sessie (of set)-ID

Wat bedoel je precies?

fish schreef op woensdag 01 september 2010 @ 18:08:
Je mist gewoon een beetje fantasie volgens mij.

Voor het zelfde geld is dit een referentie naar een opgeeslagen zoekactie en niet meer
Dus Leeg nou eerst eens uit wat je aan het doen bent.

Ik wil ook zo'n systeem maken. Alleen zit ik nu met het probleem dat als ik bijvoorbeeld een parameter

/filterby/color/blue

heb, dan kan ik niet nog eens de kleur rood toevoegen, of een filterby /filterby/lang/en, en dan kan ik ook niet nog een taal toevoegen.

Dus als ik dat zou willen, zou ik dit moeten doen:

filterby/color1/blue/color2/red/language1/en/language2/nl

Dan krijg je 500 parameters.


Vandaar dat ik benieuwd was hoe tweakers dit oploste.

[DexterDee]

Verwijderd schreef op woensdag 01 september 2010 @ 18:16:
Ik wil ook zo'n systeem maken.

[...]

Vandaar dat ik benieuwd was hoe tweakers dit oploste.

Het precieze algoritme van de pricewatch is natuurlijk bedrijfsgeheim, maar ik kan me in jouw situatie het volgende voorstellen:

filter id:
1 - kleur
2 - taal

kleuren id:
1 - zwart
2 - wit
3 - geel
4 - blauw

talen id:
1 - nederlands
2 - engels
3 - spaans
4 - frans

Iemand post een set aan filters naar je server, op de server maak je er het volgende van:

1=1+3&2=2+3+4
(kleur=zwart+geel en taal=engels+spaans+frans)

Om die filters een beetje onherkenbaar (obfuscated) te maken pas je wat truukjes toe:

Eerst haal je 1=1+3&2=2+3+4 door base64 encode om dit te krijgen:
MT0xKzMmMj0yKzMrNA==

Vervolgens doe je een rot13 hierop om dit te krijgen:
ZG0kXmZzZw0lXmZeAN==

Et voila, je hebt een mooie filterstring waar niet direct aan zichtbaar is wat erin zit. Deze kun je nu gebruiken achter je URL:
www.mijnsite.nl/prijskijk#filter:ZG0kXmZzZw0lXmZeAN==

Met javascript kun je de URL uitlezen en eventueel met AJAX die string naar de server sturen om de opties terug te krijgen. Of je zet die filter gewoon op een andere manier in de URL:

www.mijnsite.nl/prijskijk/filter/ZG0kXmZzZw0lXmZeAN==
of
www.mijnsite.nl/prijskijk.php?filter/ZG0kXmZzZw0lXmZeAN==

Om de filter op een meer 'tradionele manier' te behandelen in PHP

Op de server draai je het hele riedeltje weer om, dus eerst rot13 over die string, dan base64 decode en dan heb je de id's te pakken van de filters.

Dit is slechts één van de vele mogelijkheden, maar ik hoop dat je het concept snapt

[crisp]

Het is niet met opzet 'obfuscated' hoor; de methode die wij toepassen is er voornamelijk op geënt om de url's zo kort mogelijk te houden en er toch een hoop verschillende filterwaarden in kwijt kunnen. In feite is het een json-serialised object dat met gzdeflate is compressed en waar we vervolgens een url-safe base64 functie op hebben losgelaten

[Verwijderd]

DexterDee schreef op woensdag 01 september 2010 @ 18:31:
[...]

Het precieze algoritme van de pricewatch is natuurlijk bedrijfsgeheim, maar ik kan me in jouw situatie het volgende voorstellen:

filter id:
1 - kleur
2 - taal

kleuren id:
1 - zwart
2 - wit
3 - geel
4 - blauw

talen id:
1 - nederlands
2 - engels
3 - spaans
4 - frans

Iemand post een set aan filters naar je server, op de server maak je er het volgende van:

1=1+3&2=2+3+4
(kleur=zwart+geel en taal=engels+spaans+frans)

Om die filters een beetje onherkenbaar (obfuscated) te maken pas je wat truukjes toe:

Eerst haal je 1=1+3&2=2+3+4 door base64 encode om dit te krijgen:
MT0xKzMmMj0yKzMrNA==

Vervolgens doe je een rot13 hierop om dit te krijgen:
ZG0kXmZzZw0lXmZeAN==

Et voila, je hebt een mooie filterstring waar niet direct aan zichtbaar is wat erin zit. Deze kun je nu gebruiken achter je URL:
www.mijnsite.nl/prijskijk#filter:ZG0kXmZzZw0lXmZeAN==

Met javascript kun je de URL uitlezen en eventueel met AJAX die string naar de server sturen om de opties terug te krijgen. Of je zet die filter gewoon op een andere manier in de URL:

www.mijnsite.nl/prijskijk/filter/ZG0kXmZzZw0lXmZeAN==
of
www.mijnsite.nl/prijskijk.php?filter/ZG0kXmZzZw0lXmZeAN==

Om de filter op een meer 'tradionele manier' te behandelen in PHP

Op de server draai je het hele riedeltje weer om, dus eerst rot13 over die string, dan base64 decode en dan heb je de id's te pakken van de filters.

Dit is slechts één van de vele mogelijkheden, maar ik hoop dat je het concept snapt

Wow... hier heb ik echt wat aan!

Ik ga het voorlopig nog wel even op de oude manier doen (dus dat ik maar 1 filter tegelijk kan doen). Dat werkt namelijk al, en dan kan ik in de tussentijd jouw manier uitwerken.

Bedankt!

[Verwijderd]

crisp schreef op woensdag 01 september 2010 @ 18:54:
Het is niet met opzet 'obfuscated' hoor; de methode die wij toepassen is er voornamelijk op geënt om de url's zo kort mogelijk te houden en er toch een hoop verschillende filterwaarden in kwijt kunnen. In feite is het een json-serialised object dat met gzdeflate is compressed en waar we vervolgens een url-safe base64 functie op hebben losgelaten

Interessant. Dus in plaats van een string met 1=1+2+3 maken jullie gebruik van json.

Dat is wellicht ook nog een methode. Dat scheelt in ieder geval weer om van die string een array te maken. Json kan je zo uitlezen.

[DexterDee]

crisp schreef op woensdag 01 september 2010 @ 18:54:
Het is niet met opzet 'obfuscated' hoor; de methode die wij toepassen is er voornamelijk op geënt om de url's zo kort mogelijk te houden en er toch een hoop verschillende filterwaarden in kwijt kunnen. In feite is het een json-serialised object dat met gzdeflate is compressed en waar we vervolgens een url-safe base64 functie op hebben losgelaten

JSON kan natuurlijk ook, aangezien het een van de meest compacte vormen is om data te (text)serialiseren in PHP. Maar in essentie zat ik dus een heel eind in de goede richting. Ik dacht alleen dat jullie wellicht nog een drempeltje hadden opgeworpen tegen bijvoorbeeld crawlers die automatisch pricewatch data indexeren op basis van filters. Niet dat daar niet omheen te werken is

Wil je overigens écht compact filtersetting opslaan, dan zou je de filters binair kunnen opslaan met bijvoorbeeld een bitmask:

/  herhaalbaar packet  \
[byte][byte][byte][byte][...................][...................]
\ filterid /\ bitmask  /

En deze binary string achteraf gzippen. In deze opzet kun je 64k filters kwijt met ieder 64k aan opties. Met minder bits heb je uiteraard nog minder overhead

[mcDavid]

DexterDee schreef op woensdag 01 september 2010 @ 18:31:
[...]

Het precieze algoritme van de pricewatch is natuurlijk bedrijfsgeheim, maar ik kan me in jouw situatie het volgende voorstellen:

filter id:
1 - kleur
2 - taal

kleuren id:
1 - zwart
2 - wit
3 - geel
4 - blauw

talen id:
1 - nederlands
2 - engels
3 - spaans
4 - frans

Iemand post een set aan filters naar je server, op de server maak je er het volgende van:

1=1+3&2=2+3+4
(kleur=zwart+geel en taal=engels+spaans+frans)

Kan nog mooier, als je met machten van 2 werkt.
1: Nederlands
2: Engels
4: Spaans
8: Frans

Language=6, en je weet dat hij spaans en engels zoekt.

[DexterDee]

mcDavid schreef op donderdag 02 september 2010 @ 14:06:
[...]

Kan nog mooier, als je met machten van 2 werkt.

Aldus wat ik in mijn voorlaatste post voorstelde. Die machten van 2 noemen ze een bitmask

[Cartman!]

Dat zorgt wel voor een beperking aan keuzes, je kunt niet oneindig door blijven masken namelijk

[Juup]

Cartman! schreef op donderdag 02 september 2010 @ 14:51:
Dat zorgt wel voor een beperking aan keuzes, je kunt niet oneindig door blijven masken namelijk

Noem eens iets wat niet kan dan?

[RobIII]

Juup schreef op maandag 06 september 2010 @ 15:16:
[...]

Noem eens iets wat niet kan dan?

Kiezen uit 174 verschillende types Maar dat is wel op te lossen door 2 128-bits of 3 64-bits of 6 32-bits velden aaneen te plakken
Punt is: een bitmask is niet altijd handig.

[Voutloos]

Het is nu dus een makkelijk te verwerken datastructuur met een bewerkinkje eroverheen voor de compressie, waarom zou je nog moeilijker doen? Je bespaart een handjevol bytes maar moet wel de nodige extra uren devven... dat kan al gauw een behoorlijk slechte trade-off zijn.

[dirkpostma]

Is zo'n filter wel handig m.b.t. SEO?

Vergelijk:

http://tweakers.net/categ...PK1bSUSooykxO9c3MU7IyqAUA

met:

http://tweakers.net/categ...lets/producten/merk:apple

Of nog beter, met wat handige URL routing:

http://tweakers.net/apple/tablets/

Of is SEO nog een van de vele punten op de todo-list?

[NMe]

SEO boeit geen fluit op dit punt, want zoekmachines filteren sowieso niet. De crawler komt via de listings vanzelf wel overal uit.

[crisp]

We willen niet eens dat alle mogelijke filtercombinaties gecrawled worden Voor bijvoorbeel apple hebben we al http://tweakers.net/merk/122/apple/ welke we veel liever terugzien in Google

Het is dus voor de rest puur 'state' voor de client en bookmarkability

[Wolfboy]

RobIII schreef op maandag 06 september 2010 @ 15:30:
[...]

Kiezen uit 174 verschillende types Maar dat is wel op te lossen door 2 128-bits of 3 64-bits of 6 32-bits velden aaneen te plakken
Punt is: een bitmask is niet altijd handig.

Javascript kan in (alle?) moderne browsers overigens tot 1024 bits werken

[meneer william]

Kun je niet beter gewoon traditioneel gebruik maken van en goeie get string: website.nl/pricewatch?id=99&kleur=zwart~geel~bruin&taal=eng etc.

Het gebruik van bijvoorbeeld website.nl/pricewatch/id/kleur etc is niet echt aan te bevelen.

Hiervoor zijn ook prima PHP functies om deze te verwerken. Pas als je wat verder bent kun je de string inkorten door deze door gzip te halen of iets dergelijks.

Ook is het zo ie zo altijd te adviseren om nummers te gebruiken voor data die altijd het zelfde is. Voor bijvoorbeeld een select veld met 4 keuzes weet je op de webserver al welke 4 dat zijn en hoef je deze niet op en neer te sturen.

website.nl/pricewatch?id=99&kleur=2~3~5&taal=2 etc.

Dat is natuurlijk aan een array of misschien zelf db sleutel gekoppeld.

[ Voor 31% gewijzigd door meneer william op 20-10-2012 00:43 ]

[dirkpostma]

crisp schreef op vrijdag 19 oktober 2012 @ 17:41:
We willen niet eens dat alle mogelijke filtercombinaties gecrawled worden Voor bijvoorbeel apple hebben we al http://tweakers.net/merk/122/apple/ welke we veel liever terugzien in Google

Het is dus voor de rest puur 'state' voor de client en bookmarkability

Oké, dat "state" begrijp ik :-)

Mbt SEO: de termen "merk" en "122" zorgen wel voor meer ruis waardoor "Apple" wellicht als minder belangrijk gezien wordt dan bv. "Tweakers.net/Apple". En what about "tweakers.net/tablets/Apple"? Zijn deze links ook gecovered, bv door deze te mappen naar gefilterde pagina's? Of is dat nog todo? Of niet belangrijk in jullie ogen?

[crisp]

Van wat ik begrepen heb is de URL lang niet zo belangrijk voor Google als dat sommige mensen denken

[RobIII]

crisp schreef op zaterdag 20 oktober 2012 @ 02:26:
Van wat ik begrepen heb is de URL lang niet zo belangrijk voor Google als dat sommige mensen denken

Juist. Content is king. Rest is gepiel in de marge.

[NMe]

meneer william schreef op zaterdag 20 oktober 2012 @ 00:36:
Kun je niet beter gewoon traditioneel gebruik maken van en goeie get string: website.nl/pricewatch?id=99&kleur=zwart~geel~bruin&taal=eng etc.

Het gebruik van bijvoorbeeld website.nl/pricewatch/id/kleur etc is niet echt aan te bevelen.

Sorry? Als je dan toch al met SEO bezig bent dan is dat juist wél aan te bevelen en die querystring niet.

RobIII schreef op zaterdag 20 oktober 2012 @ 02:30:
[...]

Juist. Content is king. Rest is gepiel in de marge.

URL in combinatie met die content is wel belangrijk. Ook de positie van keywords binnen die URL en binnen de titel maakt verschil. Niet zo veel als de content zelf uiteraard, maar het is ook niet zomaar verwaarloosbaar.

[ Voor 30% gewijzigd door NMe op 20-10-2012 03:36 ]

[Soultaker]

Wolfboy schreef op vrijdag 19 oktober 2012 @ 17:42:
Javascript kan in (alle?) moderne browsers overigens tot 1024 bits werken

Echt niet. 53 bits is het maximum (52 bits + 1 impliciete bit). Dat de exponent tot 1023 gaat (niet 1024 — die waarde is gereserveerd voor non-numbers) betekent niet dat je ook 1023 bits precisie hebt.

Praktisch gezien kun je grote bitmasks wel makkelijk base-64 encoden; dan kun je 6 bits per karakter kwijt, wat aardig efficiënt is voor een URL. Dat is sowieso beter dan een decimale encoding, want die biedt maar ²log(10) ≈ 3,322 bits per karakter. Base-64 encoding is dus bijna twee keer zo efficiënt.

[ Voor 35% gewijzigd door Soultaker op 20-10-2012 04:14 ]

[jessy100]

RobIII schreef op zaterdag 20 oktober 2012 @ 02:30:
[...]

Juist. Content is king. Rest is gepiel in de marge.

Dit is waar, maar dat betekent niet dat de url geheel onbelangrijk is. Wij hebben op 't werk een Wordpress site draaien (ja, kromme vergelijking met T.net) maar daar was je link van site.nl/post="id" of site.nl/catagorie/naampagina net het laatste beetje CEO wat we nodig hadden om perfect vindbaar te zijn. dus het is niet onbelangrijk.

[mcDavid]

NMe schreef op zaterdag 20 oktober 2012 @ 03:35:
[...]

Sorry? Als je dan toch al met SEO bezig bent dan is dat juist wél aan te bevelen en die querystring niet.

volgens mij geldt dat alleen als er ook daadwerkelijk een hierarchische structuur bestaat.

/forum/topic/12345 is dus handig
/artikel/kleur/geel/maat/large/ slaat nergens op. Dat kon net zo goed /artikel/maat/large/kleur/geel zijn, wat weer duplicate content oplevert. Terwijl:
artikel?kleur=geel&maat=large en artikel?maat=large&kleur=geel wel gewoon als dezelfde pagina gezien wordt.