Tuve que implementar un scroll dinámico de contenido, al mejor estilo Facebook o Twitter, y luego de revisar bastante algún componente que me ahorrara unas buenas horas de trabajo forzado, me di cuenta que no existía lo que yo necesitaba, al menos no partiendo de lo que ya tenía implementado.

Vi en muchos lugares cosas del tipo: el código JS invoca una página y lo que esta te devuelve lo vas mostrando a continuación de lo que ya está, etc etc… pero mi caso es un poco más complejo. Tenía una app J2EE con JSF2, RichFaces, jQuery y todo funcionando con AJAX … y de ahí tenía que salir la solución, preferentemente. Y de ser aún más posible, tendría que seguir siendo AJAX. Nada de invocaciones truchas a páginas. AJAX señores, AJAX.

Manos a la obra, lo primero fue investigar como darme cuenta cuando el usuario llegó al tope del scroll. Afortunadamente, jQuery ya trae algo de eso y permite que al momento de llegar a lo más bajo de la página, se ejecute determinado javascript. Perfecto! … pero… no quiero hacer una llamada AJAX artesanal, porque luego es complicado renderear el contenido que quiero… Y ahí apareció mi amiga a4j:jsFunction, permitiendo definir una función javascript que al ser invocada llamara un método en el bean, y luego de la llamada renderear determinada área de mi página… BAM !

Mi caso se complicó más ya tenía un combo que, dependiendo su valor, tenía que permitir cargar contenido dinámico o sinó mostrar un paginador. Esto quiere decir que mi función a4j no se tenía que invocar siempre, sino que se tenía que invocar cuando el scroll dinámico estaba habilitado… y se habilitada o deshabilitaba vía AJAX. Muy lindo si… De momento no viene al caso, pero esa parte la solucioné attachando o desattachando la función  que se ejecutaba en el scroll vía jQuery, dependiendo qué se seleccionaba en el combo… no lo voy a poner acá, si estás en el mismo caso, preguntá que te explico más.

En fin, sin más preámbulos, este es el código.

Código jQuery que debería ir en el onload() o el ready() del Body.

$(window).scroll(function(){

      if ($(window).scrollTop() == $(document).height() – $(window).height()){

            miFuncionA4J();

      }

});

Y luego, en el código JSF mismo, algo como esto:

<a4j:jsFunction name=”miFuncionA4J” action=”#{MiBean.unMetodo}” render=”seccionARenderear” />

Esto implica que cada vez que el usuario llegue al final de la página, se ejecutará miFuncionA4J(), que a su vez invocará el MiBean (presumíblemente para cargar algun otro contenido en una propiedad) y luego de re-rendeará determinada sección de la página (presumíblemente aquella que lee el contenido modificado en la propiedad mencionada).

Bombastik!

Estuve jugando con uno de los nuevos scopes de JSF2, el View Scope. Está muy lindo, sobre todo para lo que es AJAX. El bean se mantiene vivo mientras no se cambie de vista (página). Pero hete aquí que mi bean al momento de realizar la primera llamada ajax se re instanciaba. Muy raro. Y no era la idea. Al re instanciarse perdía todo lo que podía haber hecho antes,  y lo más raro es que luego de re instanciarse (que palabra complicada) todo seguía funcionando bien.

Luego de leer mil sitios diferentes donde a muchas personas les pasaba lo mismo, pero a todas se les solucionaba de formas diferentes, me iluminé y probé algo que resolvió mi problema en particular: Como lo que estaba haciendo era una migración de código para dotarlo de ajax, tuve que poner un <h:form> que abarque toda mi página. Lo que no me di cuenta era que había métodos que generaban código para embeber en mi página que también le metían tags <form>. Por lo tanto tenía varios forms embebidos dentro de mi form (el que puse yo).

Para resumir, quité los forms embebidos y listo! Todo se arregló mágicamente y el bean funcionó como se suponía. Horas y horas de dolor de cabeza buscando una solución compleja a un problema que resultó ser de lo más básico.

Espero haber ahorrado un par de horas a quien visite este post

Leyendo bastante di con una solución que, si bien decía que era para un bug cuando corría sobre jBoss 5.x (cuando la mía era jBoss 4.x), funcionó perfectamente y permitió desplegar sin problemas el WAR armado con SpringSource STS en un server jBoss ordinario.

Dentro del proyecto Grails, carpeta grails-app/conf, van a encontrar un archivo BuildConfig.groovy

En este archivo, dentro del nodo (por asi decirlo) “grails.project.dependency.resolution{}” hay que agregar lo siguiente:

runtime(‘org.hibernate:hibernate-validator:3.1.0.GA’) {
excludes ‘sl4j-api’, ‘hibernate.core’, ‘hibernate-commons-annotations’, ‘hibernate-entitymanager’
}

Vale destacar para orientarnos mas que este nodo “resolution” suele tener adentro otros nodos como “inherits”, “repositories” y “dependencies” … con agregar este nuevo “runtime” al mismo nivel que los anteriores mencionados, estamos del otro lado!

Espero haya servido el tip !

El origen de la solución: (http://jira.codehaus.org/browse/GRAILS-5606?focusedCommentId=212135&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_212135)

Hace poco empezamos a tener algunos problemas con las aplicaciones grails que se estaban desplegando en determinado servidor. Para arrancar los tiempos de despliegue pasaron de 1 a 4 minutos, y además de eso cada vez que se invocaban ciertas acciones, grails demoraba unos 30 segundos en responder… una vida !!

Investigando, llegué a que cuando demoraba esos 30 segundos era justo en los métodos donde se hacían consultas directas a la base, creando nuevas conexiones y demás. Al parecer, grails estaba teniendo serios problemas para crear nuevas conexiones a la base, y si bien ya había leído por otro lado que la forma correcta de consultar la base era haciendo un Sql.newInstance(db, user, pass,driver); y luego mandando la query, parece que de esta forma se crean conexiones por fuera del pool cada vez que se invoca… y eso es costoso.

Luego de probar y leer bastante, llegué a la solución más prolija: tomar la conexión del pool de conexiones y ejecutar la consulta. De esta manera, utilizo conexiones que ya están listas que no tienen que crearse ni inicializarse, y de paso hago las cosas bien. Cabe destacar que el código que aquí voy a exponer es Java puro y duro. En groovy sería lo mismo, pero en mi caso la consulta a la BD la realizaba desde un servlet.

A por ellos…

 GrailsApplication ga = ApplicationHolder.getApplication();

Sql sql = new Sql(ga.getMainContext().getBean(“dataSource”, DataSource.class));

List<groovy.sql.GroovyRowResult> lista = sql.rows(“select XXX from YYY where ZZZ = ‘KKK’ ” );

sql.close();

Como resultado, el proceso de tomar la conexión y realizar la consulta demora menos de UN segundo. BAM !

Si bien no llegué todavía a solucionar el tema de porqué ahora demora mucho desplegar los war’s de grails (me suena a que está todo intimamente relacionado, y relacionado además con un cambio de memoria que hicimos en la base) si se pudo solucionar este tema que es vital, sobre todo porque impactaba cada vez que se invocaba la acción.

Espero haber podido ayudar a alguien

Un OCR gratuito y online para tirarle imágenes o pdfs y que te devuelva el texto de los mismos. Lo probé y funciona bastante bien, hay que tirarle texto legible y estructurado para que el output sea coherente, pero salvo eso, me salvó de un lindo trabajo de mono apuro.

http://www.free-ocr.com/

Enjoy it!

En primer lugar, decirles que mi dataTable en el atributo “value” tiene el binding a una propiedad en el bean que es del tipo Map<Integer, Algo> y yo quiero ordenar la tabla por una de las propiedades de ese algo. Por defecto rich:dataTable me ordena todo de acuerdo a la clave del Map, algo bastante inservible en mi caso.

Entonces, hice lo siguiente: en la columna en cuestión dentro de la jsp agregué las propiedades “comparator”, “selfSorted” y “sortOrder”.

<rich:column comparator="#{MiBean.comparaAlgo}" selfSorted="false" sortOrder="DESCENDING">

Luego en el bean definí el comparador “comparaAlgo” con su get y set (no lo detallo aquí abajo, pero sepan que es necesario).

Comparator<Map.Entry<Integer, Algo>> comparaAlgo =
new Comparator<Map.Entry<Integer, Algo>>() {
	public int compare(Map.Entry<Integer, Algo> e1, Map.Entry<Integer, Algo> e2) {
		return e1.getValue().getPropiedadDeAlgo().compareTo(e2.getValue().getPropiedadDeAlgo());
	}
};

Y ta, cuando lea la jsp y vea que queremos un orden ascendente por esa columna, va a utilizar el comparador para armar la lista y todo va a salir según lo planeado!

Lo “bueno” de este método infalible es que no necesita ningun complemento extra.

Para arrancar, importamos un par de librerías:

import org.w3c.dom.*;
import javax.xml.parsers.*;
import javax.xml.transform.*;
import javax.xml.transform.dom.*;
import javax.xml.transform.stream.*;

Luego a los bifes. Creamos primero los constructores, factory’s y demás…

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
DOMImplementation implementation = builder.getDOMImplementation();

Ahora creamos el objeto Document, lo que vendría a ser nuestra raíz del arbol XML  y también le seteamos la versión de XML.

Document document = implementation.createDocument(null, "documento", null);
document.setXmlVersion("1.0");

Obtenemos la raíz

Element raiz = document.getDocumentElement();

Y luego creamos un nodo para agregarle a la raíz, el cual va a contener algún texto.

Element nodoNombreCampo = document.createElement("ElementoHijoDeLaRaíz"); //creamos un nuevo elemento
Text nodoValorCampo = document.createTextNode("contenido del elemento hijo"); //Ingresamos la info
nodoNombreCampo.appendChild(nodoValorCampo);
raiz.appendChild(nodoNombreCampo); //pegamos el elemento a la raiz "Documento"

De esta forma nuestro XML quedaría con una estructura similar a la siguiente:

<?xml version="1.0" encoding="UTF-8"?>
<documento>
<ElementoHijoDeLaRaíz>contenido del elemento hijo</ElementoHijoDeLaRaíz>
</documento> 

Para terminar podemos guardar ese XML creado en un archivo, array de byte o lo que queramos…

Source source = new DOMSource(document);
Result result = new StreamResult(new java.io.File("resultado.xml")); //nombre del archivo
Transformer transformer = TransformerFactory.newInstance().newTransformer();
transformer.transform(source, result);

Listo el pollo !

Básicamente consiste en utilizar un objeto java.util.Calendar, que aparentemente andabien para estas cosas!

Por ejemplo, vamos a sumar 47 meses (47 porque se me antoja) a la fecha de hoy.

String hoy = new SimpleDateFormat(“dd/MM/yyyy”).format(new Date());
String [] dataTemp = hoy.split(“/”);
Calendar c = Calendar.getInstance();
c.set(Integer.parseInt(dataTemp[2]), Integer.parseInt(dataTemp[1])- 1, Integer.parseInt(dataTemp[0]));
c.add(Calendar.MONTH, 47);

Aclaraciones: en primer término, al setearle el mes al Calendar le resto uno porque va de 0 a 11 … si, yo también pensé WTF ??  … Y en segundo lugar, luego de todo esto se puede hacer un c.getTime() y eso devuelve un DATE que tranquilamente puede ser parseado por un DateFormat nuevamente.

Además de todo, podría obviarse la parte del split, ya que el getInstance del calendar obtiene la fecha actual, pero el ejemplo está bueno por si en algun momento hay que sumar “cosas” a fechas que no son la de hoy

Enjoy!

Partamos de la base que tengo un form, que en el evento onSubmit tiene lo siguiente: return validar();

Esto implica que si la función validar retorna true el form se va a submitear y sinó… no.

Ahora bien, cómo hacemos para que esa función validar se arme dinámicamente cada vez que abro la página? Mi primer pensamiento fue: Un Binding, obvio! … pero no, no hay un elemento del tipo Script q pueda bindearse (estoy halando pal tujes, lo se). Entonces? A huevo, si señor … y a huevo implica que el binding sea de un Div y ahi dentro mandarle el script… veamos como.

En la jsp

<t:div binding=”#{MiBean.funcionValidar}” />

En el Bean

public Div getFuncionValidar(){
Application app = FacesContext.getCurrentInstance().getApplication();
Div function = (Div)app.createComponent(Div.COMPONENT_TYPE);

UIScript script = new UIScript();

//Aca es donde se debe crear el codigo javascript.

HtmlOutputText text = new HtmlOutputText();
text.setValue(“function validar(){return false}”);

script.getChildren().add(text);
function.getChildren().add(script);

return function;

}

Y listo. Como veran, dentro del div le metí un UIComponent del tipo Script y adentro el texto que va a contener, que tal como lo necesitamos, será javascript.

Obviamente que donde yo puse text.setValue hay que poner en realidad el código a ejecutar. Ahora con ese return false nunca se va a hacer el submit del form.

Eso es todo amigos

En fin, desde hace un par de días la solución llegó a mi… por partida doble.

Primero encontré un servicio, llamado Memolane. Te registrás, vinculas tus cuentas (Twitter, Face, Flickr, etc) y te arma una timeline eterna con todo lo q pusiste, compartiste, te comentaron, te etiquetaron, publicaste, etc… por ejemplo, fue muy copado volver a Agosto de 2009 y ver el proceso de mi viaje a USA desde ese punto de vista.

Y hoy encuentro el google de las redes sociales, como lo llaman en varios sitios. Este es Greplin. Te registrás, vinculas tus cuentas (Gmail, Face, Twitter y muchas más, aunque algunas vinculaciones son premium) y voilá! tenés un buscador de tus cosas. Genial. SI bien GMail ya trae un buscador, el hecho de tener un solo lugar donde buscar en toda tu vida digital me parece buenísimo.

En fin, será cuestión de probar