Thanks Pete for the quick answer! It helps somewhat, but still I don't really
know how to make use of conversations.
If you could stay with me for a while that would be great! I will really try to
come up with a helpful example in the end.
1) Deletion problem
You suggested calling both setInstance(null); and setId(null); in the remove
method of the employee home.
That did not help. After some late night debugging I found out that page
param should be read literally. The employee id is stored in Seam's page
context whenever an employee is selected. It stays there if the employee is
deleted, so the next creation of a new EmployeeHome will dutifully transfer it
again.
Adding this in remove() helps: Contexts.getPageContext().remove("groupId");
I would prefer not to hard code parameter names in Java, though.
Of course you do not have this particular problem when you use separate pages
for listing of employees and and the employee details (and only have a delete
button on the details page).
It would help if the doc made it clear that page params are in fact stored in
the page context. Currently all I read is "request parameter is transfered to
the model according to the page param definition in pages.xml".
2) Page params vs. request params vs. DataModelSelection
Turns out in seampay the @RequestParameter field is really needed.
seampay uses two different ways to transfer an id parameter to a home object:
Account home uses the page param method. Payment home uses @RequestParameter
and overrides the base class's getId() to return the id from the parameter.
An additional option would be to use neither page params nor request
parameters, but to use @DataModel/@DataModelSelection (like the "clickable
list" messages example does).
How should I decide which method to use?
2) Conversation scoped query result
You're right it really feels strange to update the query's result list
directly.
However I do not want to refresh all entities because a single, unrelated
entity has been created.
I could either wrap the query in a conversation scoped component of my own
and outject a List from that component (again pretty much like the
MessageManagerBean in the messages example).
(That way it wouldn't be so strange to add an element to the list after a
create operation.)
Alternatively I could add that functionality to the EmployeeHome itself, but
that would mix responsibility for the employee list with that for the selected
employee.
Or of course I could make the query itself conversation scoped and continue
to update the result list in such a strange way. In the end however I'll
probably have to wrap the query anayway because the
"restrictions"/query-by-example feature will be too limiting to support more
complex filters.
What do you think?
3) Atomic create
Oh well, adding a newly created instance to the list myself isn't
transaction-save, is it? When in the end the transaction fails I may already
have added the instance. Can I do something like this (in my home object)?
| public String save() {
| if (isManaged()) {
| return update();
| }
| String result = persist();
|
| //noinspection unchecked
| List<T> resultList = getEntityQuery().getResultList();
| resultList.add(getInstance());
|
| return result;
| }
|
save() is not marked @Transactional. Will the @Transactional annotation on
persist() still be honored when I call persist() directly from within the
save() method as above?
4) Conversations
What annotations/tag attributes do I need to add where to start a
conversation when the "Employees" header is clicked or when an employee in the
list is opened in a new browser tab?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085362#4085362
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085362
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
