Re: [Durito-dev] Busqueda en rails

[asierra]

On Wed, 30 Nov 2005, ahg wrote:

> Parece más sencillo, quizá, pero no es la manera correcta de hacerlo.
> Funcionaría para las búsquedas en todos los campos, pero saldrán errores
> a partir del momento en que se empiezan a hacer búsquedas en un sólo
> campo. Por ejemplo, en la búsqueda avanzada, si se busca en un solo
> campo--por ejemplo, la palabra "tranvía" sólo en los títulos, o "1950"
> sólo en los campos relacionados con las fechas--entonces puede que se
> devuelvan resultados donde viene esa cadena en varios campos. 

Esos son casos de busqueda compuesta para los cuales la sustitucion se
haria unicamente en los campos indicados. Este razonamiento no contradice
la propuesta de hacer una sustitucion en lugar de contar caracteres. Esto
ultimo no es tan seguro debido a las distintas transformaciones del texto
desde el almacen, pasando por el protocolo xml-rpc, algunos caracteres
podrian desaparecer o ser modificados durante el envio, ya con eso la
cuenta generada desde jena falla. Ademas, contar los caracteres para cada 
subrayado es mas latoso. 

> Es decir, puede que "tranvía" no aparezca sólo en el título de un
> registro que se haya devuelto, sino también en la descripción. O puede
> que aparezca el número "1950" en el número de clasificación, no sólo en
> el campo de fecha. En dichos casos, sólo deberían de subrayarse las
> cadenas que aparecen en los campos en los que se hizo la búsqueda, no
> las que aparecen en cualquier campo que forme parte del record.

Asi se hara. El subrayado actual de todos los campos unicamente se hara en
busqueda simple.

> Ni controller ni view tiene porque saber de este tipo de sutilezas. Es
> en model que se hacen las búsquedas; es model que entiende cómo los
> criterios de búsqueda se relacionan con los datos mismos; y es el model
> que genera los resultados. 

De hecho eso no es cierto, el modelo no hace las busquedas, las hace el
controlador al hacer la llamada al xml-rpc y el hash que obtiene se lo
pasa al modelo para que contruya el objeto con los datos del resultado.
Este objeto, salvo los campos extra que contendran los registros, es
identico al de colecciones.

> La información de cuáles palabras subrayar y cuáles no forma parte de
> los resultados de búsqueda.

Si, y son parte de los elementos extra de los resultados, hasta aqui no 
hay contradiccion.
 
> Hay más casos que surgirán más adelante donde también será necesario
> mandar desde model la información acerca de qué palabras subrayar; por
> ejemplo, cuando se integren mecanismos de reconocimiento ligüístico,
> para que al buscar un verbo (p.e., "hablar") se busquen todas las formas
> del verbo ("hable", "habló", etc.) o al buscar un adjetivo (p.e.,
> "divertido") también aparezcan todas las formas del mismo ("divertida",
> "divertidos", etc.).

Eso lo soporta jena? Porque para rails lo unico que necesitamos es la
lista de palabras a subrayar (o las posiciones de caracteres, si se
insiste en ello, aunque opino que es mala idea).

> El diálogo de búsqueda avanzada está en la maqueta:
> http://durito.nongnu.org/maqueta3/prueba_interfaz3_col.html
> http://durito.nongnu.org/maqueta3/prueba_interfaz3.html
> http://durito.nongnu.org/maqueta3/prueba_interfaz3_registro.html

Esas son las vistas de los dialogos pero no se suponia que los campos de
busqueda variarian segun el caso. O debemos suponer que estos campos seran
los mismos para todas las colecciones?

Suponiendo que asi sea, como se van a construir los queries que seran 
enviados a jena por medio del xml-rpc? Cual sera el formato?
 
Otra duda es el orden. Debemos suponer que siempre va a haber los campos 
titulo, descripcion y autor? Si no es asi, esos campos deben obtenerse de 
una consulta a jena.

Saludos.

--
Alejandro Aguilar Sierra
address@hidden