9 Replies Latest reply on Jan 21, 2009 4:24 AM by michaelneale

    Console workspace framework

    heiko.braun

      It came to my ears that someone is developing a framework for dealing with the workspace/editor layout and plugin to the console. Can someone point me any resources?

        • 1. Re: Console workspace framework
          heiko.braun

          I was looking into it myself and it turned out to be not such a big effort to do it on my own: http://jboss-overlord.blogspot.com/2009/01/developing-bpm-console-plugins.html

          • 2. Re: Console workspace framework
            michaelneale

             

            "heiko.braun@jboss.com" wrote:
            It came to my ears that someone is developing a framework for dealing with the workspace/editor layout and plugin to the console. Can someone point me any resources?


            Mike Brock is working on replacement widgets so we can reduce the dependency on GWT-EXT for the core stuff, so that would feed into this nicely.

            • 3. Re: Console workspace framework
              heiko.braun

              Michael wrote:


              Any chance we could:

              a) Find a place in SVN we can put this base console
              b) think of a namespace that is neutral: I propose org.jboss.gwt.console
              c) have a skype chat next week sometime you and I?
              d) Do you think we could call "Editor" something like "View" ? cause
              editor means something else to me.


              • 4. Re: Console workspace framework
                heiko.braun

                Yes, we can move it and rename as we like. Outside the BPM console is a good idea. I am open for suggestions how to rename the interfaces. Maybe something close to eclipse terms would make sense, because many people know it.

                There is currently one problem with the API: It has a dependency on gwt-ext. So I need to remove it first, before we can proceed.

                • 5. Re: Console workspace framework
                  heiko.braun

                  I just realized something else. The first cut of the API assembles plugins on the BPM console level. It needs to be changed to have a console stub project instead, which projects can leverage.

                  Current:

                  Plugin-API --> BPM Console
                  


                  Future:

                  Plugin-API --> Console Stub
                   |
                   ^
                   BPM Console
                  



                  • 6. Re: Console workspace framework
                    heiko.braun

                    The console stub and plugin API would then leverage the mosaic project.

                    • 7. Re: Console workspace framework
                      heiko.braun

                      Thomas said:



                      Are there any plans to extend the notion of plugins to the server module? For example, if I write a plugin for Process Management or Task Management I would also want to extend the server side REST facade.

                      Taking this idea even further, as the number of available plugins grows there might be an overlap of conceptually common data. For example the list of active Process Instances might be of interest to more than just one plugin.

                      Instead of every plugin defining its own propriatary REST facade for Process Instance data, there might be a need for data access that is "native" to the gwt-console. This would result in a standard interface that is available to every server side plugin.

                      Some of this we have in the BPM Integration Layer, which already deal with the notion of

                      * ProcessEngine
                      * ProcessDefinition
                      * ProcessInstance
                      * Message
                      * Signal

                      Note, that I've taken the notion of Token out of this list, which seems to be proprietary to jBPM


                      • 8. Re: Console workspace framework
                        heiko.braun

                        @Thomas

                        Yes, plugins for the console server would be the next step. As for the common model: Yes, that came to my mind as well. The shared model (i.e. Process Definition, Process Instances, User, etc) should be available to any plugin, probably through the ApplicationContext.


                        • 9. Re: Console workspace framework
                          michaelneale

                           

                          "heiko.braun@jboss.com" wrote:

                          There is currently one problem with the API: It has a dependency on gwt-ext. So I need to remove it first, before we can proceed.


                          Actually that isn't really a problem with the API - but the implementation used - I don't think that the API should expose any specific gwt-ext apis, but for the moment if it needs to use it, that is ok I think - any people that use the API don't have to explicitly use gwt-ext (and shouldn't, ideally, unless they really really want to !).