[Php-avanzado] Trabajo Jorge Era: Coordinando encuentro en la FI Era: Cursada 2do cuatrimestre 2012

[Leonardo Tadei - Pegasus Tech Supply]

Hola jorge,

El sáb, 09-03-2013 a las 18:51 -0300, Jorge Di Iorio escribió:

>       En cuanto al trabajo, te comento que lo tengo pero para reservas
> de mesas de restaurant en vez de complejos deportivos, ejejejeje. El
> tema es que me surgió un laburo durante la temporada y lo estoy
> terminando. los conceptos son muy parecidos.

	Ok.  Buenísimo el aprovechar un trabajo para hacer la tesis del curso.
	Estoy de acuerdo con que los conceptos son muy parecidos, pero
acordate: el diablo está en los detalles.
	Lo que voy a necesitar es una SRS de esto, porque si no, no tengo sobre
qué evaluar si hace lo que tiene que hacer, la completitud y si hace las
cosas bien...

>  Igualmente quiero sacarme unas cuantas dudas y consulltar un par de
> recomendaciones antes de volcarlo y hacer el de las canchas de
> papi.... 

	Ok.

>       Tengo 5 cuestiones para consultar por aquí:

	Veamos:

>       1: El sistema de reservas lo usan desde una tablet (me pelié
> mucho con css para que quede "aceptable").

	Trabajar en HTML5 y CSS con "media querys" te facilita mucho este tipo
de trabajos.

>  Traté de no usar JS mas que para temas visuales y de comodidad de
> navegación.

	O no entiendo qué querés decir con esto, o no estás usando HTML5 y CSS,
que resuelven las cuestiones visuales y de navegación son nada de código
JS...

>  Pero si utilice AJAX para recargar el mapa de mesas del restaurant
> sin recargar toda la página del alta o modificación de la reserva.

	Es un buen ejemplo de un caso en que vale la pena usar AJAX.

>  El tema es... tengo que mostrar la disponibilidad de mesas para
> asignar a los comensales según la fecha y el turno(horario). Lo que
> hago es lo siguiente: cuando se dispara el evento de cambiar fecha o
> turno, llamo con AJAX a un método que recarga el mapa(una tabla) de
> las mesas del resto con las disponibilidades. 
>           No me encontré con dificultades a la hora de dar el alta, ya
> que se carga una fecha, un turno, se eligen las mesas y se graba!
> peroooo cuando voy a modificar me encuentro con que empiezo a tener el
> riesgo de que si quiero cambiar alguno de los atributos antes
> mencionados puedo no llegar a tener la misma disponibilidad de mesas
> porque en otro momento ya las ocupó otra reserva.... y varias cosas
> mas.......
>           En conclusión la pregunta es: Sigo volviendome loco metiendo
> validaciones y advertencias por todos lados o trato la reserva como un
> comprobante que cuando se graba no se puede modificar(solo el
> estado:[reservado, confirmado, caido, cancelado, anulado]), y que en
> ese caso la anulen y hagan otra??? queda muy desprolijo???   

	Bueno, la respuesta a tu pregunta debería estar en la SRS: si hace
falta poder mover una reserva vas a tener que hacer todas las
validaciones necesarias antes de hacer el movimiento, para saber si es
posible, y si no decir que no se puede mover.
	Ahora bien, no me queda muy claro por qué estas validaciones son más
complejas que las de agregar una nueva reserva a una mesa, ya que el
algoritmo debería ser el mismo.
	Si no tenés dificultades a la hora del alta, no deberías tener
dificulades a la hora de un movimiento, porque si se puede dar de alta
una reserva también se puede mover... y luego borrar la anterior o
editar la existente es un mero detalle interno del software.


>        2: Adjunto un txt con el método que graba y modifica las
> reservas. en un movimiento de éstos se tocan mas de una tabla por lo
> que tengo que usar transacciones. por lo que estuve viendo la manera
> de implementarlo en éstos casos es ir viendo si alguna de las querys
> da error y hacer el ROLLBACK y si llego bien al final de las
> instrucciones COMMIT.

	Es correcto tu enfoque de que, al modificar varias tablas, encapsules
todo en una transacción de la DB para mantener la atomicidad del proceso
completo.
	Si embargo vas a ver poco el uso de transacciones en aplicaciones web,
porque la única oportunidad de tener una inconsistencia se da por una
query mal ejecutada de algo que se puede validar previamente, ya que el
servidor web no inicia la ejecución del código hasta que termina la
petición, y una vez que empieza el proceso no hay como detenerlo.
	En una aplicación que se sirva de varios servidores concurrentes, la
transacciones son indispensables, porque varios Apache pueden querer
usar la DB a la vez.
	En cualquier caso, es una linda práctica.

>        Las preguntas acá son:
>               a) está "correcto" como estoy implementando éstos
> algoritmos? alguna recomendación? 

	Sin la SRS y sin las tablas, no puedo opinar casi nada!!!

	No entiendo el DELETE a reservas_mesas, y mucho menos que el INSERT sea
condicional... de hecho no entiendo la existencia de la tabla
reservas_mesas, porque conociendo un poco el problema pero sin tener ni
idea de la SRS, pareciera que lo que sea que se guarda ahí es un pifie
en la normalización :-(
	Pero no me hagas caso, porque sin SRS hablo basado en suposiciones.


>               b) mi inseguridad viene por el lado que cuando programo
> en descktop utilizo excepciones (TRY CATCH) y hago un THROW con mis
> mensajes de error... por lo que estuve viendo en foros al programar
> como lo estamos haciendo no lo hacen de ésta manera. se mezclan
> conceptos o es muy enroscado hacerlo así? o se utiliza cuando se
> programa solo con objetos? vuelvo a la pregunta anterior, si me decis
> quue así como en el adjunto  esta bien, me quedo tranquilo.  

	Por lo que te digo arriba, no te puedo dejar tranquilo: me falta
contexto.
	Respecto a los TRY CATCH, acá los usamos permanentemente, pero es que
estamos implementando en POO hace rato. Sin embargo, lo que viste en los
foros no parece estar mal, porque si estás usando las funciones mysql_*,
estas no generan errores catcheables, a diferencia de las PDO que sí los
generan. A su vez, las PDO son una ActiveRecord, así que te queda todo
con semántica de Objetos y un código del tipo:

try {
   ...
   ...
   $count = $dbh->exec("DELETE FROM fruit WHERE colour = 'red'");
} catch (PDOException $e) {
    echo "Failed to get DB handle: " . $e->getMessage() . "\n";
}

	es de lo más habitual, pero si usás las mysql_*, vas a tener que poner
la query en un IF y actuar según el resultado de la función.

	En resumen: si estás haciendo PE, seguí con los IF, y si estás haciendo
PDO, usá los try - catch de toda la vida.


>        3: que método implementamos para encriptar las contraseñas para
> el loguin??? donde se desencripta y se compara??? nunca lo hice....

	Una forma simple de no dejar las contraseñas en texto claro, aunque no
sea encriptación, es guardar el resultado del md5() de la password. Lo
bueno del md5() es que es rápido y no tiene reversa (es un algoritmo
asimétrico)
	Luego en el login, le hacés md5() a lo que ingresa el usuario y lo
comparás con lo almacenado.

>        4: Inyección SQL, ya me encontré con los primeros problemas que
> han metido algún carácter raro y pum! que solución reocomendás
> implementar para ésto??? 

	Pasarte a PDO, que es "safe" por diseño al ejecutar querys.
	Igual, las mysql_* están ya "deprecated", así que por lo menos pasate a
las mysqli_*

>        5: Concurrencia¿? que pasa si se meten de dos lados a cambiar
> la misma reserva.... y ambos ven los datos de una manera primero
> modifica 1 y después el otro pensando que modifico los datos primarios
> que veía.... vuelvo a consultar el item antes de grabarlo y comparo
> los datos antes de modificaros y doy una advertencia sin son
> distintos?? hay algo mas simple???

	Es rarísimo que se produzca la concurrencia: gana el primero usando un
solo Apache, así que el 2do se encuentra con un mensaje de "mesa
ocupada" o "no hay meses disponibles".


> Saludos y gracias (no pienzo tocar una tecla en todo el domingo, lo
> prometo!!)


	Por nada!
	No toques ni una tecla, y escribí en papel la SRS... el lunes la tipeás
y me la pasás por mail }:->


-- 
Leonardo Tadei
leonardot en pegasusnet.com.ar
Web: http://leonardo.tadei.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key