Pues es un tema que me han preguntado en el trabajo donde tienen que enviar
las nóminas a los empleados de la empresa adjunto como un pdf. El texto del
mensaje es lo de menos, aunque tal vez podría ser personalizado y el número
de destinatarios es pequeño: menos de 200.

Gracias a ambos.
Pete.

Pues es un tema que me han preguntado en el trabajo donde tienen que enviar
las nóminas a los empleados de la empresa adjunto como un pdf. El texto del
mensaje es lo de menos, aunque tal vez podría ser personalizado y el número
de destinatarios es pequeño: menos de 200.

Gracias a ambos.
Pete.

Pues es un tema que me han preguntado en el trabajo donde tienen que enviar
las nóminas a los empleados de la empresa adjunto como un pdf. El texto del
mensaje es lo de menos, aunque tal vez podría ser personalizado y el número
de destinatarios es pequeño: menos de 200.

Gracias a ambos.
Pete.

Mindundi wrote:

> Adem***s, los replace a partir de la 1.4 van con
> expresiones regulares por debajo, por lo que el rendimiento
> no ser*** el mismo que el de una gram***tica javacc (como es
> Velocity), pero no deben ir mal del todo.

Ya, ya. Yo es que no conozco mucho Velocity, y estoy de acuerdo contigo
en que para segun qué cosas y qué volúmenes, es mejor buscar las
herramientas adecuadas en vez de tirar de apaños caseros.

Pero ahora, una curiosidad. Más que nada, por incordiar, eh? Cómo sabré yo
si Velocity, en última instancia, no acaba usando igualemnte
String.replaceXXX()? :-D Tiene una varita mágica? Un algoritmo más
eficiente? Código nativo?

Quizá no use expresiones regulares. De todas formas, lo costoso de éstas
suele ser la precompilación ... cosa que podríamos obviar reutilizando las
expresiones, precisamente si han de usar demasiadas veces.

Mindundi wrote:

> Adem***s, los replace a partir de la 1.4 van con
> expresiones regulares por debajo, por lo que el rendimiento
> no ser*** el mismo que el de una gram***tica javacc (como es
> Velocity), pero no deben ir mal del todo.

Ya, ya. Yo es que no conozco mucho Velocity, y estoy de acuerdo contigo
en que para segun qué cosas y qué volúmenes, es mejor buscar las
herramientas adecuadas en vez de tirar de apaños caseros.

Pero ahora, una curiosidad. Más que nada, por incordiar, eh? Cómo sabré yo
si Velocity, en última instancia, no acaba usando igualemnte
String.replaceXXX()? :-D Tiene una varita mágica? Un algoritmo más
eficiente? Código nativo?

Quizá no use expresiones regulares. De todas formas, lo costoso de éstas
suele ser la precompilación ... cosa que podríamos obviar reutilizando las
expresiones, precisamente si han de usar demasiadas veces.

Mindundi wrote:

> Adem***s, los replace a partir de la 1.4 van con
> expresiones regulares por debajo, por lo que el rendimiento
> no ser*** el mismo que el de una gram***tica javacc (como es
> Velocity), pero no deben ir mal del todo.

Ya, ya. Yo es que no conozco mucho Velocity, y estoy de acuerdo contigo
en que para segun qué cosas y qué volúmenes, es mejor buscar las
herramientas adecuadas en vez de tirar de apaños caseros.

Pero ahora, una curiosidad. Más que nada, por incordiar, eh? Cómo sabré yo
si Velocity, en última instancia, no acaba usando igualemnte
String.replaceXXX()? :-D Tiene una varita mágica? Un algoritmo más
eficiente? Código nativo?

Quizá no use expresiones regulares. De todas formas, lo costoso de éstas
suele ser la precompilación ... cosa que podríamos obviar reutilizando las
expresiones, precisamente si han de usar demasiadas veces.

No, Velocity no usa replace al final. Ya te digo que usa un compilador de
gramáticas llamado javacc para generar el parser y, al igual que los parser
XML u otros muchos, usan temas de más bajo nivel que los replace (sobre todo
streams). Además, cachea las plantillas si así lo deseas, y en este caso la
plantilla debería ser una sola, así que iría bastante bien.
De todas formas, no tienes más que hacer unas pequeñas pruebas de
rendimiento y verás la diferencia, como yo hice en su día.

Pienso como tú en que en estos casos hay que evaluar el coste de ponerse a
mirar algo nuevo y la ganancia de hacerlo, que puede no ser tanta. De todas
maneras, si para una cosa así te dan un par de días, que son los que se
pueden necesitar para manejar Velocity de sobra, conseguiría, de paso,
conocer una herramienta que le puede venir bien a futuro.

Un saludo

"znôrt" <kktuapowah***yahoo.es> escribió en el mensaje
news:Xns96AD94F066085smoothskuarematrix***62.81.31.2 8...
> Mindundi wrote:
>
>> Adem s, los replace a partir de la 1.4 van con
>> expresiones regulares por debajo, por lo que el rendimiento
>> no ser el mismo que el de una gram tica javacc (como es
>> Velocity), pero no deben ir mal del todo.
>
> Ya, ya. Yo es que no conozco mucho Velocity, y estoy de acuerdo contigo
> en que para segun qué cosas y qué volúmenes, es mejor buscar las
> herramientas adecuadas en vez de tirar de apaños caseros.
>
> Pero ahora, una curiosidad. Más que nada, por incordiar, eh? Cómo sabré yo
> si Velocity, en última instancia, no acaba usando igualemnte
> String.replaceXXX()? :-D Tiene una varita mágica? Un algoritmo más
> eficiente? Código nativo?
>
> Quizá no use expresiones regulares. De todas formas, lo costoso de éstas
> suele ser la precompilación ... cosa que podríamos obviar reutilizando las
> expresiones, precisamente si han de usar demasiadas veces.

No, Velocity no usa replace al final. Ya te digo que usa un compilador de
gramáticas llamado javacc para generar el parser y, al igual que los parser
XML u otros muchos, usan temas de más bajo nivel que los replace (sobre todo
streams). Además, cachea las plantillas si así lo deseas, y en este caso la
plantilla debería ser una sola, así que iría bastante bien.
De todas formas, no tienes más que hacer unas pequeñas pruebas de
rendimiento y verás la diferencia, como yo hice en su día.

Pienso como tú en que en estos casos hay que evaluar el coste de ponerse a
mirar algo nuevo y la ganancia de hacerlo, que puede no ser tanta. De todas
maneras, si para una cosa así te dan un par de días, que son los que se
pueden necesitar para manejar Velocity de sobra, conseguiría, de paso,
conocer una herramienta que le puede venir bien a futuro.

Un saludo

"znôrt" <kktuapowah***yahoo.es> escribió en el mensaje
news:Xns96AD94F066085smoothskuarematrix***62.81.31.2 8...
> Mindundi wrote:
>
>> Adem s, los replace a partir de la 1.4 van con
>> expresiones regulares por debajo, por lo que el rendimiento
>> no ser el mismo que el de una gram tica javacc (como es
>> Velocity), pero no deben ir mal del todo.
>
> Ya, ya. Yo es que no conozco mucho Velocity, y estoy de acuerdo contigo
> en que para segun qué cosas y qué volúmenes, es mejor buscar las
> herramientas adecuadas en vez de tirar de apaños caseros.
>
> Pero ahora, una curiosidad. Más que nada, por incordiar, eh? Cómo sabré yo
> si Velocity, en última instancia, no acaba usando igualemnte
> String.replaceXXX()? :-D Tiene una varita mágica? Un algoritmo más
> eficiente? Código nativo?
>
> Quizá no use expresiones regulares. De todas formas, lo costoso de éstas
> suele ser la precompilación ... cosa que podríamos obviar reutilizando las
> expresiones, precisamente si han de usar demasiadas veces.

No, Velocity no usa replace al final. Ya te digo que usa un compilador de
gramáticas llamado javacc para generar el parser y, al igual que los parser
XML u otros muchos, usan temas de más bajo nivel que los replace (sobre todo
streams). Además, cachea las plantillas si así lo deseas, y en este caso la
plantilla debería ser una sola, así que iría bastante bien.
De todas formas, no tienes más que hacer unas pequeñas pruebas de
rendimiento y verás la diferencia, como yo hice en su día.

Pienso como tú en que en estos casos hay que evaluar el coste de ponerse a
mirar algo nuevo y la ganancia de hacerlo, que puede no ser tanta. De todas
maneras, si para una cosa así te dan un par de días, que son los que se
pueden necesitar para manejar Velocity de sobra, conseguiría, de paso,
conocer una herramienta que le puede venir bien a futuro.

Un saludo

"znôrt" <kktuapowah***yahoo.es> escribió en el mensaje
news:Xns96AD94F066085smoothskuarematrix***62.81.31.2 8...
> Mindundi wrote:
>
>> Adem s, los replace a partir de la 1.4 van con
>> expresiones regulares por debajo, por lo que el rendimiento
>> no ser el mismo que el de una gram tica javacc (como es
>> Velocity), pero no deben ir mal del todo.
>
> Ya, ya. Yo es que no conozco mucho Velocity, y estoy de acuerdo contigo
> en que para segun qué cosas y qué volúmenes, es mejor buscar las
> herramientas adecuadas en vez de tirar de apaños caseros.
>
> Pero ahora, una curiosidad. Más que nada, por incordiar, eh? Cómo sabré yo
> si Velocity, en última instancia, no acaba usando igualemnte
> String.replaceXXX()? :-D Tiene una varita mágica? Un algoritmo más
> eficiente? Código nativo?
>
> Quizá no use expresiones regulares. De todas formas, lo costoso de éstas
> suele ser la precompilación ... cosa que podríamos obviar reutilizando las
> expresiones, precisamente si han de usar demasiadas veces.

Bueno, como a cada uno hay que enviarle su nómina, eso ya te impide el
mandar un sólo correo con múltiples destinatarios, que es la opción más
fácil.
Como tienes que mandarlos distintos, recuerda lo que comenté en el otro
post: reutiliza la sesión JavaMail, pues establecer una nueva es un proceso
que puede llegar a tardar un segundo o más, dependiendo del servidor de
correo. Si al final queréis personalizar el texto, con 200 correos puede que
no te merezca la pena el tema de Velocity. Además, la ejecución supongo que
sea batch, así que tampoco te va a matar el tema del rendimiento. Tira de
replace como dice znôrt y listo.

Un saludo

"pete" <pandiazQuita***ya.com> escribió en el mensaje
news:dd8kiv$bt7$1***nsnmpen3-gest.nuria.telefonica-data.net...
> Pues es un tema que me han preguntado en el trabajo donde tienen que
> enviar
> las nóminas a los empleados de la empresa adjunto como un pdf. El texto
> del
> mensaje es lo de menos, aunque tal vez podría ser personalizado y el
> número
> de destinatarios es pequeño: menos de 200.
>
> Gracias a ambos.
> Pete.
>
>