[jboss-user] [JBoss Seam] - Re: Wannabe-Example needs help growing up

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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...