8 Replies Latest reply on Jun 28, 2007 5:41 PM by Matthew Sandoz

    dataflow integration

    Matthew Sandoz Newbie

      i'm working on a custom extension to the editor to support dataflow and more custom nodes. my first thought for a direction is to create a new semantic element for a dataflow node which i would then extend with custom nodes and provide custom editors - as property tabs.

      Concerning mapping:

      is this the right way to go? i also considered adding mapping support through an extra mapping element for the existing node class and then extending that with the custom node classes. the mapping extension would provide a mechanism for mapping the handler variables to inputs and outputs which would be configurable through a simple property editor.

      Concerning custom editors:

      i think it would be nice to be able to construct custom handler editors by creating a mapping from the handler class to the editor class and then simply bringing up the appropriate editor in a property tab. to help differentiate the various custom nodes in the designer it would also be nice to have the mapping provide an icon and to have a palette entry for it.

      is this a reasonable direction?

        • 1. Re: dataflow integration
          Matthew Sandoz Newbie

          is this a better topic for the user forum?

          • 2. Re: dataflow integration
            Ronald van Kuijk Master

            no it is not, but I think the people most knowledgeable in this area are fairly busy at the moment ant therefor did not have the time to respond.

            • 3. Re: dataflow integration
              Koen Aers Master

              To be honest, I did not see the post until now.

              As for the questions asked, I will document how to do this type of customization soon. It is not as easy as I want it to be yet. The best way to do it at the moment is indeed create a new mapping with a new semantic element that would derive from the generic node and a new xml mapping element that uses the 'node' xml tag. You can provide entries in the palette for it with the paletteEntry extension point and additional property editors that would appear in a new tab or in a tab of your choice by using the propertyTab and propertySection extension point.

              Let us know how it goes.

              Regards,
              Koen

              • 4. Re: dataflow integration
                Matthew Sandoz Newbie

                thanks for the encouraging and informative replies. i will begin working on this next week.

                • 5. Re: dataflow integration
                  Matthew Sandoz Newbie

                   

                  "koen.aers@jboss.com" wrote:
                  To be honest, I did not see the post until now.

                  As for the questions asked, I will document how to do this type of customization soon. It is not as easy as I want it to be yet. The best way to do it at the moment is indeed create a new mapping with a new semantic element that would derive from the generic node and a new xml mapping element that uses the 'node' xml tag. You can provide entries in the palette for it with the paletteEntry extension point and additional property editors that would appear in a new tab or in a tab of your choice by using the propertyTab and propertySection extension point.

                  Let us know how it goes.

                  Regards,
                  Koen


                  I'm working on the extension points with limited success. The XmlAdapterFactory and SemanticElementFactory are where I've been concentrating my work and they seem to be heavily dependent on the xml node name - for creating new elements and reading elements in from the process definition file.

                  what i've done so far is:

                  1. added a SemanticElement "Jython Node", pointed it to a model class I copied from Node, gave it the name "jython-node" and id "org.jbpm.gd.jpdl.jythonNode". the model class was identical to Node other than where it explicitly cast something as a node, I changed it to cast to a JythonNode.
                  2. added a palette entry with object org.jbpm.gd.jpdl.jythonNode
                  3. added an xmlMappings mapping with id and semantic element "org.jbpm.gd.jpdl.jythonNode" and a JythonNodeDomAdapter adapter class and an xmlElement of "node"
                  4. added a notationMapping mapping id jythonNode with semantic element "org.jbpm.gd.jpdl.jythonNode" and notation element org.jbpm.gd.jpdl.node


                  An alternative to having to change the node name in the xml for each of my nodes - which leads to lots of changes - is to have the mapping between semantic elements and dom adapters managed by a set of mapping classes operating like a chain of responsibility. these mapping classes would be able to determine, given a semantic element, if they were able to map it to a dom adapter or, given a dom adapter, they would be able to determine if they could map it to a particular type of semantic element. when generating one from the other, you could simply loop through the classes until one was able to do the mapping desired. you could then deal with any overlaps with precedence among the mappers.

                  for example a mapper could take a chunk of xml and determine which semantic element should be generated by introspecting into it. it could then choose a dom adapter appropriate to that semantic element.

                  in my case id like nodes to be different semantic elements based upon their handler class. if i couldnt identify what element to provide, id just fall back on Node.

                  what do you think? is there an easier way to do this?

                  • 6. Re: dataflow integration
                    Koen Aers Master

                     

                    "msandoz" wrote:

                    for example a mapper could take a chunk of xml and determine which semantic element should be generated by introspecting into it. it could then choose a dom adapter appropriate to that semantic element.

                    This is definitely the way to go. My idea about the dom adapters was to make it possible to mostly configure them declaratively. After all, they contain only mapping information. But the mapper will be necessary to resolve any possible conflicts between xml elements.
                    So at a first glance following things have to happen:
                    - add another (optional) attribute to the xmlMapping extension point: mapperClass
                    - modidfy the XmlAdapterRegistry and more in particular the method getConfigurationElementByXmlElementName to include the mapper behaviour
                    - for each overloaded xml element include the appropriate mapperClass implementation in the xmlMapping extension contribution
                    The mapperClass should of course implement an interface XmlMapper or something that is to be included in the org.jbpm.gd.common.xml package. I would be very grateful if you could pull this off. If you do and are able/wiling to contribute, you can submit a JIRA issue with your changes attached.

                    Let us know how it goes!

                    Regards,
                    Koen

                    • 7. Re: dataflow integration
                      Matthew Sandoz Newbie

                      I've put together some classes, plugin.xml and exsd changes. im working on the jira ticket now...

                      • 8. Re: dataflow integration
                        Matthew Sandoz Newbie

                        ive recorded this as GPD-111:
                        http://jira.jboss.com/jira/browse/GPD-111

                        and attached my changes in a zip file. I hope it meets with your approval. Please feel free to contact me if you have any questions/concerns about the implementation. I will check back on the JIRA status tomorrow as well though.

                        Now on to node dataflow... :)