Activiti_Explorer not refreshing menu entries as expected

[jon_k_]

Hi I have an issue with Activiti-Explorer and I hope someone can help.  Firstly Acitiviti's a great product and well done to all those involved in the dev' of the s/w.  However I have an issue that I'm unable to fix within the Activiti-Explorer web application regarding the refreshing of tasks queued.  Although the problem does not stop the software from operating in any capacity it must be noted whilst I as a developer can get by but the same cannot be said the final users of the software who are are not developers and this poses quite an issue [when|if] the software is to be used in a production environment.

I'll try and explain it as best as I can…

    1. A user, belonging to group A and B, completes a task with the following task only valid for group B
    2. As expected Queued[0] does not update with the current number of jobs waiting for group B but remains constant.
    3. Forcing the software to refresh (F5 does not work in this instance) by clicking a menu entry or moving the screen away and causing the software to internally to refresh causes the entry to appear correctly.  The menu now reads Queued[1] with the submenu indicating that a job has been added.
    4. Clicking on the appropriate entry in the drop down list under the Queued[0] menu before forcing a refresh brings up the job at hand even though the job is not indicated as being queued

Any help to resolve this problem would be greatly appreciated.

[frederikherema1]

First of all, activiti is a developer-platform and the Explorer-app is an app demonstrating the usage of the full Activiti API. The queued menu's are not altered after task-operations, only the assigned and involved tabs are. Pressing F5 doesn't refresh the list, as Vaadin caches the widget-state on the server. When changing page, this list is refeshed again.

We opted for this strategy (not refreshing queued) as this can be a heavy query to perform on "every" operation you do in the UI. You can, off course, alter this behavior in the app yourself to suit your needs…

[jon_k_]

Ok, got it.   Thank you for your reply.

… Update…
After downloading the Activiti-Webapp-Explorer2 source code and adjusting to get the desired behaviour I thought I'd post back to let anybody else who may be interested know where to inject the code within the application to gain the functionality as described in my earlier post.

1. find the TaskDetailPanel class and within this the initTaskForm() method and then the handleFormSubmit method.
2. inject the following line of code so it's the last line of code in the handleFormSubmit method to cause the refresh of the UI taskPage.initUi();

In my case I wrapped the call to refresh inside a function that filtered whether or not the refresh actually needed to take place.
If anyone's interested the following is an overview of code within the application, what to look for and where I placed the code to refresh the menu bar

package org.activiti.explorer.ui.task;
public class TaskDetailPanel…
  …
  protected void initTaskForm() {
    …
    if(formData != null… ) {
    @Override
    protected void handleFormSubmit(FormPropertiesEvent event) {
      …
     taskPage.initUi(); // *** new injected code ***
    }
  } else {
    …
  }
}

Anyway, great job.  And thank you for your advice and prompt response.
Regards
JK

[udoderk]

I thank you for the buffix solution , my TODO list has shrunk by one point.

[udoderk]

…
We opted for this strategy (not refreshing queued) as this can be a heavy query to perform on "every" operation you do in the UI. You can, off course, alter this behavior in the app yourself to suit your needs…

The refresh button on some place on gui would be (imho) better solution, to avoid the "automatically" refreshing after "every" operation.
The current solution is  realy not optimal   ops: An user of this web applicarion just click on entries to perform the operation and amazes, because no operations to do…