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#4029777
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4029777
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user
