[alg] Slechtste programmeervoorbeelden deel 4

[jbdeiman]

Wooow... Best een bout code dan, degene die het gemaakt heeft kent in elk geval de ctrl+v en ctrl+c knoppen wel goed zeg.
Adrestypen kan je net zo goed online (in een database) koppelen en met AJAX ophalen. Scheelt je enorme bakken code op cliënt side, en je kan je code heel eenvoudig uitbreiden met een nieuw land, nieuwe adres opmaak.
Hoeft de cliënt ook geen js file in te laden die zo groot is.

[Woy]

jbdeiman schreef op woensdag 09 september 2009 @ 10:22:
Wooow... Best een bout code dan, degene die het gemaakt heeft kent in elk geval de ctrl+v en ctrl+c knoppen wel goed zeg.
Adrestypen kan je net zo goed online (in een database) koppelen en met AJAX ophalen. Scheelt je enorme bakken code op cliënt side, en je kan je code heel eenvoudig uitbreiden met een nieuw land, nieuwe adres opmaak.
Hoeft de cliënt ook geen js file in te laden die zo groot is.

Dat er het een en ander te optimaliseren valt is wel duidelijk, maar om het dan maar meteen met AJAX te doen hoeft ook niet natuurlijk.

Je kunt perfect een JS file laten genereren met de landen in een array bijvoorbeeld. Als je toch altijd alle landen nodig hebt op de client, heeft het niet zoveel meerwaarde om die later via AJAX op te halen, want je moet dan nog net zo goed alle waardes oversturen.

[jbdeiman]

@Woy
Dat wel, maar het is voor de onderhoudbaarheid van de code veel eenvoudiger als je die laat genereren. Vandaar mijn opmerking over AJAX. Je kan wel 1 grote array maken, maar je moet in die array ook meteen de adresopmaak koppelen aan het land.
Je krijgt zo:
a) Behoorlijke overhead in je code
b) Nog steeds een behoorlijk JavaScript bestand
c) Code waarbij niets werkt als JS is uitgeschakeld, dus je ook niets te zien krijgt van een dropdownlijst.

Je moet hoe dan ook al dat soort gegevens (ook adres opmaak) toch al aan de serverkant controleren, omdat de inputcontrole op de client kant niet waterdicht is. Waarom dan een dubbele controle toepassen en dubbele code (JS en PHP) maken, die je bij een wijziging ook nog eens beiden aan moet passen? Lijkt mij sowieso niet handig, vandaar dus mijn opmerking.

Alles in een JS array opslaan (cliënt side) en ook nog in PHP (bijvoorbeeld) controleren (Server Side) omdat dat nu eenmaal nodig is, wegens het niet waterdicht zijn van de JS controle, is gewoon dubbel werk en ook lastiger te onderhouden.
Ik zeg niet dat het dubbel doen fout is, maar het kan gewoon vanuit 1 systeem gaan werken, dat is qua onderhoudbaarheid van je code stukken eenvoudiger. Vantevoren misschien wat lastiger/ ingewikkelder/ meer werk, maar het helpt je uiteindelijk je acties sneller te kunnen uitvoeren.

[.oisyn]

jbdeiman schreef op woensdag 09 september 2009 @ 11:01:
@Woy
Dat wel, maar het is voor de onderhoudbaarheid van de code veel eenvoudiger als je die laat genereren. Vandaar mijn opmerking over AJAX. Je kan wel 1 grote array maken, maar je moet in die array ook meteen de adresopmaak koppelen aan het land.
Je krijgt zo:
a) Behoorlijke overhead in je code

Nee, want je moet het sowieso doen.

b) Nog steeds een behoorlijk JavaScript bestand

Volgens mij valt dat best mee...

c) Code waarbij niets werkt als JS is uitgeschakeld, dus je ook niets te zien krijgt van een dropdownlijst.

Als JS is uitgeschakeld werkt AJAX ook niet he.

Wat de rest van je verhaal betreft: ik ben geen webhippie, maar zijn er niet systemen waarin je met 1 taal werkt voor zowel server- als clientside, waarbij de clientside code vertaald wordt naar javascript als die taal niet js is?

[Woy]

jbdeiman schreef op woensdag 09 september 2009 @ 11:01:
@Woy
Dat wel, maar het is voor de onderhoudbaarheid van de code veel eenvoudiger als je die laat genereren. Vandaar mijn opmerking over AJAX. Je kan wel 1 grote array maken, maar je moet in die array ook meteen de adresopmaak koppelen aan het land.
Je krijgt zo:
a) Behoorlijke overhead in je code
b) Nog steeds een behoorlijk JavaScript bestand
c) Code waarbij niets werkt als JS is uitgeschakeld, dus je ook niets te zien krijgt van een dropdownlijst.

Je moet hoe dan ook al dat soort gegevens (ook adres opmaak) toch al aan de serverkant controleren, omdat de inputcontrole op de client kant niet waterdicht is. Waarom dan een dubbele controle toepassen en dubbele code (JS en PHP) maken, die je bij een wijziging ook nog eens beiden aan moet passen? Lijkt mij sowieso niet handig, vandaar dus mijn opmerking.

Alles in een JS array opslaan (cliënt side) en ook nog in PHP (bijvoorbeeld) controleren (Server Side) omdat dat nu eenmaal nodig is, wegens het niet waterdicht zijn van de JS controle, is gewoon dubbel werk en ook lastiger te onderhouden.
Ik zeg niet dat het dubbel doen fout is, maar het kan gewoon vanuit 1 systeem gaan werken, dat is qua onderhoudbaarheid van je code stukken eenvoudiger. Vantevoren misschien wat lastiger/ ingewikkelder/ meer werk, maar het helpt je uiteindelijk je acties sneller te kunnen uitvoeren.

Ik snap niet wat AJAX hier aan oplossing voor bied? Of je nu direct een JS file genereert met de juiste waardes, of via AJAX alsnog de gegevens doorstuurt, waarna je ze ook gewoon in JS moet behandelen. Je zult sowieso je server checks moeten hebben, daar kom je op geen enkele manier onder uit. Ook aan de client kant wil je nog checks hebben om de responsivness zo goed mogelijk te houden.

a) Behoorlijke overhead in je code

Hoezo is een gegenereerde lijst in Javascript dan dat je het via AJAX overstuurt? Ik zie het verschil niet

b) Nog steeds een behoorlijk JavaScript bestand

Of je nu een groot javascript bestand hebt, of een groot XML/JSON/whatever bestand wat je via AJAX opvraagt haalt ook niet zo veel uit. Je hebt die gegevens blijkbaar nodig op de client, dus op de een of andere manier moet je die daar krijgen. Natuurlijk moet je het niet zoals in het voorbeeld x keer defineren.

c) Code waarbij niets werkt als JS is uitgeschakeld, dus je ook niets te zien krijgt van een dropdownlijst.

Ja en AJAX werkt wel lekker als je geen javascript hebt

edit:

Grrr .oisyn

[!null]

@jbdeiman, je argumenten zijn al onderuit gehaald.
Maar wat bedoel je met code generatie? Je gebruikt dan een bepaalde studio om AJAX code te genereren? Op basis van XML-tjes ofzo? Of bedoel je dat de inhoud voor de dropdown wordt gegenereerd op basis van de database en je het dus via de database kan onderhouden?

[Domdo]

ik denk dat API's á la GWT(http://code.google.com/webtoolkit/) bedoelt

[jbdeiman]

@!null
Precies wat ik bedoel is het laatste wat je noemt, je dropdown e.d. wordt gegenereerd vanuit je database, aanpassingen / toevoegingen zijn gauw gedaan. Je kan er evt. ook voor kiezen om de code verder (op het steeds opnieuw declareren van die JS variabelen na) zo te laten en die JS array vanuit je database te genereren natuurlijk.
Argumenten onderuitgehaald zie ik niet zo, en daar gaat het ook niet om. Het is geen wedstrijdje wie er nu wel of geen gelijk heeft he!

@Woy

Woy schreef op woensdag 09 september 2009 @ 11:10:
Ik snap niet wat AJAX hier aan oplossing voor bied? Of je nu direct een JS file genereert met de juiste waardes, of via AJAX alsnog de gegevens doorstuurt, waarna je ze ook gewoon in JS moet behandelen. Je zult sowieso je server checks moeten hebben, daar kom je op geen enkele manier onder uit. Ook aan de client kant wil je nog checks hebben om de responsivness zo goed mogelijk te houden.

Maar moet je dan zowel in PHP als in Javascript handmatig je arrays intikken? Is ook dubbel werk met onderhoud he, daar doel ik op. Als je dit laat genereren vanuit PHP dan hoef je maar op 1 locatie een nieuwe locatie/ wijziging te doen, om het in 1 keer door je hele systeem aan te passen.
AJAX bied een oplossing dat je maar een 1 malige controleconstructie hoeft te schrijven en wel server side. De controle vind ook meteen al server side plaats vanuit AJAX, het is dan niet nodig om de gehele controle ook nog eens in JS te schrijven. Daarom dus, het is gewoon dubbel werk om een hele controle structuur in JS op te zetten, als je het ook in PHP (of ASP, of wat voor taal dan ook) kan doen.
Daarin kan AJAX een bult meerwaarde bieden.
Wil jij bij een nieuwe controle / nieuwe adres opmaak mogelijkheid, zowel een PHP code voor de controle schrijven als een JS code, of wil je slechts in PHP een nieuwe controle maken die in 1 keer aangeroepen kan worden?

Woy schreef op woensdag 09 september 2009 @ 11:10:
Hoezo is een gegenereerde lijst in Javascript dan dat je het via AJAX overstuurt? Ik zie het verschil niet

Zei ik dat? Dat bedoel ik niet, maar overhead is meer in de zin van die dubbele controle schrijven (zie reactie hierboven deze quote)

Woy schreef op woensdag 09 september 2009 @ 11:10:
Of je nu een groot javascript bestand hebt, of een groot XML/JSON/whatever bestand wat je via AJAX opvraagt haalt ook niet zo veel uit. Je hebt die gegevens blijkbaar nodig op de client, dus op de een of andere manier moet je die daar krijgen. Natuurlijk moet je het niet zoals in het voorbeeld x keer defineren.

Het ging mij niet zozeer om de overhead in het meegeven van die array, of al die waarden, maar om de overhead in de controle. Als je in JS ook de controle wilt doen, ben je bezig (mijns inziens) met het schrijven van dubbele code, 1x in PHP en 1x in JS, wat je dus met AJAX kan afvangen. Die overhead bedoelde ik. Sorry als dat niet helemaal duidelijk was

Woy schreef op woensdag 09 september 2009 @ 11:10:
Ja en AJAX werkt wel lekker als je geen javascript hebt

Ik dacht toch echt dat ik aangaf dat alleen JS controle niet goed is. Je genereert de dropdown vanuit je database/ PHP code. Vervolgens kan je (indien JS aan staat) live controleren of de inhoud van een veld klopt, staat die niet aan, dan controleer je het na het posten.
Is prima werkbaar, je hebt wel de dubbele controle waar je nu ook voor kiest, maar het is veel generieker.

[ Voor 66% gewijzigd door jbdeiman op 09-09-2009 12:16 ]

[.oisyn]

jbdeiman schreef op woensdag 09 september 2009 @ 11:47:
Je kan er evt. ook voor kiezen om de code verder (op het steeds opnieuw declareren van die JS variabelen na) zo te laten en die JS array vanuit je database te genereren natuurlijk.

Dat is toch precies wat Woy zei in eerste instantie?

Woy schreef op woensdag 09 september 2009 @ 10:50:
Je kunt perfect een JS file laten genereren met de landen in een array bijvoorbeeld. Als je toch altijd alle landen nodig hebt op de client, heeft het niet zoveel meerwaarde om die later via AJAX op te halen, want je moet dan nog net zo goed alle waardes oversturen.

[ Voor 53% gewijzigd door .oisyn op 09-09-2009 11:52 ]

[flashin]

Ik vind toepassingen van 'AJAX' vaak echt een dailywtf... Hoe onnozel mensen daar mee omgaan.
Als je je website volledig baseert op AJAX events, hoe handel je bijv. timeouts af? Mensen denken dat die niet kunnen voorkomen en handelen dat bijna nooit af.
Ik vind dat een site moet kunnen werken zonder en dat AJAX verder alleen complementair is.

[jbdeiman]

flashin schreef op woensdag 09 september 2009 @ 12:07:
Ik vind toepassingen van 'AJAX' vaak echt een dailywtf... Hoe onnozel mensen daar mee omgaan.
Als je je website volledig baseert op AJAX events, hoe handel je bijv. timeouts af? Mensen denken dat die niet kunnen voorkomen en handelen dat bijna nooit af.
Ik vind dat een site moet kunnen werken zonder en dat AJAX verder alleen complementair is.

Daarom geef ik ook aan dat die niet volledig op AJAX moet bouwen, maar de controle eigenlijk server side moet plaats vinden. Dit kan je live doen (mits ondersteund) of gewoon na posten. Als AJAX niet werkt, werkt (waarschijnlijk) JavaScript controle niet. Je hoeft dan echter maar 1 maal de controle functionaliteiten te schrijven en op 1 plek aan te passen.

Een volledige website op AJAX ben ik zeker geen fan van, het kan wel een en ander toevoegen aan je websitefunctionaliteiten. Echter zonder AJAX/ JS ondersteuning moet je website ook werken. JavaScript is mijns insziens een leuke manier om extra functionaliteiten/ gelikte acties toe te voegen op je website, maar moet geen doel op zich zijn. Zonder JS ondersteuning moet je website gewoon functioneren, maar moeten misschien wat vaker hele pagina's herladen worden, of bezoekers wachten op controle van ingevoerde gegevens tot ze op de verzendknop drukken.

[mcdronkz]

jbdeiman schreef op woensdag 09 september 2009 @ 12:19:
[...]

Daarom geef ik ook aan dat die niet volledig op AJAX moet bouwen, maar de controle eigenlijk server side moet plaats vinden. Dit kan je live doen (mits ondersteund) of gewoon na posten. Als AJAX niet werkt, werkt (waarschijnlijk) JavaScript controle niet. Je hoeft dan echter maar 1 maal de controle functionaliteiten te schrijven en op 1 plek aan te passen.

Een volledige website op AJAX ben ik zeker geen fan van, het kan wel een en ander toevoegen aan je websitefunctionaliteiten. Echter zonder AJAX/ JS ondersteuning moet je website ook werken. JavaScript is mijns insziens een leuke manier om extra functionaliteiten/ gelikte acties toe te voegen op je website, maar moet geen doel op zich zijn. Zonder JS ondersteuning moet je website gewoon functioneren, maar moeten misschien wat vaker hele pagina's herladen worden, of bezoekers wachten op controle van ingevoerde gegevens tot ze op de verzendknop drukken.

Unobtrusive JavaScript zijn de woorden waar je naar opzoek bent

[Haan]

Vanmiddag schoot me nog eentje te binnen die ik vorig jaar een keer tegenkwam op internet, maar kan deze niet meer terugvinden. Het ging om een property om te kijken of er op Windows XP, of op Vista gedraaid werd, ivm andere UI layout o.i.d. Deze check werd gedaan door op te vragen wat het gebruikte systeem font is..

C#:

public bool IsVista
{
      get
      {
           return System.Drawing.SystemFonts.MenuFont.Name == "Segoe UI";
      }
}

Wat is er mis met Environment.OSVersion zou je dan zeggen

[RayNbow]

Haan schreef op zondag 20 september 2009 @ 17:05:
Vanmiddag schoot me nog eentje te binnen die ik vorig jaar een keer tegenkwam op internet, maar kan deze niet meer terugvinden. Het ging om een property om te kijken of er op Windows XP, of op Vista gedraaid werd, ivm andere UI layout o.i.d. Deze check werd gedaan door op te vragen wat het gebruikte systeem font is..

C#:

public bool IsVista
{
      get
      {
           return System.Drawing.SystemFonts.MenuFont.Name == "Segoe UI";
      }
}

Wat is er mis met Environment.OSVersion zou je dan zeggen

* RayNbow draait Vista met Tahoma

[Maghiel]

jbdeiman schreef op woensdag 09 september 2009 @ 12:19:
[...]

Daarom geef ik ook aan dat die niet volledig op AJAX moet bouwen, maar de controle eigenlijk server side moet plaats vinden. Dit kan je live doen (mits ondersteund) of gewoon na posten. Als AJAX niet werkt, werkt (waarschijnlijk) JavaScript controle niet. Je hoeft dan echter maar 1 maal de controle functionaliteiten te schrijven en op 1 plek aan te passen.

Een volledige website op AJAX ben ik zeker geen fan van, het kan wel een en ander toevoegen aan je websitefunctionaliteiten. Echter zonder AJAX/ JS ondersteuning moet je website ook werken. JavaScript is mijns insziens een leuke manier om extra functionaliteiten/ gelikte acties toe te voegen op je website, maar moet geen doel op zich zijn. Zonder JS ondersteuning moet je website gewoon functioneren, maar moeten misschien wat vaker hele pagina's herladen worden, of bezoekers wachten op controle van ingevoerde gegevens tot ze op de verzendknop drukken.

Ja nogal wiedes, als JavaScript uit staat werkt AJAX niet idd
(en uberhaupt ajax, ik heb het nooit begrepen, we deden het allang alleen gaf iemand er een naampje aan en was het ineens HET ding om te doen )

Validatie aan client kant is een leuk hulpmiddel, en kan de gebruiker meer gemak geven. Maar het kan niet de echte validatie voor input in je systeem zijn. Als je als javascript ingeschakeld is puur op client side validatie vertrouwd.....vul zelf maar aan

[ Voor 5% gewijzigd door Maghiel op 24-09-2009 03:41 ]

[roy-t]

jbdeiman schreef op woensdag 09 september 2009 @ 12:19:
[...]

Daarom geef ik ook aan dat die niet volledig op AJAX moet bouwen, maar de controle eigenlijk server side moet plaats vinden. Dit kan je live doen (mits ondersteund) of gewoon na posten. Als AJAX niet werkt, werkt (waarschijnlijk) JavaScript controle niet. Je hoeft dan echter maar 1 maal de controle functionaliteiten te schrijven en op 1 plek aan te passen.

Een volledige website op AJAX ben ik zeker geen fan van, het kan wel een en ander toevoegen aan je websitefunctionaliteiten. Echter zonder AJAX/ JS ondersteuning moet je website ook werken. JavaScript is mijns insziens een leuke manier om extra functionaliteiten/ gelikte acties toe te voegen op je website, maar moet geen doel op zich zijn. Zonder JS ondersteuning moet je website gewoon functioneren, maar moeten misschien wat vaker hele pagina's herladen worden, of bezoekers wachten op controle van ingevoerde gegevens tot ze op de verzendknop drukken.

De ASP.Net validation controls doen exact dat altijd 2 manieren van controleren. Zijn vast andere 'ajax' frameworks die dat ook kunnen.Scheelt een hoop werk

[!null]

Ik ben benieuwd hoe software voor blinden en dergelijke doorgaans om kan gaan met ongein zoals AJAX.

Maghiel schreef op donderdag 24 september 2009 @ 03:40:
(en uberhaupt ajax, ik heb het nooit begrepen, we deden het allang alleen gaf iemand er een naampje aan en was het ineens HET ding om te doen )

Ben ik toch niet met je eens, data heen en weer smijten met XML, en dan met javascript je pagina opnieuw invullen zonder te herhalen was nou niet echt gebruikelijk. Dat het maar een naampje is, dat het hip is en dat het vroeger al kon ben ik wel met je eens.

[ Voor 9% gewijzigd door !null op 24-09-2009 08:47 ]

[Verwijderd]

!null schreef op dinsdag 08 september 2009 @ 16:40:
Whaha. En "Christmas Island", die kende ik nog niet.
Ik verwacht dat de rest van de implementatie ook niet veel soeps is.

Is dat niet naast de paaseiland?

[kenneth]

Maghiel schreef op donderdag 24 september 2009 @ 03:40:
[...]


Ja nogal wiedes, als JavaScript uit staat werkt AJAX niet idd
(en uberhaupt ajax, ik heb het nooit begrepen, we deden het allang alleen gaf iemand er een naampje aan en was het ineens HET ding om te doen )

Nee, het was opeens HET ding om te doen en daarom was het makkelijk om het een naampje te geven om niet steeds te hoeven uitleggen wat je nou bedoelt

[Erkens]

kenneth schreef op donderdag 24 september 2009 @ 09:03:
[...]
Nee, het was opeens HET ding om te doen en daarom was het makkelijk om het een naampje te geven om niet steeds te hoeven uitleggen wat je nou bedoelt

Alleen zo jammer dat er meestal geen XML gebruiken of niet asynchroon werken en het dan alsnog AJAX blijven noemen Heb het altijd een waardeloze naam gevonden, maargoed "iedereen" weet wat je ermee bedoeld en daar gaat het om

[kenneth]

Juist Ik vind e-mail ook een waardeloze term maar het is praktischer dan SMTP/POP3/IMAP over TCP/IP

[YopY]

En SJAJ, SJAH of SJAPT bekt gewoon niet zo lekker in het Engelsch. Niet dat AJAX dat overigens doet, maar boeie.

[Janoz]

roy-t schreef op donderdag 24 september 2009 @ 08:42:
[...]


De ASP.Net validation controls doen exact dat altijd 2 manieren van controleren. Zijn vast andere 'ajax' frameworks die dat ook kunnen.Scheelt een hoop werk

Dit zat bijvoorbeeld ook al in commons.validator wat onderandere ook in struts gebruikt werd zo'n 5 jaar geleden.

Het allergrootste voordeel van een dergelijke aanpakt blijft dat je slechts 1x je validatie regels configureert. Het is natuurlijk wachten op problemen wanneer je je clientside en je serverside validatie apart moet valideren. Murphy dicteert dat er dan een keer een discrepantie insluipt waardoor clientside iets wel verplicht is, maar vergeten wordt dit ook aan de serverkant toe te voegen .

Maar helaas zijn er nog legio ontwikkelaars met een hoog NIH-gehalte die denken dat webgui's ontwikkelen toch echt iets is dat ze vooral helemaal zelf moeten doen .

[Verwijderd]

Janoz schreef op donderdag 24 september 2009 @ 11:28:
[...]
Maar helaas zijn er nog legio ontwikkelaars met een hoog NIH-gehalte die denken dat webgui's ontwikkelen toch echt iets is dat ze vooral helemaal zelf moeten doen .

Mjah, soms kan 't best handig zijn om iets te hebben wat beter aansluit op de rest van je app, maar ik ben het zeker met je eens. Sterker nog, ik had er zelf laatst per ongeluk last van. Nou ja, eigenlijk blindstaren op functionaliteit die ook beschikbaar was zoals ik em nodig had ;-)

In ASP.NET MVC 2 heb je de DisplayFor<>/EditorFor<> extension methods op de HTMLHelper. Wat deze doen is een partial view renderen, waarbij de details worden afgeleidt vanuit een lambda die je als parameter meegeeft. Stel ons model is een BlogPost. Effe minimaal:

C#:

class BlogPost
{
  public string Subject { get; set; }
}

in de ASPX kan je dan op deze manier een template gebruiken voor je edit field:

C#:

<%= Html.EditorFor(x => x.Subject) %>

het parameter type van de lamdba is automatisch die van het model van je view.

Nu was bij mij het geval dat ik een lijst van strings heb (namen van properties), die ik ook graag templated wou zien. Nu verwacht EditorFor een expression van het type 'PropertyOrField' o.i.d, dus ik kan niet simpelweg een lamdba met een methodcall er in zetten. Dus ik een uurtje of twee prutsen met het zelf construeren van een mooie expression, kom ik er achter dat er ook een variant bestaat die gewoon een string accepteert, namelijk:

C#:

<%= Html.Editor("Subject") %>

[!null]

Zo had ik tijdje terug ook een functie geschreven in C om een getal in chars om te zetten naar een decimale int, waarbij het tekstuele getal een getal was met afwijkende base. Het was geen decimaal of hexadecimaal, het was base 4 of 8 ofzo iets. Ik daar een functie voor geschreven, wou ik hem net gaan testen, komt m'n leidinggevende toevallig binnengelopen. "Oh maar daar heb je gewoon die en die functie voor.." Toen gingen we mijn functie nog wel even testen, en hij werkte wel in 1 keer

[Grijze Vos]

Janoz schreef op donderdag 24 september 2009 @ 11:28:
[...]

Maar helaas zijn er nog legio ontwikkelaars met een hoog NIH-gehalte die denken dat webgui's ontwikkelen toch echt iets is dat ze vooral helemaal zelf moeten doen .

Dat is zeker zo, maar helaas zijn er ook veel te veel gui componenten die gewoon niet anders zijn te omschrijven als "brak". Mede daardoor hebben wij op een gegeven moment besloten om bijvoorbeeld zelf met jQuery een C# datagrid implementatie te schrijven. Kostte ons een week aan arbeid. Ik denk dat we in het verleden al makkelijk een maand kwijt zijn geraakt aan bugs met het grid van Telerik, om maar iets te noemen.

Bovendien is ons grid ook een stuk performanter. Tis niet altijd NIH, maar "we can do it better".

[Verwijderd]

Slurp. Het is nog vroeg. Mijn eigen include suggestie in [PHP] Is deze switch functie wel veilig? wil ik graag nomineren voor het nekschot van het jaar. Ik ga maar even stil in een hoekje zitten huilen.

[!null]

Verwijderd schreef op vrijdag 25 september 2009 @ 11:29:
Slurp. Het is nog vroeg. Mijn eigen include suggestie in [PHP] Is deze switch functie wel veilig? wil ik graag nomineren voor het nekschot van het jaar. Ik ga maar even stil in een hoekje zitten huilen.

Zou niet geheel onterecht zijn om dat te gaan doen

[Matis]

!null schreef op vrijdag 25 september 2009 @ 11:34:
Zou niet geheel onterecht zijn om dat te gaan doen

Dit wordt een unanieme stemronde denk ik

[Creepy]

Je doet je nick eer aan

[MBV]

Wanneer heb je die nickchange aangevraagd?

[Janoz]

Grijze Vos schreef op donderdag 24 september 2009 @ 16:21:
Bovendien is ons grid ook een stuk performanter. Tis niet altijd NIH, maar "we can do it better".

Vanuit het perspectief van een NIH-er is zijn (of haar) oplossing ook van het kaliber "we can do it better". De scheidslijn is heel erg dun en je moet wel kunnen relativeren om niet in de valkuil te stappen.

[MBV]

.NET grids zijn hopeloos, ik heb dat al heel vaak gezien/gehoord. Sowieso vind ik dat hele .NET gebeuren zwaar overrated: de HTML-code die het standaard produceert is echt om van te huilen

[Verwijderd]

Grijze Vos schreef op donderdag 24 september 2009 @ 16:21:
Ik denk dat we in het verleden al makkelijk een maand kwijt zijn geraakt aan bugs met het grid van Telerik, om maar iets te noemen.

Tikkie offtopic, maar heb je een indicatie of bv. een link naar die bugs in Teleriks grid? Op m'n werk zijn we op zoek naar een goede control suite incl. grid en treeview (eerst ASP.NET, later Silverlight en WPF), en hebben DevExpress, Infragistics en Telerik op het oog.

DevExpress gebruiken we al jaren in Delphi/Win32 apps, met mixed feelings: alles werkt prima totdat je upgrade naar een nieuwere versie (oude properties bestaan niet meer, nieuwe properties werken anders, en soms is de active control opeens niet meer de DevEx control, maar een inner control waar de de DevEx control alleen maar de placeholder van is, irritant en een pain in the **s).

Infragistics hebben we alleen nog maar in C#/WinForms applicaties gebruikt. Prima control suite, en hun grid kan alles wat we zoeken (soms met wat quirks, maar daar is omheen te werken). Alleen is 't ding vooral *traag*.

In came Telerik, and in came een nieuwe collega die vol goede moed en zonder de bovenstaande ervaringen op zoek ging naar een suite die 't voor ons voor de toekomst het best zou doen, en hij kwam (met goede argumenten en demo's) op Telerik.

In principe doen ze alle 3 hetzelfde, maar als er bij Telerik lijken in de kast liggen zou ik graag weten waar, en wat de impact is...

[Yeroon1986]

Even een schopje doen

Weer een duik in legacy code aan het doen. Kom je dit tegen:

PHP:

function euro($bedrag) {
    return "€ " . number_format($bedrag, 2, ",", ".");
}

Kende setlocale() en money_format() zeker niet .

[.oisyn]

De grotere WTF vind ik eigenlijk nog het opslaan van bedragen in floating point

[Onbekend]

.oisyn schreef op woensdag 30 september 2009 @ 11:33:
De grotere WTF vind ik eigenlijk nog het opslaan van bedragen in floating point

Dat komt omdat dat weinig op school wordt geleerd. Geheel getal? -> Integer. Kommagetal ? Floating point.

[Standeman]

.oisyn schreef op woensdag 30 september 2009 @ 11:33:
De grotere WTF vind ik eigenlijk nog het opslaan van bedragen in floating point

Dat is net zoiets als een datum opslaan als met de kolommen dag, maand, jaar, uur, minuut. Wat ik ooit ook wel eens ben tegengekomen

[!null]

Ik kan meerdere redenen bedenken om het niet te doen, maar ik ben benieuwd waarom jullie er nou zo over vallen.
Verder vind ik het ook wel redelijk logisch dat mensen het doen, een cent is toch een honderdste van een euro. Maar ik verwacht ook wel dat het veiliger is om het in integers op te slaan, dus alles x100.

[P_de_B]

Grijze Vos schreef op donderdag 24 september 2009 @ 16:21:
[...]

Dat is zeker zo, maar helaas zijn er ook veel te veel gui componenten die gewoon niet anders zijn te omschrijven als "brak". Mede daardoor hebben wij op een gegeven moment besloten om bijvoorbeeld zelf met jQuery een C# datagrid implementatie te schrijven. Kostte ons een week aan arbeid. Ik denk dat we in het verleden al makkelijk een maand kwijt zijn geraakt aan bugs met het grid van Telerik, om maar iets te noemen.

Bovendien is ons grid ook een stuk performanter. Tis niet altijd NIH, maar "we can do it better".

In een week schrijf je echt geen grid die dezelfde mogelijkheden heeft als een commercieel verkrijgbare grid. Dat kán gewoon niet. Als je kunt leven met minder opties is het natuurlijk prima, maar wij gebruiken in een aantal applicaties de grid nogal intensief met veel opties voor de gebruiker (sorteren, groeperen, tussentellingen, totaaltellingen, per user de kolommen onthouden, lazy loading, autofilters, uitgebreide filters, master detail, tabs in de detail etc etc. Dat kost je maanden werk om te bouwen. Dat is echt weggegooid geld als je voor een paar honderd euro een grid kan kopen. Er zal met elke grid wel iets aan de hand zijn, maar zelf schrijven lijkt me in veel gevallen geen optie.

[kenneth]

!null schreef op woensdag 30 september 2009 @ 12:10:
Ik kan meerdere redenen bedenken om het niet te doen, maar ik ben benieuwd waarom jullie er nou zo over vallen.
Verder vind ik het ook wel redelijk logisch dat mensen het doen, een cent is toch een honderdste van een euro. Maar ik verwacht ook wel dat het veiliger is om het in integers op te slaan, dus alles x100.

Floating point is onnauwkeurig. Dat kan in bepaalde situaties acceptabel zijn, maar als je in een veld €1,73 propt, is het prettig dat dat er ook € 1,73 uitkomt en niet €1,72994232. Juist als er dan gerekend gaat worden (wat natuurlijk vaak gebeurt met bedragen) krijg je enorme fouten.
Gebruik gewoon een fixed point datatype zoals decimal, of als je database dat ondersteunt een money/currency ...

[Sebazzz]

!null schreef op woensdag 30 september 2009 @ 12:10:
Ik kan meerdere redenen bedenken om het niet te doen, maar ik ben benieuwd waarom jullie er nou zo over vallen.

Een floating point is groot en heeft een slechte precisie. Laatst nog een topic waar 35,45 werd afgerond als 35,5 en 36,45 als 36,4. Dat geeft al aan dat je het floating point type niet goed kan vertrouwen. Daarnaast scheelt het ook nog eventuele fouten door het gebruik van komma in plaats van punt als decimaalscheider.

[.oisyn]

Het punt is niet zozeer de slechte precisie van floats, want dat zit wel goed. De standaard PHP float heeft 54 bits aan mantissa, wat neerkomt op zo'n 15 decimalen.

Het gaat 'm om twee dingen: de plek van de komma is variabel (oftewel, als je teveel decimalen vóór de komma nodig hebt dan gaat dat ten koste van je centen), en ze werken in basis-2, waardoor je basis-10 getallen niet altijd goed kunt weergeven (om dezelfde reden dat je 1/3 ook niet goed weer kunt geven in basis-10, maar wel heel goed in basis-3, namelijk resp. 0.333333... en 0.1).

Als je de boel gewoon als centen benadert dan heb je effectief een 7.2 fixed point getal in basis-10.

[ Voor 19% gewijzigd door .oisyn op 30-09-2009 12:49 ]

[Onbekend]

Sebazzz schreef op woensdag 30 september 2009 @ 12:18:
[...]

Een floating point is groot en heeft een slechte precisie. Laatst nog een topic waar 35,45 werd afgerond als 35,5 en 36,45 als 36,4. Dat geeft al aan dat je het floating point type niet goed kan vertrouwen. Daarnaast scheelt het ook nog eventuele fouten door het gebruik van komma in plaats van punt als decimaalscheider.

Dit heeft gewoon te maken met een dubbele afronding.

36,45 staat in de database ongeveer zo: 36,44859. Als deze waarde op het scherm getoond wordt, wordt deze afgerond op 2 decimalen. Maar als je dat nog eens wilt afronden, moet je van de weergegeven waarde afronden, en niet van de oorspronkelijke waarde.

[!null]

Toch wel de veiligheidsaspecten die ik dacht (veiligheid van berekeningen), en nog iets meer dan ik kon bedenken ook. Zoals het wegdrukken van centen als het getal te groot wordt, dat is wel ernstig ja. Zeker omdat het onbetrouwbaar / onverstelbaar wordt omdat de basis indd verschilt. Goeie.

[Janoz]

Zoals een meetwaarde geen integer is, een getal geen datum is, een datum geen tekst is en een tekst geen array van bytes is, is geld geen floating point. Het is niet het type dat bij de grootheid hoort vanwege de eigenschappen.


Een meetwaarde (afstand, temperatuur, hoeveelheid neerslag) is bijvoorbeeld een floating point hoeveelheid (Wanneer er een mililiter water verdampt is dat bij honderd liter water compleet niet relevant, maar bij 2 mililiter heeft het een behoorlijke impact). Kern van de floating point is dat het een heel groot bereik heeft, maar daarbij concessies doet op significantie. Gelukkig is dat binnen de natuurkunde een bekend begrip en kan daar keurig mee gewerkt worden.

Bij een geldbedrag daarintegen is het wel degelijk van belang dat een mutatie van een cent altijd het saldo van een rekening aanpast, ook al loopt het saldo tot over de triljarden. Een geldbedrag is daarom dan ook een perfect voorbeeld van een fixedpoint getal.

[Erkens]

Janoz schreef op woensdag 30 september 2009 @ 13:31:
Zoals een meetwaarde geen integer is

Dat ligt er maar aan wat je meet, als ik het aantal auto's meet wat op een weg rijdt dan komt daar als het goed is een integer uit (rare ongelukken uitgezonderd)

[Janoz]

Erkens schreef op woensdag 30 september 2009 @ 13:44:
[...]

Dat ligt er maar aan wat je meet, als ik het aantal auto's meet wat op een weg rijdt dan komt daar als het goed is een integer uit (rare ongelukken uitgezonderd)

Eens. Ik had het misschien nog beter op kunnen schrijven als continue meetwaarde om het verschil met een discrete meetwaarde duidelijker aan te geven.

[Sebazzz]

Ik kwam een leuke CSS selector tegen bij de code van één van mijn klasgenoten.

Cascading Stylesheet:

#nav ul li.hover ul li a {
    ...
}

Hij werkt overigens wel, maar kan in die context een stuk simpeler.

[RobIII]

Janoz schreef op woensdag 30 september 2009 @ 13:31:
Bij een geldbedrag daarintegen is het wel degelijk van belang dat een mutatie van een cent altijd het saldo van een rekening aanpast, ook al loopt het saldo tot over de triljarden. Een geldbedrag is daarom dan ook een perfect voorbeeld van een fixedpoint getal.

Als je me een paar triljard over maakt mag je die 3 cent afwijking houden hoor

Sebazzz schreef op woensdag 30 september 2009 @ 16:54:
Ik kwam een leuke CSS selector tegen bij de code van één van mijn klasgenoten.

Cascading Stylesheet:

#nav ul li.hover ul li a {
    ...
}

Hij werkt overigens wel, maar kan in die context een stuk simpeler.

Behalve de .hover class itt tot de :hover pseudo-class zie ik niets heel geks

[ Voor 30% gewijzigd door RobIII op 30-09-2009 17:01 ]

[jbdeiman]

Hmm... vreemd, de li heeft dus de class: hover? Of had die . daar een : moeten zijn, zodat bij een hoever een bepaalde actie wordt uitgevoerd?

Overigens ziet ik niet zo snel wat daar mis aan is. Wat die doen moet is in het element met id "nav", een wanneer in de ul over een li wordt gehovered (uitgaande dat de . een : moet zijn) een actie uitvoeren op een a in een li in een ul die weer binnen de li valt waarover is gehovered. Een techniek die nog wel eens wordt gebruikt bij CSS dropdown menuutjes.

Wanneer het echter wel een class betreft (dus dat de . geen : moet zijn, voor de pseudo class) dan kunnen in elk geval de #nav en ul ervoor weg. Hetgeen wat daarna staat moet dan waarschijnlijk blijven staan (wel afhankelijk van het doel).

[RobIII]

jbdeiman schreef op woensdag 30 september 2009 @ 17:01:
Wat die doen moet is in de div nav

Wie zegt dat 't een div is? 't Gaat om 't element met ID "nav"

jbdeiman schreef op woensdag 30 september 2009 @ 17:01:
Wanneer het echter wel een class betreft (dus dat de . geen : moet zijn, voor de pseudo class) dan kunnen in elk geval de #nav en ul ervoor weg

Want? De class "hover" wordt alleen maar toegepast binnen het #nav ul element? Wie weet wordt de hover class nog op andere plekken gebruikt?

[ Voor 50% gewijzigd door RobIII op 30-09-2009 17:09 ]

[jbdeiman]

RobIII schreef op woensdag 30 september 2009 @ 17:07:
[...]

Wie zegt dat 't een div is? 't Gaat om 't element met ID "nav"

Helemaal gelijk... in de snelheid van de reactie zal 'k maar zeggen.

[Sebazzz]

RobIII schreef op woensdag 30 september 2009 @ 17:00:
Behalve de .hover class itt tot de :hover pseudo-class zie ik niets heel geks

Javascript menu. En onbewust heeft de maker zijn applicatie ook nog eens compatible gemaakt met IE6, die alleen een :hover op anchors ondersteunt.

[ Voor 23% gewijzigd door Sebazzz op 30-09-2009 17:53 ]

[Janoz]

RobIII schreef op woensdag 30 september 2009 @ 17:00:
Als je me een paar triljard over maakt mag je die 3 cent afwijking houden hoor

Als mijn bank floats zou gebruiken en de drie cent buiten de range zou vallen dan zou ik met alle liefde enkele triljarden keren 3ct naar je overmaken . Behalve dat het me wat tijd kost wordt ik daar niet slechter van.

[RobIII]

Janoz schreef op woensdag 30 september 2009 @ 18:10:
[...]

Als mijn bank floats zou gebruiken en de drie cent buiten de range zou vallen dan zou ik met alle liefde enkele triljarden keren 3ct naar je overmaken . Behalve dat het me wat tijd kost wordt ik daar niet slechter van.

Deal
Nu nog even samen een bank zoeken die aan onze voorwaarden voldoet

* RobIII begint te mijmeren...
* Yacht...
* Eiland...
* Sportauto's...
* ...

[ Voor 13% gewijzigd door RobIII op 30-09-2009 18:14 ]

[Olaf van der Spek]

Janoz schreef op woensdag 30 september 2009 @ 18:10:
Als mijn bank floats zou gebruiken en de drie cent buiten de range zou vallen dan zou ik met alle liefde enkele triljarden keren 3ct naar je overmaken . Behalve dat het me wat tijd kost wordt ik daar niet slechter van.

Het gaat niet om de range maar om de precisie. 0,03 is geen probleem.

[Janoz]

De precisie range

[mcDavid]

RobIII schreef op woensdag 30 september 2009 @ 18:13:
[...]

Deal
Nu nog even samen een bank zoeken die aan onze voorwaarden voldoet

* RobIII begint te mijmeren...
* Yacht...
* Eiland...
* Sportauto's...
* ...

Ik gok zomaar dat je uberhaupt wel eerst even een telefoontje krijgt als je zulke bedragen gaat overmaken

[Olaf van der Spek]

Ook niet

mcDavid schreef op woensdag 30 september 2009 @ 21:02:
Ik gok zomaar dat je uberhaupt wel eerst even een telefoontje krijgt als je zulke bedragen gaat overmaken

3 cent? Nee hoor, kan best zonder telefoontjes.

[ Voor 94% gewijzigd door Olaf van der Spek op 30-09-2009 21:04 ]

[MBV]

Olaf van der Spek schreef op woensdag 30 september 2009 @ 21:03:
Ook niet

[...]

3 cent? Nee hoor, kan best zonder telefoontjes.

Huh? Het gaat erom dat als je 100000 keer 3 miljard overmaakt, er dan een paar keer 3 cent blijft zitten in het systeem. Lekker boeiend, qua rente loop je al meer mis door die 3 miljard over te maken

[HeSitated]

Standeman schreef op woensdag 30 september 2009 @ 12:10:
Dat is net zoiets als een datum opslaan als met de kolommen dag, maand, jaar, uur, minuut. Wat ik ooit ook wel eens ben tegengekomen

Maar dat heb ik weer liever dan een datum en een tijd veld beide van het type DateTime.....

Waarbij je dus beide bij elkaar op moet tellen om de juiste datum + tijd te krijgen.

[ Voor 11% gewijzigd door HeSitated op 01-10-2009 11:04 ]

[bat266]

RobIII schreef op woensdag 30 september 2009 @ 18:13:
[...]

Deal
Nu nog even samen een bank zoeken die aan onze voorwaarden voldoet

* RobIII begint te mijmeren...
* Yacht...
* Eiland...
* Sportauto's...
* ...

Ik heb zo waawaawaawaanzinnig gedroomd .....

[ Voor 77% gewijzigd door bat266 op 01-10-2009 11:40 ]

[Janoz]

MBV schreef op donderdag 01 oktober 2009 @ 10:45:
[...]

Huh? Het gaat erom dat als je 100000 keer 3 miljard overmaakt, er dan een paar keer 3 cent blijft zitten in het systeem. Lekker boeiend, qua rente loop je al meer mis door die 3 miljard over te maken

Nee, andersom. Het gaat er om dat je saldo hoog genoeg is zodat de 3 cent buiten de significantie valt. Het overmaken van de 3ct heeft dan geen invloed op je saldo.

[Cartman!]

HeSitated schreef op donderdag 01 oktober 2009 @ 11:03:
[...]

Maar dat heb ik weer liever dan een datum en een tijd veld beide van het type DateTime.....

Waarbij je dus beide bij elkaar op moet tellen om de juiste datum + tijd te krijgen.

Hoe bedoel je? Ben je niet bekend met dat je kunt rekenen met tijden in je DB ?

[MBV]

SQL:

SELECT x,y,z FROM tablex
ORDER BY date;
-- of:
SELECT x, y, z 
FROM tablex
ORDER BY (date + time);

En dan heb ik het niet over performance, en de 5% van de keren dat je vergeet om de tijd toe te voegen aan de datum.

[P_de_B]

MBV schreef op donderdag 01 oktober 2009 @ 14:46:

SQL:

SELECT x,y,z FROM tablex
ORDER BY date;
-- of:
SELECT x, y, z 
FROM tablex
ORDER BY (date + time);

En dan heb ik het niet over performance, en de 5% van de keren dat je vergeet om de tijd toe te voegen aan de datum.

Toch is er veel voor te zeggen om het tijd in een apart veld op te kunnen slaan. Microsoft heeft dat met de introductie van SQL Server 2008 ook ingezien. Als ik een query wil draaien om alle records van een bepaalde tijd (ongeacht de datum) terug te krijgen moet ik ranzige dingen doen. Het gaat erom dat de ontwikkelaar zelf de keuze heeft om datum en tijd apart op te slaan afhankelijk van het doel van de betreffende kolom. Bij SQL Server voor 2008 was dit niet mogelijk en had je altijd een datum bij een tijd en andersom.

[Canaria]

P_de_B schreef op donderdag 01 oktober 2009 @ 14:51:
[...]

Toch is er veel voor te zeggen om het tijd in een apart veld op te kunnen slaan. Microsoft heeft dat met de introductie van SQL Server 2008 ook ingezien. Als ik een query wil draaien om alle records van een bepaalde tijd (ongeacht de datum) terug te krijgen moet ik ranzige dingen doen. Het gaat erom dat de ontwikkelaar zelf de keuze heeft om datum en tijd apart op te slaan afhankelijk van het doel van de betreffende kolom. Bij SQL Server voor 2008 was dit niet mogelijk en had je altijd een datum bij een tijd en andersom.

Eens, je kunt in een DateTime de time-component nu eenmaal niet op NULL zetten, en de waarde 00:00 vertegenwoordigt ook een tijd. In ieder geval heb ik wel eens de tijd en datum apart opgeslagen, beide in DateTime-velden.

C# heeft ook een DateTime.Date property.

[Cartman!]

Je kunt, in MySQL iig, ook alleen de datum of alleen de tijd terugvragen van een DATETIME veld.

[P_de_B]

Canaria schreef op donderdag 01 oktober 2009 @ 15:08:
[...]

In ieder geval heb ik wel eens de tijd en datum apart opgeslagen, beide in DateTime-velden.

In SQL Server < 2008 kon dat dus niet. Als je geen datum meegaf met een tijd werd de datum 1-1-1900.

[Canaria]

P_de_B schreef op donderdag 01 oktober 2009 @ 15:38:
[...]

In SQL Server < 2008 kon dat dus niet. Als je geen datum meegaf met een tijd werd de datum 1-1-1900.

Dat maakte op zich niet zo veel uit. In dat veld was alleen de tijd significant (werd gebruikt om het dagdeel te bepalen), de datumcomponent werd genegeerd, al kwam die toevallig wel altijd overeen met de waarde in het datumveld.
Was er geen tijd maar alleen een datum, dan was het tijdveld dus leeg.

[Verwijderd]

Leuk topic dit, kwam zelf net nog wat van mezelf tegen van een tijdje terug (paar jaar..):

HTML:

<table>
    <td class="header">
        ....
    </td>
</table>

[mcdronkz]

Dat lijkt me meer iets voor het webdesign forum . Je staat overigens niet alleen, ik zie de meest rare HTML/CSS constructies voorbijkomen terwijl er ook een simpele tag voor gebruikt had kunnen worden. Maar goed, vind je het gek, er zijn waanzinnig veel tags, je kunt niet alles weten.

[Verwijderd]

mcdronkz schreef op maandag 05 oktober 2009 @ 02:51:
Dat lijkt me meer iets voor het webdesign forum . Je staat overigens niet alleen, ik zie de meest rare HTML/CSS constructies voorbijkomen terwijl er ook een simpele tag voor gebruikt had kunnen worden. Maar goed, vind je het gek, er zijn waanzinnig veel tags, je kunt niet alles weten.

Ohja, nou je het zegt... Maar zit daar nooit, vandaar dat ik het hier plaatste.

Maar is van een aantal jaar geleden, snap nu echt niet dat ik dat niet wist toen, maar zal binnenkort eens wat oude sites uit de backup halen, daar zit ook wel het een en andere aan PHP stuff die hier thuis hoort.

[_Noldy]

Op mijn huidige werkadres werken we met VBscript. De code post ik niet maar wel het commentaar van mijn voorganger :):

'Tell recordset to split records in the pages of our size.
if rs.eof then
'behoorlijke crappy oplossing maar gebeurt toch alleen de allereerste keer maar, voel je vrij om het netter te doen

Het werk van deze creatieveling heeft een plekje aan onze wall op shame verdient.

EDIT: de ene regel code ziet er nog niet zo slecht uit maar het commentaar verklaart weinig goeds.

[ Voor 11% gewijzigd door _Noldy op 05-10-2009 11:04 . Reden: verduidelijking ]

[raptorix]

Niet echt foute code, maar wel enorme denkfout die ik maakte was dat je wel even een find/replace op een Text field kon doen in Sqlserver, in 1 keer was alle content op honderden websites afgekapt tot 4096 tekens

Gelukkig was ik zo slim geweest om wel even backup te maken voor ik die replace deed

[_JGC_]

Cartman! schreef op donderdag 01 oktober 2009 @ 15:35:
Je kunt, in MySQL iig, ook alleen de datum of alleen de tijd terugvragen van een DATETIME veld.

Dat kan ja, maar als je erop wilt selecten resulteert dat in een full table scan, wat ranzig traag is met een database met miljoenen records.

[MBV]

Views, indices, dat soort dingen? Oh wacht, MySQL

[P_de_B]

MBV schreef op maandag 05 oktober 2009 @ 16:49:
Views, indices, dat soort dingen? Oh wacht, MySQL

Dat kan in MS SQL ook niet . Alleen de datum of alleen de tijd van een DateTime opvragen vereist het gebruik van een functie. Dat betekent dat er geen index gebruikt kan worden en er dus een table scan gedaan moet worden.

[RobIII]

P_de_B schreef op maandag 05 oktober 2009 @ 16:52:
[...]

Dat kan in MS SQL ook niet . Alleen de datum of alleen de tijd van een DateTime opvragen vereist het gebruik van een functie. Dat betekent dat er geen index gebruikt kan worden en er dus een table scan gedaan moet worden.

Met een materialized view toch wel?

[P_de_B]

RobIII schreef op maandag 05 oktober 2009 @ 16:53:
[...]

Met een materialized view toch wel?

Nee hoor, je moet toch nog steeds een functie toepassen om _alleen_ de tijd terug te krijgen van een DateTime? Of je moet in de view het datatype aanpassen naar een string, maar ik hoef je denk ik niet uit te leggen dat dat een minder goed idee is Als de view een DateTime teruggeeft is er niks veranderd.

Pas in SQL2K8 is het mogelijk alleen een tijd of datum op te slaan.

[RobIII]

P_de_B schreef op maandag 05 oktober 2009 @ 16:56:
Nee hoor, je moet toch nog steeds een functie toepassen om _alleen_ de tijd terug te krijgen van een DateTime?

Maar die (enkel) date of time kun je dan toch in de materialized versie stoppen?

P_de_B schreef op maandag 05 oktober 2009 @ 16:56:
Of je moet in de view het datatype aanpassen naar een string

En waarom dan niet gewoon naar een date of time? (Ik heb 't wel even over RDBMS'en die dus én materialized views én "losse" date en/of time velden ondersteunen.

P_de_B schreef op maandag 05 oktober 2009 @ 16:56:
Pas in SQL2K8 is het mogelijk alleen een tijd of datum op te slaan.

Dat zeg ik

[.oisyn]

P_de_B schreef op maandag 05 oktober 2009 @ 16:56:
[...]

Nee hoor, je moet toch nog steeds een functie toepassen om _alleen_ de tijd terug te krijgen van een DateTime?

Ja, en dat kan toch gewoon bij het updaten van de index? Oftewel, je kunt toch een index maken op GET_TIME(date) ipv alleen op date (geen idee of die functie ook zo heet trouwens)
Ik ken MS SQL verder niet, maar jij doet nu alsof het überhaupt een theoretische onmogelijkheid is

Overigens, wat krijg je terug met GET_TIME() als er geen apart time object bestaat? Waarschijnlijk een datetime, met de datum gezet naar iets als 1-1-1900. Op het moment dat je een view hebt van je data met een datetime kolom dat GET_TIME(date) is, moet je niet in je query alsnog een GET_TIME() daarop doen, maar gewoon selecteren op iets als BETWEEN 1-1-1900 12:00 AND 1-1-1900 13:00

[ Voor 41% gewijzigd door .oisyn op 05-10-2009 17:07 ]

[P_de_B]

RobIII schreef op maandag 05 oktober 2009 @ 16:59:
(Ik heb 't wel even over RDBMS'en die dus én materialized views én "losse" date en/of time velden ondersteunen.

Maar daar hadden we het hierboven niet over, vandaar dat ik dat puntje noemde. Vanaf 2K8 heb je gelijk

[RobIII]

P_de_B schreef op maandag 05 oktober 2009 @ 17:01:
[...]

Maar daar hadden we het hierboven niet over, vandaar dat ik dat puntje noemde. Vanaf 2K8 heb je gelijk

Nee, OK. Dan begrijpen we mekaar. Anders had ik je moeten komen meppen

[P_de_B]

.oisyn schreef op maandag 05 oktober 2009 @ 17:00:
[...]

Ja, en dat kan toch gewoon bij het updaten van de index? Oftewel, je kunt toch een index maken op GET_TIME(date) ipv alleen op date (geen idee of die functie ook zo heet trouwens)
Ik ken MS SQL verder niet, maar jij doet nu alsof het überhaupt een theoretische onmogelijkheid is

Die functie is er dus net (pre 2008). GET_TIME zou een datatype TIME op moeten leveren en die bestaat niet (pre 2008) De enige opties vziw zijn een convert naar een char zijn die alleen de tijd overlaat of iets creatiefs met DATEADD die zorgt dat je datum altijd 1-1-1900 is. Natuurlijk kun je daarmee prima queries zoals je hieronder aangeeft, maar alleen de tijd teruggeven is dus niet zo eenvoudig (pre 2008)

Overigens, wat krijg je terug met GET_TIME() als er geen apart time object bestaat? Waarschijnlijk een datetime, met de datum gezet naar iets als 1-1-1900. Op het moment dat je een view hebt van je data met een datetime kolom dat GET_TIME(date) is, moet je niet in je query alsnog een GET_TIME() daarop doen, maar gewoon selecteren op iets als BETWEEN 1-1-1900 12:00 AND 1-1-1900 13:00

[MBV]

Tja, dan moet je in die materialized view de tijd gewoon formatteren als een integer tussen 001 en 2359, en daar je queries op los laten. Net zoals je IP's in MySQL als integer kan opslaan.

[Standeman]

Weer een leuke bug gevonden in de code. Deze heeft vziw nog geen problemen opgeleverd, maar dat is imo slechts een kwestie van tijd.

Java:

  public boolean Foo(Bar bar) throws ModelControllerException
  {
    boolean result = true;
    FooDAO dao = null;
    DAOFactory daoFactory;
   
    try
    {
      daoFactory = DAOFactory.getDAOFactory(DAOFactory.DBMS);
      dao = daoFactory.loadFooDAO();

      result = dao.addBar(bar);
     
      if (result)
      {
        dao.commit();
      }
      else
      {
        dao.rollback();
      }
    }
    catch(DataAccessException dax)
    {
      log.error(dax.getMessage());
      dao.rollback();
      throw new ModelControllerException(dax);
    }
    finally
    {
      if (dao != null)
      {
        dao.close();
      }
    }
   
    return result;
  }

10 punten voor de eerste die het ziet

[roeleboel]

als

Java:

daoFactory = DAOFactory.getDAOFactory(DAOFactory.DBMS); 
dao = daoFactory.loadFooDAO(); 

mislukt komt er een niet opgevangen nullpointer?

[ Voor 11% gewijzigd door roeleboel op 15-10-2009 15:17 ]

[jAnO!]

roeleboel schreef op donderdag 15 oktober 2009 @ 15:16:
als

Java:

daoFactory = DAOFactory.getDAOFactory(DAOFactory.DBMS); 
dao = daoFactory.loadFooDAO(); 

mislukt komt er een niet opgevangen nullpointer?

tja, maar dan kan je praktisch alles in try/catch hangen. Niet de WTF denk ik.

hmm..
Als de dao.rollback exceptie geeft, doe je die call nog een keer? bedoel je dat?

[ Voor 23% gewijzigd door jAnO! op 15-10-2009 15:24 ]

[!null]

Of dat hij tweemaal een dao.rollback() kan doen?
Weet niet of dat schadelijk is, ik ken die objecten niet, weet de context niet.

Ik bedoel, als de rollback() fout gaat, een exceptie gooit, en je gaat dan wederom een rollback() krijg je neem ik aan een onafgehandelde exceptie?

[ Voor 36% gewijzigd door !null op 15-10-2009 15:24 ]

[.oisyn]

Nou heb ik geen verstand van DAO's in java, maar wellicht dat commit() of de rollback() óók een DataAccessException kan gooien, waarna je in de catch een rollback doet op dat object waarna je weer zo'n exception krijgt, die dan dus doorrippelt naar de applicatie ipv dat hij gewrapt wordt in een ModelControllerException?

[jAnO!]

.oisyn schreef op donderdag 15 oktober 2009 @ 15:24:
Nou heb ik geen verstand van DAO's in java, maar wellicht dat commit() of de rollback() óók een DataAccessException kan gooien, waarna je in de catch een rollback doet op dat object waarna je weer zo'n exception krijgt, die dan dus doorrippelt naar de applicatie ipv dat hij gewrapt wordt in een ModelControllerException?

Dan moet het een runtime exceptie zijn, want anders kan het niet compilen... tenzij die extends van ModelControllerException...

[Haan]

Ik moest onderhoud plegen aan een .Net web service met een stuk of 10 web methods. Alle code bleek te zitten in 1 grote file van bijna 2500 regels

Daarin zat dus alle business logica, helper methods, enumerations, de webmethods zelf, en een waslijst aan classjes voor de requests/responses voor iedere web method

Na wat refactoring nog een file van 1200 regels over en de rest van de code opnieuw ingedeeld in logische bestanden.

[.oisyn]

jAnO! schreef op donderdag 15 oktober 2009 @ 15:26:
[...]


Dan moet het een runtime exceptie zijn, want anders kan het niet compilen... tenzij die extends van ModelControllerException...

http://static.springsourc.../DataAccessException.html
Dát had ik dan al wel weer opgezocht

[ Voor 5% gewijzigd door .oisyn op 15-10-2009 15:39 ]

[Standeman]

!null schreef op donderdag 15 oktober 2009 @ 15:22:
Of dat hij tweemaal een dao.rollback() kan doen?
Weet niet of dat schadelijk is, ik ken die objecten niet, weet de context niet.

Ik bedoel, als de rollback() fout gaat, een exceptie gooit, en je gaat dan wederom een rollback() krijg je neem ik aan een onafgehandelde exceptie?

rollBack() gooit in principe geen Exceptions.

Algemene tip: probeer iets minder technisch te kijken en iets meer functioneel

.oisyn schreef op donderdag 15 oktober 2009 @ 15:38:
[...]

http://static.springsourc.../DataAccessException.html
Dát had ik dan al wel weer opgezocht

We gebruiken (heelaas nog steeds) geen spring. DataAccessException in dit geval ons eigen brouwsel.

Haan schreef op donderdag 15 oktober 2009 @ 15:37:
Ik moest onderhoud plegen aan een .Net web service met een stuk of 10 web methods. Alle code bleek te zitten in 1 grote file van bijna 2500 regels

Daarin zat dus alle business logica, helper methods, enumerations, de webmethods zelf, en een waslijst aan classjes voor de requests/responses voor iedere web method

Na wat refactoring nog een file van 1200 regels over en de rest van de code opnieuw ingedeeld in logische bestanden.

Ik heb hier ook nog een paar van dat soort classes. Ik heb nog niet de moed of de tijd gehad om ze aan te pakken

[ Voor 52% gewijzigd door Standeman op 15-10-2009 15:45 ]

[MBV]

waarom doe je die rollback überhaupt? addBar geeft false terug, ik neem aan dat je het resultaat dan ook moet committen?

[Dnomaid]

code:

result = dao.addBar(bar);

als addBar een exception throwt, geef je gewoon true terug, en dat kan de bedoeling niet zijn?

Edit: verduidelijkt.

[ Voor 60% gewijzigd door Dnomaid op 15-10-2009 15:50 ]

[Standeman]

MBV schreef op donderdag 15 oktober 2009 @ 15:45:
waarom doe je die rollback überhaupt? addBar geeft false terug, ik neem aan dat je het resultaat dan ook moet committen?

Als ik even in implementatie van de DAO spiek, dan krijg je false terug wanneer de update count kleiner is dan 1.

[jAnO!]

BobbyD82 schreef op donderdag 15 oktober 2009 @ 15:46:
Bij een exception krijg je gewoon true terug?

nee, want bij een exception wordt een nieuwe exception gegooid en bereik je nooit het return statement.