New (3.3) web console - project and components

[dmlloyd]

As outlined in prior posts (and as a convenient topic to kick off the new forum), I want to sketch over my ideas for the new web console, as far as the component design goes.

My current plan is to divide the component library up in to two parts.

The first part will consist of a component library that is specific to jBPM; it will provide components that provide jBPM functions, like starting processes, signaling tokens, providing task form buttons, and so on. This library can be used completely separately from the web console. Ultimately the web console should just tie these components together.

I'd like to have maximum reusability for these components. Users should be able to just drop them in to their own web apps, whether they are plain JSF or Seam applications, and thereby add the same kind of functionality that the web console provides to their own applications. I think "jbpm4jsf" is a good name for this library - any opinions?

This library could be a subproject of the web console, or it could be standalone. I'm interested in opinions on this topic as well. If we make it standalone, that allows us to release updates independently of the jBPM core, but we then may have to ensure compatibility across a wider set of version combinations between jBPM and the component library.

The second part will consist of a component library that is completely independent of jBPM. This should be a completely self-contained project that provides the kind of basic components that we have created in the web console that are not specific to jBPM, but facilitate our page layout and the nuts and bolts of the web application itself. I think it would be best to implement this as a new project on jboss.org; the kind of components that are implemented currently in the web console have generated some degree of (JSF) community interest. So, this will be my plan for this part unless someone objects strongly.

Let's see, I think that's enough to get one thread started anyway. :-)

[fady.matar]

I absolutely agree with you David.
JBPM4JSF sounds a good name for the project, I guess the task now is to define the components that need to be built.

Now regarding the other components, I guess we should have a look at trinidad or what was previously known as ADF Faces a contribution by Oracle. ADF provides a number of components that can be reused I had a look at their samples and they're worth a try.

What do you guys say?

[aguizar]

A separate project with independent release cycles makes sense for the components not specific to jBPM.

I am not so sure about jBPM components. From what you say, I assume the purpose is to allow for updating the components even if one sticks to a specific jBPM version. As jBPM releases go out, QA costs will increase, probably beyond the benefits. Since you will be in charge of ensuring compatibility, you are in the best position to decide :-)

How about "jbpm faces"? "jbpm4jsf" is slightly hard to spell :-)

[kukeltje]

how about jboss faces, since seam has several components as well that might be interesting.... ? hmmm I thought I was just kidding, but on second thoughts....

[tom.baeyens]

A separate project with independent release cycles makes sense for the components not specific to jBPM.

I am not so sure about jBPM components. From what you say, I assume the purpose is to allow for updating the components even if one sticks to a specific jBPM version. As jBPM releases go out, QA costs will increase, probably beyond the benefits. Since you will be in charge of ensuring compatibility, you are in the best position to decide :-)

How about "jbpm faces"? "jbpm4jsf" is slightly hard to spell :-)

module web.console is just a prototype of the port to SEAM. once that is far enough advanced, it will replace the console subproject in the jbpm.3 module.

it needs to be a separate subproject in jbpm.3 with its own versioning cause i want to share this console between jPDL and BPEL and maybe later XPDL.

ronald, i think we should have our own faces component for better control. imagine if we share components with SEAM and then we want to change things... If we see a common set of very similar components arising, then it will be time to extract those. But by that time, they will be more stable and the requirements will be better known, making the extraction of the common part a lot easier.

[kukeltje]

Oh, I did not mean it has to happen *now*, just that investigating this (you talking about this with the seam guys) now could not hurt. e.g. Generating a form with a date input... which component are we going to use by default? Seam has one that is getting better by the day.... our filterable, sortable, pageable datatable/tasklist is an interesting generic one for seam. A nice menu component, etc..etc..etc... There is already a common basis to be defined.

[zipwow]

What's the right course of action for someone wanting to use and possibly contribute to the jbpm-console? Just carry on with the jsf-based one as it exists now, modifying it to do what I need it to do?

I had resisted making modifications to it up to now, even using the container-based security with the guess that this might make it easier to pick up changes in the future.

-Kevin

[tom.baeyens]

"zipwow" wrote:
What's the right course of action for someone wanting to use and possibly contribute to the jbpm-console?

as always, start with proposing the changes on the dev forums so they can be discussed. then you'll get the necessary feedback on where and how.

"zipwow" wrote:
Just carry on with the jsf-based one as it exists now, modifying it to do what I need it to do?

we're still in evaluation phase to start see if we can move the current JSF based webapp to a SEAM based web app. But every looks good and chances are good that the move will start to happen shortly.

"zipwow" wrote:

I had resisted making modifications to it up to now, even using the container-based security with the guess that this might make it easier to pick up changes in the future.

please already start with proposing and discussing the changes here.

[zipwow]

The parts of the current console that I'm most interested in(*) are the .par loading and process overview features (looking at what instances currently exist, who they're assigned to, etc). Which of the two sections would that functionality belong in?

-Kevin

* I'm interested in them because they seem like common stuff I don't want to re-write.