After login, I need to show an actor a list of all owned processes, allowing the actor to click a button to get to the current task within that process (just like the jBPM web console). When clicking, a view that is applicable for that specific task will be shown, and this view might refer to some specific actions. Alternatively just a list of the current tasks would do as well, just as long as clicking the button allows me to show some task-specific view. So, I'd like something like: <h:dataTable value="#{taskInstanceList}" var="task"> | : | <h:column> | <s:button action="#{myGenericHandler.selectTask}" taskInstance="#{task}" value="Go"/> | </h:column> | </h:dataTable> ...but I guess I need to write my own code for action=#{myGenericHandler.selectTask} -- right? So: one cannot somehow use annotations or some configuration to specify what to do when a specific task is signaled by the actor, right? In other words: using annotations Seam can signal jBPM that a task is started or completed when some Java code is executed, but Seam has no means to tell what Java code needs to be triggered for some generic action. I know that in the jBPM web console the task-specific views are defined and stored along with the process definition itself (using forms.xml to tell what view goes with each task). This allows for rendering task-specific views. I also know that, when not using such form definitions but instead using Seam to define the views (while still allowing each task some specific view and action), one can use taskInstanceListForType to render the button, like the DVD Store example admin page: <h:dataTable value="#{taskInstanceListForType['approve']}" var="task"> | : | <h:column> | <s:button action="#{accept.viewTask}" taskInstance="#{task}" value="Review"/> | </h:column> | </h:dataTable> | | <h:dataTable value="#{taskInstanceListForType['ship']}" var="task"> | : | <h:column> | <s:button action="#{ship.viewTask}" taskInstance="#{task}" value="Ship"/> | </h:column> | </h:dataTable> I wonder if this can easily be made more "generic" (realizing that "generic" will in fact be very limited, and will not be usable for just any type of process definition). Thanks for any thoughts on this, Arjan. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4029777#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...