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

[Nicolás Aimetti]

Buenisimo... parece que empezamos a avanzar, me sumo con algunos 
aportes, sugerencias u/o consideraciones...

Documentación:
    Propongo que usemos doxygen 
(http://www.stack.nl/~dimitri/doxygen/index.html) para manejar la
    documentación del proyecto. No sé si entre los que nos estamos 
sumando haya gente con experiencia en
    está herramienta (o sea, no sé si vale la pena que explique para que 
sirve, como se usa y que hace,
    o si la mayoría ya la conocemos), pero puedo asegurar que es muy 
simple de usar (aunque por la cantidad de
    opciones que ofrece al principio uno podría llegar a pensar lo 
contrario) y que las ventajas son enormes.
    Funciona bastante bien con php,  no tan bien como con C++ o java, 
pero personalmente creo que con lo
    que nos ofrece nos sobra.  Si alguien quiere que me extienda en este 
tema simplemente avise.

Base e Datos:
   ¿MySQL o Postgress? That is the question. ¿Usamos Postgress? ¿Usamos 
MySQL? ¿Hacemos que sea
   compatible con ambos RDBMS y que quien lo use elija?   Creo que está 
última opción sería la más adecuada,
   sin embargo con esto no alcanza...
   Así usásemos sólo MySql también tendríamos que decidir que versión 
soportamos, dado que  entre
   la 5 (actualmente  estable, soporta vistas, subqueries, etc..) y las 
4.x no son pocas las diferencias
    y las facilidades que ofrecen (y esto sin  entrar en el tema de si 
usamos myISAM o InnoDB).
   Con Postgress quizás la cosa en un poco más sencilla porque de 
entrada siempre soporto más funcionalidades
   que mysql, o sea que no tendremos el problema de que si usamos vistas 
la versión tiene que ser tal para
   adelante, o que si necesitamos soporte para transacciones debemos 
usar InnoDB, etc... (ojo, no quiero
   con esto decir que prefiero Postgess, que de hecho no es así ;) )
   Creo que lo primero es decidir contra que base trabajamos, si MySQL, 
Postgress o ambas. Lo ideal sería
   usar SQL compatible con ambas y soportar ambos motores. Sin embargo 
hay que tener en cuenta que esto
   agrega varias variables de complejidad al desarrollo, o sea, hay que 
testear en doble, no siempre la solución que
   funciona en la primera anda igual en la segunda, etc... Y tampoco 
creo que sería tan grave si dijieramos
   que nuestra aplicación sólo fue testeada en MySql pero debería poder 
andar bajo Postgress o viceversa,
   intentando programar de la forma más compatible posible.
   Bueno, la corto acá, a ver que otras opiniones hay dando vueltas...


Otra cosa ¿seguimos posteando en este thread, en las tres listas? Por 
ahí me parece sería bueno en principio dejar está discusión en una sola 
lista (programacion@lugro.org.ar por ejemplo).
En un futuro sería bueno tener un espacio propio para el proyecto, ya 
que por ahí, si bien este proyecto nace del lugro, debería tener un 
lugar propio (dentro o fuera del mismo) en donde discutir estos temas 
sin molestar a quienes no estén involucrados directamente en el proyecto.

Saludos,
             Nicolás.


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
>