[LUG.ro] Proyecto suscripción a jornadas

[Natalia Victoria Morán]

--nextPart3720088.0UhA4cCRo0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

El Lunes 28 Noviembre 2005 17:25, Arino Omar escribi=F3:
Una masa Omar, cuando empezamos????


Besotes

> Ac=E1 env=EDo un bosquejo del paper del proyecto, a fin de que los
> colaboradores los vean y env=EDen sus sugerencias y correcciones.
>
> Proyecto: ADMINISTRACI=D3N 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 servidore=
s.
> Librer=EDa de desarrollo: NY
>
> Objetivo:
>
> El objetivo del proyecto es poder contar con un sistema flexible de
> administraci=F3n de datos, para gestionar suscripciones a eventos varios
> (jornadas, congresos, etc.), que permita obtener datos v=EDa web, y manip=
ular
> la informaci=F3n obtenida para, registrar la asistencia, emitir comproban=
tes,
> etc. La informaci=F3n obtenida v=EDa web debe ser almacenada de varias fo=
rmas,
> ya sea en una base de datos SQL, en un archivo de texto plano o enviada p=
or
> correo. Dependiendo la forma en que se almacen=F3 el sistema debe permiti=
r de
> manera simple recuperar esa informaci=F3n para ser transportada a otro lu=
gar,
> 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=F3n que
> simplifique la configuraci=F3n del sistema. El sistema debe contar con un
> instalador y estar perfectamente documentado. Todo el c=F3digo fuente debe
> estar comentado para una correcta compresi=F3n de su funcionamiento, ante=
 la
> falta de comentario en las modificaciones aportadas estas ser=E1n rechaza=
das.
>
> Definici=F3n de m=F3dulos:
>
> a)	Obtenci=F3n de datos
> 	Este modulo debe proveer un formulario web que permita al interesado
> ingresar todos los datos definidos por el usuario. En una primera instanc=
ia
> los campos ingresados ser=E1n est=E1ticos, hasta tanto se defina un m=E9t=
odo
> simple para configurar los datos obtenidos y su futuro reprocesamiento.
>
> 	Verificaci=F3n de la integridad de la informaci=F3n.
> 	Cuando los datos son ingresados en el formulario web estos datos deben
> validados siguiendo determinados par=E1metros, como ser en datos filia to=
rios
> que se ingrese texto, en campos num=E9ricos que solo tomen n=FAmeros, en
> direcciones de correo que se ingres=E9 una direcci=F3n v=E1lida. Para log=
rar esto
> y previendo que la informaci=F3n ingresada en el formulario puede variar a
> pedido del usuario se deben definir tipos est=E1ndar de datos para poder
> realizar la validaci=F3n que para lograr mayor eficiencia se realizar=E1
> utilizando expresiones regulares, y no por medio de java scripts a fin de
> lograr mayor compatibilidad con los distintos navegadores.
>
> 	Almacenamiento de la informaci=F3n
> 	A fin de flexibilizar la aplicaci=F3n, la informaci=F3n obtenida debe po=
der
> 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=F3nico.
>
> 	Comprobante de registraci=F3n
> 	El sistema emitir=E1 un comprobante de registraci=F3n para que el intere=
sado
> cuenta con un pre-comprobante que agilice la comprobaci=F3n de datos cuan=
do
> se presente en el evento. (Este elemento puede ser utilizado de al manera
> que m=E1s crea conveniente el cliente).
>
> b)	Recuperaci=F3n 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=F3n debe estar disponible para su
> utilizaci=F3n. El sistema local de procesamiento contar=E1 con los siguie=
ntes
> m=F3dulos: 1)	Alta. (para ingresar informaci=F3n de personas no registrad=
as v=EDa
> web) Esta informaci=F3n validar=E1 contra los datos obtenidos de la web a=
 fin
> de evitar duplicaciones. Se puede verificar contra el comprobante de
> registraci=F3n web. Este puede ser una clave generada con la hash MD5
> correspondiente a la uni=F3n de los campos Apellido, Nombre y Email.
> 2)	Modificaci=F3n. 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=F3n. Este modulo servir=E1 para acreditar a los asistentes.=
 Debe
> permitir buscar por cualquiera de los campos de la registraci=F3n y por el
> comprobante de registraci=F3n. Adem=E1s debe permitir modificar los datos=
 o
> ingresar datos nuevos (relaci=F3n con los puntos 1 / 2 / 3). Debe emitir =
un
> comprobante de acreditaci=F3n el cual debe imprimir los datos definidos p=
or
> el cliente. 5)	Listados e impresiones.
> 		Este modulo debe permitir la emisi=F3n de listados, certificados defini=
dos
> 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=F3. d)	Modulo de administraci=F3n
> 	Este modulo debe permitir al usuario la configuraci=F3n y adecuaci=F3n a=
 sus
> especificaciones.
>
> Reglas y normas comunes de desarrollo:
> 1)	Nombre de variables : se utilizar=E1 el m=E9todo camello para los nomb=
re. En
> el caso de variables todas empezar=E1n en min=FAsculas, en el caso que se
> utilicen mas de una palabra para formar su nombre, no contendr=E1n espaci=
os,
> no estar=E1n separadas por guiones y deben ser representativo de lo que
> almacena,  la primer palabra se pone en min=FAscula y la siguiente deben
> empezar en may=FAscula, por ej.: apellidoNombre 2)	Funciones: se utilizar=
=E1 el
> sistema doble camello. El nombre no contendr=E1n espacios y/o guiones
> empezar=E1n con la primer letra en may=FAscula y las restantes en min=FAs=
culas y
> en el caso de estar formadas con m=E1s de una palabra, cada una de ellas
> empezar=E1n en may=FAsculas, ej.: ApellidoNombre. 3)	 Todas las variables=
 ser=E1n
> tratadas como inseguras. Para esto se debe deshabilitar la opci=F3n
> GLOBAL_REGISTER asign=E1ndole el valor OFF. Adem=E1s se deber=E1 filtrar =
toda las
> variables recibidas para evitar posibles ataques, limpi=E1ndolas de c=F3d=
igos
> HTML, etc. 4)	Todos los formularios enviar=E1n sus datos por el m=E9todo =
POST.
> 5)	Todos los par=E1metros se enviaran por el m=E9todo GET (a trav=E9s de =
la url).
> 6)	Todos los campos de los formularios se trabajar=E1n como ARRAY, para
> facilitar la limpieza del contenido.
>
> Integrantes del proyecto TODO NOSOTROS!!!!!
>
>
>
> Omar Arino

=2D-=20
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Natalia Victoria Mor=E1n

nmoran@arnet.com.ar=20
nataliamoran@arnet.com.ar
natalia_moran_76@hotmail.com

Linux User Registered #216577
=2D ----------------------------------------------
Actuar es f=E1cil; pensar es dif=EDcil...
Actuar seg=FAn se piensa
es a=FAn m=E1s dif=EDcil...

          Johann Wolfgang Von Goethe=20


=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCyqVsN0pu4F13mzURAiNIAJ0TnwFPV/Ii9MIerFifl1lgQ2+e+gCgu6LF
MP4v73t5TZHTJ7R5KyLJuK8=3D
=3DGeZ1
=2D----END PGP SIGNATURE-----

--nextPart3720088.0UhA4cCRo0
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQBDi39oN0pu4F13mzURAh6NAJ9oS2l7/jxcjAB7Rq/i10J/s5iMVACgkyPH
VwAoP4FcEtzv6d8WwxYGZzY=
=LYw8
-----END PGP SIGNATURE-----

--nextPart3720088.0UhA4cCRo0--