This content has been marked as final.
Show 4 replies
-
1. Re: Seam Comments
gavin.king Dec 19, 2005 7:01 AM (in response to werpu)First of all the data model seems to be some collection, maybe seam could provide a model which can rely on paging as well, thus not the entire collection has to be loaded. (some kind of ejb3 jsf data model)
There is no problem here, pagination is easy to implement (the Hibernate Tools plugin actually generates code to do pagination). All you do is have a nextPage() action that re-runs the query with a diff setFirstResults()/setMaxResults(). Very, very simple.Another thing is, you have a model counter, which is a cood thing, which can be automatically requested, after an action from the data table itself. But this is a problematic pattern, because data can change in between, thus passing the surrogate of the affected object or the object makes more sense in this case.
Huh?? I think you have misunderstood. This is a *stateful* session bean. The list is cached.Third, setup, programming and deployment. This is somewhat the biggest problem.
Yes, this can be a bit tricky. For now, the best way is "follow the examples".
Another way is to use Hibernate Tools to generate everything.Some of the config files need documentation
I have tried to do this. Which files in particular are lacking? -
2. Re: Seam Comments
werpu Dec 19, 2005 6:22 PM (in response to werpu)
There is no problem here, pagination is easy to implement (the Hibernate Tools plugin actually generates code to do pagination). All you do is have a nextPage() action that re-runs the query with a diff setFirstResults()/setMaxResults(). Very, very simple.
Well I was thinking more along a different line. JSF has the generic data model mechanism, a mechanism rather rough to implement, but very generic.
I was thinking about the line of a generic EJB3/Hibernate data model, which you only have to feed with a query.
The advantage of such an approach to something like you propose is following. MyFaces and other component libs have semi automatic data scrollers which work on the data tables.
They basically do automatically what you propopse by incrementation of
the internal scroller index of the data model.
In the end the result would be, that you only have to feed an initialized data model, and do not even have to care for the next and back paging.
have tried to do this. Which files in particular are lacking?
I have to apologize here, I overlooked the online docs to the config files somewhat.
Typical case of RTFM on my side.
I will check the docs out thoroughly on this issue to see if I can find something unclear.
Anyway seams is an excellent framework, all it needs is better integration into different IDEs and you have a clear winner, once this thing can be deployed with some wizards and reverse engineering tools (like they exist for hibernate already) in an instant you have something amazing on your hands. -
3. Re: Seam Comments
rdewell Dec 20, 2005 1:35 PM (in response to werpu)werpu,
I think something like your idea about the generic data model has been previously discussed. You might want to check out this thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70199
Gavin actually came up with some related code but didn't appear to offer clear advantages.
Ryan -
4. Re: Seam Comments
werpu Dec 20, 2005 7:45 PM (in response to werpu)Ah thanks, yes it seems that I triggered this a while ago (cannot really remember that).
Actually I see one clear advantage.
With the paginators, of myfaces for instance (dont know if the RI also has one)
you do not need the @page and nextPage() definition as in the examples
the final example probably would look like this:
@Name("bookingList")
@NamedQuery(name="userBookingList",
ejbql="from Booking b where b.user = :user order by b.checkinDate")
@QueryFactory(variable="bookings",
query="userBookingList",
context="bookingDatabase")
public class BookingListAction implements Serializable
{
@In @Parameter
private User user;
@PageSize
private int pageSize = 100;
@Page
private int page = 0;
@DataModelSelection
private Booking booking;
public String cancel()
booking.cancel();
return null;
}
You can omit the page holders and data model
definitions in the seam backend bean /session bean entirely
Also there is no explicit paging code
since the paginators increment the internal data model
positional counter automatically
or differently:
@Name("bookingList")
public class BookingListAction implements Serializable
{
@In @Parameter
private User user;
@DataModelQuery("bookingmodel")
private Query bookingQuery;
@PageSize
private int pageSize = 100;
@Page
private int page = 0;
@DataModelSelection
private Booking booking;
private String queryParam;
public dosearch() {
//change the query here according to the query params
}
public String cancel()
booking.cancel();
return null;
}
...
setters and getters for the query params here
Advantage in both cases, no navigational code,
in the second case only the query has to be defined
the counter position still can be injected.
Advantage in all of those cases, you only keep one page
of objects maximum in ram, which is a clear advantage to keeping
an entire (and possibly huge) collection of proxy or non proxy objects in ram.