[JS] Scriptlogica

[Mei]

Ik ben bezig met een Javascript library. De hele library werkt intern met zogenaamde Collections: arrays die HTML elementen bevatten (dus de nodes). Werkt opzich erg handig, maar nu zit ik met één dingetje. Met Collection.get(first, last) kan je een selectie van de elementen uit de Collection maken. Collection.first() en Collection.last() zijn ook dergelijke functies. Nou returnen deze 3 functions heel mooi een Collection met 1 of meerdere elementen (hangt er dus een beetje af van welke selectie je maakt bij get() ). Maarrrr.... Wat nou als je puur een bepaald HTML element terug wil en geen Collection? Ik zit te brainstormen over een praktische manier om dit te bereiken. Ik kan natuurlijk extra functies maken (hup, weer drie erbij) of aan alle functies een extra parameter geven om te bepalen of de retourwaarde een Collection of een HTML element moet zijn.

Wat is in dit geval een logische - en vooral praktische - oplossing?

[Gomez12]

Wat ik zou doen is gewoon niets in je core veranderen, en een 2e library maken genaamd "html" of iets in die richting die je huidige library extend, en daar dan dus de functies in aanmaken...

Intern werk je met je collections, wil je je collections omzetten naar iets anders dan moet je even een extra library includen.

Op deze manier houd je je core library schoon, en als je straks animatie / ajax effecten wilt hebben kan je hier ook weer losse library's van maken. Zodat iemand niet in 1x 200kb JS moet inladen, maar zelf kan uitkiezen wat hij nodig heeft...

P.S. Let wel op met het onderhoud, dit wordt hierdoor wel enigszins bemoeilijkt als je core nog niet 99% vastligt. Want je moet op 2 plekken wijzigen dan.

P.P.S. nieuwsgierigheidsvraagje : Waarom een eigen JS lib maken, wat voldoet er niet aan de huidige? Kijk alleen voor intern gebruik kan ik het begrijpen...

[ Voor 21% gewijzigd door Gomez12 op 01-03-2008 20:42 ]

[Verwijderd]

FF een recap, dat ik t goed begrijp:

JavaScript:

Collection.get(3,6); // returnt het 4e t/m 7e element in de collectie als een collectie
Collection.first() // returnt het 1e element als een collectie
Collection.last() // returnt het laatste element als een collectie

first() en last() zouden wat mij betreft geen collection moeten returnen maar een enkel element, zoals Array.pop() en Array.shift() ook niet een array returnen.
get() zou je natuurlijk zo uit kunnen breiden dat het 2e argument optioneel is. Collection.get(4) returnt dan sec het 5e element (en dan niet in een collection). Collection.get(4,4) moet natuurlijk wel gewoon een collection returnen. Let er wel op dat je dit soort variabel gedrag goed documenteert!

[Verwijderd]

Collection.get ( first, last ) is gewoon een rare implementatie van een method voor een collection. In andere talen kun je ook geen "range" opgeven. Ik zou dan zeggen, maak een methode Collections.getRange ( first, last ), maar ook dat is raar. Een Collection heeft over het algemeen geen vaste volgorde. Maak er dan een ArrayList van, of een Vector.

Ik heb er persoonlijk een bloedhekel aan als ik documentatie moet raadplegen om te zien wat dergelijke "standaard" classes en methods precies doen.

[Mei]

Gomez12 schreef op zaterdag 01 maart 2008 @ 20:40:
Wat ik zou doen is gewoon niets in je core veranderen, en een 2e library maken genaamd "html" of iets in die richting die je huidige library extend, en daar dan dus de functies in aanmaken...

Intern werk je met je collections, wil je je collections omzetten naar iets anders dan moet je even een extra library includen.

Op deze manier houd je je core library schoon, en als je straks animatie / ajax effecten wilt hebben kan je hier ook weer losse library's van maken. Zodat iemand niet in 1x 200kb JS moet inladen, maar zelf kan uitkiezen wat hij nodig heeft...

P.S. Let wel op met het onderhoud, dit wordt hierdoor wel enigszins bemoeilijkt als je core nog niet 99% vastligt. Want je moet op 2 plekken wijzigen dan.

Waarom volgens jou een externe library? In mijn ogen is het een redelijk belangrijke feature, aangezien je ook buiten de library om HTML nodes moet kunnen bewerken. Als je dan met de lib iets wil selecteren moet het bewerken van standaard properties wel mogelijk zijn.

P.P.S. nieuwsgierigheidsvraagje : Waarom een eigen JS lib maken, wat voldoet er niet aan de huidige? Kijk alleen voor intern gebruik kan ik het begrijpen...

Het is voor mij voornamelijk een leerproject. Misschien ga ik het nog gebruiken, maar dat weet ik niet. Heb tot nu toe al wel wat dingen gezien die ik andere bekende libraries niet naar mijn wens gedaan worden. Ik kijk nu voornamelijk naar jQuery en Prototype om te zien hoe ze daarbij dingen opgelost hebben, maar heb bij sommige dingen dus expres besloten het anders te doen.

Verwijderd schreef op zaterdag 01 maart 2008 @ 21:36:
FF een recap, dat ik t goed begrijp:

JavaScript:

Collection.get(3,6); // returnt het 4e t/m 7e element in de collectie als een collectie
Collection.first() // returnt het 1e element als een collectie
Collection.last() // returnt het laatste element als een collectie

Bingo!

first() en last() zouden wat mij betreft geen collection moeten returnen maar een enkel element, zoals Array.pop() en Array.shift() ook niet een array returnen.
get() zou je natuurlijk zo uit kunnen breiden dat het 2e argument optioneel is. Collection.get(4) returnt dan sec het 5e element (en dan niet in een collection). Collection.get(4,4) moet natuurlijk wel gewoon een collection returnen. Let er wel op dat je dit soort variabel gedrag goed documenteert!

Ik heb er zeker aan gedacht om first() en last() gewoon een element te laten retourneren, maar dan zit je er weer mee dat je dat element niet meer de methods van de library heeft, want het is geen Collection. Daarom had ik toch besloten er Collections van te maken. Jouw oplossing met de parameters is opzich wel leuk, maar dan zou ik misschien zelf een derde parameter laten opgeven om te forceren dat het geen Collection is. Minder handig, maar wel een helderdere oplossing, althans, zoals ik het nu zie Als jullie daar iets op tegen hebben, dan hoor ik het graag

Verwijderd schreef op zaterdag 01 maart 2008 @ 21:41:
Collection.get ( first, last ) is gewoon een rare implementatie van een method voor een collection. In andere talen kun je ook geen "range" opgeven. Ik zou dan zeggen, maak een methode Collections.getRange ( first, last ), maar ook dat is raar. Een Collection heeft over het algemeen geen vaste volgorde. Maak er dan een ArrayList van, of een Vector.

De volgorde van de Collection is de volgorde van de elementen in de pagina. Niks randoms dus.

Ik heb er persoonlijk een bloedhekel aan als ik documentatie moet raadplegen om te zien wat dergelijke "standaard" classes en methods precies doen.

Kan ik me goed in vinden. Aan de andere kant... Wat is standaard? Elk systeem implementeert dingen ook op een eigen manier. Dat is waarom systemen verschillen van elkaar. Ik probeer nu een oplossing te vinden die zowel intuïtief/logisch is en die efficiënt/gemakkelijk werkt. En da's best lastig soms

[Gomez12]

Mei schreef op zaterdag 01 maart 2008 @ 22:08:
[...]
Waarom volgens jou een externe library? In mijn ogen is het een redelijk belangrijke feature, aangezien je ook buiten de library om HTML nodes moet kunnen bewerken. Als je dan met de lib iets wil selecteren moet het bewerken van standaard properties wel mogelijk zijn.

In mijn ogen is het juist een standaard feature, maar als jij er nu pas achter komt dat je het wilt en omdat je je collections raar hebt staan dacht ik dat jij er iets heel anders mee wilde dan ik ooit zou willen... En dan ging ik uit van, nog niet aan gedacht dus geen standaard feature, dus niet in de core...

[...]
maar dan zou ik misschien zelf een derde parameter laten opgeven om te forceren dat het geen Collection is. Minder handig, maar wel een helderdere oplossing, althans, zoals ik het nu zie Als jullie daar iets op tegen hebben, dan hoor ik het graag

Dus als ik een.first aanroep en ik wil echt het 1e element hebben dan moet ik 3 parameters opgeven, nouja het is tenminste anders dan de andere library's ( en daarom onhandiger, iets als .first verwachten mensen gewoon 1 werking van )

Elk systeem implementeert dingen ook op een eigen manier. Dat is waarom systemen verschillen van elkaar. Ik probeer nu een oplossing te vinden die zowel intuïtief/logisch is en die efficiënt/gemakkelijk werkt.

Ach, basale dingen zijn in 90% van de systemen op dezelfde manier geimplementeert, dat heet gewoon good practices. Als jij ergens over twijfelt hoe je het wil gaan doen, en bestaande libs doen het op manier x doe het dan ook maar op manier x, want als jij onzeker bent of manier y handig is dan is het voor een gebruiker absoluut niet meer duidelijk. De andere libs zijn hier allemaal al tegenaan gelopen.
Als jij denkt het ei van columbus te hebben gevonden, dan gewoon op jouw manier implementeren, maar als je twijfelt dan gewoon de standaard pakken...

[Mei]

Gomez12 schreef op zaterdag 01 maart 2008 @ 23:12:
[...]

Dus als ik een.first aanroep en ik wil echt het 1e element hebben dan moet ik 3 parameters opgeven, nouja het is tenminste anders dan de andere library's ( en daarom onhandiger, iets als .first verwachten mensen gewoon 1 werking van )

Je ehbt helemaal gelijk. Onhandiger, maar wel consistenter (dezelfde parameters hebben niet een verschillende werking). Denk dat ik dan toch maar voor de 'onhandige' methode ga.

[...]

Ach, basale dingen zijn in 90% van de systemen op dezelfde manier geimplementeert, dat heet gewoon good practices. Als jij ergens over twijfelt hoe je het wil gaan doen, en bestaande libs doen het op manier x doe het dan ook maar op manier x, want als jij onzeker bent of manier y handig is dan is het voor een gebruiker absoluut niet meer duidelijk. De andere libs zijn hier allemaal al tegenaan gelopen.
Als jij denkt het ei van columbus te hebben gevonden, dan gewoon op jouw manier implementeren, maar als je twijfelt dan gewoon de standaard pakken...

Ook hier helemaal gelijk. Het punt is een beetje dat ik deze library niet zozeer maak om een library te hebben, maar om er eentje te maken. Vandaar dat ik met alles zit te denken hoe ik het ga aanpakken. Natuurlijk ben ik niet de eerste die zoiets maakt en als je zegt dat ik het wiel opnieuw aan het uitvinden ben, dan is dat ook wel zo, maar het is een goede (en leuke) manier om beter met JS om te leren gaan.

[Sendy]

Je kan ook een methode maken die een Collection met een enkel element naar een HTML element omvormt. Maar ja, dan moet je daar weer op de return code letten

Je kan denk ik ook je Collection methodes prototypen in de HTML elementen.

[ Voor 40% gewijzigd door Sendy op 02-03-2008 00:29 ]

[Mei]

Sendy schreef op zondag 02 maart 2008 @ 00:25:
Je kan denk ik ook je Collection methodes prototypen in de HTML elementen.

Wat bedoel je precies? Geen Collections gebruiken, maar de huidige Collection prototype toepassen op HTML elementen? Het nadeel is dan een beetje dat je dus elementen weer niet gegroepeerd hebt, wat juist mijn bedoeling was.

[Sendy]

Ik denk dat ik dat bedoelde inderdaad. Maar nu ik er nog eens over nadenk lijkt 't me toch niet zomaar te doen; je moet dan toch ook 2x de hele set functies maken (eens voor een Collection, anders voor de HTML elementen.)

[Bosmonster]

Mei schreef op zaterdag 01 maart 2008 @ 22:08:
[...]

De volgorde van de Collection is de volgorde van de elementen in de pagina. Niks randoms dus.

Wat Cheatah bedoelt is dat Collection een vrij gebruikelijke naam is voor een NIET-volgorde gebonden lijst. Dat jouw implementatie dus ineens iets heel anders is is erg verwarrend voor andere developers die er mogelijk mee zouden moeten werken.

[Mei]

Dan noem ik het wat anders Is zo te doen. Wat is volgens jullie een betere naam?