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

    Custom Join Clause for DataSourceField

    Is it possible to override the ansi join clause on a specific datasource field? Something similar to the customSelectExpression, was interested if there was any way to do this for the generated join clause.

    There are settings controlling how the default join is generated, but you haven't said how you want the join to differ from the default, so we are kind of "shooting blind" in responding to the question as phrased.

    Here are all of the relevant settings for controlling how joins are generated:

    DataSourceField.joinType: specify inner vs outer join

    DataSource.useAnsiJoins: moves all joins to the table clause, in the ANSI style
    related, OperationBinding-specific setting: OperationBinding.includeAnsiJoinsInTableClause

    Then, here is a list of all the different clauses that you can override:


      We were just looking to see if this could be done for 1 field instead of in each binding. The use case is adding an additional condition to the join (for query optimization):

      For example:

      SELECT * FROM t1
      JOIN t2 ON =
      WHERE ...

      SELECT * FROM t1
      JOIN t2 ON = AND t2.value='some other condition'
      WHERE ...
      The datasource has probably 10 other joins in it for related data, so overriding the ansi join clause becomes a lot of work, and on each binding. We were just looking to see if that clause could be overridden for a specific field. We solved our issue another way, but just wanted to ask to see if there was another feature we could use for this.

      One other question, is this system reference site new: I like this view, is it supposed to replace the regular javadoc pages?


        Hi aderosso,

        I can see the benefit of the joinClause override for non-ANSI-joins. That would have to be defined on a DataSourceField level then instead of DataSource level I assume.

        Regarding the docs: I totally agree. I'm using SmartGWT as well but started using the SmartClient Reference docs for client side development as well because the search and filtering are really good. I even suggested what you asked about in #5 and #6 here. But I think the current JS docs are easy enough to use and apply to SmartGWT, so a SmartGWT Reference docs application is not necessary, if it is complicated to create for Isomorphic, I'd say. These docs have been around forever.

        Best regards


          Blama is correct that those are SmartClient docs. That viewer actually pre-dates the existence of SmartGWT as a product.

          Honestly, the more JavaScript-centric developers on our team have repeatedly expressed astonishment that Java developers have tolerated such an awful documentation format for so many years.

          You can use the SmartClient Reference as a way to navigate the SmartGWT API so long as you understand the correspondence between APIs, for example, that things are properties in SmartClient, but exist as separate getters and setters in SmartGWT.

          Note that the documentation differs in some spots. You can actually see this in the source code, if you download it: there are <smartgwt> and <smartclient> tags in the JSDoc.

          The vast majority of the SmartGWT API is actually generated from our documentation, but there are a number of places where we had to hand-code things because of Java/JavaScript differences. It's because of these hand-coded areas that we can't quickly build a SmartGWT version of the SmartClient Reference viewer.

          We often use Google to find things in JavaDoc. If you add "javadoc" as a search term, it will usually return just JavaDoc results. You can also use the "site:" prefix to restrict results to just

          However, if you discover good tools for navigating & searching JavaDoc (aside from Google), you can share them here, and others will benefit.


            With all that about the documentation in SmartClient and SmartGWT, we forgot to come back to the question about customizing a join!

            Yes, we could add a feature where on an includeFrom field you could specify something like "customJoinSQL" and it would be a Velocity expression with "$joinClause" available to get the auto-generated join, so you could just add SQL from there.

            You have the Hourly Support plan, so you can repurpose hours there to Feature Sponsorship if you like. This would be in the neighborhood of 12 hours (remember we need to write the docs, build automated tests, etc). Let us know if you'd like to do this.


              That would be great, we would love to sponsor this feature.


                Great! It won't be started for a while (2-3 weeks) as we are in the middle of another large sponsorship (which we will announce on the blog). But we'll keep you posted.


                  Sounds good, thank you!