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

[pete.muir@jboss.org]

"stephen.friedrich" wrote : 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).

I think this is a case where @RequestParameter may be better.

You can then just use it to initialize the id of the EntityHome in the first instance of the click on the list - it won't get propagated if you remove it from pages.xml.

anonymous wrote : 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".

http://jira.jboss.com/jira/browse/JBSEAM-1896
  
anonymous wrote : 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?

I would use @RequestParameter.  page params are very useful, but not quite as versatile (as they do the parameter management for you whilst using @RequestParameter you have to do it yourself)

anonymous wrote : 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?

I would do something like the event handling method in Seam2.  Build a custom version of EntityHome

public class EmployeeHome extends EntityHome<E> {
  | 
  | @Transactional
  | public String persist() {
  |    String result = super.persist();
  |    raiseEvent("mydomain.afterTransactionSuccess.Employee");
  | }
  | 
  | // Same for remove, update
  | }

<event type="myDomain.afterTransactionSuccess.Employee">
  |    <action execute="#{employees.refresh}" />
  | </event>

I would avoid futzing with the EntityQuery results yourself.

anonymous wrote : 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?

The method called by Seam must be marked @Transactional, and calls to super. aren't intercepted by Seam. So yes, you must mark it @Transactional.

anonymous wrote : 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?
  | 

Probably best to do this in pages.xml using <begin-conversation /> - you need to decide where to do conversation demaraction - I wouldn't on clicking on employees, but on clicking on an employee to edit (and make sure to rejoin any existing conversation).

Actually you really should use Seam2 (CR1 out over the next couple of days) as you get the events described above, and natural conversation id support which is ideal for this application.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4085423#4085423

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4085423