2008/12/1 Leonardo Otero <[EMAIL PROTECTED]> > Respondiendo a una de los temas desde mi experiencia previa en java: > > Hasta donde entiendo que el usario ingrese un valor erroneo es algo > perfectamente posible y no deberia ser tratado de la misma forma que se > trata un error de aplicación (ejemplo falta de conectividad con la base). > Un ingreso de un valor registrado puede resultar en una excepcion producto > de una clave duplicada pero si el caso es "funcionalmente hablando > esperable" y puede ser manejada entonces la excepcion deberia ser consumida > (al menos en el caso de java, entiendo que ruby puede no ser necesario por > tanto buscaria la forma en que el codigo quede mas entendible/mantenible y > elegante) y el usuario deberia simplemente recibir un mensaje advirtiendo de > la duplicación en forma user friendly. > > Es aqui donde aparece la idea de tener una capa de validacion. > > La pregunta seria ahora donde hago la validación en el cliente o en el > servidor? > > Lo mas seguro segun versan las buenas practicas es tener validación en > ambas partes pero claro esto es más costoso en terminos de desarrollo si el > framework no lo soporta. > > Tenerlo del lado cliente en general mejora la experiencia de usuario ya que > no tiene que esperar molestas recargas de paginas. Cave aclarar que con web > 2.0 tenemos la posibilidad de tener un unico validador en servidor y > reutilizarlo con llamadas desde cliente sin necesidad de recargar la pagina, > esto sera especialmente util si podemos pagar el precio de la latencia de > estas validaciones ya que con un framework apropiado que nos resuelva en > forma elegante las validaciones no necesitaremos codificar por duplicado > nuestras validaciones. > > Como parte del proceso de validacion es importante agregar que en ningún > caso los datos deberian ir directamente a la base sin un > pre-procesamiento/normalizacion de los datos ya que la inyeccion de codigo > SQL es un potencial problema de seguridad y por tanto un riesgo a manejar. > > Para responder lo del save, save!, dejame que termine de leer el libro que > me gane (soy muy nuevo en ruby todavia :) pero te adjunto lo que encontré en > el framework open source de ecommerce substruct. > > http://code.google.com/p/substruct/ vengo analizandolo desde hace unas > semanas y me resulto interesante. > > Saludos, > > Leo > still another monkey java coder ;) > > > 2008/12/1 Pedro Visintin <[EMAIL PROTECTED]> > >> Hola Gente: >> >> >> Tema medio filosófico que se aplica a otros lenguajes también. >> >> Cuando tenemos que, por ejemplo, grabar un modelo active record en un >> controller. >> >> No se imaginen cosas raras, el modelo no tiene ninguna cosa mágica dentro, >> solo validaciones. >> >> Qué usamos save! o save? >> >> Pregunta adicional, los errores funcionales (el usuario mete mal los >> dedos) deben ser tratados como excepciones? >> >> Todo debería ser una excepción? o se simplifica si los errores funcionales >> (las password no coinciden por ejemplo) son manejados por el código sin >> excepciones y los técnicos (duplicate key entry) son manejados por >> excepciones. >> >> Que piensan? >> >> P >> >> -- >> Pedro Visintin . S o f t w a r e A r c h i t e c t >> http://www.pedrovisintin.com >> >> Ruby On Rails Argentina. http://blogs.onrails.com.ar >> >> Personal page: >> http://www.p-e-t-e-r-p-u-n-k.com.ar >> >> "Todo descontento por aquello que no tenemos parece provenir solamente de >> nuestra falta de gratitud por aquello que tenemos" >> >> >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> >> > > > -- > Leonardo Daniel Otero > CEL:155 405 7196 > http://www.jstruts.com.ar ingresa y enterate de todas las novedades en > RC!!! > > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > >
Yo creo que depende donde es el dominio de tu aplicación, los errores funcionales (los esperados) dentro del dominio deben ser manejados "en general" sin excepciones salvo excepciones ;-) Para mi, el concepto de excepción es algo inesperado, que no puede ser resuelto, se produjo una "condicion inesperada" una "excepción" En el caso de que uno tenga la precondición que todo viene valiado de la vista, podría ser otro caso. Interactuando con otras aplicaciones o bibliotecas es lógico trabajar con excepciones, pero dentro del dominio de la app si el error es algo esperado, para mi no debería ser lanzada una excepción. Me encantaron las opiniones ;-) Saluti P -- Pedro Visintin . S o f t w a r e A r c h i t e c t http://www.pedrovisintin.com Ruby On Rails Argentina. http://blogs.onrails.com.ar Personal page: http://www.p-e-t-e-r-p-u-n-k.com.ar "Todo descontento por aquello que no tenemos parece provenir solamente de nuestra falta de gratitud por aquello que tenemos"
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
