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().
Announcement
Collapse
No announcement yet.
X
-
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
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
Leave a comment:
-
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.
Leave a comment:
-
Hi Isomorphic,
I do have a question w.r.t. to this:
Originally posted by Blama View PosthttpServletRequest.setAttribute() in a DataSourceLoader-subclass.doGet() for automatic GUI changes because of canView:false.
Code: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); } }
Code:<servlet> <servlet-name>DataSourceLoader</servlet-name> <servlet-class>com.lmscompany.lms.server.LMSDataSourceLoader</servlet-class> </servlet>
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
Leave a comment:
-
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.
Leave a comment:
-
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
Leave a comment:
-
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.
Leave a comment:
-
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
Leave a comment:
-
Hi Isomorphic,
as followup: It is working as expected with handleDSRequest().
Thank you & Best regards
Blama
Leave a comment:
-
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.Last edited by Isomorphic; 10 Apr 2018, 09:36.
Leave a comment:
-
Hi Isomorphic,
that's why I was asking. I expected it should be handleDSRequest(), but that does not work - breakpoint in T_CONFIG.getVisible() not hit on fetch, diet- and information-fields missing in SQL.
not working MyIDACall.java:
Code:package com.smartgwt.sample.server.listener; import com.isomorphic.datasource.DSRequest; import com.isomorphic.datasource.DSResponse; import com.isomorphic.rpc.RPCManager; import com.isomorphic.servlet.IDACall; import com.isomorphic.servlet.RequestContext; public class MyIDACall extends IDACall { private static final long serialVersionUID = -2103887355803373948L; @Override public DSResponse handleDSRequest(DSRequest arg0, RPCManager arg1, RequestContext arg2) throws Exception { arg0.addToTemplateContext("t_config", T_CONFIG.getInstance()); // breakpoint hit, if set return super.handleDSRequest(arg0, arg1, arg2); } /* @Override public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // request.setAttribute("t_config", T_CONFIG.getInstance()); // breakpoint hit, if set super.doGet(request, response); } @Override public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setAttribute("t_config", T_CONFIG.getInstance()); // breakpoint hit, if set super.doPost(request, response); } */ }
Blama
Leave a comment:
-
There are obscure cases where doGet() would also need to be overridden. However, there's no need to know this, as handleDSRequest() would also work.
Leave a comment:
-
Hi Isomorphic,
this is working like this. I get this SQL (expected, with diet and without information) and on FETCH my breakpoint in T_CONFIG.getVisible() is hit twice (expected). I do have a question though (see below).
Code:SELECT LIMIT 0 75 animals.commonName, animals.scientificName, animals.lifeSpan, animals.status, animals.diet, animals.picture FROM animals WHERE ('1'='1')
Code:package com.smartgwt.sample.server.listener; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import com.isomorphic.servlet.IDACall; public class MyIDACall extends IDACall { private static final long serialVersionUID = -2103887355803373948L; /* @Override public DSResponse handleDSRequest(DSRequest arg0, RPCManager arg1, RequestContext arg2) throws Exception { // arg0.addToTemplateContext("t_config", T_CONFIG.getInstance()); // breakpoint hit, if set return super.handleDSRequest(arg0, arg1, arg2); } @Override public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // request.setAttribute("t_config", T_CONFIG.getInstance()); // breakpoint hit, if set super.doGet(request, response); } */ @Override public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { request.setAttribute("t_config", T_CONFIG.getInstance()); // breakpoint hit, if set super.doPost(request, response); } }
Can you add this to the documentation of viewRequires? I'm pretty sure noone could figure this out on his or her own currently.
Best regards
Blama
Leave a comment:
-
Declarative Security checks are actually run before DMI, well before DataSource.execute(). Sorry, this was obvious in retrospect. This means you'll need to inject custom context at the servlet level, with an override of IDACall.
Leave a comment:
-
Originally posted by Isomorphic View Postexecute(), executeFetch() etc are all documented in the superclass (as they should be - they apply across all DataSource types, not just SQLDataSource).
Then it's only explaning what most likely will be the necessary steps when one wants to use viewRequires.
Originally posted by Isomorphic View PostWe'll see if we can reproduce the issue you're claiming.
Best regards,
Blama
Leave a comment:
Leave a comment: