Les dejo un grafico del ciclo de vida de ASP.net 2. Ahora entiendo porque no se me ejecutaba ayer el Page_PreInit en el UserControl… es porque no ta 
-
« Inicio
Páginas
-
Categorías
-
Archivos
Archivos mensuales: Junio 2008
Si les da este chotisimo error, simplemente saquen cualquier tag de ASP.net que tenga que ver con los extenders del AjaxToolkit, y ponganlo cerca del control que quieren laburar. Por ejemplo, yo tenía un ajaxToolkit:UpdatePanelAnimationExtender, que referenciaba a un asp:UpdatePanel. Tenía los extenders arriba de todo, y el updatePanel más abajo. Cuando quise encerrar todo en un nuevo updatePanel, explotó todo y me daba ese error inendentible. La solución fue poner todo el código del extender justo antes del UpdatePanel, o sea, quedó así
<ajaxToolkit:UpdatePanelAnimationExtender ID="updAnimationExtender" runat="server" TargetControlID="upnlUsersList">
<Animations>
<OnUpdated>
<Parallel Duration="0.5" Fps="30">
<FadeIn />
</Parallel>
</OnUpdated>
</Animations>
</ajaxToolkit:UpdatePanelAnimationExtender>
<asp:UpdatePanel ID="upnlUsersList" runat="server" UpdateMode="Conditional">
<ContentTemplate>
...
</ContentTemplate>
</asp:UpdatePanel>
Y listo! Funciona todo perfecto.
Esta discusión la tuve cuando entré a trabajar a la empresa donde estoy ahora.
Donde estaba antes, laburabamos con 3 o 4 capas de componentes:
- Presentación (HTML o WinForms)
- Facade (solo si la aplicación era ENORME)
- Lógica
- DB
La presentación eran los ASPx y JS que fueran necesarios tener. La capa de Facade se usaba para hacer transformaciones, o tocar, si era necesario, la información que llegaba desde la capa de Presentación para pasar a la capa de Lógica. La de Lógica se encargaba de cualquier transformación a nivel lógico de la información, y por último, la capa de DataBaseAccess, que se comunicaba contra las Application Data Blocks de Microsoft (en esa época se llamaban distinto, pero whatever, era el objeto que en realidad tiraba la info a la DB, y se encargaba de las transacciones, etc).
Usando un ejemplo gráfico, quedaría de esta forma (no pongo facade aca, y es algo muy basico).
- La página default.aspx es la presentación
- La clase user.cs se encarga de verificar y transformar la información
- La clase userDB.cs se engarga de preparar la info para pasarle a las DataBlock
- La DataBlock ejecuta y devuelve True si todo salió bien
Sin embargo, aca en esta empresa sacan una capa (la de lógica) porque dicen que pasar entre capas tiene “mas peso”…
Alguien sabe si esto es verdad? O es un capricho? O sea, entiendo que una llamada a una capa mas pueden ser algunos milisegundos, pero a mi gusto, queda mucho mas prolijo de la primer manera.
La cosa era asi: yo tenia un dataset tipado, y le cambiaba el tipo de dato de Bool a Int, y el codigo se quejaba de que habia un problema de datos. Todo parecia bien, excepto que el choto del Visual Studio no me regeneraba el code behind del archivo .xsd para convertirlo a una clase, y seguia tomando como que el campo era Bool en vez de ser un Int.
Despues de renegar un rato (la mayoria de las veces es verdad, y uno intenta mandarle un valor que no corresponde al Dataset, y salta por error de tipos, pero en este caso, veiamos que en el Dataset Watcher el valor era FALSE en vez de ser 0 o 1), nos dimos cuenta la diferencia de ese dataset contra otros que existian en el proyecto: en este faltaba el valor en Custom Tool: todos los otros tenian MSDataSetGenerator, mientras el que no funcionaba estaba vacio.
Al agregarlo, se quedo pensando un rato y despues genero correctamente el CodeBehind de ese Dataset con los valores correspondientes.
Tambien paso que ese Dataset tenia vacio el Nombre (Name), asi que despues otras clases en la business dieron algunos errores. No se que fue lo que genero estos problemas, pero ya saben por donde buscar si alguna vez les pasa.
