<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	xmlns:georss="http://www.georss.org/georss"
	xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
	
	>
<channel>
	<title>
	Comentarios en: Traducir una página JSF con Java	</title>
	<atom:link href="https://www.oscarblancarteblog.com/2016/12/15/traducir-una-pagina-jsf-java/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.oscarblancarteblog.com/2016/12/15/traducir-una-pagina-jsf-java/</link>
	<description>Software Architect &#38; FullStack developer</description>
	<lastBuildDate>Sat, 07 Jul 2018 20:12:18 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.5.5</generator>
	<item>
		<title>
		Por: Oscar Blancarte		</title>
		<link>https://www.oscarblancarteblog.com/2016/12/15/traducir-una-pagina-jsf-java/#comment-278</link>

		<dc:creator><![CDATA[Oscar Blancarte]]></dc:creator>
		<pubDate>Sat, 07 Jul 2018 20:12:18 +0000</pubDate>
		<guid isPermaLink="false">http://www.oscarblancarteblog.com/?p=1298#comment-278</guid>

					<description><![CDATA[En respuesta a &lt;a href=&quot;https://www.oscarblancarteblog.com/2016/12/15/traducir-una-pagina-jsf-java/#comment-277&quot;&gt;luis carlos ramírez&lt;/a&gt;.

Ups... tu pregunta es demasiada especifica como para darte una respuesta acertada, mi consejo es que cuides bien los Scope de los Beans, en ningún caso te recomiendo usar un Scope de Sesión para guardar los datos de un formulario, pues se mantendrá los valores durante toda la sesión, creo que la mejor opción es que utilices un View Scope o si es posible Request Scope.]]></description>
			<content:encoded><![CDATA[<p>En respuesta a <a href="https://www.oscarblancarteblog.com/2016/12/15/traducir-una-pagina-jsf-java/#comment-277">luis carlos ramírez</a>.</p>
<p>Ups&#8230; tu pregunta es demasiada especifica como para darte una respuesta acertada, mi consejo es que cuides bien los Scope de los Beans, en ningún caso te recomiendo usar un Scope de Sesión para guardar los datos de un formulario, pues se mantendrá los valores durante toda la sesión, creo que la mejor opción es que utilices un View Scope o si es posible Request Scope.</p>
]]></content:encoded>
		
			</item>
		<item>
		<title>
		Por: luis carlos ramírez		</title>
		<link>https://www.oscarblancarteblog.com/2016/12/15/traducir-una-pagina-jsf-java/#comment-277</link>

		<dc:creator><![CDATA[luis carlos ramírez]]></dc:creator>
		<pubDate>Fri, 06 Jul 2018 15:59:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.oscarblancarteblog.com/?p=1298#comment-277</guid>

					<description><![CDATA[Oscar buen día. Soy Luis Carlos, escribo desde Colombia.  Hace un par de años escribí sobre adf java jsf weblogic, en ese entonces estaba incursionando con esas herramientas.  Hoy en día estoy en un proyecto de esos, aprendiendo cosas.

Quería hacerle una consulta, imagino que aún está activo ayudando en su blog, así que quisiera molestarlo con una nueva consulta, asi que lo contextualizo al respecto para que por favor me dé su recomendación como siempre.

Tengo una jsf nueva llamada asignacionCarga que es una réplica de otra jsf llamada estadosFormulario, prácticamente lo que hice fue copiar y pegar la consulta original de estadosFormulario en mi jsf asignacionCarga, solo hice pequeños ajustes porque es una consulta que ya está funcionando bien en otro módulo y me funciona correctamente en mi nueva jsf.  El inconveniente inició porque al hacer la copia de toda esa funcionalidad en mi jsf el IDE jdeveloper me mostró, dentro de mi jsf, las referencias hacia el Bean como si fueran errores, es decir, referencias como: 
value=&quot;#{backingBeanScope.backing_pageCritico_estadosFormulario.listaAnios}&quot; 
las tuve que cambiar a:
value=&quot;#{backing_pageCritico_estadosFormulario.listaAnios}&quot;

, …es decir tuve que quitarle el scope del Bean “backingBeanScope” y también tuve que cambiar el alcance del Bean en adf-config.xml, es decir, de :
backingBean 
lo tuve que cambiar a:
session 
De esta forma el IDE quitó los supuestos errores de las referencias. 

La base del inconveniente es que al salir de esa jsf asignacionCarga  ir a otra jsf directamente a través del menú de la aplicación y regresar a la jsf asignacionCarga, todos los componentes como Select one choice y Table siguen cargados con las mismas selecciones, datos y valores que se utilizaron previamente en la jsf asignacionCarga, es decir al regresar a esa jsf no se blanquean los componentes ni campos de captura ni nada, todo sigue cargado como quedaron cuando se cargó la jsf por ultima vez.      Dado que para levantar los supuestos errores del IDE (con las referencias hacia el Bean) tuve que dejar el alcance como “sesión” que mantiene todos los valores de las variables y demás mientras dure la sesión, pues menos se me van a blanquearan los valores cuando salga y vuelva a la misma jsf.   Así las cosas probé cambiar nuevamente  el alcance del Bean, y lo dejé como:
view 
Con este alcance “view” me blanquea los componentes de la jsf cada vez que regreso a esa jsf, pero el tema es que el IDE volvió a mostrar las referencias como errores, aunque desplegó bien, y corrió bien la aplicación, y se comportó bien.

La idea hubiera sido seguir usando el alcance:  backingBean   usado en la jsf estadosFormulario y sin necesidad de cambiar las referencias ni el alcance en mi jsf asignarCarga.  Mi pregunta es si ese alcance  “backingBean“ debo registrarlo o definirlo en algún otro lado del proyecto para que el IDE no me muestre como error todas esas referencias. Es decir si cambio backingBean  y utilico otro alcance para el Bean, el IDE me pone como errores todas las referencias dentro de mi jsf.

Cualquier recomendación agradezco,
Saludos desde Colombia.]]></description>
			<content:encoded><![CDATA[<p>Oscar buen día. Soy Luis Carlos, escribo desde Colombia.  Hace un par de años escribí sobre adf java jsf weblogic, en ese entonces estaba incursionando con esas herramientas.  Hoy en día estoy en un proyecto de esos, aprendiendo cosas.</p>
<p>Quería hacerle una consulta, imagino que aún está activo ayudando en su blog, así que quisiera molestarlo con una nueva consulta, asi que lo contextualizo al respecto para que por favor me dé su recomendación como siempre.</p>
<p>Tengo una jsf nueva llamada asignacionCarga que es una réplica de otra jsf llamada estadosFormulario, prácticamente lo que hice fue copiar y pegar la consulta original de estadosFormulario en mi jsf asignacionCarga, solo hice pequeños ajustes porque es una consulta que ya está funcionando bien en otro módulo y me funciona correctamente en mi nueva jsf.  El inconveniente inició porque al hacer la copia de toda esa funcionalidad en mi jsf el IDE jdeveloper me mostró, dentro de mi jsf, las referencias hacia el Bean como si fueran errores, es decir, referencias como:<br />
value=&#8221;#{backingBeanScope.backing_pageCritico_estadosFormulario.listaAnios}&#8221;<br />
las tuve que cambiar a:<br />
value=&#8221;#{backing_pageCritico_estadosFormulario.listaAnios}&#8221;</p>
<p>, …es decir tuve que quitarle el scope del Bean “backingBeanScope” y también tuve que cambiar el alcance del Bean en adf-config.xml, es decir, de :<br />
backingBean<br />
lo tuve que cambiar a:<br />
session<br />
De esta forma el IDE quitó los supuestos errores de las referencias. </p>
<p>La base del inconveniente es que al salir de esa jsf asignacionCarga  ir a otra jsf directamente a través del menú de la aplicación y regresar a la jsf asignacionCarga, todos los componentes como Select one choice y Table siguen cargados con las mismas selecciones, datos y valores que se utilizaron previamente en la jsf asignacionCarga, es decir al regresar a esa jsf no se blanquean los componentes ni campos de captura ni nada, todo sigue cargado como quedaron cuando se cargó la jsf por ultima vez.      Dado que para levantar los supuestos errores del IDE (con las referencias hacia el Bean) tuve que dejar el alcance como “sesión” que mantiene todos los valores de las variables y demás mientras dure la sesión, pues menos se me van a blanquearan los valores cuando salga y vuelva a la misma jsf.   Así las cosas probé cambiar nuevamente  el alcance del Bean, y lo dejé como:<br />
view<br />
Con este alcance “view” me blanquea los componentes de la jsf cada vez que regreso a esa jsf, pero el tema es que el IDE volvió a mostrar las referencias como errores, aunque desplegó bien, y corrió bien la aplicación, y se comportó bien.</p>
<p>La idea hubiera sido seguir usando el alcance:  backingBean   usado en la jsf estadosFormulario y sin necesidad de cambiar las referencias ni el alcance en mi jsf asignarCarga.  Mi pregunta es si ese alcance  “backingBean“ debo registrarlo o definirlo en algún otro lado del proyecto para que el IDE no me muestre como error todas esas referencias. Es decir si cambio backingBean  y utilico otro alcance para el Bean, el IDE me pone como errores todas las referencias dentro de mi jsf.</p>
<p>Cualquier recomendación agradezco,<br />
Saludos desde Colombia.</p>
]]></content:encoded>
		
			</item>
	</channel>
</rss>
