[ASP.NET C#] HtmlInputText: ID en name overriden

[Urk]

Ik ben bezig met een ASP.NET applicatie in het .NET 3.5 framework en baal ontzettend dat het framework voor mij unieke ID's op HtmlControls en WebControls genereert. In het komende .NET 4 framework schijn je dit eindelijk te kunnen uitzetten maar dat is nog even wachten.

Ik wil dus dat voor bijv. een HtmlControls.HtmlInputText de ID en name die aan de client zijde worden gegenereerd blijven hoe ik ze heb genoemd. Ik heb hier nu diverse topics op internet over gelezen (o.a. http://weblogs.asp.net/pa...-clientid-generation.aspx en http://jberke.blogspot.co...ff-aspnets-unique-id.html) maar krijg het niet werkend.

Ik heb nu bijv als simpel opzetje:

C#:

public class TextBox : System.Web.UI.HtmlControls.HtmlInputText
{
   public override string Name
   {
      get
      {
         return base.Name;
      }
      set
      {
         base.Name = "test2";
      }
   }
}

Om het name attribuut te vervangen met de opgegeven name in:

C#:

<input type="text" id="productsubcat_naam_nl" name="productsubcat_naam_nl" maxlength="20" runat="server" />

Wat ik lees moet het kunnen alleen krijg ik het niet aan de praat. Bovenstaande class heet test.cs en staat in de App_Code folder van mn ASP.NET applicatie.
Ik heb het idee dat ik nog iets in web.config moet configureren om dit te laten werken.

Hopelijk kan iemand een goede voorzet geven?

[FireDrunk]

Misschien een kort waarom, zodat we wat meer context hebben?

Misschien moet je base.Name veranderen in this.Name?

[ Voor 30% gewijzigd door FireDrunk op 18-01-2010 15:54 ]

[Urk]

thijs_cramer schreef op maandag 18 januari 2010 @ 15:53:
Misschien een kort waarom, zodat we wat meer context hebben?

Misschien moet je base.Name veranderen in this.Name?

Bedankt voor je snelle reactie
De reden is voornamelijk dat ik diverse javascript functies heb geschreven waarvoor de ID van een tekstbox hetzelfde moet zijn als de NAME. De name wordt namelijk serverside gesubmit in een HTTP POST en de ID wordt weer gebruikt via Jquery voor een Ajax validation, het is super onhandig om dat weer te omzeilen. En zo zijn er nog wel tal andere redenen te noemen.

this.Name werkt ook niet, dus ik mis blijkbaar nog iets anders...
Ik krijg nu weer zo'n walgelijk gegenereerde naam: ctl00$main_content$productsubcat_naam_nl die zelfs door de $ karakters weer voor nieuwe foutmeldingen zorgt in JQuery functies.

[Woy]

Ik dacht dat er ook een ClientID property was die je daarvoor kon gebruiken.
edit:
Die is read-only, ik heb niks gezegd.

[ Voor 25% gewijzigd door Woy op 18-01-2010 16:37 ]

[TeeDee]

Moet je niet gewoon this.Name ipv base.Name returnen?

edit:
Holy ships... dat wordt al gezegd...

Edit 2:

C#:

public override string Name 

Bovenstaande is volgens mijn Intellisense ook geen correcte override.

Heb je ook een reference naar je eigen class aangemaakt? (using...).

C#:

    public class Test : System.Web.UI.WebControls.TextBox
    {
        public Test()
        {
        }
        public override string UniqueID
        {
            get
            {
                return this.ID;
            }
        }
        public override string ClientID
        {
            get
            {
                return this.ID;
            }
        }
    }

C#:

Test t = new Test();
t.ID = "melp";

Wordt bij mij

HTML:

<input name="melp" type="text" id="melp" />

[ Voor 160% gewijzigd door TeeDee op 18-01-2010 17:30 ]

[Urk]

TeeDee schreef op maandag 18 januari 2010 @ 17:10:
Moet je niet gewoon this.Name ipv base.Name returnen?

edit:
Holy ships... dat wordt al gezegd...

Edit 2:

C#:

public override string Name 

Bovenstaande is volgens mijn Intellisense ook geen correcte override.

Tnx!

C#:

public override string Name 

Geeft bij mij geen fouten en wordt zelfs uitgevoerd.

Ik zal nu eens je andere code proberen, maar dat is een nieuwe custom class. Is het ook mogelijk de default class te overrulen zodat ik de HTML niet hoef aan te passen?

[ Voor 29% gewijzigd door Urk op 18-01-2010 17:41 ]

[Urk]

TeeDee schreef op maandag 18 januari 2010 @ 17:10:
Moet je niet gewoon this.Name ipv base.Name returnen?

edit:
Holy ships... dat wordt al gezegd...

Heb je ook een reference naar je eigen class aangemaakt? (using...).

C#:

    public class Test : System.Web.UI.WebControls.TextBox
    {
        public Test()
        {
        }
        public override string UniqueID
        {
            get
            {
                return this.ID;
            }
        }
        public override string ClientID
        {
            get
            {
                return this.ID;
            }
        }
    }

C#:

Test t = new Test();
t.ID = "melp";

Wordt bij mij

HTML:

<input name="melp" type="text" id="melp" />

TeeDee: super , dat werkt prima in de codebehind en in het Web Form zelf ook met:
(Class Test in namespace TestTextControl gezet):

C#:

[...]
<%@ Register TagPrefix="JA" Namespace="TestTextControl " %>
[...]
<JA:Test ID="test123" runat="server"></JA:Test>
[...]

Dat gaat idd prima en genereert <input name="test123" type="text" id="test123" />
Alleen heb ik veel <input type="text" id="productsubcat_naam_nl" name="productsubcat_naam_nl" maxlength="20" runat="server" /> controls/html elementen op m'n pagina en het zou dus super zijn om de standaard HtmlControls.HtmlInputText te pakken i.p.v een nieuwe control te maken. Maar hoe doe ik dat?

[boe2]

Urk schreef op maandag 18 januari 2010 @ 16:24:
[...]

Bedankt voor je snelle reactie
De reden is voornamelijk dat ik diverse javascript functies heb geschreven waarvoor de ID van een tekstbox hetzelfde moet zijn als de NAME. De name wordt namelijk serverside gesubmit in een HTTP POST en de ID wordt weer gebruikt via Jquery voor een Ajax validation, het is super onhandig om dat weer te omzeilen. En zo zijn er nog wel tal andere redenen te noemen.

Wat je ook kan doen is je javascript serverside genereren en dan de namen van je controls (.ClientID) dynamisch toevoegen.

[Urk]

@Boeboe: ja, ik weet dat dat kan maar ik wil m'n javascript niet serverside genereren. Het is toch belachelijk dat ik niet simpel auto generating van ID's en names op Formcontrols uit kan zetten.
Gelukkig komt daar met .NET 4 verandering in... maar daar heb ik nu niks aan...

[gorgi_19]

Met 3.5 en MVC heb je dit probleem niet of zit je per se vast aan webforms?

[TeeDee]

Urk schreef op maandag 18 januari 2010 @ 17:59:
[...]
Alleen heb ik veel <input type="text" id="productsubcat_naam_nl" name="productsubcat_naam_nl" maxlength="20" runat="server" /> controls/html elementen op m'n pagina en het zou dus super zijn om de standaard HtmlControls.HtmlInputText te pakken i.p.v een nieuwe control te maken. Maar hoe doe ik dat?

En als je nu eens niet inherit van .TextBox? (Weet even niet uit mijn hoofd of dat kan...).
Je ontkomt er afaik niet aan om alles aan te passen.

[Urk]

@gorgi_19: Ja dat had ik al een paar keer eerder gelezen toen ik hier over viel.
Ik heb me echter nog helemaal niet kunnen verdiepen in MVC en heb daar voor dit project ook geen tijd meer voor.

Maar simpelgezegd is MVC gewoon een pakket wat je installeert als een soort .NET framework add-on, right?

[Urk]

TeeDee schreef op maandag 18 januari 2010 @ 19:37:
[...]

En als je nu eens niet inherit van .TextBox? (Weet even niet uit mijn hoofd of dat kan...).
Je ontkomt er afaik niet aan om alles aan te passen.

In mijn ogen moet dat juist wel omdat je de overige properties van een TextBox gewoon wilt kunnen gebruiken. Kan er ook niks op Google over vinden om een standaard class of control te editen.
Gezocht op termen zoals modify asp.net control, edit default asp.net class, adjust asp.net html controls etc...

[gorgi_19]

Urk schreef op maandag 18 januari 2010 @ 19:57:
@gorgi_19: Ja dat had ik al een paar keer eerder gelezen toen ik hier over viel.
Ik heb me echter nog helemaal niet kunnen verdiepen in MVC en heb daar voor dit project ook geen tijd meer voor.

Maar simpelgezegd is MVC gewoon een pakket wat je installeert als een soort .NET framework add-on, right?

En een volledig ander pattern wat je gebruikt voor de indeling van je webapplicatie. De manier van controls aanspreken is anders, evenals de te gebruiken denkwijze

[Urk]

gorgi_19 schreef op maandag 18 januari 2010 @ 20:30:
[...]

En een volledig ander pattern wat je gebruikt voor de indeling van je webapplicatie. De manier van controls aanspreken is anders, evenals de te gebruiken denkwijze

Precies, dat had ik min of meer ook al een beetje begrepen. Een slogan die ik veel in combinatie met MVC heb gezien is "full control over HTML and URL's", en dat is wel iets wat ik echt belangrijk vindt.
Is MVC in principe iets wat je naast ASP.NET Web Forms gebruikt of meer in plaats van?

Moet daar echt eens induiken, hoewel in het .NET framework v4 ook al veel verbeteringen zitten zoals degene die ik al noem mbt ID's van controls.

[Urk]

Om weer even optopic te komen:

Weet iemand of het mogelijk bovenstaande te doen maar dan met de huidige System.Web.UI.HtmlControls.HtmlInputText en die dus aan te passen?

Vraag me uberhaupt af of het wel kan want vindt hier weinig over met Google....

[TeeDee]

Je kan toch gewoon inheriten van HtmlInputText. Override de gewenste properties et voila. Je zal nog wel extra werk moeten verzetten om je reeds bestaande controls/html/meuk aan te passen.

[gorgi_19]

Urk schreef op maandag 18 januari 2010 @ 21:02:
Om weer even optopic te komen:

Weet iemand of het mogelijk bovenstaande te doen maar dan met de huidige System.Web.UI.HtmlControls.HtmlInputText en die dus aan te passen?

Vraag me uberhaupt af of het wel kan want vindt hier weinig over met Google....

Met reflector kan je eea ook achterhalen

Urk schreef op maandag 18 januari 2010 @ 20:36:
Is MVC in principe iets wat je naast ASP.NET Web Forms gebruikt of meer in plaats van?

In plaats van.

[Urk]

TeeDee schreef op maandag 18 januari 2010 @ 21:12:
Je kan toch gewoon inheriten van HtmlInputText. Override de gewenste properties et voila. Je zal nog wel extra werk moeten verzetten om je reeds bestaande controls/html/meuk aan te passen.

Ja, dat heb ik nu ook, dat werkt prima, hierdoor heb ik echter een nieuwe class in een nieuwe namespace gemaakt en die roep ik in m'n code aan.
Echter, zou het mooi zijn als dat niet hoeft en gewoon de standaard HtmlInputText controls kan blijven gebruiken en daar deze properties van kan overriden, snap je?
Ik weet echter niet of dat uberhaupt kan....

[gorgi_19]

Urk schreef op maandag 18 januari 2010 @ 23:50:
[...]

Ja, dat heb ik nu ook, dat werkt prima, hierdoor heb ik echter een nieuwe class in een nieuwe namespace gemaakt en die roep ik in m'n code aan.
Echter, zou het mooi zijn als dat niet hoeft en gewoon de standaard HtmlInputText controls kan blijven gebruiken en daar deze properties van kan overriden, snap je?
Ik weet echter niet of dat uberhaupt kan....

Wat ik zei, gooi dat ding in reflector Zie je gelijk wat sealed, friend, etc. is en wat je kan overriden

[TeeDee]

gorgi_19 schreef op dinsdag 19 januari 2010 @ 08:29:
[...]

Wat ik zei, gooi dat ding in reflector Zie je gelijk wat sealed, friend, etc. is en wat je kan overriden

offtopic:
Neemt niet weg dat je normale Intellisense prima deze opties aan kan geven imo. In ieder geval voldoende voor de initiële vraag van TS.

En waarbij je dus nog handmatig 'iets' moet doen; als in: je .net markup code aanpassen. Ik krijg namelijk de indruk dat Urk dat niet wil/kan doen omdat de applicatie al zo goed als klaar is. Urk komt er nu achter dat het, nu het <insert> Framework er aangeknoopt wordt, het e.e.a. bemoeilijkt wordt door de ID's/Name's van de controls.

[R4gnax]

Urk schreef op maandag 18 januari 2010 @ 16:24:
[...]

De reden is voornamelijk dat ik diverse javascript functies heb geschreven waarvoor de ID van een tekstbox hetzelfde moet zijn als de NAME. De name wordt namelijk serverside gesubmit in een HTTP POST en de ID wordt weer gebruikt via Jquery voor een Ajax validation, het is super onhandig om dat weer te omzeilen. En zo zijn er nog wel tal andere redenen te noemen.

Het is waarschijnlijk onhandiger om serverside te gaan lopen hacken aan WebForms of je hele applicatie om te porten naar MVC of een andere methode die niet gebruik maakt van autogenerated IDs en/of System.Web.UI.Controls classes.

Waarom gebruik je enerzijds eigenlijk het id attribuut wanneer anderzijds het name attribuut al gebruikt moet worden? Gebruik gewoon $("input[name=foo]") en selecteer een input element op het name attribuut. Geef dat al voorgeselecteerde element dan mee aan je javascript AJAX validatie framework of vis met attr("id") het ID er uit als je het per sé ergens voor nodig hebt. (Waarvoor zou ik alleen niet weten, als je met name ook al DOM elementen kunt identificeren en opvragen.)

[b]Urk schreef op maandag 18 januari 2010 @ 16:24:
this.Name werkt ook niet, dus ik mis blijkbaar nog iets anders...
Ik krijg nu weer zo'n walgelijk gegenereerde naam: ctl00$main_content$productsubcat_naam_nl die zelfs door de $ karakters weer voor nieuwe foutmeldingen zorgt in JQuery functies.

Je kunt een regex replace gebruiken om je selector te escapen voor je het id gebruikt. De characters die ge-escaped moeten worden zijn terug te vinden in de documentatie van de jQuery selectors API. (En zoals eerder gezegd: tenzij je een nog niet door jou toegelichte afhankelijkheid hebt van de waarde in het id attribuut, kun je dus ook gewoon selectors maken op basis van het name attribuut...)

[ Voor 3% gewijzigd door R4gnax op 19-01-2010 23:12 ]

[Urk]

TeeDee schreef op dinsdag 19 januari 2010 @ 08:53:
[...]

offtopic:
Neemt niet weg dat je normale Intellisense prima deze opties aan kan geven imo. In ieder geval voldoende voor de initiële vraag van TS.

En waarbij je dus nog handmatig 'iets' moet doen; als in: je .net markup code aanpassen. Ik krijg namelijk de indruk dat Urk dat niet wil/kan doen omdat de applicatie al zo goed als klaar is. Urk komt er nu achter dat het, nu het <insert> Framework er aangeknoopt wordt, het e.e.a. bemoeilijkt wordt door de ID's/Name's van de controls.

TeeDee: dat valt wel mee, ben nu bezig met beheermodules die dit dus moeten regelen, veel andere code is idd al klaar en heeft dit niet direct nodig. Bovendien kan ik behoorlijk snel de standaard HTML markup vervangen door mijn nieuwe ASP.NET control.
Trouwens, nog 2 dingen. Reflector heb ik nog nooit van gehoord, wel even snel gegoogled maar moet ik eens naar kijken wat dat is. Je kan niet alles weten tegenwoordig...

Ten tweede is het vreemd dat Intellisense van mijn nieuwe control niet alle attributen correct laat zien, zoals bijv. maxlength, terwijl ik die wel kan gebruiken.

[Urk]

R4gnax schreef op dinsdag 19 januari 2010 @ 23:09:
[...]
Je kunt een regex replace gebruiken om je selector te escapen voor je het id gebruikt. De characters die ge-escaped moeten worden zijn terug te vinden in de documentatie van de jQuery selectors API. (En zoals eerder gezegd: tenzij je een nog niet door jou toegelichte afhankelijkheid hebt van de waarde in het id attribuut, kun je dus ook gewoon selectors maken op basis van het name attribuut...)

Dat was het eerste wat ik had gedaan om die $ signs te escapen, maar toch bleven die meldingen (weliswaar warnings) tevoorschijn komen in Firefox.