[Isomorphic]

Sorry, you're correct that handleDSRequest() is too late, however there is still no need to worry about doGet or doPost or know anything about the encoding of the request, as APIs such as processRequest() or processRPCTransaction() are both early enough.

[Blama]

Hi Isomorphic,

as followup: It is working as expected with handleDSRequest().

Thank you & Best regards
Blama

[Blama]

For other finding this thread:

You need to inject the class with:

• httpServletRequest.setAttribute() in a IDACall-subclass.handleDSRequest() for SQLs
• httpServletRequest.setAttribute() in a DataSourceLoader-subclass.doGet() for automatic GUI changes because of canView:false.

The only thing not working as of today is that joins for not needed includeFrom fields are still being generated. This is not a security issue, but results in SQLs more complicated than necessary.

Isomorphic: If I understand correctly, the IDACall-subclass only affects incoming GUI requests. Therefore I also need this in my RESTHandler-subclass, correct? What about server initiated requests? Wouldn't it be better this this were in my SQLDataSource-subclass instead of IDACall and RESTHandler?

Best regards
Blama

[Isomorphic]

No, because there are multiple kinds of DataSources that can use Velocity, and because DMI and other kinda of business logic execute before DataSource-specific logic becomes involved.

[Blama]

OK, but doesn't that mean that requests that don't go through IDACall (=all server initiated requests) don't have that variable for viewRequires-calculation? Is this then just ignored and therefore true?

Best regards
Blama

[Isomorphic]

As written your requires expression would crash, and be ignored. You could write it differently so that it doesn't crash, and does whatever is the right thing for server-initiated requests.

[Blama]

Hi Isomorphic,

I do have a question w.r.t. to this:

httpServletRequest.setAttribute() in a DataSourceLoader-subclass.doGet() for automatic GUI changes because of canView:false.

If I have a viewRequires="$t_config.getVisible("diet", $servletRequest)" with a variable I need to inject like the one here, I do need to inject it in a DataSourceLoader subclass

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.isomorphic.servlet.DataSourceLoader;
import com.lmscompany.lms.server.worker.T_SETTINGS;

public class MyDataSourceLoader extends DataSourceLoader {
    private static final long serialVersionUID = 616663945156810788L;

    @Override
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        request.setAttribute("[I]t_config[/I]", T_CONFIG.getInstance());
        super.doGet(request, response);
    }
}

I also need to register MyDataSourceLoader like this in web.xml:

    <servlet>
        <servlet-name>DataSourceLoader</servlet-name>
        <servlet-class>com.lmscompany.lms.server.LMSDataSourceLoader</servlet-class>
    </servlet>

Now I know that you load and perhaps cache DataSource yourself quite often in your server side processing.
Does this internal "get DataSource" also use the class (=the servlet) from web.xml?
Somehow I can't imagine it is that way, as there is not always a HTTP request and therefore I think you'll do this somehow differently.
Can I (and must I) also inject my Velocity variables there?

Thank you & Best regards
Blama

[Isomorphic]

Can't quite figure out the question here, but if we have it right, no, code in a DataSourceLoader servlet will not be invoked if processing starts from IDACall (or a subclass).

If you've written your DataSource so that it requires certain variables to be present when created, then you will need to make sure those variables are defined in all the ways you might invoke it, including in standalone (non-servlet-triggered) usage if you are using the DataSource that way too.

[Blama]

Hi Isomorphic,

OK, understood.
So for me, DataSourceLoader is just the way to transport the .ds.xml config relevant on the client side for the logged in user to the browser.

DataSourceLoader and IDACall and RESTHandler requests:

• httpServletRequest.setAttribute() in a DataSourceLoader-subclass.doGet() for automatic GUI changes because of canView:false.
• httpServletRequest.setAttribute() in a IDACall-subclass.handleDSRequest() for SQLs created for an incoming IDACall-request
• httpServletRequest.setAttribute() in a RESTHandler-subclass.handleDSRequest() for SQLs created for an incoming RESTHandler-request

What about all other cases, like the one you mention in #23. I think this applies to every request created in DMI with new DSRequest(), no matter if I use the incoming RPCManager (for requests additional to an incoming IDACall request) or created RequestContext.instance() for server initiated requests (e.g. servlet hit from cron job).

You write "then you will need to make sure those variables are defined in all the ways you might invoke it". How to do that? I have the strong feeling this is somehow to be done in SQLDataSource-subclass, but in #19 you write this is too late. Do I need it additionally there?


Additional question for better debugging: Is there some way for me to get the DataSource, it's fields etc you are using to generate an SQL?
So this means the "XML" (most likely not possible) or at least the DataSource instance after Dynamic DataSource modification and after Velocity declarative security evaluation, so that I can use getters on it? Can/Should I put a breakpoint in SQLDataSouce.execute() for this?
Or just DataSourceManager.get()? But how to inject then velocity-variables then?

Thank you & Best regards
Blama

[Isomorphic]

If those are the ways you invoke DataSource operations, then you are covered.

As we explained, there is also Standalone Usage. In that case, there isn't even a servlet, so your DataSource cannot work in that mode. If you are not using that mode, there's no reason to care.

Second question: the XML is on disk and/or returned from your own DataSourceGenerator code, so you already have that. Then, as far as the created DataSource instance, there are server-side APIs such as DataSource.getFieldNames() / getField().