langsam das eventmodel von asp.net verstanden
wenn man einen repeater mit buttons drin hat, deren funktion von was anderem (z.b. einem drop down menu nebenan) abhängt und man auf einen klick reagieren möcht dann:
rendert man den repeater und das dropdown mal auf page_load
dann klickt der user das dropdown - man rendert darauf wieder den repeater, dann wird das dropdown-selectionChangedDingsBums-Event aufgerufen und man rendert also den repeater nochmals und schreibt am besten den veränderten wert (z.b. die zu verwendende sprache) in den viewstate
klickt der user dann auf den repeater, rendert man den repeater erneut (beachtet diesmal die werte aus dem viewstate) und dann wird das buttonClickedDingsBums-Event aufgerufen und dann macht man was man halt grad will
also rendert man den repeater viermal (wenn man pech hat samt DB-Access) und kann nur auf wunder in punkto c# geschwindigkeit und ado.net connection pooling und caching hoffen
die resultate sind dann eh nit langsam aber man wundert sich
toll auch, dass alle buttons mit denen man "interessante" interfaces bauen könnt, bzw. welche ein bissi komfortabler methoden aufrufen könnten javascript verlangen und man somit bei jeder site außerhalb eines intranets eh wieder beim lustigen querystring auslesen landet (bzw. mal Server.Transfer() ansehen)
andererseits wenn man nix gegen javascript hat und nur fix fertige controls verwendet (und nsich somit nit selbst um viewstate, renderin u.ä. kümmern muss) fühlt sich arbeiten durchaus wie apple-script-studio/visual-basic mäßiges desktop-app-entwickeln an
wenn man einen repeater mit buttons drin hat, deren funktion von was anderem (z.b. einem drop down menu nebenan) abhängt und man auf einen klick reagieren möcht dann:
rendert man den repeater und das dropdown mal auf page_load
dann klickt der user das dropdown - man rendert darauf wieder den repeater, dann wird das dropdown-selectionChangedDingsBums-Event aufgerufen und man rendert also den repeater nochmals und schreibt am besten den veränderten wert (z.b. die zu verwendende sprache) in den viewstate
klickt der user dann auf den repeater, rendert man den repeater erneut (beachtet diesmal die werte aus dem viewstate) und dann wird das buttonClickedDingsBums-Event aufgerufen und dann macht man was man halt grad will
also rendert man den repeater viermal (wenn man pech hat samt DB-Access) und kann nur auf wunder in punkto c# geschwindigkeit und ado.net connection pooling und caching hoffen
die resultate sind dann eh nit langsam aber man wundert sich
toll auch, dass alle buttons mit denen man "interessante" interfaces bauen könnt, bzw. welche ein bissi komfortabler methoden aufrufen könnten javascript verlangen und man somit bei jeder site außerhalb eines intranets eh wieder beim lustigen querystring auslesen landet (bzw. mal Server.Transfer() ansehen)
andererseits wenn man nix gegen javascript hat und nur fix fertige controls verwendet (und nsich somit nit selbst um viewstate, renderin u.ä. kümmern muss) fühlt sich arbeiten durchaus wie apple-script-studio/visual-basic mäßiges desktop-app-entwickeln an