3 Replies Latest reply on Feb 10, 2007 6:02 AM by koen.aers

    GPD New Generation Extensibility

    koen.aers

       

      Hi Koen,

      Am trying to do it on my own - am running into an issue with the JpdlLabelProvider. The list of icons and labels is hard-coded in here - are you planning to expose these via additional elements/attributes on the "core" and "ui" element extensions?

      thanks,
      Mohan


      Hi Mohan,

      Nice to see that you are investigating the GPD code. Please don't hesitate to use this forum to ask questions and generate feedback if you think things can be improved.
      As for your question, the new generation of the GPD is not yet ready for custom extensions. As you correctly have observed, not all the necessary information can be specified in the available extension points. In some places (such as the label provider and the editpart factories) big switch/case logic is present to select the right icon or figure. Also the editpolicies can not yet be specified in the plugin.xml. Well, to be more correct, the extensions are not used at the moment.
      These capabilities (custom extensions of the GPD) will certainly *not* make it into the 3.1.0 GA release because of time constraints. They will be however most certainly be part of a future release in the 3.1.x branch. I know the answer is probably disappointing. However, if you really want to do a custom extension right now, you can identify the places where the switch/cases are found, and replace those classes with your own implementation.

      Best regards,
      Koen

        • 1. Re: GPD New Generation Extensibility
          mohankishore

          The original question:

          Had a quick question on the ability to add a custom node to the designer. Checked the Jira to find that you had commented that this is already available in may 2005 - is that still valid?

          http://jira.jboss.com/jira/browse/JBIDE-136

          Can you point me in the right direction? Have been looking at the plugin.xml for the jpdl designer and the pageflow designer (don't think the pageflow has caught up with the jpdl yet). Basically, I want to show up a custom node in the jBPM designer palette - its just a standard Node pre-associated with a specific ActionHandler and a custom icon, label, etc. Even a few on-liner descriptions of the semantic-element, notational-element, graphical-edit-parts would go a long way..

          • 2. Re: GPD New Generation Extensibility
            mohankishore

            Thanks for the reply Koen.

            Like I said, even a few one liners would probably go a long way in helping me. From what I have been able to figure out, we have the following structure:

            - the plugin.xml defines two kinds of objects:
            a) "core" objects - model or semantic elements
            b) "ui" objects - also known as notation elements

            - the model elements are associated with DomAdapters that serialize/deserialize the model into XML.

            - the ui elements have corresponding EditParts to render them in the graphical editor or the tree view. The problem here is that the label/icon mapping is currently hard-coded in the code.

            - we already have the ability to use a model element and plug it into the palette using an extension point. But am running into a fundamental problem with the XML schema itself...

            The jBPM schema has elements like <fork ..> and <join ..>, whereas I think it might be more extensible if it were <node type="fork" ..> etc. Right now when my custom node gets added to the ProcessDefinitionDomAdapter, it automatically creates an XML element with the same name as the "id" of my model object in the plugin.xml.

            Do you have any comments on this disconnect and the best way to solve it?

            To repeat my underlying requirement: suppose I have an EmailActionHandler that I anticipate being used multiple times within a single workflow. I do not want my users to keep browsing and finding the action mapping. I want to provide a custom icon on the palette, which when placed in the flow will translate to a node with a pre-associated action-handler. (Am currently doing the pre-association by extending the Node class to create my own model object, which associates the action-handler in its constructor).

            • 3. Re: GPD New Generation Extensibility
              koen.aers

              Hi Mohan,

              You are completely right as for what you found about the architecture of the GPD.
              the dom adapters will probably be completely generic in the future; as you may have remarked much of the implementation is mere mapping information.

              the editparts and their associated figures are probably the area where still a lot of work is needed to make things really pluggable. I am afraid there is at the moment no easy way to work around this problem. All the creation factories are implemented with switch statements based on instanceof logic. All this will be replaced by a generic factory that will instantiate configurable classes in the future... To plug-in your own representation, you would have to break open these factory classes. A quick patch would be for me to enable extenders of the GPD to add the label and icon information to the extension definition. If you would like this, file a JIRA issue and refer to this thread. I cannot however promise to implement this in the coming days. I think it will take at least a month before this change would make it into the codebase.

              you are right also about the extensibility using the syntax. This is however a limitation of the implementation of the engine. In jBPM 4 it will probably change, but of course this does not help you now. The good news is that you can do something like you want to do with the current extension point:

              <element
               id="mySpecialMailNode"
               name="node"
               adapterClass="org.jbpm.gd.jpdl.model.xml.MySpecialMailNodeDomAdapter"
               modelClass="org.jbpm.gd.jpdl.model.MySpecialMailNode"/>


              I hope this helps you a little bit. However, I need to stress that the GPD and its extension mechanism are moving targets at the moment. The extension points and the API will without doubt still change in the near future. Let's keep this discussion going on so that you stay up to date with the latest changes.

              Regards,
              Koen