[Programación] Re: [Programación] Re: [Programació n] Re: [Programación] RE: [Programa ció n] Re: [Programación] RE: [ Programa ción] Proyecto suscripción a jor nadas

[J. Mario Oroz]

oarino@fagdut.org.ar escribió:

>Creo que ahora se va entendiendo lo que tengo en mente, aunque quiero 
>simplificar algunos procedimientos para no tener tantos problemas con la 
>generación de niveles de usuario.
>
>El proceso de generación de las tablas debe ser un script que el 
>administrador pueda ejecutar una vez a modo instalación. De manera que una 
>vez instalado no se vuelva a repetir. 
>Despues veriamos el problema de hacer modificaciones.
>
>La tabla molde puede puede modificarse por un archivo de configuración en 
>texto plano o XML. Creo que va a ser más conveniente que una tabla en la base 
>de datos, mas si tenemos en cuenta el caso de utilizar el sistema de archivo 
>como almacenamiento de datos o el envio por correo.
>  
>
Bueno por lo que comentas en el parrafo anterior  entiendo que se debe 
contemplar el hecho de trabajar con recursos minimos por parte del 
sistema donde se instale la aplicacion. Es decir estamos atados a lo que 
nos pueda ofreser un instalacion de Apache y PHP *bien default*. Si es 
asi y dependemos del sistema de archivos como el unico soporte viable de 
almacenamiento de datos no seria preferible manejarse con XML de una. 
Pregunta: XML esta soportado por defecto en una instalacion comun de 
PHP????? de no ser asi; tendriamos que lidiar *mal* con los archivos de 
texto plano.

No tengo conocimiento de XML pero se que hay maneras de trabajarlo mucho 
mas eficientes.

>En cuento a la utilización del sistema de archivo como almacen de datos, la 
>idea surgío para el caso en que esta aplicación se deba colgar en un servidor 
>de terceros, donde no tengo motor de base de datos disponible. Para este caso 
>se debería utilizar esta alternativa y solo en este caso ya que estariamos 
>exigiendo a PHP para que se comporte como motor de base de datos, cosa para 
>la que no fue echo. En este caso podría ser un archivo plano donde cada 
>registro se almacene en una lines (ingresando el retorno de carro al final 
>del registro) y cada campo esté separado por como, punto y como o 
>tabulaciones a fin de poder importarlo en una tabla o base de datos.
>  
>
Si esto del formato del registro esta entendido, no hay mucho mas que 
agregar, comas, tabs, ";", es lo de menos.
El tema es como estructuras los datos dentro del texto plano, una 
posibilidad es la que te copmente anteriormente; que creo es bastante clara.


>La descripción que hiciste es bastante acertada a mi idea, aunque quiero 
>evitar todo lo posible la utilización de niveles de usuario. Tene en cuenta 
>que lo mas probable es que cuando se realize las acreditaciones en el evento 
>el sistema no va a estar accesible al publico y probablemente estara 
>instalado localmente.
>
>  
>
Bueno pero deberiamos al menos; disponer de 2 maneras diferenciadas de 
acceder al sistema, a traves de dos paginas diferentes que me permitan 
si soy operado modificar datos;agregar suscriptos; imprimir  "gafetes" 
-le robé el termino a Rafael-
y si soy suscriptor solamente meter mis datos en un formulario y apretar 
el "enviar" nada mas.

>Omar
>  
>

Barbaro; pero te parece buena idea seguir? con esta *narrativa* o 
*procedimiento descriptivo*; ... digo ...alo mejor nos ayudaria a tener 
un idea global del tema ... una ves concretada esta idea global 
pasariamos a ver en profundidad punto a punto
y en una instancia posterior ir delineando procesos , metodos, y 
estructuras para ir plasmando en codigo.
Seria cuestion de  <SIGUIR>  agregando lo qe podamos interpretar del tema.

Saludos.
Mario.