Re: [Jamesproject-devel] Borrador API 2.0

[Manuel R. <re...@im...>]

Hola

El Sábado, 16 de Agosto de 2003 12:31, Jose Ignacio escribió:
> Buenas!!
>
> He mirado lo que mandastes 'por encima', mas que nada porque es un pelin
> largo y no me da tiempo (me vuelvo a ir esta tarde), de todas formas te
> comento un par de cosas:
>
> Lo de la tabla GroupTypes ya lo hable con Guti y si, se van a quitar del
> nucleo pero el motivo es algo distinto, no sirve para agrupar grupos, sino
> modulos, con esa tabla tienes un conjunto de modulos y eso se lo asignas al
> grupo, ademas no creo que sea necesario 'agrupar grupos'. Pero si, es una
> 'cosa' mu fea pero que despues ayuda bastante en la administracion.

Ok, weno, ahora mismo si q agrupaba grupos... asignaturas, etc. al menos 
visualmente en la interfaz.

> Directorios -> internacionalizacion ¿como vamos a hacerla? yo creo que como
> lo hizo guti da problemas, ademas creo que tampoco permite seleccionar el
> idioma.

Si q lo permite :-) Si quieres podemos discutir eso tranquilamente, pero me
parece q la forma de guti tiene mas ventajas.

> Tabla Users: haber, el login ¿es del nucleo? yo creo que es del modulo de
> login o del modulo de admUsuarios, al igual que password (por ejemplo), yo
> lo dejaria:
>
> Users				ModAdmUsers			ModLogin
> -------			----------------			-----------
> id				id					id
> gg				idU					idU
> gr				nombre				login
> 				apellidos				pass
>
> y el modulo de login ofrezca unos eventos para modificar el login y el
> pass.

Ya, lo que pasa es que creo q el núcleo debería dar un sistema de login al 
menos muy básico, no? Total no cuesta trabajo implementarlo y así no requiere
necesariamente de un módulo de login.

Por otro lao, quizá sería interesante quitar el idU y dejar como clave 
primaria el campo de login, al fin y al cabo, el nombre de usuario va a ser 
único en el sistema.

> Esto se ve muy claro en la API, cuando pides un objeto Users para mirar el
> GG o el GR no te importa que login o pass tenga, y viceversa.
>
> Clase Groups: en lugar de SubGroups -> childGroups
> GetUserWithPermission(usuario,modulo,PERMISO) habra que especificar el
> permiso.

Ok, totalmente de acuerdo :-)

> Bueno, el resto lo he leido muy por encima (me canso) y seguramente no me
> de tiempo antes de irme, de modo que ahi queda esto.

Weno, algo es algo, has sio el único ;-) En fin, en vista de que nadie ha 
dicho na y que las encuestas por messenger han sio favorables he empezado a 
hacer una primera implementación de la api (cn algunos cambios menores que he 
tenido que ir haciendo sobre la marcha pq había cosas q no me gustaban del 
to).

> Nota: Avisad antes de poneros a hacer algo (lo digo por la documentacion),
> que ya con la pagina de SF hemos estado apunto de hacer lo mismo por
> separao.

Toy con la API 2.0 :-) 
Se podría mirar en sf.net a ver si hay una especie de gestor de tareas o algo 
así y írselas asignando a cada uno y tal...

> nos vemos.

yep yep, dentro de na tos en Sevilla otra ve.

Taluego!