Uso de IDataProvider

[Juansoft]

Hola a todos, antes de nada me presento, soy Juan ,de España y llevo
unos meses programando con wicket. He hecho búsquedas en el foro
acerca del tema que quiero tratar y no he encontrado nada, en el foro
de wicket en inglés también he dejado una entrada pero nada, nadie
responde!

Bueno, ahí va mi humilde pregunta jejeje.

Quiero utilizar un dataview para mostrar unos datos y así aprovecharme
de sus características de paginación. He visto que hay que
proporcionarle un Objeto que implemente la interfaz IDataProvider en
el cual un método que se llama iterator le devuelve un objeto iterator
que son los datos que "en teoría" carga en el DataView.

El método model del IDataProvider entonces, se ejecuta una vez por
cada fila retornada para otra vez volver a obtener ese objeto de la
base de datos.

Con lo cual en el método iterator preguntamos una vez a la base de
datos , devolvemos los datos y luego por cada fila, un
LoadableDetachableModel vuelve a obtener mas datos de la BBDD
normalmente usando para ello un ID que previamente había almacenado.

¿Cómo usáis vosotros el Dataview/IDataProvider/
LoadableDetachableModel? ¿No os parece un poco extraño el
funcionamiento? ¿Hacer una consulta para obtener los datos y luego por
cada fila obtenida volver a llamar a la BBDD?

Gracias y saludos

[Marcelo Morales]

2011/2/28 Juansoft <juanandresc...@gmail.com>:

> El método model del IDataProvider entonces, se ejecuta una vez por
> cada fila retornada para otra vez volver a obtener ese objeto de la
> base de datos.

Algo que he hecho constantemente es devolver serializables, e
implementar algo como:

IModel<T> model(T object) { return Model.of(object); }

Entonces wicket no necesita llamar a detach, y por lo tanto no
necesitas cargarlo en un LDM.

Lo que queda es medir la memoria que usarías. Depende de la presión de
sesiones que tienes en la aplicación.

Si tienes presión y necesitas usar el LDM, un cache de segundo nivel a
base de datos (en disco) es una excelente solución de desempeño. Yo
uso ehcache.

Saludos

--
Marcelo Morales

[Juan I Felice]

hola yo uso dataprovider y la consulta se ejecuta una sola vez
y lo hago invocando a un webservice

--
Has recibido este mensaje porque estás suscrito al grupo "wicket-es" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a wick...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a wicket-es+...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/wicket-es?hl=es.

[Juansoft]

Antes de nada quiero daros las gracias por las respuestas.

@Marcelo Morales:

Si te soy sincero desconozco cuantos usuarios van a estar conectados a
la web. Me ha faltado decir que no es una aplicación para la intranet
de una empresa ni un sistema de gestión digamos corporativo. El
proyecto una vez en producción en internet vaya bien o mal debe ser
poco glotón de memoria porque al principio irá en un hosting con unas
prestaciones medias.

Por lo que he leido si se usa un objeto IModel en el método model del
IDataProvider pueden aparecer problemas debido a la serialización
(como tu apuntas), por eso había pensado en escribir el código
utilizando un LDM.

Me imagino que mi problema es que no utilizo hibernate ni ningun layer
que me haga de proxy entre mi aplicación y wicket. Siempre he sido
desarrollador de ASP.NET y la idea era empezar con un framework
sencillo, y con las mínimas capas de abstracción posibles para hacer
todo algo más entendible.

Mi acceso a datos lo realizo yo con clases que directamente consumen
procedimientos almacenados de mysql , normalmente devuelven recordset
cacheados y cuando relleno el iterator libero todos los recursos que
he utilizado.

Por eso quizá me pareceron un poco locura los ejemplos oficiales de
wicket del componente DataView donde retornan un iterator con las
filas de la BBDD y luego por cada fila creaba un LDM cual
aparentemente almacenan la primary key del objeto para después cuando
se invoca automáticamente al método load del LDM recuperar ese objeto
de la BBDD. Digo de la BBDD aunque imagino que hibernate cuando
devolvió datos para el iterator cacheó esos objetos que ahora el
método load del LDM va a recuperar de esa misma caché y no de la BBDD
como ocurriría en mi aplicación en la que el DAO es escrito por mí con
la máxima simplicidad posible (realmente escrito como lo hubiera
escrito en ASP.NET... supongo que cualquier programador me entenderá,
tiramos hacia lo conocido!!)

Al final y disculpa por enrollarme, pienso que esta puede ser una
buena implementación de LDM para un IDataProvider que se utilizará en
un DataView que únicamente mostrará filas, es decir, no hay acciones
de fila ni de celda por lo tanto no habrá que recuperar el model a
posteriori.

public class DetachableContactModel extends LoadableDetachableModel
{

public DetachableContactModel(Contact c)
{
/*Internamente "c" se almacena en private transient T
transientModelObject; con lo cual al finalizar el render de la página
todos estos recursos son liberados de manera implícita*/
super(c);
}

protected Object load()
{
// recuperamos el objeto para que el dataview pueda
"alimentar" los distintos label que muestran los datos de la fila
return this.getObject();

// Esto es lo que se suele ver en ejemplos: return
getContactsDB().get(id); Me imagino que muy util cuando se utiliza
hibernate...
}


Creo que esta implementación de LDM no serviría para un dataview que
tenga un botón que por ejemplo haga un sumatorio en una determinada
fila ya que no podría recuperar el modelo al haber sido eliminado en
el método detach de el LDM de manera automática.

Me imagino que por eso en el evento load , ayudándose de un ID (no
transient) almacenado en el LDM recuperan el objeto de la capa DAO.
(return getContactsDB().get(id);)

Muchas gracias por tu ayuda.

On 28 feb, 18:43, Juan I Felice <jeik...@gmail.com> wrote:
> hola yo uso dataprovider y la consulta se ejecuta una sola vez
> y lo hago invocando a un webservice
>
> El 28 de febrero de 2011 06:05, Juansoft

> <juanandrescallejago...@gmail.com>escribió:

[Marcelo Morales]

2011/2/28 Juansoft <juanandresc...@gmail.com>:

> Al final y disculpa por enrollarme, pienso que esta puede ser una
> buena implementación de LDM para un IDataProvider que se utilizará en
> un DataView que únicamente mostrará filas, es decir, no hay acciones
> de fila ni de celda por lo tanto no habrá que recuperar el model a
> posteriori.
>
> public class DetachableContactModel extends LoadableDetachableModel
> {
>
>  public DetachableContactModel(Contact c)
>    {
>        /*Internamente "c" se almacena en private transient T
> transientModelObject; con lo cual al finalizar el render de la página
> todos estos recursos son liberados de manera implícita*/
>        super(c);
>    }
>
>  protected Object load()
>    {
>        // recuperamos el objeto para que el dataview pueda
> "alimentar" los distintos label que muestran los datos de la fila
>        return this.getObject();
>
>        // Esto es lo que se suele ver en ejemplos: return
> getContactsDB().get(id); Me imagino que muy util cuando se utiliza
> hibernate...
>    }

Mmm, mmm, mmm. ¿no vas a tener un StackOverflowError?

¿Qué tiene de malo hacer Contact Serializable y usar un Model?

Saludos

--
Marcelo Morales

[Juansoft]

No entiendo porqué he de obtener un desbordamiento de pila...

He leido en muchas webs que usar objetos serializables en Dataview o
listas que obtienen muchos datos de una base de datos es perjudicial
ya que todo eso se almacena en la sesión , la última ayer...

Of course the developer must exercise sound judgment when deciding
what and how much to persist in the objects associated with Wicket web
pages and HTML controls. Persisting a list of 100,000 database
records, for instance, for thousands of concurrent users is wasteful
and could cause severe degradation or even cause the server to fail
altogether.

For instance, persisting a database table row's unique identity in a
web page object is preferable to persisting the actual row of data
since the database itself already serves as the underlying cache for
the data. Having the identity of the row of data is enough to allow
the data to be retrieved through a query to the database when and if
it is needed. Wicket also provides a model architecture that promotes
this type of resource usage. Wicket's LoadableDetachableModel class
provides the developer with the ability to persist only the minimum
amount of information across HTTP requests - such as a data row's
identity value - which can be used to query the database for the
actual data when and if it is needed and released at the end of the
request.

Sacado de aquí http://jeff-schwartz.blogspot.com/2009/07/wicket-state-icing-on-cake.html

Disculpa que lo ponga en inglés.

On 28 feb, 20:06, Marcelo Morales <marcelomorales.n...@gmail.com>
wrote:
> 2011/2/28 Juansoft <juanandrescallejago...@gmail.com>:

[Marcelo Morales]

On Mon, Feb 28, 2011 at 3:14 PM, Juansoft
<juanandresc...@gmail.com> wrote:
> No entiendo porqué he de obtener un desbordamiento de pila...

org.apache.wicket.model.LoadableDetachableModel##getObject(), Línea 113 aprox:

public T getObject()
{
if (!attached)
{
attached = true;
transientModelObject = load();
....

Si load() llama a getObject(), como en tu clase, va a ocurrir un Stack Overflow.

Saludos

--
Marcelo Morales

[Marcelo Morales]

2011/2/28 Marcelo Morales <marcelomo...@gmail.com>:

Olvida el último mail. Evidentemente estoy privado de sueño.

No hace tu implementación correcta, though.

Saludos

--
Marcelo Morales