El Lunes 28 Noviembre 2005 17:25, Arino Omar escribió: Una masa Omar, cuando empezamos????
Besotes
> 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
--
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Natalia Victoria Morán
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Linux User Registered #216577
- ----------------------------------------------
Actuar es fácil; pensar es difícil...
Actuar según se piensa
es aún más difícil...
Johann Wolfgang Von Goethe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCyqVsN0pu4F13mzURAiNIAJ0TnwFPV/Ii9MIerFifl1lgQ2+e+gCgu6LF
MP4v73t5TZHTJ7R5KyLJuK8=
=GeZ1
-----END PGP SIGNATURE-----
pgpd8yleJQN3P.pgp
Description: PGP signature
