12 Replies Latest reply on Jun 12, 2007 12:17 PM by Matthew Sandoz

    Should GD 3.1 support complex action children?

    John Ruud Newbie

      I recently posted a similar message (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=108375) on the "JBoss jBPM" forum, but I'm now posting it here hoping hoping to get more feedback:

      Our custom actions are able to process complex (nested) children like in the example below (the parent... stuff):

      <node name="Cancel Bill">
       <action class="MyAction">
       <parent>
       <child>CANCEL</child>
       </parent>
       </action>
      </node>


      However, I'm a little confused as to how GD 3.1 deals with these complex elements (we're currently using the XML editor to modify them, but plan on adding custom property pages).

      Assuming I understand correctly, children of Delegation subclasses like Action are stored in a configInfoElements collection. However, I get the feeling that ConfigInfoElement may possibly not have been designed to deal with complex elements (for example because: ConfigInfoElementDomAdapter.doModelAdd(XmlAdapter) seems to be intentionally ignoring any children).

      In order to support complex structues like those above, does it make sense to try to make it work with the ConfigInfoElement approach (and extending it if necessary), or should I rather create my own semantic element and xml adaper to deal with the complex Action children? (please let me know if you need more info)

      Thanks, John

        • 1. Re: Should GD 3.1 support complex action children?
          Koen Aers Master

          Hi John,

          You are really living on the edge, stretching the GPD to its limits ;-)

          The GPD is indeed not capable of handling complex configuration children. I think at present the best way is indeed to create a dedicated semantic element as well as an xml adapter for this kind of configurations, but I have not yet tested this myself.

          There is a need for the ESB project to make a dedicated ESB node, so I am very interested in the issues you run into. Please keep me posted about them.

          Regards,
          Koen

          • 2. Re: Should GD 3.1 support complex action children?
            John Ruud Newbie

            Hi Koen,

            just the person I was hoping to hear from :) I will give the custom element and xml adapter approach a try, and will let you know if I run into any serious issues.

            My plan is to implement a workflow editor that supports our own DSL, that is basically a slightly modified version of jPDL with some new node types (so not exactly rocket science, while things are never as easy as planned...). I'm positively surprised by the new GD design, as I haven't needed to make any significant changes to org.jbpm.gd.jpdl so far (other than a few tweeks, posted as bug reports, and that hopefully may eventually become part of gd/gd.jpdl).

            John

            • 3. Re: Should GD 3.1 support complex action children?
              Koen Aers Master

              Hi John,

              I saw your JIRA issues, but did not have time to respond/investigate/implement them yet.
              To raise your confidence even more, we currently have a customer doing the exact same thing as you want to do, so normally things should work out fine. ;-)

              Regards,
              Koen

              • 4. Re: Should GD 3.1 support complex action children?
                Tom Baeyens Master

                Koen, for the future versions of jPDL, it would be good if you could think about how we could handle this in general.

                How can a developer of a an actionhandler specify a form to be plugged in to the gpd for configurating it ?

                It would be nice if we could offer a pluggable, flexible way of handling this. Also think about the tradeoff: the more generic you want to solve this, the complexer the solution will be.

                I was thinking about specifying forms and use some kind of el expression language for referencing the properties and beans in the action handler.

                • 5. Re: Should GD 3.1 support complex action children?
                  Edward Staub Expert

                  Tom,

                  Have you thought about the ramifications of going to a GPL license for the GPD in this area? IANAL, but I think it would forbid inclusion of any closed-source Java code by the form developer.

                  You wrote:

                  I was thinking about specifying forms and use some kind of el expression language for referencing the properties and beans in the action handler.

                  This sounds like you're thinking thin-client - but I'm reading too much into it.

                  Longer-term, I wonder if JavaFX is relevant here.

                  -Ed Staub


                  • 6. Re: Should GD 3.1 support complex action children?
                    Koen Aers Master

                     

                    "Ed" wrote:
                    Have you thought about the ramifications of going to a GPL license for the GPD in this area? IANAL, but I think it would forbid inclusion of any closed-source Java code by the form developer.

                    I am also not a laywer but I am pretty sure that this is only the case if you want to redistribute the GPD. We specifically want to prohibit users from taking our GPD adding stuff withoug contributing back and selling commercial licenses for it. If they want to do that fine, but the idea is that they then obtain a license for doing it.

                    As for the original topic. I will give this a good thought first. Complex configuration of action handlers should definitely be pluggable. But I am not sure yet as how this would best be realized.

                    Cheers,
                    Koen

                    • 7. Re: Should GD 3.1 support complex action children?
                      Edward Staub Expert

                      Koen,

                      You wrote:

                      If they want to do that ["adding stuff withoug contributing back and selling commercial licenses for it"] fine, but the idea is that they then obtain a license for doing it.

                      Does this mean you're contemplating a dual-license model for the GPD?
                      I'm a little surprised - this isn't my area, but I thought this wasn't something Red Hat did.

                      Thanks for the info,
                      -Ed Staub

                      • 8. Re: Should GD 3.1 support complex action children?
                        Koen Aers Master

                        Hi Ed,

                        It is not me contemplating about this. This is a discussion that is already going on for quite some time. More specifically since the hibernate tools project had problems with MyEclipse modifying the plugin and redistributing it under their commercial license.
                        This discussion is not yet finished, so I cannot say yet where exactly we are going. Anyway, a normal user should not be affected by this decision.

                        Regards,
                        Koen

                        • 9. Re: Should GD 3.1 support complex action children?
                          Matthew Sandoz Newbie

                          Im basically doing the same thing here and so am VERY interested in anyone else working on it. My story is that I was working with another workflow product and we have decided to switch to jbpm. having looked at the code it seems very well designed overall.

                          we are converting over our editor hoping to leverage your editor, just with some addons mostly - custom editors of the handler data among them. i put together a custom schema for some dataflow pursuant to that.

                          we are also interested in providing a version that has a "live" view of the executing flow - including getting at the instance variables and token states.

                          but the first thing i want to get in is the custom editors :)

                          anyway thanks for a great project. i look forward to working with it and contributing back anything that looks of value. all of our work is LGPL.

                          • 11. Re: Should GD 3.1 support complex action children?
                            Bernd Ruecker Master

                             

                            we are also interested in providing a version that has a "live" view of the executing flow - including getting at the instance variables and token states.


                            Maybe you want to have a look at our admin client, but it is Swing not SWT:
                            http://www.camunda.com/toolkit_for_jbpm/jbpm_gui_tutorial.html#additional_components (The page is not yet released, so sorry for the poor layout). Currently I am pushing it to sourceforge, so it is easy available.


                            • 12. Re: Should GD 3.1 support complex action children?
                              Matthew Sandoz Newbie

                              Bernd I like what I see there.

                              I'm bound though by my requirements to provide an all-in-one view - which looks like it will be better building on top of jbpm GPD. Even though it has been painful to get started, I think that is my best hope. Unfortunately what we have is a swing app and im not a great gui developer and have no foreknowledge of SWT so am at a deficit there.

                              I just hope that I can get the builds working soon so that I can make a couple additions.

                              I am probably going to need to put together custom editor dialog boxes and will also need a way of bringing up instance windows that look like the a read-only version of the GPD - that can listen to the changing state of the workflow - and update visually based on the transitions. We do that currently with our swing product and its a beloved feature of the users.

                              unfortunately it is all swing, using jgraph and points to another workflow system.

                              are you looking to do a SWT version of custom xml editor dialog box? from other posts it sounds like they are considering doing a plugin architecture for new editors. if this is true it would actually help with about half of my work :)

                              Does anyone know if theres a timetable or relative priority for configurable or custom editors or dataflow editors?