Cuando en vez un input normal se quiere garantizar que la entrada cumple un formato o tipo de valor específico hace falta irse a su hermano 'raro' el JFormattedTextField.
Para conseguir que funcione bien en Griffon lo primero es entender correctamente como funciona en Java, así que tal vez debas echar un ojo a este enlace:
http://docs.oracle.com/javase/tutorial/uiswing/components/formattedtextfield.html
Aunque siendo realista, es posible que no te apetezca leer tanto así que te pongo un ejemplo básico y listo, :D.
En este ejemplo vamos a ver como se hace el binding de valores de un formattedTextField:
Model:
View:
A partir de ahi cualquier necesidad diferente pasará casi siempre por jugar con el NumberFormat para crear la máscara adecuada y demás historias.
Ale, que la fuerza te acompañe!
Para conseguir que funcione bien en Griffon lo primero es entender correctamente como funciona en Java, así que tal vez debas echar un ojo a este enlace:
http://docs.oracle.com/javase/tutorial/uiswing/components/formattedtextfield.html
Aunque siendo realista, es posible que no te apetezca leer tanto así que te pongo un ejemplo básico y listo, :D.
En este ejemplo vamos a ver como se hace el binding de valores de un formattedTextField:
Model:
View:
A partir de ahi cualquier necesidad diferente pasará casi siempre por jugar con el NumberFormat para crear la máscara adecuada y demás historias.
Ale, que la fuerza te acompañe!
En la historía de la humanidad siempre ha habido guerras, seguramente este en nuestra genética, no sabemos estarnos quietecitos.
Al principio algunos luchaban por su libertad:
más adelante muchos lucharon contra muchos:
y así hasta nuestros días.
El caso es que poco a poco intentamos ser más civilizados (aunque honestamente no lo conseguimos demasiado) así que para la próxima guerra ya se están reclutando los nuevos soldados y muchas de las balas serán sockets, callbacks y raspberrys.
¿Quée?
Pues eso, en los próximos años se librarán muchas batallas, algunas tendrán pocos muertos pero muchas victimas (económica o socialmente hablando) y cada frente se está preparando para ello.
En Corea, China, Japón y similar, los niños son presionados por sus padres y profesores para ser la mejor versión de si mismos intelectualmente hablando y en vez de futbolistas muchos de esos pezqueñines sueñan con hacer saltar la banca.
En vista de esto US ya se ha puesto manos a la obra y no quiere quedar atrás de ningún modo, haciendo un llamamiento a la juventud a que se aliste al frente y haga fuertes sus trincheras:
Mola, ¿no?
Pues figurate si te lo pide Shakira, Asthon Kutcher o similar:
Y es que encima, estos frentes de nueva creación no entienden de nacionalidades, si quieres te puedes unir al frente de Coders Lapones, eso depende ti y tu habilidad.
El caso es que está oportunidad no ya puede dejar pasar España y ya se han puesto manos a la obra toda la piara de asesores de nuestros mandatarios para contrarrestar estas iniciativas y mover a nuestros jóvenes al futuro:
Podemos estar tranquilos, nos van a dar tal paliza que no nos dolerá.
Al principio algunos luchaban por su libertad:
más adelante muchos lucharon contra muchos:
y así hasta nuestros días.
El caso es que poco a poco intentamos ser más civilizados (aunque honestamente no lo conseguimos demasiado) así que para la próxima guerra ya se están reclutando los nuevos soldados y muchas de las balas serán sockets, callbacks y raspberrys.
¿Quée?
Pues eso, en los próximos años se librarán muchas batallas, algunas tendrán pocos muertos pero muchas victimas (económica o socialmente hablando) y cada frente se está preparando para ello.
En Corea, China, Japón y similar, los niños son presionados por sus padres y profesores para ser la mejor versión de si mismos intelectualmente hablando y en vez de futbolistas muchos de esos pezqueñines sueñan con hacer saltar la banca.
En vista de esto US ya se ha puesto manos a la obra y no quiere quedar atrás de ningún modo, haciendo un llamamiento a la juventud a que se aliste al frente y haga fuertes sus trincheras:
Mola, ¿no?
Pues figurate si te lo pide Shakira, Asthon Kutcher o similar:
Y es que encima, estos frentes de nueva creación no entienden de nacionalidades, si quieres te puedes unir al frente de Coders Lapones, eso depende ti y tu habilidad.
El caso es que está oportunidad no ya puede dejar pasar España y ya se han puesto manos a la obra toda la piara de asesores de nuestros mandatarios para contrarrestar estas iniciativas y mover a nuestros jóvenes al futuro:
Podemos estar tranquilos, nos van a dar tal paliza que no nos dolerá.
Cuando manejamos un Tomcat instalado en un servidor Linux personalizar las opciones de memoria (heap mínima, máxima, permsize, ..) se reduce a meter las variables o bien en las variables de entorno (JAVA_OPTS, CATALINA,OPTS) o bien a modificar el script de arranque directamente.
Sin embargo cuando el servidor es un Windows y el Tomcat está instalado como servicio la cosa difiere un poco de lo habitual, y la verdad, cuesta un poco encontrarlo.
En este caso en la carpeta
hay un ejecutable Tomcat6w.exe que permite lanzar una herramienta para arrancar/parar/reiniciar el servidor y a su vez cambiar la configuración de paramétros del servicio.
Si la arrancamos tiene una pestaña donde se puede configurar todo lo referente a la memoría y resto de parámetros, una imagen vale más que 1000 palabras:
Sin embargo cuando el servidor es un Windows y el Tomcat está instalado como servicio la cosa difiere un poco de lo habitual, y la verdad, cuesta un poco encontrarlo.
En este caso en la carpeta
TOMCAT_HOME\bin
hay un ejecutable Tomcat6w.exe que permite lanzar una herramienta para arrancar/parar/reiniciar el servidor y a su vez cambiar la configuración de paramétros del servicio.
Si la arrancamos tiene una pestaña donde se puede configurar todo lo referente a la memoría y resto de parámetros, una imagen vale más que 1000 palabras:
Cuando se crea un MVC a través de una de las variantes de:
es fundamental entender el proceso interno que lleva a la correcta construcción del MVC. El proceso se ejecuta en 3 fases y en cada de ellas se sigue por defecto el orden lógico (modelo, vista y finalmente controlador *), la secuencia es como sigue:
La primera fase invoca al constructor de cada una de las partes, por ejemplo:
La segunda fase invoca a los setters de los objetos según los parámetros que se hayan pasado al invocar el buildMVCGroup, por ejemplo:
Es importante subrayar que sólo se invoca al setter si los nombres entre el argumento y la propiedad coinciden. Finalmente se hace el paso de 'postproducción', llamandose al mvcGroupInit de cada artefacto.
Un truco importante aqui es que el pintado de la pantalla (es decir la ejecución del script PintadorView.groovy en nuestro ejemplo) se realiza en esta última etapa después del mvcGroupInit del modelo (PintadorModel.groovy) lo cual permite hacer uso de bucles limpios en el propio script si fuera necesario algún tipo de calculo añadido sobre el modelo antes de mostrarlo:
Listo! A partir de ahora hacer mvcs no debería tener ningún secreto.
*Nota:
En realidad este orden es así por defecto dado que en la declaración del mvc en el fichero Application.groovy se sigue ese orden, si el orden fuera:
def mvc=buildMVCGroup([arg1:value1,arg2:..],"pintador")
es fundamental entender el proceso interno que lleva a la correcta construcción del MVC. El proceso se ejecuta en 3 fases y en cada de ellas se sigue por defecto el orden lógico (modelo, vista y finalmente controlador *), la secuencia es como sigue:
La primera fase invoca al constructor de cada una de las partes, por ejemplo:
PintadorController(){
...
}
La segunda fase invoca a los setters de los objetos según los parámetros que se hayan pasado al invocar el buildMVCGroup, por ejemplo:
class PintadorModel{
def arg1
...
void setArg1(def cosa){
this.arg1=cosa
}
Es importante subrayar que sólo se invoca al setter si los nombres entre el argumento y la propiedad coinciden. Finalmente se hace el paso de 'postproducción', llamandose al mvcGroupInit de cada artefacto.
void mvcGroupInit(Map args) {
...
}
Un truco importante aqui es que el pintado de la pantalla (es decir la ejecución del script PintadorView.groovy en nuestro ejemplo) se realiza en esta última etapa después del mvcGroupInit del modelo (PintadorModel.groovy) lo cual permite hacer uso de bucles limpios en el propio script si fuera necesario algún tipo de calculo añadido sobre el modelo antes de mostrarlo:
//File: PintadorModel.groovy
class PintadorModel{
def arg1
def objetos
void mvcGroupInit(Map args){
objetos=server.getObjetos(arg1)
}
}
...
//File: PintadorView.groovy
...
vbox(){
model.objetos.each{
label $it
}
}
Listo! A partir de ahora hacer mvcs no debería tener ningún secreto.
*Nota:
En realidad este orden es así por defecto dado que en la declaración del mvc en el fichero Application.groovy se sigue ese orden, si el orden fuera:
mvcGroups {
'pintador' {
model = 'com.mycompany.PintadorModel'
controller = 'com.mycompany.PintadorController'
view = 'com.mycompany.PintadorView' } .... }
el orden de invocación de los artefactos sería ese para cada una de las tres etapas.
