Cargar lista vs Búsqueda

No habia visto la respuesta de Pepeto cuando envié mi ultimo mensaje.

De todas formas, cuando dice “con otro manejador de objetos y pasar los valores del formulario a la búsqueda.”

Alguien sabe como se hace eso?

Es decir, ¿al salir del primer manejador de objetos, como usar las variables locales de este primer objeto (el formulario) para pasárselos al segundo objeto (la búsqueda), todo dentor de un mismo proceso?

 

Al igual que muchos de ustedes… nosotros también lanzamos nuestras búsquedas en 3plano, y como dice Tomás eso nos da la certeza de que se ejecuta en el servidor y no llenamos de trafico la red.

 

Att

Elmer

Muy interesante el tema de las búsquedas.

Siguiendo con el tema de la optimización para aplicaciones en cloud, ¿ alguno sabe cómo funciona en ese ámbito el objeto localizador ?

Gracias.

Aquí tenéis el ejemplo:

http://www.ascsl.com/2013/01/busquedas-en-3-plano/

un saludo

José Luis

Hola.

En cuanto al localizador, mi impresión es que, como se utiliza un índice cada vez, su funcionamiento “nativo” será muy similar al de una búsqueda con un sólo índice, o al de un cargar lista, aunque tenga que “refrescar” la búsqueda cada vez que escribimos algo.

Y, por cierto: Pepeto, muy bien explicado.

@Pepeto, cuando dices: Que realmente tampoco es tanto, porque cuando se tiene un sistema de trabajo depurado, el resto es “Copiar” y “Pegar como”

Te comento, el proceso para garantizar que una búsqueda COMPLEJA (con muchos componentes cruzando y a veces añadiendo) se haga en tercer plano siempre, tal como me lo describió soporte, es DEMASIADO ENGORROSO, e incumple con la filosofía LIFE IS SOFT. Ver las pantallas adjuntas.

‘Pegar como’ no ayuda mucho, porque las búsquedas pueden ser muy diferentes entre si, entonces las variables locales hay que estarlas corrigiendo, al igual que los muchos SET y GET y eso hace perder mucho tiempo.

Ver una idea nueva en el tema, ¿amerita una idea separada para búsquedas?, ¿o podemos incluir en esta misma idea el pedido de mejora?

http://velneo.zendesk.com/entries/22993003-funciones-en-tercer-plano

 

 

image

Está claro, que velneo puede mejorar muchas cosas, y esta es una de ellas.

Pero, si usamos un poco de imaginación, este caso que puede ser considerado “ENGORROSO”, puede ser solucionado de formas más simples.

En la imagen en adjunto explico como soluciono yo este tema, de referir que las funciones auxiliares que uso UT_GET_JSON y UT_SET_JSON, no son funciones de parseo de cadenas, javascript lo hace de forma automática (En adjunto también el codigo fuente de las dos funciones).

Como podreis ver, el trabajo que tengo al lanzar una busqueda en 3p es lo mismo, do que lanzar una busqueda en 1P, con la unica difirencia de que existe un proceso por el medio.

Me ahorro hacer los SET y GET del manejador del objecto 2 veces, y el rendimiento no es afectado de ningnuna forma.

 

image

@fgomes, se te olvido el adjunto.

Muchas gracias

No. yo lo veo correctamente, son imagenes.

uuff perdona la torpeza, pense que solo era una imagen, disculpa

@Filipe: ¿Y qué rendimiento tiene eso? ¿Se resiente algo por tener que formatear en cada componente de la búsqueda la cadena que le pasas?

No hay cualquier diferencia en tiempo de ejecución, debemos tener en cuenta que en Javascript así como en otros lenguajes las funciones de JSON son nativas del entorno, y por lo tanto no se asemejan en nada a parseo de cadenas.

De hecho, para que tengamos una idea, un for en javascript es como unas 5 veces más rápido do que el mismo for en V7.

Para los que se manejan más o menos bien con javascript, todo esto puede ser hecho desde el editor de formulas de velneo, sin necesidad de tener funciones auxiliares.

Disculpen repita la pregunta aquí, pero es que aprovecho que Filipe está por este hilo.

Quisiera, si es posible, se comente esto que dejó Filipe en su tiempo

“1 – Evita las funciones, si puedes usar un proceso lanzado desde un manejador de objectos, usa el manejador (También te permite enviar parametros).”

Si las funciones se ejecutaran siempre en tercer plano, ¿creen que ya se podría usar funciones en la nube sin penalizar severamente el rendimiento?, ¿creen que ese era el origen del problema?

¿Hay forma de aplicar lo que dices aquí, a funciones, Filipe?

Esta es la idea lanzada al respecto, por favor verla, comentarla, votarla si hace falta.
http://velneo.zendesk.com/entries/22993003-funciones-en-tercer-plano

Cuanto sé, las funciones por si solas no penalizan el rendimiento (me he explicado mal en ese hilo), el rendimiento podrá ser penalizado si se las ejecutas en 1º plano y tienes cargar listas o busquedas en 1º plano, pero eso ya no es una cosa de las funciones pero si de su contenido.

No veo la necesidad de tener funciones en 3ºplano, para ello tenemos el manejador, y por otro lado, hay casos en que es conveniente que las funciones se ejecuten en 1º plano.

@cjribera

Disculpa que te repita yo aquí mi respuesta también:

La afirmación de “Evita las funciones” es como todo en esta vida, ¡relativo!

  1. La afirmación de que las funciones se ejecutan en 1º plano es correcta.
  2. Hay un pequeño detalle que debemos tener en cuenta:
  • Cuando ejecutamos una función desde un manejador de evento o proceso, esta se ejecuta en 1º plano en el cliente.
  • Pero si ejecutamos una función en un proceso en 3º plano o desde un evento de tabla (trigger), esta se ejecuta en 1º plano del servidor, es decir, lo que todos consideramos como 3º plano.
    Así qué, no se trata de evitarlas, sino de hacer buen uso de ellas.
    un saludo
    José Luis