You would follow directions basically like found
here.
That example builds a custom query, whereas for SB binding I'd keep the values around and use as flags for invoking the correct finder method.
The size() method override would call the appropriate SB method to return the query count, and the loadItems method would invoke the similar paged query from the SB API.
For example, to handle all Liferay users you'd probably do something like:
package com.dnebinger.example;
import java.util.ArrayList;
import java.util.List;
import org.vaadin.addons.lazyquerycontainer.Query;
import org.vaadin.addons.lazyquerycontainer.QueryDefinition;
import com.vaadin.data.Item;
import com.vaadin.data.util.BeanItem;
import com.liferay.portal.model.User;
import com.liferay.portal.service.UserLocalServiceUtil;
public class LiferayUserQuery implements Query {
private EntityManager entityManager;
private QueryDefinition definition;
public MovieQuery(EntityManager entityManager, QueryDefinition definition,
Object[] sortPropertyIds, boolean[] sortStates) {
super();
this.entityManager = entityManager;
this.definition = definition;
// ...
}
@Override
public Item constructItem() {
return new BeanItem<user>(UserLocalServiceUtil.createUser(0));
}
@Override
public int size() {
return (int) UserLocalServiceUtil.getUsersCount();
}
@Override
public List<item> loadItems(int startIndex, int count) {
List<user> users = null;
try { users=UserLocalServiceUtil.getUsers(startIndex, startIndex+count); } catch (...)
List<item> items = new ArrayList<item>(users.size());
for (User user : users) {
items.add(new BeanItem<user>(user));
}
return items;
}
@Override
public void saveItems(List<item> addedItems, List<item> modifiedItems,
List<item> removedItems) {
throw new UnsupportedOperationException();
}
@Override
public boolean deleteAllItems() {
throw new UnsupportedOperationException();
}
}</item></item></item></user></item></item></user></item></user>
Now this is a contrived example that I simply wouldn't put into production... First, the User object has a lot of stuff in it, most of what you don't need to keep around in your bean items. I'd use some sort of transient user class to thin out what isn't needed by the front end.
Second, the bean items will not resolve any foreign key references and do other translations from codes to display values, so it's yet another reason to use a transient user class that is more display friendly.
Third, I didn't deal with sorting and/or filters in any way. Not that it's hard to do in general, but for users well it just isn't supported (I mean, all you get is the single getUsers() method, there aren't alternatives for filtering and no way to indicate sort outside of what the entity definition is). For your own custom entities, you can expose this information (personally I'd probably build method(s) in my CustomEntityLocalServiceImpl that I passed in a similar set of arguments the lazy loader gives you and build the method(s) to handle the right invocation of your finders or dynamic queries or what not).
Finally, I would note that the lazy loader is not a panacea. First, any table with a lot of rows in it can potentially be called upon to lazy load all of them, and you must remember that all objects lazily loaded will remain bound in the user session until purged. Multiplying by the number of users that will have access to this table and be online at the same time, it should become obvious that this may lead to a drain of all of your server side resources.
Basically what I'm saying is that all implementation decisions come with consequences, and you should at least try to be aware of the consequences and make an educated decision about whether you can live with those consequences.
