Bienvenidos.
Vamos a ver la introducción a Lápiz Cetelem.
De qué se trata?
Bueno, el happy select o el select en sí es una clase, un objeto de Java que se utiliza para crear
una página web, pero una página web dinámica que tiene características del protocolo HTTP.
Es decir, se encarga de procesar un request, lo maneja y por supuesto, también de acuerdo al procesamiento
que se realiza, devuelve una respuesta.
Otra característica es que son manejado.
Esto significa que se crean por el contenedor de Cerler, que también se le conoce como contenedor web.
Se crean, se almacenan y tienen un ciclo de vida.
Este ciclo de vida manejado por este contenedor que después vamos a ver.
Otra característica importante que son mapeados os asigna a una ruta wireless para que después, mediante
un navegador web o un cliente HTTP podamos acceder a un select y realizar una petición y haga un procesamiento.
Bien, veamos cómo funciona el Saleta.
Vamos a tener un cliente, por ejemplo, un navegador con contenido HTML, un HTML estático o bien una
JSP.
Incluso puede ser otros, otros.
Se muestra en pantalla esta información y el usuario va a interactuar con esta página.
Va a realizar algún tipo petición.
Esto puede ser mediante un enlace wireless haciendo clic en una ruta °l enviando parámetros, pero también
puedes enviar tu formulario llenando campos y enviando este formulario se envía al servidor.
Pero quién maneja?
Quién procesa?
Esta información es el SELECT.
Es decir, todo pasa por Starlet.
Bueno, por detrás de escena hay un From Controller que se encarga de manejar los Arlett y según la
ruta °l del request va a asignar el cerle correspondiente que está mapeado a esa ruta va a obtener estos
parámetros que son enviados por este cliente.
Parámetros http mediante el objeto http select rickles.
Después vamos a ver más en detalle, pero lo importante es que el usuario puede enviar parámetros y
el SELECT lo recibe y lo procesa.
De acuerdo a estos parámetros va a realizar algún tipo de tarea, por ejemplo, algún acceso a la base,
datos, lógica, negocio o algún cálculo matemático.
Y de acuerdo, eso va a devolver una respuesta al cliente, típicamente un objeto.
Y ese objeto se muestra en esta plantilla, por ejemplo.
JSP Pero también, no solamente muestra información en el navegador como respuesta como resultado,
sino que también podría redirigir hacia otro saddle o o hacia otro JSP.
Es decir, podría redireccionar la respuesta a otro recurso.
Bien, veamos una característica importante que es el contexto MVC con el API Select.
También podemos implementar un patrón m%s donde toda la responsabilidad es decir, el flujo de nuestra
aplicación cae por shores, select y select.
Se encarga de maquinar todo, de manejar las peticiones del usuario que le están llegando.
manejÃ respuesta, pero entre medio tiene que realizar alguna tarea o interactúa con la persistencia
con lógica negocio, con consultas según los parámetros que envía el usuario y obtiene un resultado
del servicio de la lógica de negocio.
Ese resultado generalmente es un objeto de modelo.
Puede ser un POJO, un objeto que contiene los datos de una aplicación con atributo método quieten setter.
También se le conoce como lo llama Vinz y como respuesta se lo devuelve al cliente.
En la respuesta.
Pero esta respuesta sería una vista JCP separado y eso es separación de roles, separación entre el
controlador, el celeste de nuestro controlador, el modelo o el resultado que devuelve la lógica negocio
el el service, por ejemplo, y la vista HTML es el JSP.
Había explicado que un SALDE también puede tener HTML embebido, es decir, dentro de la misma clase
en código Java mediante el objeto print greater podemos guardar contenido en la repuesta contenido HTML
y es decir que el SELECT hace papel de vista y controlador al mismo tiempo.
Eso se puede hacer ahora no recomendado.
Lo mejor es separar los roles y llevar todo el HTML a una JSP a un archivo separado que se encargue
solamente de la presentación de manejar este código HTML.
Además, hace mucho más amistoso, mucho más fácil de manejar html.
Claro, porque si estamos utilizando HTML con Java dentro del SELECT, todo mezclado anidado se fijan
o se hace muy difícil manejar porque tenemos que concatenar el HTML con otras variables y también es
poco manteni dible en el tiempo.
Bien, veamos un repaso del rico y el repost.
Yo sé que lo vimos, lo vimos en la introducción del protocolo HTTP, pero acá lo vamos a ver más orientado
a la PÍSALE.
Bueno, ya vimos lo que es un rico es una petición web, una solicitud, información que es enviada
desde un cliente, típicamente un navegador, pero también podría ser, por ejemplo, una aplicación
en Android, una aplicación con algún frontend JavaScript como Angular, como React.
Se fijan?
Bueno, da lo mismo, pero envía información desde un cliente hacia el servidor.
Este servidor, un contenedor web, por ejemplo Tomcat.
Sitios de aplicaciones recibe este request y según el for controllers según la ruta jureles que te tapiada
los deriba a un starlet, exhalen maneja este request, lo procesa y más de lo mismo, más de lo que
hemos hablado.
También dentro del request están los datos o parámetros que envía, que ingresa el usuario mediante
una ruta °l en una petición http get o mediante un formulario una petición http post.
También es request maneja cabeceras las cabeceras http que también en metadata esa información del cliente.
Eso también lo Bhima ven?
Y la respuesta es lo que el servidor devuelve al cliente una vez que se procesa el recuestas típicamente.
Pues el texto en formato HTML o texto plano también puede ser Jason.
Si trabajamos con API, rest, xml o datos binario alguna imágenes, video, pdf, un exel.
En fin.
Pero también tenemos las cabeceras de la respuesta donde va el tipo contenido el content type.
También está el estado de la respuesta el http status.
Se acuerdan los código 200 cuando todo sale bien?
404 cuando no existe la página web.
El recurso cuando nos encuentra.
Por ejemplo el select.
Ahora veamos los métodos http soportados por el Ãpice atleta.
Son 7.
Acá tenemos la lista.
Lo más típico cuando trabajamos con API Rest, por ejemplo el Dilek, el GET, el post y el put@ son
los 4 principales en API Rest en edad písale son implementado dentro de la clase servlet de la clase
http halder con los métodos dú algo.
Por ejemplo Nugget.
Grupos Dudek.
AR Claro, esos son cuando trabajamos con API rest, pero en una aplicación web común y corriente.
Típicamente vamos a trabajar con Tom-Tom, con el sujeto y con el post.
Ahora estos métodos se llaman de forma automática mediante el método cervesa y de acuerdo al tipo de
request.
Si se envía un tipo GET va invocar de forma automática el método Nugget.
Ahora, si la petición viene de un formulario.
Por lo tanto proviene de un tipo post, va a ejecutar el método rupos.
Si mediante una jureles va a seguir este flujo http rico en GET se llama el service.
El server deriva al Huguette.
El luge devuelve la respuesta al service.
El servidor devuelve la respuesta al cliente, al navegador y la muestra pantalla.
Si es un rico es del tipo post lo mismo, pero el service va a embocar en método rupos.
El Dupont va a procesar el formulario o el contenido que se envía en el cuerpo del request y lo va a
devolver.
Se fijan al service y el service al usuario.
No se preocupen, pero todo esto tema quizás sea un poco abstracto.
Lo vamos a ver durante el curso ya con ejemplo, con código.
No me gusta repetir mucho las cosas que digo, pero a veces lo hago porque para evitar problemas, errores,
típico.
Pero el método service nunca lo tenemos que sobrescribir.
De la clase hates debe ser Lett, porque él se encarga de llamar a los métodos de la petición a los
métodos http Nugget o Dupont, o lo que sea, de forma automática él lo maneja.
Si los orcs vivimos no se van a llamarlo metodo U.G.T.
Ni mi post no va a funcionar correctamente.
Entonces, si queremos manejar una petición con Salde, lo que vamos a sobrescribir a implementar van
a ser los métodos dú get tu post o dú algo, pero no el service.
Continuemos.
Veamos un poco la estructura de las clases e interfaces de la pisarlas.
Bueno, la clase principal y con la que vamos a trabajar y con implementemos nuestro propio Arlett,
vamos a tener que heredar de esta clase de http select en la clase más importante, pero no es la única
porque tenemos generic select que es una clase tracta, la cual hereda http select.
Y luego tenemos la interface Arlett, que es una interfaz con métodos por supuesto sin implementar.
Protocolo de implementación como el método init, el método service y el método Destroy son los métodos
más importante.
Hay otros más, pero esos tres son lo más importante porque representan el ciclo de vida.
La clase generics.
El le da una pequeña implementación al init y al distraido.
Pero obviamente nosotros podríamos sobrescribir.
Es un método irra implementarlo a nuestra forma.
Después vamos a ver que el método init es para inicializar el stadler y el distraido es para destruir
o cerrar el Cerler para terminar con el ciclo de vida.
Y el método servis es un método abstracto en la clase generics Selden no tiene implementación.
Quien implementa este método servis https: Arlett le da una implementación tal como ha dicho hace poco,
según el tipo de petición o el http método.
Si es get o post se encarga de llamar a los método Bullet Dupont do put respectivamente.
Por lo tanto, nosotros nunca vamos a sobrescribir el service jamás.
Solamente vamos a implementar los métodos dú algo.
Luego el https: arlett trabaja con el https: el let response para la respuesta.
Rickles para la solicitud y a su vez cada uno de todos implementa la interfaz Saddle Request y Celle
ripostó.
Pero de esto lo único que me interesa es que la clase principal es el http Selden, en la cual nosotros
vamos a heredar de esta ya sobrescribir los métodos Duckie Odú Post y por último, veamos el ciclo de
vida de un celler.
Bien, cuando implementamos un Saler, bueno, vamos a compilar nuestra aplicación.
Vamos a realizar el despliegue en Tomcat o en un servidor de aplicaciones y automáticamente estos Hallet
que están en nuestra aplicación se van a registrar en el contenedor de Tomcat en un contenedor web o
de Stadler como se le llama entonces se registra, se almacenan y dentro se maneja el ciclo de vida.
Una vez que se registran, se le invoca el método init, pero una sola vez es para inicializar el servlet
se llama una sola vez dentro de todo el ciclo de vida y muy parición constructor.
En el fondo podemos inicializar algunos parámetros de configuración, alguna conexión que necesitemos.
Se fijan algo por el estilo.
Después de que se realiza una petición, no es que se cree un shell de nuevo?
No, para nada.
El chalet es compartido por toda la aplicaciones y por todos los clientes.
Es como un singleton.
Va a estar prácticamente durante el tiempo que va a estar nuestra aplicación desplegada en el servidor.
Pero lo que si cada vez que se realiza un rico test se genera un hilo o un proceso separado del resto
por cada request, es un único hilo independiente a los demás.
Y acá se invoca el método service y por cada uno se a pasar un objeto nuevo y también único del Rickert
y del Response.
Por cada cliente, por cada usuario que realiza una petición.
Se pasa por argumento en el service.
El método service obtiene el request, el response y lo va a derivar al Bullet o al Dupont o al método
Dú que corresponda.
Y ahí procesamos nuestra petición.
Hacemos lo que tenemos que hacer.
Entonces importante que quede claro que durante el ciclo hoy día un SELECT puede recibir muchas cientos
y miles de peticiones, cientos de llamada al método Arques y cada una se manejan en un hilo distinto,
separada, el resto nos afectan.
Y al finalizar.
Por ejemplo, si un select pasa mucho tiempo que no recibe ninguna llamada, no recibe ningún request,
automáticamente se va a destruir.
Por lo tanto, se invoca el método destroy y ya deja de ser manejado por el contenedor de SELECT.
O bien cuando bajamos el servicio de nuestra aplicación, también se destruyen todos los servlet de
nuestra aplicación y se le va llamando el método y Troi.
El método Destroy es para cerrar todo.
Por ejemplo, si en el init inicializamos algún recurso, por ejemplo, si abrimos alguna conexión en
el destroy la tenemos que cerrar y conexión de objetivo.
Por ejemplo, alguna base rato.
Ahora no está recomendable quienes iní tengamos una conexión a la base de datos porque sería una conexión
compartida por varios request por el cliente.
La mejor opción es tener una conexión de un pull de conexiones distinta y se le asigna una a un cliente
en particular y manejar un pull, por ejemplo.
Se fijan entonces cuando se inicializa un Rickert, a un usuario se le asigna una conexión del pool
y después, cuando finaliza el request, libera esa conexión para que sea utilizado por otro usuario
y así y además lo importante que maneje su propia transacciones independiente a los demás clientes que
nos afectan unos con otros.
Y por último, otro punto importante de los Alder como un objeto select puede ser compartido por muchos
usuarios.
Ojo, no el método Service, porque el método service se llama en un hilo distinto, pero en general
la clase Select es única o Aloma.
Podríamos tener un pool de San Letra, pero independiente es compartido por varios cliente por varios
usuario y si tenemos un atributo que guarda información en este SALDE y un usuario modifica ese atributo,
ese valor de ese atributo va a afectar al resto.
Entonces es muy importante que un SELECT no maneje estado sea Styles sin estado.
De hecho el rico es y el response y el protocolo HTTP por defecto no maneja estado.
El SALDE tampoco debiese manejar estado para que nos afecten a los demás.
Cualquier estado que queramos manejar o mantener algún objeto entre peticiones, entre páginas.
Utilizamos el objeto http session.
Pero ese otro tema que después vamos a ver.
Por ejemplo para un carro de compra.
Pero no tener un objeto carro de compra como atributo encarcelen.
Claro.
Porque si un usuario modifica agrega producto, esos productos se van a ver reflejado también para los
demás usuarios.
Y no le diré que ese carro de compra o esa información de ese usuario sea solamente específico para
ese usuario.
Se tiene que manejar en un contexto distinto.
En la sesión.
Bueno, eso sería todo.
Creo que me queda un poco largo la introducción del SELECT.
Lo dejamos así y nos vemos en la siguiente clase.