Announcement

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

    Need to pass additional info from FilterBuilder to DataSource fetch()

    I currently have a spring-loaded set of DataSources that are wired into server-side Hibernate models.

    This is all setup correctly and working like a charm. I have a custom fetch() operation that calls DAO's that are defined and re-used elsewhere in my application.

    Basically, I need the ability to pass custom parameters from the client to the executeFetch(...) operation on the server.

    I have tried every way possible to attach parameters to the client-side DSRequest, but from what I have found through researching your javadocs is that this practice is actively opposed, (referred to as 'smuggling data') due to technical implications of caching custom sets of data.

    (Side question - why can't you just add in a map of custom parameters that are required to be serializable and which are transformed into a same-named map on the server-side com.isomorphic.datasource.DSRequest that is passed into executeFetch? SmartGWT could ignore these parameters for caching or other purposes entirely and this would solve my problem.)

    So is there a way to do this? If so, how the heck do you do it?

    I thought I might be on the right track with creating an overridden client-side DataSource and overriding the transformRequest method, but that didn't work. I'm using DataSource.get("data_source_id"); to get an instance of the client-side DataSource, but I had no idea how to get that to be cast to an instance of my CustomDataSource object - maybe that is my problem?

    Also, side-note, why does the server-side DSResponse have a map to which you can call setParameter(...), but the client-side DSResponse is getAttribute()? The difference in wording isn't documented, and is very confusing.

    #2
    There's no way to "ignore" extra parameters for caching purposes. Either the extra parameters change the results or they don't. If they change the results and we don't know about it, that will break caching.

    dsRequest.operationId is the designed-in way to create a variant of a fetch operation that has different results from the normal fetch operation (for example, additional fields, implicitly removed records). If this is the kind of thing you're doing, you might be able to take the parameters you are trying to pass and combine then into an operationId.

    Otherwise, anything that affects the results *must* be represented as criteria - because that's what it actually is.

    The server-side API for adding additional properties to the request is setProperty, not setParameter. getAttribute() client-side is a method that exists universally (also on things like widgets) for getting and setting attributes and a getProperty() method would be redundant with that, so we didn't add such a method.

    Comment


      #3
      It would be ideal if I could actually filter on the parameter that I want to filter on, but unfortunately, it's a datatype that is unsupported by SmartGWT.

      What I need to use to filter the data is a Geometry object (JTS), but when trying to pass the Geometry to the client, it causes JSTranslator to fail with infinite recursion. See more detail in this thread I posted here:

      http://forums.smartclient.com/showthread.php?t=26119

      I will try the operationId approach and see if I can make that work.

      Thanks!

      Comment


        #4
        You should pass it as criteria (because it is criteria). Just turn it into a String and add it as a Criterion, and make sure you turn off client-side filtering (can't be done in this case obviously).

        Then on the server you can use dsRequest.getAdvancedCriteria() and get rid of the Criterion before the Server Framework tries to interpret it.

        Comment

        Working...
        X