Dema chyba każdego frameworku elementy powtarzalne (w skrócie, aczkolwiek upraszczając użyjmy słowa tabele) zasila się modelem danych np
List<Person>
W realnym życiu na milionie wierszy to się nie sprawdzi. Profesjonalny framework ma to przemyślane. Widzę nasz Grid jest “zasilany” jest z interface Container.Indexed, i wiele w tym rozumiem ale nie wszystko. Ma, jak się spodziewałem koncepcję paginacji (???) danych czyli zażąda ich od programującego model danych w porcjach w nie milion (chętnie bym doczytał
które muszę zaimplementować
najpierw , które wynikają z innych)
Zgaduję z javadoc’u że pytanie o ilość się implementuje w
int size()Czy mój tok myślenia jest OK?
Czy / jak się przekazuje sortowanie? Na przykład prezentuję użytkownikowi grid (tabelę) z sortowalnymi kolumnami. Użytkownik chce skorzystać z tego feauture i klika. Nie posortuję miliona wierszy w RAM (a nawet ich tam nie mam), z UI przez wartswy mam zarządać nowego sortowania od backendu. Nie doczytałem jak to zrobić.
Czy jest artukuł skupiony na wydajnym zrobieniu tego tematu dla dużych baz? Oczywiście może być po angielsku.
Czy zasilanie Table / Grida się jakoś istotnie rózni? W javadoc’u widzę ten sam interfejs źródła danych.
czy jest koncepcja “zakończenia” requestu tj na koniec requestu webowego zamykam sesje JPA
*)
/ ResultSet JDBC itd …
Dla zainteresowanych, u sąsiada to wygląda tak (z tym że sąsiad nie ma o fabrycznej dystrybucji przewijanej tabeli). Jak programista umie wypracować stronicowane dane (np z JDBC/JPA) nie przez “brutal force”, jest to łatwe i wydajne, a jak jeszcze sobie mądrze cachuje to super.
[code]
package org.apache.wicket.markup.repeater.data;
…
public interface IDataProvider extends IDetachable
{
/**
* Gets an iterator for the subset of total data
*
* @param first
* first row of data
* @param count
* minimum number of elements to retrieve
*
* @return iterator capable of iterating over {first, first+count} items
*/
Iterator<? extends T> iterator(long first, long count);
/**
* Gets total number of items in the collection represented by the DataProvider
*
* @return total item count
*/
long size();
/**
* Callback used by the consumer of this data provider to wrap objects retrieved from
* {@link #iterator(long, long)} with a model (usually a detachable one).
* @param object
* the object that needs to be wrapped
* @return the model representation of the object
*/
IModel<T> model(T object);
}
[/code]oraz
public interface ISortableDataProvider<T, S> extends IDataProvider<T>, ISortStateLocator<S>
{
}
*) mam świadomość że ktoś pytający o zamykanie sesji JPA wcześniej czy później ucierpiał przez Lazy fetching encji podrzędnych, session in view uznawany za anty-wzorzec itd… albo przez wyczerpanie conections