Dynamically generating DataSources ( using addDynamicDSGenerator )

[ewilliams]

I'm trying to use the addDynamicDSGenerator API to generate a dynamic set of fields for a datasource a grid is attached to.

I was able to get the addDynamicDSGenerator() to load/register a new DynamicDSGenerator successfully by extending the DataSourceLoader class and having it add/register the generator following the instantiation of DataSourceLoader (super()).

In my client I am calling DataSource.load("myPrefix_mySuffix") and I see the DynamicDSGenerators's getDataSource() method being called.

My question is how can I get client context information to the DynamicDSGenerator's getDataSource() call?

I need to be able to filter/adjust the fields created for a DataSource using by a set of context-value pairs and a company ID. I was hoping to be able to somehow inject this information in the DSRequest which is a parameter to getDataSource() but am not sure how to do that.

I only see the getDataSource() being called when i call DataSource.load(myPrefix_mySuffix) in the client, calls to DataSource.get(myPrefix_mySuffix) do not trigger the call to getDataSource() for me. Should it?



Be sure your post includes:

1.SmartClient Version: v8.3p_2013-02-08/PowerEdition Deployment (built 2013-02-08)

2. not browser specific

3. Not a failing request issue.



6. sample code if applicable

Posts with incomplete information are much more likely to be ignored.

[Isomorphic]

Whatever context you need to generate the DataSource should be embedded into the DataSource ID in some way. The DataSource ID is what's used to uniquely identify the DataSource for pooling and other purposes, not the DSRequest.

[ewilliams]

So I would build an ID string to represent a Datasource that corresponds to this context. There could be a number of context key-value pairs, maybe 20 or 30..

Is there a length limit to the ID string?

[Isomorphic]

No limit that you could reasonably hit - URLs in general, for example, are limited to 4K, so think about this when using the DataSourceLoader Servlet from a <script> tag.

[ewilliams]

Ok, Thanks Isomorphic..

[claudiobosticco]

No limit that you could reasonably hit - URLs in general, for example, are limited to 4K, so think about this when using the DataSourceLoader Servlet from a <script> tag.

Hello, to proactively avoid issues of this kind, would it be supported to implement an extension of the DataSourceLoader in order to retrieve the list of DataSource IDs on the server side?

[Isomorphic]

We haven't currently documented a way to subclass DataSourceLoader and hardcode the list of DataSources.

However, if instead of using a <script> tag, you call isc.DataSource.load(), that's an HTTP POST, so you won't hit this issue.

You can also have separate <script> tags, of course.

[claudiobosticco]

Hi, so doing something like this can't be considered safe?

public class CustomDataSourceLoader extends DataSourceLoader {

    private static final String DATASOURCE_IDS = "foo,bar,foobar";

    @Override
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        request = new HttpServletRequestWrapper(request) {
            @Override
            public String getParameter(String name) {
                if ("dataSource".equals(name)) {
                    return DATASOURCE_IDS;
                }
                return super.getParameter(name);
            }
        };
        super.doGet(request, response);
    }
}

[Isomorphic]

We considered mentioning this approach and decided not to, because, if the modified parameter exceeds 4k., the servlet engine might reject it.

It's the kind of thing that an overzealous Java programmer would do, and it could easily differ across different servlet engines, or be the kind of thing that breaks mysteriously when you install a newer version of the servlet engine.

However, outside of the risk of a servlet engine deciding the modified request is invalid, yes, this is an approach that our software supports :)

[claudiobosticco]

Thank you for the heads-up.
I wasn't aware there could be limits when using HttpServletRequestWrapper. On Tomcat 8.5, I haven't found any warnings or documentation suggesting this, and all the configuration parameters I’ve seen seem to apply to the HTTP input itself - not to server-side manipulations like wrapping the request.

Out of curiosity, have you come across actual limits of this kind on more recent versions of Tomcat or on other servlet containers?

[Isomorphic]

No, we haven't seen any actual limits. It simply that our codebase is littered with workarounds for situations where Java developers threw Exceptions out of sheer pedantry: the functionality would have worked but they broke it via overzealous validation.

This is the kind of thing where we can imagine that sometime in the future, someone is going to add a check for an overlong URL and throw an Exception.

[claudiobosticco]

Thanks, I understand your point of view better now.
I must admit, I'm not a big fan of that kind of overzealous validation either.
I'll carefully consider whether it's worth taking the risk in my case, and if so, how I might safeguard against potential issues.