Announcement

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

    Enhancing DataSource definitions with custom attributes

    Along with what is already included in the DataSources, I would like to store some more declarative information for my client side about how do display/edit various things. If possible, in order to avoid fragmentation, I would like to embed this information inside the DS XML files.

    Therefore, I started to add custom attributes to my DataSource XML files. Upon loading these DataSources, the custom attributes are automatically translated to JS, and sent over to the client just fine. Of course the DataSource and DataSourceField classes at the client side do not understand the custom attributes, but I created subclasses that do, and act upon them.

    Will this break anything? Is this in line with the current design of the system, or is this stupid?

    #2
    This is generally fine. However consider the SimpleType API for creating re-usable field types across multiple DataSources for defining how values are displayed and edited.

    Comment


      #3
      Originally posted by Isomorphic
      [...] consider the SimpleType API for creating re-usable field types across multiple DataSources for defining how values are displayed and edited.
      Thank you for pointing this out, but my additions typically touch more than a single field, so I need more than that.

      I am generally satisfied with the current method. I need one more thing: how can I trigger the "autoDeriveSchema" mechanism from the server side? (To reduce redundancy, I prefer not to repeat the fields of the SQL table in the DS XML, unless I have to do something special with them. But when my DS enhancement code runs, it would be nice to have access to the fields that are not declared in the DS, but derived from the SQL.)

      Thank you for your help, again.

      Comment


        #4
        Take a look at the BatchDataSourceGenerator (you might need to get the Enterprise eval if you don't have it). In there we show a process for getting the SQL metadata and modifying it and producing a DataSource from it.

        But note this is Enterprise license functionality. You can always go to JDBC directly.

        Comment


          #5
          I starged using com.isomorphic.datasource.DataSourceManager.get(), which does exactly what I need. (Builds up the DS definition, based on the table in the DB and the DS XML.)

          However, this is a non-documented internal API. (I found it while looking at the usual DS loading mechanism.)

          Is this OK?

          Comment


            #6
            As with anything undocumented, that API is subject to change without notice, but it's likely that similar behavior will exist as a documented API in the future.

            Comment


              #7
              Originally posted by csillag
              I starged using com.isomorphic.datasource.DataSourceManager.get(), which does exactly what I need. (Builds up the DS definition, based on the table in the DB and the DS XML.)

              However, this is a non-documented internal API. (I found it while looking at the usual DS loading mechanism.)

              Is this OK?
              For the record: I have given up on this approach, since I have run into too many obstacles. (Things missing from field definitions, field definitions duplicated, order messed up, etc.) I guess it all makes perfect sense it some undocumented way, but I can not expect you to explain internal undocumented APIs...

              Now I wait for the first client to connect, then use the client-side APIs for analyzing DataSources, send the information back to the server side, and then do my custom DataSource enchancement.

              I am aware that involving the client in the process is totally unnecessary from the technical point of view, but this way I do not have to use undocumented APIs, so I am relatively safe.

              Comment


                #8
                Originally posted by Isomorphic
                ... However consider the SimpleType API for creating re-usable field types across multiple DataSources for defining how values are displayed and edited.
                I searched the SmartGWT and SmartGWT EE showcases for examples for SimpleType usage, but could not find anything.

                After taking a look at the relevant Javadoc, I am getting the impression that the Java wrapper of the SimpleType api is ... not quite complete.

                Specifically, I can not find the method to specify the formatter to use.

                How do I do this? Even if there if a direct Java wrapper is not available, could you please show me an example using JSNI or JSOHelper.eval() ?

                Or if it's not possible to do this on Type level, it's also OK if I can do this on the ListGridField level. How can I replace the default renderer?

                (I am already doing a bunch of modifications based on various in-house metadata declarations, so this would not hurt.)

                Thank you very much!
                Last edited by csillag; 19 Feb 2010, 16:51.

                Comment


                  #9
                  up.

                  (Sorry.)

                  Comment

                  Working...
                  X