"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
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
