[learn_smartgwt]

Oh, was your expectation that every time the server is contacted for data loading, all DataSource definitions are reloaded?

Yes. That's what i am expecting from API. Below is what's written in your java doc.

"The framework will call the getDataSource method of registered DynamicDSGenerators whenever it needs to obtain a DataSource, giving user code a means of generating DataSource definitions at runtime, rather than (or as well as) providing them as .ds.xml files in the filesystem."


And if that's not the intended behavior then i would say it's a little disconnect in design.

I mean in case where i need to load data source definition once then
* I would use .ds.xml file for static ones
* and can use jsp for dynamic generated data sources which would load once per user per SESSION

Hence I would not need this API. But if we look at the beauty of this API is - it ask for updated data source definition per user REQUEST and provide opportunity to developer to modify data source definition per user request (NOT just per user session).

If i would take your argument that this API is designed to load data source once then why would it call DSGeneratoer per request? It call this method at application start up and should never ever call it but it does.
Also, why would this API require datasource id and DSRequest as parameter? My assumption is your awesome architect designed it to provide us an opportunity to modify data source defination per request.

I think API design is right. Either I am missing something on how to use it at client side or there is an bug in DataSource.get() method.

Having this API in 2.4; i think updated DataSource.get() method should always first check with server for updated datasource defination and if server returns null then it should look into locally loaded data sources and if not found then should throw null pointer exception. Isn't it?

And DataSource.load() won't help us as it does the same think what DataSourceLoader does at bootstrap. It doesn't take request as parameter and it designed to lazy load datasources (may be to boot application load time if you have too many datasources to start with ).

Ya! an alternative to DynamicDSGenerator API could be to provide one more DataSource.load() method which will take request as an argument (along with datasource id, and properties). DynamicDSGenerator forces every data source lookup to go through with server but adding this load method will give the control to API users to when to load updated data source definition and when to use existing one.

[Isomorphic]

The docs are correct and the behavior is as designed. This is a *server* API and every server-side call to retrieve a DataSource goes through this API.

It would be an extremely bad idea to have every client-side call to DataSource.get() initiate a network connection to load DataSource definitions. By design, this only happens if you ask for it (the forceReload parameter of DataSource.load()).

The DSRequest parameter is there for access to servlet context, for HTTP session access, caching of intermediate results, and similar reasons. It is absolutely not the intent of this API to regenerate DataSources per request, in fact, the docs go into significant depth on DataSource pooling.

Once again, if you have an actual use case you're trying to implement and you need advice on what APIs to use, explain that use case in a new thread - and explain it with reference to an actual application problem that you would like to solve, and not in terms of this particular API.

[learn_smartgwt]

I am not supporting the idea to support that behavior in DataSource.get(). I was saying that's that's how it should behave based on new API understanding.

But i would love to see a DataSource.load() method should also take Criteria as an argument. That would be very helpful in many cases.

Thanks for advise. I will cerate the new thread will post my use case.

Thanks again,