Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Design strategy for multi-entity ListGrid

    I'm moving forward with SmartGWT Power 3.0 and have begun to develop some applications with it. As this is such a big product, with many alternatives for working with a database via different types of DataSources, I'm looking for some guidance, or "best practice" advice...

    I ultimately want to use a single ListGrid (or possibly a Datacube) where each ListGrid row will contain values from several database tables, but not necessarily in a traditional one-to-one join. Furthermore, some of the values in the row will be computationally derived on the fly from other values, and the table will be editable, such that if the user changes a value in one cell, other cell values will change. In other words, it's a situation far more complicated than a simple ListGrid representation of a single database table where each of the table columns is mapped to a single column in the ListGrid.

    I want to use Hibernate Envers for persistence and versioning.

    Given all of the above, I have three questions:

    1. Is there a particular example in the demos that I should study?
    2. Is there a particular type of DataSource that I should be focused on?
    3. I know that the ListGrid ultimately needs to use a single DataSource as its "backing store" (ListGrid.setDataSource). Should I pursue a strategy where that DataSource is derived on the fly from the data held in other DataSources, where the latter DataSources are the ones that interact with the database?

    #2
    In the QuickStart Guide, SQLDataSource is what we unequivocally recommend. This is especially true since you are talking about results that are not 1-to-1 with tables and where you have calculated results - ORM makes this much harder, whereas SQLDataSource lets you use SQL directory where needed, without having to re-invent the parts of the query that still apply.

    So, we still recommend this despite you mentioning being interested in Hibernate Envers.

    The most applicable single example is SQL -> Dynamic Reporting.

    Anything you don't do in SQL you should do in Java logic in a DMI, for example, calculations that you don't do in SQL, or combining multiple tables in a way that is not a join.

    If the DataSource *definition* is dynamic (not just the results - the list of fields) look at DataSource.addDynamicDSGenerator().

    Comment


      #3
      Thanks for the reply... I have no problem ditching Envers, considering I haven't started using it, although it makes the versioning problem look seductively easy. I've "rolled my own" in that regard for the last 15 years or so, and it's a pain, hence my quest for something more industry standard and off-the-shelf.

      Again, in search of best practices here, I'm wondering how to best use your product. I was hoping to not integrate my proprietary scheme into something like SQLDataSource, and go in a more industry standard direction, so on the versioning problem, I'll again ask you for your recommended approach. But I'll certainly spend more time pursuing SQLDataSource.

      I've already done a bunch of dynamic DataSource stuff, but have achieved that via dynamically controlling the fields put into the Records, and it's worked very well so far.

      PLEASE don't misunderstand me here... I've read through your QuickStart guide several times, and will probably read it several more times. It's one of the half dozen or so Isomorphic web pages and/or PDF files I have open and am bouncing between on two 28" monitors, all the while trying to keep the proper context and acquire the big picture in my head. "addDynamicDSGenerator", for example, is not mentioned there, and yes, it certainly is mentioned in the JavaDoc, but I've thus far had no reason to know or guess why I should want to explore that method.

      I respectfully chime in with the frustration of @dejan and @evanross as expressed here http://forums.smartclient.com/showthread.php?p=82388

      Comment


        #4
        Versioning tables is particularly easy to accomplish in SmartGWT - see the QuickStart guide sections on using DMI for business logic, there is a specific example of storing an update log to a related DataSource.

        We can't tell if you're reiterating your best practices question or not, but once again, best practice is to use SQLDataSource. There's a very in-depth discussion of this here.

        Of course, not every method is in the QuickStart, that's why it's the "QuickStart" and not the reference. To find other relevant methods, use search.

        If you find something poorly documented, suggest what's missing, or where it could have been better placed - you have enough experience, it would seem, to know the difference between actionable feedback and something too vague to address. There's not a lot we can do about a complaint that you have too many windows open, except to suggest you go through more linearly: QuickStart -> reference topics it refers to -> examples they in turn refer to.

        Comment

        Working...
        X