[LUG.ro] Proyecto suscripción a jornada s

[Ulises M. Enrico]

hola, respecto a la DBs podriamos usar la libreria adodb que permite 
manejar de manera abstracta mysql, postgress, la he usado y esta 
bastante interesante (aunque puede haber otra), sobre el tema de los 
formularios creo que tendria que poder definirse que campo va a tener, 
ya que este sistema de registracion/acreditacion podria utilizarse para 
algun otra cosa, ahora no se me ocurre :) , pero estaria bueno que 
existiera alguna clase para crear formularios con sus respectivas 
validaciones asi de esta manera el que lo implemente no tenga que tocar 
codigo. Estaria copado que pueda usar modulos, como para ir con el 
tiempo agregandole cosas u otras personas lo hagan, encuestras, 
noticias, etc. no digo que hagamos todo ahora pero si que dejemos los 
"ganchos" para que algun dia se pueda realizar.
Usar web services? Ajax?

bueno dejo un saludo
Ulises M. Enrico

PD: sobre doxygen no lo conozco.
Arino Omar wrote:
> Acá envío un bosquejo del paper del proyecto, a fin de que los 
> colaboradores los vean y envíen sus sugerencias y correcciones.
> 
> Proyecto: ADMINISTRACIÓN DE SUSCRIPCIONES.
> 
> Nombre tentativo: JORNADAS LIBRES.
> 
> Plataforma de desarrollo: PHP 4
> 
> Herramientas auxiliares:
> 
> Base de datos: MySQL o Postgress. (Ver objetivos)
> 
> Servidor Web: Apache, evaluar compatibilidad con otros posibles servidores.
> 
> Librería de desarrollo: NY
> 
> Objetivo:
> 
> El objetivo del proyecto es poder contar con un sistema flexible de 
> administración de datos, para gestionar suscripciones a eventos varios 
> (jornadas, congresos, etc.), que permita obtener datos vía web, y 
> manipular la información obtenida para, registrar la asistencia, emitir 
> comprobantes, etc.
> 
> La información obtenida vía web debe ser almacenada de varias formas, ya 
> sea en una base de datos SQL, en un archivo de texto plano o enviada por 
> correo. Dependiendo la forma en que se almacenó el sistema debe permitir 
> de manera simple recuperar esa información para ser transportada a otro 
> lugar, para su reprocesamiento.
> 
> El sistema debe contar con una interfase clara para poder ser expandido 
> de acuerdo a las necesidades propias del usuario. De ser posible se debe 
> contar con un modulo de configuración que simplifique la configuración 
> del sistema.
> 
> El sistema debe contar con un instalador y estar perfectamente documentado.
> 
> Todo el código fuente debe estar comentado para una correcta compresión 
> de su funcionamiento, ante la falta de comentario en las modificaciones 
> aportadas estas serán rechazadas.
> 
>  
> 
> Definición de módulos:
> 
> a)      Obtención de datos
> 
>       Este modulo debe proveer un formulario web que permita al
>       interesado ingresar todos los datos definidos por el usuario. En
>       una primera instancia los campos ingresados serán estáticos, hasta
>       tanto se defina un método simple para configurar los datos
>       obtenidos y su futuro reprocesamiento.
> 
>       Verificación de la integridad de la información.
> 
>       Cuando los datos son ingresados en el formulario web estos datos
>       deben validados siguiendo determinados parámetros, como ser en
>       datos filia torios que se ingrese texto, en campos numéricos que
>       solo tomen números, en direcciones de correo que se ingresé una
>       dirección válida. Para lograr esto y previendo que la información
>       ingresada en el formulario puede variar a pedido del usuario se
>       deben definir tipos estándar de datos para poder realizar la
>       validación que para lograr mayor eficiencia se realizará
>       utilizando expresiones regulares, y no por medio de java scripts a
>       fin de lograr mayor compatibilidad con los distintos navegadores.
> 
>       Almacenamiento de la información
> 
>       A fin de flexibilizar la aplicación, la información obtenida debe
>       poder soportar varios modos de almacenamiento, de acuerdo a las
>       necesidades y posibilidades del cliente. Esto medios son en un
>       servidor SQL, en uno o varios archivos de texto plano o enviados
>       por correo electrónico.
> 
>       Comprobante de registración
> 
>       El sistema emitirá un comprobante de registración para que el
>       interesado cuenta con un pre-comprobante que agilice la
>       comprobación de datos cuando se presente en el evento. (Este
>       elemento puede ser utilizado de al manera que más crea conveniente
>       el cliente).
> 
> b)      Recuperación de datos
> 
>       Los datos ingresados desde la web deben poder ser recuperados por
>       el cliente de manera remota. Para lograr este objetivo se debe
>       proveer de una interfase para la captura remota de los datos, ya
>       sean estos almacenados en los tipos anteriormente detallados.
> 
> c)      Procesamiento de datos
> 
>       Una vez recuperada la información debe estar disponible para su
>       utilización.
> 
>       El sistema local de procesamiento contará con los siguientes módulos:
> 
> 1)      Alta. (para ingresar información de personas no registradas vía 
> web) Esta información validará contra los datos obtenidos de la web a 
> fin de evitar duplicaciones. Se puede verificar contra el comprobante de 
> registración web. Este puede ser una clave generada con la hash MD5 
> correspondiente a la unión de los campos Apellido, Nombre y Email.
> 
> 2)      Modificación. Permite corregir los datos ingresados en la web.
> 3)      Baja. La baja debe ser solo una marca correspondiente a un 
> posible error. El registro original nunca debe ser eliminado fisicamente.
> 
> 4)      Acreditación. Este modulo servirá para acreditar a los 
> asistentes. Debe permitir buscar por cualquiera de los campos de la 
> registración y por el comprobante de registración. Además debe permitir 
> modificar los datos o ingresar datos nuevos (relación con los puntos 1 / 
> 2 / 3). Debe emitir un comprobante de acreditación el cual debe imprimir 
> los datos definidos por el cliente.
> 
> 5)      Listados e impresiones.
> 
>             Este modulo debe permitir la emisión de listados,
>             certificados definidos por el cliente o reimprimir cualquier
>             comprobante emitido. A fin de poder llevar un control
>             estricto de estos debe llevar un contador de la cantidad de
>             veces que se emitió.
> 
> d)      Modulo de administración
> 
>       Este modulo debe permitir al usuario la configuración y adecuación
>       a sus especificaciones.
> 
> Reglas y normas comunes de desarrollo:
> 
> 1)      Nombre de variables : se utilizará el método camello para los 
> nombre. En el caso de variables todas empezarán en minúsculas, en el 
> caso que se utilicen mas de una palabra para formar su nombre, no 
> contendrán espacios, no estarán separadas por guiones y deben ser 
> representativo de lo que almacena,  la primer palabra se pone en 
> minúscula y la siguiente deben empezar en mayúscula, por ej.: apellidoNombre
> 
> 2)      Funciones: se utilizará el sistema doble camello. El nombre no 
> contendrán espacios y/o guiones empezarán con la primer letra en 
> mayúscula y las restantes en minúsculas y en el caso de estar formadas 
> con más de una palabra, cada una de ellas empezarán en mayúsculas, ej.: 
> ApellidoNombre.
> 
> 3)       Todas las variables serán tratadas como inseguras. Para esto se 
> debe deshabilitar la opción GLOBAL_REGISTER asignándole el valor OFF. 
> Además se deberá filtrar toda las variables recibidas para evitar 
> posibles ataques, limpiándolas de códigos HTML, etc.
> 
> 4)      Todos los formularios enviarán sus datos por el método POST.
> 5)      Todos los parámetros se enviaran por el método GET (a través de 
> la url).
> 6)      Todos los campos de los formularios se trabajarán como ARRAY, 
> para facilitar la limpieza del contenido.
> 
> Integrantes del proyecto TODO NOSOTROS!!!!!
> 
> 
> 
> Omar Arino
>