[JS] functie aanroep zo begrijpelijk?

[Mei]

Ik ben bezig mijn JS library vanaf scratch op te bouwen, aangezien ik die kwijt was door een crash. Ik ben nu aangekomen bij een functie met één parameter, maar wel eentje die behoorlijk ingewikkeld is. Ik heb er vooraf al gelijk een stukje documentatie bij geschreven, zodat het zowel voor mij als voor anderen die de lib eventueel zullen gebruiken duidelijk is hoe je die functie moet gebruiken. Wat ik me nu echter afvraag is of de opbouw van die parameter en/of de documentatie misschien duidelijker kan. Wat de parameter betreft: Ik maak mijn library met het woord 'flexibiliteit' in mijn achterhoofd. Ik vind het zelf erg handig als iets flexibel werkt, het kost echter wel meer moeite het te maken of het te implementeren, vandaar dat de boel nu ook een beetje ingewikkeld is geworden volgens mij. Maargoed, hier de code, ik hoor jullie commentaar graag aan

JavaScript:

/**
Init function for new transformations

@param oParams object Parameter object containing the transformation properties:
- selector string CSS selector, for instance 'h1', '.error' or '#content'
- styles array
- $object object No-name object containing all transformation properties
-- style string The style property to change
-- duration integer Duration of the transformation in milliseconds. Should be a multiple of 5.
-- transformation string Transformation type: 'linear', 'ease', 'easein' or 'easeout'
    Optional, defaults to 'linear'
-- values array The start and end values for the style property. Logically, the start value is the first value in the array.
-- unit string The unit to use for the style property, for instance 'px', 'em' or '%'.
    Optional
-- callback object Information about the function to call after the transformation has been completed
    Optional
--- function string Name of the function to call
--- arguments array Arguments to pass on to the function
--- timeout integer Time in milliseconds between completing the transformation and calling the callback function

Example:

$f.t.transform({
    selector:'#content',
    styles:[
        {
            style:'background-color',
            duration:45,
            transformation:'ease',
            values:[red, blue]
        },
        {
            style:'width',
            duration:175,
            values:[20, 50],
            unit:'%'
        }
    ]
    })

This example code will change the background-colour from red to blue and the width from 20% to 50% for the element with ID=='content'
*/
$f.t.transform=function(oParams)
{

}

[Verwijderd]

kick ass code... zo clean ook...

[Erkens]

JavaScript:

$f.t.

als er iets is wat ik ranzig/onduidelijk vind is het dat wel

[LeVortex]

in plaats van ze code af te zeiken zou je hem ook een stap de goede richting in kunnen geven

heb helaas niet zo veel verstand van dit, kan je er dus niet mee helpen

[Erkens]

LeVortex schreef op zondag 27 januari 2008 @ 00:00:
in plaats van ze code af te zeiken zou je hem ook een stap de goede richting in kunnen geven

heb helaas niet zo veel verstand van dit, kan je er dus niet mee helpen

Een stap in de goede richting? kwa code verder dan mijn opmerking niks op aan te merken, en aangezien ik niet weet waar die $f en t voor staan kan ik daar vrij moeilijk meer over zeggen.

Wat betreft de documentatie? tja, te veel. Daarnaast lijkt het me onhandig en vrijwel nutteloos om op deze manier CSS opnieuw uit te vinden. Hiervoor hebben we classes uitgevonden imo.

offtopic:
maar plaats voortaan een TR, en ga niet in het topic lopen blaten en zeggen dat ik hem zit af te zeiken, zeker niet als je er zelf toch geen verstand van hebt, hou dan gewoon je mond...

[Verwijderd]

Erkens schreef op zondag 27 januari 2008 @ 00:04:
Een stap in de goede richting? kwa code verder dan mijn opmerking niks op aan te merken, en aangezien ik niet weet waar die $f en t voor staan kan ik daar vrij moeilijk meer over zeggen.

Eens, zelfs als het gaat om een lib voor persoonlijk gebruik raad ik het gebruik van non-descriptive variable/function-names sterk af.

Daarnaast lijkt het me onhandig en vrijwel nutteloos om op deze manier CSS opnieuw uit te vinden. Hiervoor hebben we classes uitgevonden imo.

Met CSS classes alleen kun je natuurlijk geen transformaties schrijven

[Erkens]

Verwijderd schreef op zondag 27 januari 2008 @ 01:01:
Met CSS classes alleen kun je natuurlijk geen transformaties schrijven

Ow, dat soort transformaties als in "animatie". Mja, blijkt dus dat zelfs deze documentatie niet altijd duidelijk is voor andere developers Dat komt denk ik vooral doordat het zo'n grote lap tekst is, dan wil het nog wel eens dat je niet alles (goed) leest.

[_eXistenZ_]

No offence maar voor die transformaties hebben we Mootools toch?

[Mei]

_eXistenZ_ schreef op zondag 27 januari 2008 @ 10:37:
No offence maar voor die transformaties hebben we Mootools toch?

Alsof ik er wat van leer door alleen maar Mootools te gebruiken

$f is het parent object van mijn library. De f is de eerste letter van de naam van de lib. De t property is het object van de transformation. Ik kan het wel allemaal gaan uitschrijven, maar dan krijg je ellenlange dingen als librarynaam.modulenaam.method(). Het wordt ook weer irritant om dat telkens in te typen. Ik ben zelf ook altijd een voorstander van descriptive names, maar hier leek het me wat minder praktisch. Alle moduleobjecten komen nu dus aan $f te hangen met logischerwijs alle methods weer in de moduleobjecten. Ik wil nog wel de belangrijkste (zo niet alle) methods van de modules met een reference gelijk onder $f hangen, dus in plaats van $f.t.transform() $f.transform(). Is voor veelvuldig gebruik wat makkelijker. 'Private' methods kunnen dan gewoon onder $f.t blijven.

Deze module is inderdaad voor transformaties/animaties. Geen kant en klare effecten, gewoon een stukje code om vloeiend CSS properties aan te passen. Wil je dingen dus laten vergroten, dan kan je bijvoorbeeld tegelijkertijd de width en de height aanpassen.

[chem]

Verwijderd schreef op zondag 27 januari 2008 @ 01:01:
[...]

Met CSS classes alleen kun je natuurlijk geen transformaties schrijven

http://webkit.org/blog/130/css-transforms/ *kuch*

[Verwijderd]

chem schreef op zondag 27 januari 2008 @ 11:38:
[...]

http://webkit.org/blog/130/css-transforms/ *kuch*

Dat zijn nog steeds geen animaties (wat de TS bedoelt)

[Erkens]

Verwijderd schreef op zondag 27 januari 2008 @ 12:18:
[...]

Dat zijn nog steeds geen animaties (wat de TS bedoelt)

Dat staat ook niet in zijn documentatie dat er animaties mee gemaakt kunnen worden.

[Mei]

Geen ingewikkelde animaties, zoals met Flash mogelijk is (morphen bijvoorbeeld gaat niet lukken), maar je kan wel dingen over het beeld laten stuiteren of draaien (als in cirkelbewegingen maken).

Die Safari dingen zijn wel leuk, maar Webkit-only Mijn module moet veel meer effecten aan kunnen. Eigenlijk alles wat door CSS ondersteund wordt. Momenteel zal je daardoor in de praktijk bijvoorbeeld geen dingen kunnen laten draaien, want CSS3 is nog niet voldoende geïmplementeerd door alle browsermakers. Elke property met standaard decimale numerieke waardes kan sowieso aangepast worden met mijn library. Voor opacity moet ik net een klein beetje extra inbouwen (IE fix) en voor kleuren ook, aangezien je die in RGB, hex of voorgedefiniëerde waardes ('red', 'black', 'green', etc.) kan opgeven. Verder ondersteunt mijn module diverse overgangen: lineair, easing, ease in en ease out. Redelijk uitgebreid volgens mij, maar dat is ook de uitdaging

[SuperRembo]

Waarom geef je alle parameters door via 1 object? Waarom niet een selector en een styles parameter bijvoorbeeld?
Waarom moet je de style opgeven waar de animatie start, het lijkt me handiger als je uit gaat van de huidige style.

[Mei]

SuperRembo schreef op zondag 27 januari 2008 @ 15:36:
Waarom geef je alle parameters door via 1 object? Waarom niet een selector en een styles parameter bijvoorbeeld?

Via objectnotatie is gewoon het overzichtelijkst. Je moet gewoon erg veel info doorgeven (krijg je met die flexibiliteit) en dan is een object het makkelijkst in te voeren, zeker als je met optionele instellingen zit).

Waarom moet je de style opgeven waar de animatie start, het lijkt me handiger als je uit gaat van de huidige style.

Style properties die in je stylesheet gedefiniëerd zijn, zijn niet zo 1, 2, 3 op te vragen. Het DOM heeft er wel een manier voor en IE heeft weer zijn eigen manier, maar toen ik geprobeerd heb dit in te bouwen bij de vorige versie van mijn library lukt er ergens iets niet. Ik kan later wel even kijken of ik dit alsnog kan inbouwen, maar ik laat de mogelijkheid om handmatig een beginwaarde op te geven gewoon staan, is in sommige gevallen gewoon handig.

[SuperRembo]

Mei schreef op zondag 27 januari 2008 @ 15:49:
[...]

Via objectnotatie is gewoon het overzichtelijkst. Je moet gewoon erg veel info doorgeven (krijg je met die flexibiliteit) en dan is een object het makkelijkst in te voeren, zeker als je met optionele instellingen zit).

De objectnotatie kan inderdaad handig zijn als je veel optionele parameters hebt. De selector lijkt me niet optioneel, die kan prima de eerste parameter zijn. Zonder styles begin je ook niets, dus dat wordt dat de tweede parameter. Als je dan nog optionele parameters hebt, dan kan je die in een objectje gooien als derde parameter. Dat lijkt mij veel duidelijker.
Het is nog minder typen ook

[Mei]

Selector is inderdaad niet optioneel, maar een container element of een tagname opgeven (voor als de selector een className aangeeft) zijn is wel weer optioneel, vandaar dat ik het ook niet meer als losse parameter kan instellen. Ik heb deze twee extra opties er later bij bedacht, vandaar dat ze nog niet in de TS stonden, zal ik nu gelijk even doen:

- element string CSS selector, for instance 'h1', '.error' or '#content'
- container string CSS ID selector that points to the closest common parent of the elements to select, for instance '#content'
Optional (use only when selecting classNames)
- tagname string CSS tagName selector, for instance 'h1', 'div' or 'a'
Optional (use only when selecting classNames)

De styles kunnen inderdaad wel in een tweede parameter. Je krijgt dan wel meerdere objecten als parameters (selector wordt de eerste objectparam, styles de tweede), dus of het er echt overzichtelijker van wordt... Alle optionele parameters, zoals transformation-type, callbacks enzo kunnen niet in een derde parameter, omdat die uniek zijn voor elke transformation. De enige info die voor elke transformation gelijk is, is de info over de elementen waar ze op van toepassing zijn (dat selectorgedoe dus).

[benoni]

Erkens schreef op zondag 27 januari 2008 @ 00:04:
Daarnaast lijkt het me onhandig en vrijwel nutteloos om op deze manier CSS opnieuw uit te vinden. Hiervoor hebben we classes uitgevonden imo.

Het één sluit het ander niet uit natuurlijk. Je kunt vooraf een passende object class definiëren en de parameters in deze vorm meegeven aan de functie. Je kunt dan dezelfde class als basis gebruiken om in combinatie met een generieke parser functie de meegegeven waarden te kunnen valideren (of te kunnen voorzien van een default waarde (of DOM value) in 't geval dat ze afwezig zijn).

[Erkens]

benoni schreef op zondag 27 januari 2008 @ 16:34:
[...]


Het één sluit het ander niet uit natuurlijk. Je kunt vooraf een passende object class definiëren en de parameters in deze vorm meegeven aan de functie. Je kunt dan dezelfde class als basis gebruiken om in combinatie met een generieke parser functie de meegegeven waarden te kunnen valideren (of te kunnen voorzien van een default waarde (of DOM value) in 't geval dat ze afwezig zijn).

ehm, ik bedoelde meer het scheiden van logica en presentatie zelf zou ik in principe nooit een style aanpassen in mijn code, maar een className bijzetten oid.

[Mei]

Mijn code is er niet voor om CSS te vervangen, zoals ik al uitgelegd heb. Het is bedoeld om properties vloeiend van waarde te laten veranderen, wat gewoon niet met standaard CSS of door het toekennen van classNames kan, dat laatste is wel mogelijk, maar zo onhandig dat het gewoon niet te doen is.

[Erkens]

Mei schreef op zondag 27 januari 2008 @ 17:04:
Mijn code is er niet voor om CSS te vervangen, zoals ik al uitgelegd heb. Het is bedoeld om properties vloeiend van waarde te laten veranderen, wat gewoon niet met standaard CSS of door het toekennen van classNames kan, dat laatste is wel mogelijk, maar zo onhandig dat het gewoon niet te doen is.

Dat heb je idd gezegt (maar pas na mijn eerdere reactie) maar als iemand reageert op mijn posts mag ik daar toch wel even op doorgaan
Ik geef je groot gelijk als je zegt dat het met classNames niet handig/te doen is, dergelijke animaties. Daarvoor zal je toch idd losse properties moeten aanpassen.

[Mei]

Oh, kreeg het idee dat jullie nog niet helemaal doorhadden wat ik nou bedoelde, maar dat is dus wel duidelijk

[Mei]

Mei schreef op zondag 27 januari 2008 @ 16:17:
Selector is inderdaad niet optioneel, maar een container element of een tagname opgeven (voor als de selector een className aangeeft) zijn is wel weer optioneel, vandaar dat ik het ook niet meer als losse parameter kan instellen. Ik heb deze twee extra opties er later bij bedacht, vandaar dat ze nog niet in de TS stonden, zal ik nu gelijk even doen:

[...]


De styles kunnen inderdaad wel in een tweede parameter. Je krijgt dan wel meerdere objecten als parameters (selector wordt de eerste objectparam, styles de tweede), dus of het er echt overzichtelijker van wordt... Alle optionele parameters, zoals transformation-type, callbacks enzo kunnen niet in een derde parameter, omdat die uniek zijn voor elke transformation. De enige info die voor elke transformation gelijk is, is de info over de elementen waar ze op van toepassing zijn (dat selectorgedoe dus).

Ik ben nog steeds bezig met mijn library en was nog even dit topic aan het doorlezen om nuttige tips te vinden. Een andere reden om één object als parameter te gebruiken is dat het intern zeer gemakkelijk door te geven is. Je schuift alleen dat ene object door naar de volgende functie.

[Borizz]

Mei schreef op zaterdag 12 april 2008 @ 19:39:
[...]


Ik ben nog steeds bezig met mijn library en was nog even dit topic aan het doorlezen om nuttige tips te vinden. Een andere reden om één object als parameter te gebruiken is dat het intern zeer gemakkelijk door te geven is. Je schuift alleen dat ene object door naar de volgende functie.

Met jou redenering zou dus elke functie genoeg hebben aan 1 parameter. Voor iemand anders die dit gaat gebruiken is dat totaal onlogisch, want hij zal altijd de documentatie erbij moeten hebben om uit te vinden wat er nu aan die ene parameter meot worden meegegeven. Het kan een string zijn, een int, of een object... Maar wat voor object het is weet je dan nog steeds niet.

Volgens mij heb je echt meer aan parameters die al beschrijven wat voor data type of object je mee moet geven, een voorbeeld van 2 functies, mag jij vertellen welke nu direct duidelijk is:

JavaScript:

function concat(oParam) {
  return oParam.str1 + oParam.str2;
}

function concat(str1, str2) {
  return str1 + str2;
}

Nu is dit een heel simpel voorbeeld, maar je ziet aan de parameters al gelijk wat je als input aan de functie mee moet geven bij functie 2. Bij het eerste voorbeeld moet je al in de code van de functie kijken om te weten wat oParam nu eigenlijk inhoud.

[Mei]

Ik snap heel goed wat je bedoelt hoor Heb er zelf ook lang over getwijfeld. Het voordeel aan losse parameters is dat de notatie van de functie zelf wat logischer is. Het voordeel aan een enkel object als parameter is dat de aanroep (want de waarde wordt gewoon aan een ter plekke genoemde variabele toegekend) vanzelfsprekender is en dat ik intern niks hoef samen te voegen.

[Borizz]

Ja het kan in sommige gevallen makkelijker zijn, maar dan zou ik er tenminste aan meegeven wat voor type object je verwacht. Dus niet oParam (of dat type object heeft altijd dezelfde properties), maar oString of oTransformation bijvoorbeeld. Dan weet je dat het over een object van het type String of van het type Transformation gaat. Bij oParam weet je helemaal niets!

Nadeel met je 'universele' parameter is dat je eigenlijk altijd in je functie moet checken of de benodigde properties wel aanwezig zijn in het object dat wordt meegegeven. Bij een normale functie kan je ervan uitgaan dat de gedefinieerde parameters er ook zijn (oke dit hoeft niet zo te zijn bij javascript, maar de gebruiker weet in ieder geval wel wat er aan de functie meegegeven dient te worden, dus is het zijn eigen fout als hij dit niet doet).

[Mei]

Borizz schreef op zaterdag 12 april 2008 @ 20:51:
Ja het kan in sommige gevallen makkelijker zijn, maar dan zou ik er tenminste aan meegeven wat voor type object je verwacht. Dus niet oParam (of dat type object heeft altijd dezelfde properties), maar oString of oTransformation bijvoorbeeld. Dan weet je dat het over een object van het type String of van het type Transformation gaat. Bij oParam weet je helemaal niets!

Hmm, voor mezelf is het aardig logisch. Het is gewoon een object met parameters voor die functie. Nog niet bij nagedacht hoe dit voor anderen kan zijn. Opzich staat in de comments boven de betreffende functie wel uitgelegd wat het parameter object is en welke properties het moet hebben en van welke types deze properties dan weer zijn.

Nadeel met je 'universele' parameter is dat je eigenlijk altijd in je functie moet checken of de benodigde properties wel aanwezig zijn in het object dat wordt meegegeven. Bij een normale functie kan je ervan uitgaan dat de gedefinieerde parameters er ook zijn (oke dit hoeft niet zo te zijn bij javascript, maar de gebruiker weet in ieder geval wel wat er aan de functie meegegeven dient te worden, dus is het zijn eigen fout als hij dit niet doet).

Check jij altijd en overal of de parameters goed zijn meegegeven? Dat wordt meestal alleen gedaan bij gebruikersinvoer, omdat die invoer een live site/programma overhoop kan halen. Als een developer per ongeluk een waarde vergeet, dan ziet hij dat vaak wel aan het resultaat. Niet altijd even ideaal, dat klopt, maar anders blijf je controles op parameters intikken. Ik ben met deze library ook begonnen om te controleren op input, maar daar ben ik al snel mee gestopt. Je code wordt er gewoon een stuk lomper en trager door.

Dit is trouwens het nieuwste commentaar. Zoals je kan zien is de opbouw van de functie ook wat aangepast en de parameteropbouw is wat versimpeld.

JavaScript:

    /**
    Init function for new transformations
    
    @param oParams object Parameter object containing the transformation properties:
    - properties array An array containing information about all the properties to be effected
    -- name string The Javascript representation of the CSS property to change, for instance 'paddingLeft' or 'fontSize'.
    -- values array The start and end values for the style property. Logically, the start value is the first value in the array.
    -- unit string The unit to use for the style property, for instance 'px', 'em' or '%'.
        Optional
    - duration integer Duration of the transformation in milliseconds. Should be a multiple of 10, values are rounded.
        Optional, defaults to 10
    - transition string Transition type: 'linear', 'ease', 'easein' or 'easeout'
        Optional, defaults to 'linear'
    - callback string Name of the function to call
    - callbackArguments array Arguments to pass on to the function
    - callbackTimeout integer Time in milliseconds between completing the transformation and calling the callback function
    @param bReturnID boolean Whether to return a unique ID for this transformation (can be used to interrupt) or the Collection
    
    Example:
    
    flote.transform({
        {
            properties : [
                {
                    name : 'backgroundColor',
                    values : ['red', 'blue'],
                },
                {
                    name : 'width',
                    values : [100, 300],
                    unit : 'px'
                }
            ],
            duration : 50,
            transition : 'ease',
        }
    });
    
    This example code will change the background-colour from red to blue and the width from 20% to 50% for the element with ID=='content'
    */

[ Voor 32% gewijzigd door Mei op 12-04-2008 21:04 ]

[Borizz]

Het probleem blijft dat je niet in een oogopslag kan zien wat je mee moet geven, ook al staat er nog zoveel documentatie bij, het is gewoon onhandig als je niet aan de parameter kan zien wat voor type object je mee moet geven.

Nee ik check ook niet overal of alles goed is meegegeven, maar nogmaals het is gewoon duidelijker dat je in een oogopslag kan zien wat je meemoetgeven, dat voorkomt ook fouten. Een spelfout in een (property)key van jou object is moeilijker te traceren dan een parameter die niet meegegeven wordt. Daarbij komt dat je met de verschillende parameters eigenlijk zegt: ik verwacht deze parameters. Terwijl je met de parameter oParam eigenlijk zegt geef maar iets mee ik maak er wel wat van zolang het object Param niet gedefinieerd is.

Zolang je het object Param ergens definieerd is het geen probleem, maar zodra je de ene keer zo'n Param object hebt:

JavaScript:

oParam = {
            properties : [
                {
                    name : 'backgroundColor',
                    values : ['red', 'blue'],
                },
                {
                    name : 'width',
                    values : [100, 300],
                    unit : 'px'
                }
            ],
            duration : 50,
            transition : 'ease',
        } ;

En de volgende keer zoiets:

JavaScript:

oParam = {
            settings : [
                {
                    color : 'white',
                    test : [3, 5, 5, 6],
                },
                {
                    color : 'blue',
                    test : [4, 5, 6],
                }
            ],
            time : '13:00'
        } ;

Dan is daar natuurlijk geen touw aan vast te knopen wat oParam nou voorstelt als parameter. Dit lijkt me zeker voor een library niet echt handig (zeker niet als je er later nog wat aan wilt knutselen).

[ Voor 3% gewijzigd door Borizz op 12-04-2008 21:23 ]

[Mei]

Aah, nu krijg ik je door Jij bedoelt dus dat parameerobjecten opzich niet zo erg zijn, mits ze voor elke situatie maar een consistente opbouw hebben? Dus zoals jouw voorbeeld zegt moet een oParams hier dezelfde opbouw hebben als een oParams daar, maar als je oTransformation en oSettings gebruikt, dan kan dat dus wel?

[Borizz]

Inderdaad, dan weet je in ieder geval wat voor type object je mee moet geven aan de functie. Een Transformation object heeft andere properties dan een Settings object. Door daar onderscheid in te maken in de naamgeving en door deze objecten ook consistent op dezelfde manier (dus met dezelfde properties) te gebruiken zal de library in ieder geval transparanter worden om mee te werken.

En dan nog zou je misschien na kunnen denken om meerdere van deze objecten aan een functie mee te geven in verschillende parameters:

JavaScript:

function doSomething(oTransformation, oSetting, oString) {
     // do something with the passed objects.
}