next steps for the console webapp

[tom.baeyens]

hi, this post is to sync everyone on the next steps of the web application.

* currently, in head, there is a JSF based web application using facelets (instead of jsps) for the presentation layer. also the task forms mechanism is now based on facelets.

* the first thing that should be done is convert this to a jboss seam web application. then monitoring and administration functionalities should be added.

* we have a new full time developer for the web application starting in august.


who else wants to contribute to the web app and in which parts are you interested ?

[tom.baeyens]

i'm not yet 100% sure if the move to seam is a good one. my main concern is runtime deployment constraints.

but everything that i can see now points in the direction that moving to SEAM would be a great thing.

so after the conversion to a seam app we should have a small evaluation. i don't expect any problems so we should proceed as if we are sure of the move to seam.

[kukeltje]

Most of the work will be in creating the JSF ui components, adding monitoring then and administration functionalities (including some ui components, defining HQL etc) is for me the next step. The webapp itself is not to difficult.

If seam works with jdk1.4 and runs on Tomcat, JBoss AS, WLS and Websphere, then it would be fine by me, altough I will not have the time to learn seam in the near future. But since seam requires jdk 5.0 I would personally not do it (yet)

[svetzal]

Seam is a lot of infrastructure to add in as a base requirement, but it's oh so sweet to use.

I think there's a lot of work to do regardless of seam or not in terms of JSF components. Seam does interesting things to expose things for you but leaves it up to you to do the rendering.

Any JSF components built would be the same regardless as to whether this was a seam app or not.

My hope over the past several months has been to gain insight into writing complex JSF components, and thus far I'm not particularly keen. There are a lot of rough edges throughout MyFaces and JSF.

I've been trying to avoid creating yet another JSF framework for components, this seems outside the scope of jbpm. The alternative is tying ourselves to a specific implementation (MyFaces) and using their existing infrastructure(s) for things like external resource binding.

How does everyone feel about an explicit tie to MyFaces?

[aguizar]

I want to make sure the monitoring tools work with BPEL processes too. Things like watching/updating variables and showing/signaling stalled tokens would be a great thing to have.

IMO we should not depend on Seam. Personally I love it, but some jBPM users might not be in the position to jump to it. On the other hand, Seam users can still leverage our JSF components.

Regarding the JSF implementation dependency, I have two concerns:

Is there any other open source implementation we might want to switch to at some point? If not, depending on MyFaces is OK.
Can we take only what we need from MyFaces and use that on other JSF implementations? I don't mean forking it, just redistributing the portions we don't want to write ourselves.

[kukeltje]

agreed, not be dependant on seam (yet, jsr 299 would be good if they hurry ;-) go gavin go....) but try to create good enough jbpm ui components that maybe inherit lots of things from default myfaces/tobago/trinidad/aruba/curacao/.... to be usefull.

[tom.baeyens]

about the infrastructure requirements of SEAM:

i'm not so sure if SEAM adds too much infrastructure. especially since you should consider that these requirements DO NOT propagate to the engine. jBPM 3.x will remain runnable on JDK 1.4.2

The two main requirements are:

Java 5: i think that should not be a big problem by now for the console. I do think it would be a big problem for the jbpm core runtime library.

EJB3: That can be packaged with the microcontainer and is runnable on a standard java environment. SEAM is usable in tomcat, jboss and in other app servers. While this seems tricky to me, i have full confidence in Gavin that it will work 'seamless' :-)

any other requirements i forgot ?

what is your opinion on those 2 ?

again: note that this is for jbpm console. you could run jbpm console on a separate tomcat, while your jbpm runtime environment is running in a jboss or other environment.

[tom.baeyens]

"svetzal" wrote:

My hope over the past several months has been to gain insight into writing complex JSF components, and thus far I'm not particularly keen. There are a lot of rough edges throughout MyFaces and JSF.

sure a task list and a task form JSF component should be possible, no ?

"svetzal" wrote:

The alternative is tying ourselves to a specific implementation (MyFaces) and using their existing infrastructure(s) for things like external resource binding.
How does everyone feel about an explicit tie to MyFaces?

i don't see why an explicit ty to myfaces would be required. also i don't get what you mean with external resource binding.

could it be that these problems can be solved with a thread local ? simple version of the idea is to create a http-filter that sets up the environment which is able to fetch the external resources and store this environment in a thread local somewhere. then inside of your JSF components, you can access the external resources through the environment. it should be very similar to how we do it now in the console. i think.

[kukeltje]

I disagree that requireing JEE 5 for the console is a valid option. Many serious organizations have environments that have to be identical. I myself cannot get a JEE 5 environment just for the console/webapp (in fact, I cannot get one at all).

Since I do some of the development indirectly in the time of my employer, this will certainly not be appreciated and most likely result in withdrawing this 'time'.

Regarding the components, I would try to to base the tasklist (sortable, pageble) on an existing datatable. The myfaces one (in tomahawk) fits nicely.

The taskform component should also not be to difficult

[svetzal]

sure a task list and a task form JSF component should be possible, no ?

For sure, it's all a matter of how interactive you want it to be. Event propogation and state coordination between sub-components we've found tricky due to the way the components are instantiated throughout the JSF request lifecycle.

And if we're not adding much more value than a single-tag analog of a JSF dataTable, I'm not sure why we'd want to make the effort.

i don't see why an explicit ty to myfaces would be required. also i don't get what you mean with external resource binding.

In order for a component to be highly interactive, and visually interesting, we will require some client-side JavaScript, CSS styles, possibly iconography/images... In order to make this easy for JSF app developers to use we would want to package the components in a JAR along with their own resources.

Serving out these resources is not difficult, but seems "hackish" as you need to settle on your own URL convention, build a phase listener to implement that convention, and broker requests to these private resources. And you need to build it flexibly so you can grow this library in the future.

MyFaces has some interesting efforts underway to make this flexible and elegant, but the classes are buried in recent implementations. You can see if you check out HEAD and look through the Tomahawk implementations.

It would be very interesting to split these out into a separate package in hopes that it could be used with other JSF implementations.

I have an interactive JSF component written by one of our guys here (with much cursing and swearing) that does LDAP browsing and object selection. Our next step is to refactor it so that it is simpler.

[kukeltje]

"svetzal" wrote:

For sure, it's all a matter of how interactive you want it to be.

Not much, certainly not initially

"svetzal" wrote:

And if we're not adding much more value than a single-tag analog of a JSF dataTable, I'm not sure why we'd want to make the effort.

Correct, for the form elements that is true. Now you'd have to pass it some thing to make it read-only or not, pass the label, the formelement etc.... That could all be hidden, but the advantage is imo to little.
For the 'transition buttons' it would hide some things, but there to I'm looking for a different implementation instead of using javascript to set another field. I'm no supporter of hiding complexity, removing complexity is imo always better.

"svetzal" wrote:

It would be very interesting to split these out into a separate package in hopes that it could be used with other JSF implementations.

Please explain a little more, I do not exactely get what you mean.

"svetzal" wrote:

I have an interactive JSF component written by one of our guys here (with much cursing and swearing) that does LDAP browsing and object selection. Our next step is to refactor it so that it is simpler.

Would things like combining dojo/myfaces solve anything here?

[alkero]

I don?t see the interest to convert the console to a jboss seam web application. I think the console must be as simple as possible, and pre requisites are to avoid.
However a generic and reusable monitoring/administration console have a lot of interest from my point of view.

And welcome to the new developer !


Regards,
David

[tom.baeyens]

"kukeltje" wrote:
I disagree that requireing JEE 5 for the console is a valid option.

me too. JBoss SEAM requires JSE 5. with the microcontainer, it can make use of embedded ejb3.

[tom.baeyens]

"kukeltje" wrote:
I would try to to base the tasklist (sortable, pageble) on an existing datatable. The myfaces one (in tomahawk) fits nicely.

The taskform component should also not be to difficult

that would be great. please, try to avoid any non JSF dependencies (like tomahawk). i don't know if their license permits it, but forking that source to for that component into a jbpm tasklist might be an option. of course, that is only possible if their component source doesn't use all kinds of tomahawk abstractions (quite likely), in which case we would end up forking half of the tomahawk base code. that would not be good.

the main reason is that for now, i would like to keep the JSF implementation open.

[tom.baeyens]

"svetzal" wrote:
And if we're not adding much more value than a single-tag analog of a JSF dataTable, I'm not sure why we'd want to make the effort.

Maybe we should consider writing only a task list backed bean that fits the JSF dataTable nicely. That would seem like a good gain/effort ratio.