[ASP.NET] Forceren van id/naam van een html element

[BlackHawkDesign]

Beste Tweakers,

Ik zit opnieuw met een probleem. Ik heb een aantal hidden elementen in mijn formulier die een bepaalde naam en id moeten hebben om mijn javascript en c# validatiecode te laten werken. Nu werkte dit perfect in mijn testomgeving, echter werkt het niet meer in mijn eerste formulier.

Wat blijkt, asp vond het grappig om plots andere id en namen te gebruiken dan ik opgaf. Na wat leeswerk ben ik erachter dat de control class hier verantwoordelijk is. Ik wil gewoon forceren dat hij voor die 4 velden die id's en namen geeft die ik wil.

Na wat zoekwerk kwam ik dit artikel tegen : http://www.west-wind.com/WebLog/ShowPost.aspx?id=4605

Maar hoe kan ik dit precies uitvoeren? Een customized control class maken met die 2 functies? Maar hoe laat ik alle pagina's die van mij gebruiken in plaats van de reguliere control class?

Edit: Misschien wat voorbeeldcode:

HTML:

  <input type="hidden" id="field_names" value="" runat="server"/>

wordt dit

HTML:

  <input type="hidden" name="ctl00_cphMain_field_names" id="ctl00_cphMain_field_names" value=""/>

p.s: Het gebruik van mijn eigen validatiemethoden is een bewuste keuze, dus alsjeblieft geen reacties hierover.

[ Voor 18% gewijzigd door BlackHawkDesign op 24-04-2009 11:05 ]

[BM]

Als je in je stukje javascript code iets als dit neerzet, zou het volgens mij moeten werken:

JavaScript:

<script type="text/javascript">
  var idvanjeveld = '<%= field_name.ClientID %>';
</script>

Op deze manier word daar automatisch het id ingevuld wat de control aan de clientkant krijgt.

[BlackHawkDesign]

Bij mij is die javascript in een apart bestand opgeslagen. Ik vind het dan ook vrij 'lelijk' om zo los in de pagina javascript te pleuren.

Dus ik doe het liever op de manier zoals in dat artikel werd aangegeven, overschrijven van die functies zodat hij gewoon de namen gebruikt die ik opgeef. Ik controleer zelf wel of de namen uniek zijn. (Heb ik altijd al gedaan en ook nooit problemen mee gehad)

[Janoz]

Waarom vind je het misbruiken van een hidden form field om gegevens aan je javascript door te geven minder lelijk dan een stukje javascript waarin je gegevens aan je javascript doorgeeft?

[dsmits]

Het is tot en met 3.5 niet mogelijk om het ID te forceren. Vanaf 4.0 (VS2010) kan het wel even geduld nog dus

[BlackHawkDesign]

Janoz schreef op vrijdag 24 april 2009 @ 11:59:
Waarom vind je het misbruiken van een hidden form field om gegevens aan je javascript door te geven minder lelijk dan een stukje javascript waarin je gegevens aan je javascript doorgeeft?

In dat hidden field staat alle velden die gevalideerd moeten worden, zowel c# als javascript leest dat veld uit en valideert vervolgens alle velden met een for loopje. In het formulier hoef ik alleen 4 hidden velden op te nemen, daarmee op te geven welke velden en hoe ze moeten worden gevalideerd, de rest gaat automagisch.

Maar omdat asp.net het leuk vind zelf die id's en namen te veranderen, moet ik me dus nu weer in allerlei bochten wringen om dat goed te krijgen...

[Janoz]

Persoonlijk vind ik meer dat jij je in allerlei bochten wringt en het jezelf daardoor erg lastig maakt. En dat terwijl het helemaal niet zo ingewikkeld hoeft te zijn.

Het te genereren javascript kun je gewoon laten genereren door een eigen stukje code die je opneemt in je eigen validatie framework. Vanaf dat moment maakt het al helemaal niet meer uit of het naar een hidden field of naar een stukje javascript gerenderd wordt (tenzij je een generated source fetisjist bent die naast voor de browser goede en nette semantisch correcte code ook nog wil dat het human readable is).

Het afhandelen aan de serverkant lijkt me ook geen probleem aangezien je neem ik aan weet welk formulier je opgestuurd krijgt. Daaruit kun je afleiden welke validatie regels je toe zou moeten passen.

De gegenereerde id's zijn trouwens niet het enige probleem in je huidige implementatie. De validatie lijkt me namelijk ook zo lek als een mandje. Hij is namelijk clientside afhankelijk. Alles op de client kan de bezoeker aanpassen. Je bezoeker kan immers gewoon een andere inhoud van het hidden field opsturen en daarmee zelf bepalen welke validaties wel en welke validaties niet uitgevoerd worden.

[Hydra]

Janoz schreef op vrijdag 24 april 2009 @ 12:49:
Persoonlijk vind ik meer dat jij je in allerlei bochten wringt en het jezelf daardoor erg lastig maakt. En dat terwijl het helemaal niet zo ingewikkeld hoeft te zijn.

Hij heeft wel een punt. Je wil eigenlijk geen javascript op moeten nemen in een pagina als dat ook in een extern (en dus te cachen!) .js bestand kan. Wat ik meestal doe is zoveel mogelijk generieke JS code afslitsen in een extern .js bestand, en alleen de kleine stukjes JS die de externe code aanroepen uitgenereren in de HTML output.

Dus, een externe javascript met validate functions, en in de "onchange" een call naar validateInteger(<InputId>, 1000, 9999) bijvoorbeeld.

[BlackHawkDesign]

Janoz schreef op vrijdag 24 april 2009 @ 12:49:
(tenzij je een generated source fetisjist bent die naast voor de browser goede en nette semantisch correcte code ook nog wil dat het human readable is).

Ik krijg het vermoeden dat ik dat inderdaad wel aardig begin te worden.

Ik kan alleen gewoon slecht tegen het feit dat asp alles voor me wil genereren en doen. Wanneer je iets customized met javascript wilt bijvoorbeeld, wordt het zo lastig omdat ik niet van de id's kan uitgaan en moet ik in me javascript ook weer serverside code plaatsen.

Ik moet ook eerlijk bekennen dat ik redelijk nieuw ben met asp en daardoor misschien niet alles goed begrijp. Maar toch vind ik dat asp me teveel beperkt, ik kan toch zelf wel beheren of me id's en namen uniek zijn of niet..

Toch zal ik eens gaan kijken of ik dan maar niet die javascript laat genereren.

@Hydra: Ja zo wil ik het ook doen, ik vind dat gewoon veel mooier, maar ik krijg het vermoeden dat microsoft die mening niet met me deelt.

[ Voor 7% gewijzigd door BlackHawkDesign op 24-04-2009 13:16 ]

[Hydra]

BlackHawkDesign schreef op vrijdag 24 april 2009 @ 13:15:
@Hydra: Ja zo wil ik het ook doen, ik vind dat gewoon veel mooier, maar ik krijg het vermoeden dat microsoft die mening niet met me deelt.

Wij bouwen de meeste demo-sites in Asp.net, en wat ik wel geleerd heb is dat je niet tegen het gebruik van controls moet vechten, en dus eigenwijs zelf HTML gaat zitten outputten. De architectuur is gewoon helemaal opgebouwd op server-side controls. Client-side JS kan prima, ook in Asp.net, maar gaan proberen alles zelf te doen is niet productief. Ik zou dus gewoon eigen controls maken, en daarin via een klein stukje gegenereerde JS code de generieke functies in je .js file aanroepen.

[Janoz]

Hydra schreef op vrijdag 24 april 2009 @ 13:07:
[...]


Hij heeft wel een punt. Je wil eigenlijk geen javascript op moeten nemen in een pagina als dat ook in een extern (en dus te cachen!) .js bestand kan. Wat ik meestal doe is zoveel mogelijk generieke JS code afslitsen in een extern .js bestand, en alleen de kleine stukjes JS die de externe code aanroepen uitgenereren in de HTML output.

Dus, een externe javascript met validate functions, en in de "onchange" een call naar validateInteger(<InputId>, 1000, 9999) bijvoorbeeld.

Dat is ook precies wat ik bedoel hoor. Mijn opmerking ging ook meer over de configuratie van de (clientside) validatie. TS doet dat nu in een hidden field en weigert javascript, terwijl je die 4 (ofzo) hidden fields ook kunt implementeren door 4 regeltjes javascript met daarin var = "waarde".

[BlackHawkDesign]

@janoz, ik zag na het nog een keer lezen van je verhaal in wat je bedoelde en realiseerde me toen dat ik een fout maakte die ik normaal altijd zwaar afkeur.

Ik ben nu aan de slag gegaan om me serverside validator uit te breiden en daar gewoon bij te houden welke velden en hoe zij gevalideerd moeten worden. Als extra komt er een functie die een javascriptje uitpoept zoals jij dat aangaf.

Daarom hou ik van tweakers, ze verruimen je denkwijze Thnx heren.

p.s Toch vind ik het bagger dat veranderen van die id's

[Hydra]

BlackHawkDesign schreef op vrijdag 24 april 2009 @ 13:54:
p.s Toch vind ik het bagger dat veranderen van die id's

Tja, het heeft een reden natuurlijk. Stel je hebt 2 verschillende UserControls met daarin beiden een "name" textfield. Aangezien ze beiden op hetzelfde formulier staan, kun je ze niet de naam "name" laten houden maar wordt het iets als UserControl1$name en UserControl2$name.

[Bosmonster]

Waarom wil je uberhaupt de interne id's veranderen voor iets simpels als validatie? Kun je niet gewoon de validatie-rule in een custom attribute gooien en dynamisch zo je velden langslopen en valideren? Is het ook non-obtrusive.

[pasz]

[b][message=31849535,noline]p.s Toch vind ik het bagger dat veranderen van die id's

Dit is gewoon 'by-design' gedrag van ASP.NET. Ik heb zelfs een keer gezien dat (junior)programmeurs die vieze id's gebruiken in hun CSS bestanden.

Waarom gebruik je niet de standaard validatie van ASP.NET met een ValidationSummary ?

Het toevoegen van obscure javascriptjes is altijd een slecht idee in ASP.NET. Je kunt gewoon niet 100% voorspellen wat ASP.NET voor je genereert en hoe het zich gedraagt. Het enige houvast wat je hebt is je code-behind code.

Misschien kun je ook eens kijken naar het Ajax gedeelte van ASP.NET. Gooi je hele form op een updatePanel. Dan heb je ook geen last meer van Page refreshes en regelt ASP.NET de communicatie tussen client en server code.

[Snake]

Met pasz ^.

Met validation kan je zelf wijzen naar een Javascript functie die dan geplakt wordt op een input element, en moet jij alleen zorgen dat je de parameters goed afhandeld.

Op deze pagina vind je alles wat je nodig hebt http://msdn.microsoft.com/en-us/library/f5db6z8k.aspx

[ Voor 22% gewijzigd door Snake op 24-04-2009 20:42 ]

[BlackHawkDesign]

Dit is gewoon 'by-design' gedrag van ASP.NET.

En dat vind ik echt irritant soms, hoe moet je dit en dat doen, ja moet je even hier op klikken, vraag ik, maar wat is de code dan gewoon. Reactie: ehhh weet ik niet, gewoon klikken.

Waarom ik mijn eigen validatie wil, niet zozeer omdat ik waardes krijg die de asp.net validatie niet aan kan, maar meer omdat ik het gedrag van mijn validatie anders wil. Zo wil ik het in een mooi divje met een icoontje erbij. Ik wil ook die div compleet stylen. Dit ging aardig alleen kreeg ik het maar niet voor elkaar dat hij mijn eigen divjes ook liet zien zodra er een fout was. Het customizen van je eigen javascript gedrag gaat sowieso al lastig is me opgevallen. Daarnaast wil ik ook dat hij mijn veldjes onblur valideert. Na 3 dagen klooien heb ik het aan de kant gegooid. ( De asp validatie methodes dan)

[R4gnax]

BlackHawkDesign schreef op maandag 27 april 2009 @ 14:10:En dat vind ik echt irritant soms, hoe moet je dit en dat doen, ja moet je even hier op klikken, vraag ik, maar wat is de code dan gewoon. Reactie: ehhh weet ik niet, gewoon klikken.

Da's niet de fout van het framework, da's de fout van de programmeur die gewoon te lui en / of stom is om uit te vogelen hoe het werkt, maar gewoon blind dingen aan elkaar knoopt in de hoop dat het werkt. Meestal zijn dit dezelfde code-aapjes die copy&paste code schrijven en 'send me teh codez' boodschappen spammen.

BlackHawkDesign schreef op maandag 27 april 2009 @ 14:10:
Waarom ik mijn eigen validatie wil, niet zozeer omdat ik waardes krijg die de asp.net validatie niet aan kan, maar meer omdat ik het gedrag van mijn validatie anders wil. Zo wil ik het in een mooi divje met een icoontje erbij. Ik wil ook die div compleet stylen. Dit ging aardig alleen kreeg ik het maar niet voor elkaar dat hij mijn eigen divjes ook liet zien zodra er een fout was. Het customizen van je eigen javascript gedrag gaat sowieso al lastig is me opgevallen. Daarnaast wil ik ook dat hij mijn veldjes onblur valideert. Na 3 dagen klooien heb ik het aan de kant gegooid. ( De asp validatie methodes dan)

Zoals Snake al zei kun je eens kijken naar de CustomValidator klasse. Die heeft een mooie ClientValidationFunction property waarmee je misschien kunt doen wat je wilt.

Is dat niet toereikend, dan kun je een eigen validator afleiden van BaseValidator waarmee je een grotere controle hebt over hoe exact de error message gerenderd wordt. Daarmee moet het heel goed mogelijk zijn om gewoon 'binnen de regeltjes' van het framework je validatie met custom look & feel af te handelen.*

Overigens zouden controls met validators automatisch hun client-side validatie functies af moeten vuren wanneer het onchange event van die controls vuurt. Dat is het event wat je wilt hebben, want dat hoort (volgens de DOM spec) alleen te vuren wanneer je van een HTML input weg geblurred bent en de waarde van die input gewijzigd is sinds die input focus kreeg.

offtopic:
* Zelf wil ik binnenkort ook nog eens kijken of ik langs die weg wat fancy validators kan maken om de kale, lelijke standaard asp.net validators weg te doen.