Announcement Announcement Module
Collapse
No announcement yet.
3rd party integration for Glazed Lists Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 3rd party integration for Glazed Lists

    As discussed in another thread, I would like to integrate Glazed Lists into Spring RCP. Such integration would be helpful for both projects! Has Spring RCP already integrated any other 3rd party libraries? If so, how was this done on a technical level? I am specifically interested in CVS, bugtracking, Java package renaming, etc.

    I would like to keep Glazed Lists independent:
    - I would like to develop Glazed Lists independently of Spring RCP. Although Glazed Lists will integrate nicely into Spring RCP, it does have some orthagonal features that are not appropriate for Spring RCP. For example, Glazed Lists supports both Swing and SWT.
    - I would like to continue using Glazed Lists Java package name of "ca.odell.glazedlists"
    - I would like to continue using Glazed Lists independent CVS, bug tracker and mailing list.

    Yet I would also like to integrate Glazed Lists tightly into Spring RCP:
    - The Glazed Lists code should be stripped of orthagonal classes such as those for SWT.
    - The Glazed Lists code should use an appropriate package. I was thinking "org.springframework.richclient.lists"
    - The Glazed Lists code should not make it more difficult to build Spring RCP.

    I have some ideas on how to implement this:
    - I have created an elementary task for renaming Java packages in Ant. You give it a source tree and the packages to rename and it does the rest automatically. Currently this uses a modified build of the JRefactory/JavaStyle ant task.
    - The Spring RCP CVS could contain a recent copy of the appropriate Glazed Lists code in a .zip file. Spring RCP's Ant tasks could access the code inside this .zip for compile and javadoc targets.
    - The Glazed Lists build.xml file could have a task to construct that Spring RCP source .zip. Such a task would do package renaming and trim unwanted classes.
    - Finally there could be a package in either project for 'tight integration' classes. One example that comes to mind for me is a bridge between Glazed Lists and Hibernate.

    The better that this mechanism works, the easier it will be for Spring RCP to integrate other 3rd party libraries.

    Any ideas?

    Cheers,
    Jesse
    [/url]
    Last edited by robyn; May 14th, 2006, 05:04 PM.

  • #2
    I would love to see tight integration between Glazed Lists and Spring richclient. I'm not sure I like the idea of manipulating Glazed List source code at build time to accomplish that integration. Would this mean that in order to use Glazed Lists with Spring I would use one package name (org.springframework.richclient.list) and outside of Spring use another package name (ca.odell.glazedlists)? For example, would ca.odell.glazedlists.EventList be renamed to org.springframework.richclient.list.EventList?
    Maybe I'm misunderstanding your post... but it should be possible to accomplish tight Spring+Glazed List integration without touching glazed list source code, no? The only thing needed would be integration classes between Glazed Lists and Spring richclient constructs (like, for example, allowing Glazed Lists to be used in Spring-rich forms). I can see those classes going in a package like org.springframework.richclient.list - but such integration should not require code in Glazed Lists itself that is dependent on Spring. Spring itself is full of framework support for 3rd party APIs (Hibernate, for example). That support almost never requires modification on the part of the 3rd party. For example, Spring-rich currently has a table model that can present a list of JavaBeans (each bean is a row, and the bean's properties are columns). That table could be modified to use EventList instead of List, or even extend Glazed List's table model. Spring also provides the ability to sort a table by column. I could see value in Spring replacing such support (since it is not, in my opinion, as mature as Glazed Lists) with Glazed List version. However, none of these should require special modification of the Glazed List API itself.
    Again, I could be totally misunderstanding your post. Whatever the case, I look forward to seeing these two projects working together. :-)

    - Andy

    Comment


    • #3
      I don't think there is need for such a tight integration. Glazed lists can be used in any view/form/editor of spring rich.

      Comment


      • #4
        adepue makes a great point - tight integration with Glazed Lists does not need to use package names if necessary.

        But what I would really like to see is the Glazed Lists code being distributed with the Spring Rich Client. From my understanding, Spring Rich aspires to be a framework that integrates the best-of-breed for rich Swing apps.

        Now what is the 3rd party integration strategy?

        Comment


        • #5
          Jesse,

          We want to ship glazed list with Spring Rich, and integrate it into the rest of our framework: notably our control data binding, data filtering, and table frameworks. What we strive for is a simple, consistent programming model, under the covers wielding the strength of 3rdparty packages we integrate with.

          I just haven't had a chance to look at glazed list integration yet. I am quite keen on "officially" integrating your library.

          Keith

          Comment


          • #6
            Keith, that's exactly what I wanted to hear. Now how may I be of service?

            Cheers,
            Jesse

            Comment


            • #7
              Jesse,

              You could look at the areas Keith mentioned, and look what could (or should) be changed to improve them using Glazed Lists.

              Peter

              Comment


              • #8
                The first thing for me to do is check the latest glazed list binary into cvs under our lib directory, and add it to our development project file. I can do that later today.

                I think our next goal should be to work together to build some clear use cases for glazed list integration, and proceed to implement them and ilustrate them in action in our Petclinic sample / test cases. Just throwing out one off the top of my head: an asynchronously updating "pet visit" view with a filter applied might be a good case. Jesse, if you could take the lead on this that would be great. In general, Petclinic in samples/src/petclinic is the best way to get up to speed on how our framework works.

                Some design goals I can think of:
                1. We want to use our rules API (constraints) for defining filters - it's flexible, consistent, and rules are kept independent of presentation. I'd take a look at some of the methods in SwingFormModel that can create an existing, bound filtered list (search for the Constraint interface). We'd want similiar factory methods that delegate under the covers to a glazed list implementation, and adapters that bridge between our filters and what glazed list expects.

                2. Thread safety may become an issue. Right now we assume all changes to backing domain objects and/or lists are done in the event dispatching thread: no provision exists for objects that may be updated in an asynch thread.

                Comment


                • #9
                  Sounds good! A rules-based filter is an ideal candidate for a first task.

                  As for thread-safety, Glazed Lists rolls its own thread-safety in very simple way:
                  • Every EventList has a read/write lock
                  • EventLists like SortedList and FilterList that have a source EventList share the source's read/write lock
                  • Users of EventLists must manually acquire and release this lock if they are to share lists between threads
                  • Model listeners like EventTableModel and EventListModel listen to their source list via a proxy. This proxy captures events and fires them back on the event dispatch thread. Therefore lists can be updated from any source thread but the GUI will always be updated with the event dispatch thread.

                  I'm not sure how this approach could be used in the rest of Spring RCP, but it has worked very well for Glazed Lists.

                  Comment


                  • #10
                    Excellent.

                    I've checked in the latest glazedlist .jar.

                    I also created a "lib/src" directory in the project for source code, and added the source locations to the eclipse .project file for convenient source access.

                    Keith

                    Comment


                    • #11
                      Awesome stuff!

                      I am really looking forward to GlazedLists being integrated in Spring Rich. I am currently using GlazedLists extensively in a project and would like to migrate the whole thing over to Spring RCP. I am already using Spring on the server side.

                      Steve

                      Comment


                      • #12
                        There's nothing stopping you from using spring rich with glazed lists. As I stated before, the glazed lists api can be used when constructing views and forms.

                        On migrating legacy apps to spring-rich there's an interesting thread:
                        http://forum.springframework.org/showthread.php?t=11516

                        Hope this helps,

                        Peter
                        Last edited by robyn; May 14th, 2006, 05:11 PM.

                        Comment


                        • #13
                          I created a ListSelectionDialog that uses GlazedLists. It's in the sandbox area of the cvs.

                          Peter

                          Comment

                          Working...
                          X