Announcement

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

    DataSource to call DMI

    Hi,

    I was wondering if there is a way to call a DMI using the EE version without creating the datasource definition in XML?

    I see setURL but no methods that would correspond to the serverObject property in the XML.

    Also, will the com.smartgwt.client.data.DataSource and com.isomorphic.datasource.DataSource be somehow shared in the future?

    Thanks,
    Eric

    #2
    The DataSource XML file serves a security purpose in that is tells the server that a given DMI method is allowed to be called. Aside from being indispensable for that reason, it's also the place where all settings related to server behaviors like <customSQL>, operationBinding.criteria, operationBinding.values, etc are specified. This is also why there's no client-side setter for these properties, that would be insecure. Why is also why the classes are distinct.

    If you're worried about getting a DataSource XML file quickly, use the generator in Visual Builder or the Batch DataSource Generator. Likewise look at the code for the BatchDSGenerator for examples of dynamically generating DataSources from Java Beans or other metadata.

    Comment


      #3
      No, it was mostly from a maintenance concern. I'm sure the BatchDSGenerator will help in the future for larger projects.

      Thanks.

      Comment


        #4
        Isomorphic,

        I thought about this some more and the datasource definition gets loaded from the server and translated for the client so the definition is already in the client. So I guess I am not seeing the security aspect.

        Wouldn't it be as good to require that the SmartClient server be required to load the data source as a Java class and then when the client calls the server, the server can make sure any DMI calls are valid because the server has access to the Datasource definition as well? Also, it seems that feature that allow for extending the datasource so the server can make special validations would still work with this model.

        I'm probably missing something but it would be preferable to not load all the DS xml files from the server on initial load for bandwidth and startup speed. They be loaded on demand (translated from the Java class) from the server when the client needs the datasource Datasource.get(name) similar to the xml definition. This would allow it to be Java and server based and make maintenance/refactoring easier. If they were put in the GWT server directory, couldn't the GWT compiler do the translation?

        Thank-you for your consideration and time.

        Comment


          #5
          The security aspect is that the presence of the .ds.xml file on disk is what allows calls to Java methods, SQL queries, or whatever the DataSource indicates should be done. In the absence of that file, calls are rejected.

          Separately, from a data exposure standpoint, although the DataSource is output to the browser, settings that are purely server-related (such as the <serverObject> block) are omitted from what the client sees.

          Not really sure where you're going with these other suggestions.. the server already loads the DataSource definition from the XML file and creates an instance of a Java class from it, and that class is customizable. What problem is your suggestion meant to solve?

          Comment


            #6
            Hi,

            Sorry for the delayed repsonse.

            I guess I would like to see the server side datasources defined in Java. Defining the Datasources in XML especially without a DTD/schema is a tougher to do especially when refactoring occurs. One of the initial advantages to GWT is the ability to refactor and have compile time feedback for errors etc.

            So avoiding the Strings in the code that have to match up such as the datasource ID, JSP, xml file etc. is desirable. I know that the Maps and reflection that occurs will never completely remove these string associations but minimization is a goal.

            If instead of referencing the datasource in the html or JSP such as

            Code:
            <script type="text/javascript" src="../shared/ds/profitCenter.ds.jsp"></script>
            the applicable code from the server could be added to the DOM dynamically when a call is made to

            Code:
            DataSource ds = DataSource.getDataSource("profitCenter");
            this would be great. I don't know if this is possible or not but this is what I was thinking. I appreciate your consideration.

            Thanks,
            Eric

            Comment


              #7
              Hi Eric,

              The best way to minimize maintenance is not to write DataSources at all, in either Java or XML, but generate them. That's what the tools are geared around. If you choose to write Java beans for every entity, just use the DataSource generator to generate DataSources from them, on the fly or periodically.

              If you want to control every aspect of DataSource behavior from Java, make up some new Java annotations (we'll eventually provide standard ones) and add a few lines to the generator to use them (there's already sample code in the generator). If you come up with such a format along with enhancements to the generator, it would be great if you posted about them or contributed them.

              However if there is no existing source of metadata and you're choosing between a Java or XML representation as the authoritative representation, an XML representation is more concise and declarative, many more people can understand XML than Java, and changing an XML file has a much shorter development cycle time (in SmartClient, just reload the page) than changing Java files and compiling.

              All that said, we will eventually provide a way to write a server-side DataSource in pure Java for those who prefer to write 4x the code so long as it's all Java :)

              Comment


                #8
                Hi,

                Don't mean to be a pest but when you are relatively new your observations are relatively unbiased. The GWT makes things so much easier that it makes the inconveniences really stand out although there are very few.

                Certainly, Java is not the most compact format. I will investigate the generation aspect.

                It sounds like eventually the requirement to include the datasource in the client HTML will go away as well and will be on demand via the DataSource.get("dsName") call in the client. This would also reduce the initial download footprint as datasource code would be downloaded on demand.

                Do you have a DataSource DTD/schema or a example with all the options specified so I could generate one? This would make hand editing the XML in Eclipse or other XML saavy tools much easier. Easier learning is the major goal for this request.

                I guess I don't want much do I? Thanks for listening and responding to my wish list.

                :)

                Comment


                  #9
                  When you're new, it's also easy to focus on the wrong thing. Let us know once you've actually tried out SQL Templating and Transaction Chaining whether you think defining a DataSource in Java is a priority, and whether you think it actually simplifies things and speeds development.

                  On DataSource loading, we're building a servlet that will make it possible to just put this in your bootstrap .html:

                  Code:
                  <script src="../isomorphic/DataSourceLoader?dataSource=supplyItem,animals,employees"></script>
                  On demand really isn't worth it until you get to hundreds of DataSources (the files are too small). And at that point, you want to load them in batches that represent application modules, not individually.

                  Comment

                  Working...
                  X